2010-05-26 6 views
6

Ceci est similaire à Add Non-GAC reference to project mais les solutions présentées ici ne semblent pas aider.Version de référence non-GAC de DLL dans Visual Studio 2010

J'ai une bibliothèque d'interface utilisateur WinForms (Krypton de ComponentFactory) installée dans le GAC. Il y a un bug que je veux traquer dans cette bibliothèque, j'ai donc ajouté le code source à ma solution, enlevé les anciennes références de mon projet WinForms aux Krypton DLLs, les ai rajoutées en tant que références de projet, double-vérifier que le chemin (sur l'onglet Propriétés de référence) pointe vers mon projet local, et ...

... la version GAC est toujours utilisée pendant le débogage. Je ne peux pas définir un point d'arrêt dans la source Krypton, Debugger.Break() ou d'autres modifications de code ne pas exécuter, et quand je démarre le débogueur Visual Studio 2010, je vois un chargement de ... GAC_MISL message relatif aux DLL Krypton clignote dans le VS 2010 barre d'état. Les DLL ne sont pas copiées dans le dossier Debug de WinForm.

Comment puis-je référencer la version "projet" des fichiers pendant le débogage tout en les laissant enregistrés dans le GAC?

Répondre

5

Le CLR recherche toujours dans le GAC en premier. N'hésitez pas à utiliser gacutil.exe/u pour les supprimer. Pirater le [AssemblyVersion] fonctionnerait aussi pour que la copie de GAC ne soit pas une allumette.

+0

gacutil semble être situé à plusieurs endroits - essayez de chercher dans 'C: \ Program Files (x86) \'. C'est l'un des chemins sur mon serveur: 'C: \ Program Files (x86) \ Microsoft SDKs \ Windows \ v8.0A \ bin \ NETFX 4.0 Tools \ x64' – northben

+0

Est-ce encore vrai? Y a-t-il maintenant moyen de hiérarchiser le projet référencé au lieu du GAC? Cela me semble une faille majeure dans un contexte de débogage; Microsoft devrait aborder cette IMHO. –

+0

C'était vrai, c'est toujours vrai, ça sera toujours vrai. Vous devrez parler à Microsoft mais vous pouvez être sûrs d'avance qu'ils vont complètement vous ignorer :) Abuser le GAC sur votre machine dev est juste une mauvaise idée, c'est un détail de déploiement qui ne compte que sur le machine de l'utilisateur. C'est la vraie victime de DLL Hell. Avoir l'enfer sur une machine de dev est un problème auto-infligé. –

Questions connexes