Ajout de références à ASP MVC Page Moteur de compilation

J'ai écrit une solution de plug-in pour les applications ASP MVC sur la base des conseils trouvés sur ce site, cependant, j'ai atteint un barrage routier et j'apprécierais de l'aide. Sans aller trop loin dans le fonctionnement du plug-in, il charge le contrôleur avec succès et trouve sa vue appropriée - le problème est que la vue ne compile pas car elle ne peut pas résoudre toutes les références du plugin (la DLL du plugin contient des références à d'autres DLL que l'application hôte ne connaît pas). J'utilise AssemblyResolve sur CurrentDomain mais qui n'est pas appelé lorsque le BuildManager par défaut compile la vue, mais prend la liste des assemblys de la section web.config. Si j'ajoute tous les fichiers plugin au GAC et ajoute une référence dans cette section - cela fonctionne bien. Mais cela va à l'encontre du but d'avoir un système de plugin si je dois changer web.config pour chaque plug-in.Ajout de références à ASP MVC Page Moteur de compilation

Une petite illustration pour expliquer la question: plugin.dll --references -> PluginServices.dll

URL http://mysite.com/some/index MVC application --load -> plugin.dll PASS

MVC application --load -> Plugin.SomeController PASS

MVC application --find -> Plugin \ Views \ some \ Index.aspx PASS

MVC application --compile -> Index.aspx FAIL (e e view utilise un type de PluginServices introuvable)

Existe-t-il un moyen d'ajouter dynamiquement des références à BuildManager afin que la compilation passe sans changer web.config?

Merci d'avance!

Source

2009-06-02 Gil

Encore une fois, la partie de chargement de la logique fonctionne bien et localiser aussi directement les points de vue, la seule partie qui ne fonctionne pas est la partie où je ne contrôle sur - qui est le rendu réel de la page. Mais j'ai réussi à le faire fonctionner. Ce que je devais faire est la suivante: 1) ont le plug-in DLL enregistré dans le GAC

2) ajouter d'une référence à la DLL dans le web.config de l'hôte dans la section « compilation »

3) assurez-vous que toutes les vues dans le plugin n'utilisent pas l'attribut 'inherit' pour taper fortement la vue, à la place je crée une variable locale et cast le modèle au type approprié.

Tout semble fonctionner pour l'instant, mais je vais continuer à y réfléchir pour voir si je peux trouver une meilleure solution. Encore une fois, je ne sais pas comment tout le monde peut prétendre qu'ils ont un système de plugin pour MVC et n'ont pas traité un simple view.aspx qui a une ligne comme: <% = Model.Name%> où Model est un objet que l'hôte connaît.

Merci encore pour toutes vos réponses!

Source

2009-06-04 01:44:56 Gil

Cela semble être une bonne idée. Pourquoi tu ne l'aimes pas? –

La seule raison est que c'est un peu encombrant puisque vous devez continuer à mettre à jour les fichiers dans le GAC. À part cela, cela semble bien fonctionner. – Gil

Vous devez penser à créer des interfaces ou des classes abstraites (de préférence des interfaces) que vous pouvez mettre dans l'application de base, de sorte que lorsque le plugin n'est pas présent, l'application de base continuera à compiler. Vous écrivez ensuite l'implémentation pour les interfaces ou les classes de base dans votre plugin.

This article vous aidera à démarrer.

Source

2009-06-02 05:25:12

Merci pour la réponse, mais cela ne fonctionne pas vraiment car le problème est lorsque ASP tente de rendre la page et de résoudre les références, il ne peut pas trouver les DLL associées. – Gil

Si vous ne disposez pas d'une implémentation des interfaces de votre plugin disponible (même s'il ne s'agit que d'un talon ou d'un test d'unité), comment pouvez-vous espérer que l'application s'exécute? –

L'implémentation est un autre assembly qui est remis au plug-in lors de l'exécution. Le plugin ne connaît que les interfaces des objets qu'il utilise et un sous-couche de service avec un objet réel au moment de l'exécution. Le problème est que lorsque l'application hôte affiche les vues dans le plugin, elle ne peut pas résoudre les noms d'interface. – Gil

Je pense que vous ne voulez pas que votre projet hôte compile les DLL du plugin. Je pense que vous voulez avoir les plugins construits à l'avance et peut-être intégrer les vues dans le dll d'assemblage - de cette façon, vous pouvez créer les interfaces appropriées [Robert Harvey et al] et laisser l'application hôte s'appuyer sur le dynamiquement chargé L'assemblage est ok. Peut-être que vous devez également créer une solution de harnais plugin dans laquelle vous (unité?) Tester le plugin comme développé/compilé - cela semble nécessaire car certaines erreurs de compilation dans les vues n'apparaissent pas immédiatement (this post devrait également aider avec les erreurs de compilation dans les vues - ça a marché pour moi).

Source

2009-06-02 08:07:00

Cela semblait prometteur, mais fonctionne non plus. J'ai pré-compilé toutes les vues et j'ai vérifié qu'elles sont dans le même dossier que l'hôte et qu'il ne pouvait toujours pas résoudre les références. Il y a beaucoup de messages qui prétendent avoir un design de plug-in pour ASP MVC mais je n'ai pas encore vu celui qui fonctionne avec des vues réelles qui ont des références à une couche de gestion qui n'est pas connue de l'hôte application. – Gil

Gil,

Jetez un oeil à l'article suivant. Il explique comment utiliser Reflection pour obtenir des informations sur votre assembly de couche de gestion lors de l'exécution, puis utilisez InvokeMember pour appeler la méthode souhaitée. Il ne nécessite aucune forme d'enregistrement pour fonctionner; vous avez juste besoin d'un chemin vers votre assemblée.

C# Réflexion et Méthode appel dynamique
http://my.execpc.com/~gopalan/dotnet/reflection.html

Source

2009-06-04 01:23:56

Ajout de références à ASP MVC Page Moteur de compilation

Répondre

Questions connexes