2010-02-24 9 views
0

J'ai un codeUtilisation de Type.GetType() avec un assembly non référencé avec Cassini/Visual Studio Dev. Serveur

var type = Type.GetType("namespace, assembly"); 
return Activator.CreateInstance(type); 

des thats fonctionne très bien dans la plupart des situations, mais lorsque ce code est référencé dans le Global.asax d'un site Web qui est à l'aide Cassini déboguée/Visual Studio de développement du type serveur ne peut pas être trouvé.

Le type se trouve dans un assembly qui n'est pas référencé mais se trouve normalement dans le même répertoire de sortie que l'assembly en cours d'exécution. Cependant, en regardant de plus près, il apparaît que lors du débogage, Cassini a placé l'assembly d'exécution et chaque assembly référencé dans son propre répertoire à l'emplacement suivant: C: \ users ... \ AppData \ Local \ Temp \ Temporary ASP.NET Files \ root ... .. mais évidemment l'assemblage «non référencé» n'est pas là.

Existe-t-il un moyen pour VS de copier des ressources supplémentaires dans le répertoire temporaire ou de lancer à partir d'un répertoire spécifié? Est-ce que l'utilisation d'IIS est la seule solution?

Merci d'avance.

Répondre

1

Je pense que ce n'est pas le cas de Cassini, c'est ASP.NET en utilisant le cliché instantané .NET pour empêcher le verrouillage de vos DLL. Donc, en utilisant IIS ne devrait rien changer. Le manque de référence explicite semble laisser .NET mettre les DLL dans des répertoires différents.

Pouvez-vous mettre cette DLL référencée dans le GAC?

+0

Oui, c'est logique. Totalement oublié à ce sujet. Je préférerais vraiment ne pas utiliser le GAC en raison du nombre d'assemblages que cet assemblage non référencé fait référence. Je suppose qu'une autre alternative serait de désactiver le cliché instantané (http://msdn.microsoft.com/en-us/library/system.web.configuration.hostingenvironmentsection.shadowcopybinassemblies.aspx)? Est-ce que quelqu'un a d'autres solutions possibles? –

0

Ceci est en réponse à votre commentaire sur la première réponse (« Quelqu'un at-il d'autres solutions? ») ...

Oui, il y a une solution très simple et il vient de la même source provoque le "problème" (spoiler ... c'est le System.AppDomain). Il existe un événement appelé "AssemblyResolve" dans la classe AppDomain auquel vous pouvez répondre (utilisez AppDomain.CurrentDomain pour obtenir "votre" instance AppDomain). L'événement vous fournira le nom (chaîne) de l'assembly qu'il ne peut pas trouver. Je suppose que vous connaissez l'emplacement des assemblys en question, utilisez simplement System.Reflection.Assembly.Load (pathToYourAssembly) pour charger l'assembly, puis renvoyez l'instance Assembly que les méthodes "Load" retournent. Le gestionnaire d'événements "AssemblyResolve" est un peu différent. Il a un type de retour, donc dans votre gestionnaire d'évènement vous allez faire un "return thisAssembly"; où "thisAssembly" est la valeur de retour de la méthode Load. L'AppDomain a également un événement TypeResolve (et d'autres) au cas où il ne trouverait pas un type dans l'assembly "supposé être dans". Cela peut se produire si vous avez déplacé un type d'un assemblage à un autre et que vous n'avez pas recompilé tout le reste qui faisait référence à ce type. Quoi qu'il en soit, espérons que cela aide quelqu'un. Je sais que c'est une vieille question.