Voici comment j'ai fini par automatiser le processus d'enregistrement et de GAC-ing de ma DLL. D'abord, j'ai créé un répertoire dans le dossier racine de la solution appelée "ScriptedDevDellRegistration". J'ai copié les versions les plus récentes de gacutil.exe
et RegAsm.exe
(avec leurs fichiers .config correspondants) dans ce répertoire.
Ensuite, j'ai ajouté un fichier dans ce répertoire appelé RegDll.cmd
. Ce fichier va enregistrer la DLL avec sa tlb, puis l'installer dans le GAC. Ceci est utile lorsque vous avez besoin de consommer un assembly dans l'environnement de développement VB6 via COM interop. Le contenu du fichier sont:
cd "%~dp0"
regasm MyDll.dll /tlb:MyDll.tlb /u
regasm MyDll.dll /tlb:MyDll.tlb
gacutil /u MyDll
gacutil /i MyDll.dll
J'ai aussi ajouté un fichier appelé UnGacDll.cmd
qui désinstaller l'ensemble du GAC. Lors de l'exécution d'une application de test de console qui utilise un assembly dans un projet différent et que cet assembly a été ajouté au GAC, j'ai eu du mal à faire fonctionner le débogage. Ce fichier supprime simplement le dll du GAC afin que je puisse déboguer plus facilement:
cd "%~dp0"
gacutil /u MyDll
Maintenant que j'ai mis mes fichiers, je dois modifier les Événements de génération de mon projet.
Dans les propriétés du projet (j'utilise VS2010 avec VB.NET) pour l'assembly compilé et enregistré/GAC'd, cliquez sur l'onglet de compilation et cliquez sur le bouton "Build Events". Dans les événements post-construction, ajouter du code qui est similaire à ce qui suit:
IF not "$(ConfigurationName)" == "Release Scripted Dev Dll Registration" GoTo elseIf1
:default
COPY "$(TargetPath)" "$(SolutionDir)ScriptedDevDllRegistration\$(TargetFileName)"
"$(SolutionDir)ScriptedDevDllRegistration\RegDll.cmd"
GOTO exit
:elseIf1
IF not "$(ConfigurationName)" == "Debug ConsoleTest" GoTo elseIf2
"$(SolutionDir)ScriptedDevDllRegistration\UnGacDll.cmd"
GOTO exit
:elseIf2
IF not "$(ConfigurationName)" == "Debug Console Web Library" GoTo exit
"$(SolutionDir)ScriptedDevDllRegistration\UnGacDll.cmd"
GOTO exit
:exit
Le script cmd est un peu laid, mais très utile. J'utilise différentes configurations de construction pour piloter les scripts qui sont exécutés dans les événements de post-construction. Par exemple, la première ligne recherche une configuration de build nommée "Release Scripted Dev Dll Registration", qui copie la DLL dans le sous-répertoire que j'ai créé, puis exécute RegDll.cmd
pour enregistrer l'assembly et ses bibliothèques de types ainsi que l'assembly GAC. Les autres configurations, «Debug ConsoleTest» et «Debug Console Web Library», fonctionnent mieux lorsque la DLL n'est pas dans le GAC. L'événement post-build appelle donc UnGacDll.cmd
pour ces configurations.
Je suis sûr qu'il est possible de scripter certaines de ces fonctionnalités sans copier physiquement les DLL ou les utilitaires regasm.exe ou gacutil.exe, mais la solution que j'ai expliqué ci-dessus a bien fonctionné pour moi.
Un fichier .cmd va-t-il résoudre votre problème? Vous pouvez inclure un fichier .cmd dans votre projet et l'exécuter en tant qu'étape de construction personnalisée. Vous devriez exécuter la partie "unregister" en tant que "pré-build step" et "register" partie - comme "post-build step" – sharptooth
quelle version de VS et quelle langue (les étapes de construction sont plus faciles en C# qu'en VB)? –
@Kate VS2010 et VB.NET –