Comment gérer le code généré dans Visual Studio - en particulier, créer des DLL à partir de .idls

J'essaie d'ajouter un projet d'assemblage COM Interop généré à ma solution, et la seule solution que je pourrais trouver est vraiment désagréable.Comment gérer le code généré dans Visual Studio - en particulier, créer des DLL à partir de .idls

J'ai créé un projet dll .net, enlevé tous les fichiers .cs à partir, puis a créé l'événement après génération suivante:

call "$(DevEnvDir)..\tools\vsvars32.bat" 
midl.exe $(ProjectDir)relative-path-to-my-idl\MyComName.idl /tlb MyComName.tlb 
tlbimp.exe /keyfile:path-to-my-key\k.snk MyComName.tlb

Essentiellement, je crée d'abord une DLL vide, puis le remplacer par un véritable interop DLL. Et il n'y a pas de gestion des dépendances ici - c'est créé à chaque fois.

Y a-t-il une meilleure façon de procéder?

Source

2009-09-22 Mark Wright

Vous pouvez résoudre le problème de dépendance en utilisant directement les tâches MSBuild au lieu d'un fichier de traitement par lots PostBuild, qui s'aligne bien avec le système de dépendance MSBuild.

Cependant, pourquoi générez-vous le fichier manuellement à partir d'un idl? Quand j'ai besoin de COM interop, je l'importe juste et place l'assembly généré (* .Interop.dll) dans le contrôle de version. De cette façon, vous avez toujours la version dont vous avez besoin et elle est déjà prête à l'emploi, et Visual Studio peut trouver la DLL d'interopérabilité avant la première génération, c'est-à-dire qu'Indisense est là dès le début.

Maintenant, certaines personnes ne vont pas aimer vérifier dans un fichier binaire, que je suis d'accord généralement avec, mais bon, si ça marche ... :)

Bien sûr, ma méthode ne fonctionnera pas si le bâtiment le serveur COM fait partie de la construction de la solution. Dans ce cas, essayez simplement de placer la génération dans le script MSBuild pour supprimer la dépendance, à moins que Visual Studio n'accepte une référence à un projet non-.NET-COM interne à la solution.

Source

2009-09-22 16:11:33 OregonGhost

+1, restez simple: vérifiez-le. –

Mais je ne le construis pas manuellement, je le construis automatiquement. Je vérifie .idls et ne pas interop dlls pour la même raison que je vérifie dans les fichiers .cs et pas .exe/.dlls - c'est ce que le système de construction est censé faire pour moi. Il gère les dépendances et construit (et reconstruit) les modules dont les dépendances ont changé. Si je vérifie la DLL interop générée, maintenant je suis responsable de la reconstruction lorsque des changements se produisent. Malheureusement, il est difficile de faire les choses correctement avec Visual Studio, donc je vais devoir faire cela. –

Si le système de construction devrait le faire pour vous, alors la bonne façon est de le faire dans un fichier MSBuild (vous pouvez même utiliser le csproj pour cela). Ceci est un épargnant de vie si VS ne fournit pas ce dont vous avez besoin. Cela signifie que vous devez créer une version de la DLL avant que Intellisense ne la reconnaisse. IMO il y a une différence entre vérifier dans une DLL compilée où la source fait partie du projet (fondamentalement n'a aucun sens, comme vous l'avez dit), et vérifier dans une DLL qui sert de fichier d'en-tête. Si vous vous inscrivez à l'IDL, vous êtes responsable de la mise à jour de l'IDL. Qu'en est-il de la création de la DLL dans un script de post-paiement? – OregonGhost

La compilation MIDL peut être gérée en faisant du projet COM Interop un projet C++ géré (au lieu d'un projet C#), puis en ajoutant les fichiers idl et h au projet en tant que fichiers sources normaux.

Source

2009-12-04 23:22:17 Eusebio

Comment gérer le code généré dans Visual Studio - en particulier, créer des DLL à partir de .idls

Répondre

Questions connexes