Est-il possible de faire référence à une COM DLL dans un projet géré par voie de chemin plutôt que par GUID?

Cet article montre comment faire activation de l'enregistrement des composants COM. Peut-être que cela aidera: http://msdn.microsoft.com/en-us /Library/ms973913.aspx

comme John Fisher a souligné déjà que vous recherchez COMT INTEROP GRATUITE . Il y a déjà beaucoup de questions à ce sujet, recherchez la «tag à la main» regfreecom et la balise étroitement liée sxs aussi.

Vous verrez facilement que cela peut être une arène délicate, notamment:

• Il semble y avoir un confirmé Bug qui affectant ceci sur Windows XP, voir ici pour plus de détails. Un correctif est déjà disponible, ce qui pourrait être suffisant tant que vous ciblez uniquement un environnement contrôlé, par ex. votre machine de construction.
• Depuis que vous ciblez ASP.NET, vous devez savoir que contrairement à par exemple. Une application de bureau Cela implique que vous ne contrôlez pas le processus d'hébergement, qui peut varier en fonction de la plate-forme de déploiement. Cela signifie qu'il ne sera pas facile de fournir le manifeste d'application requis pour contrôler la liaison d'exécution et l'activation de votre composant COM dans l'hôte (voir point suivant pour une alternative potentielle).
• ASP.NET 2.0 semble compliquer encore les choses en laissant tomber la fonction côte à côte pour les composants non gérés. Je n'ai pas trouvé de source officielle pour cela, mais l'auteur de ASP .NET 2.0 Applications semble être dans le savoir; Il offre au moins une solution de contournement, ce qui semble compliqué et potentiellement fragile.

  Résumer cela, j'aimerais souligner que "l'enregistrement-free Interop" peut être très utile et atténuer beaucoup de scénarios. Néanmoins, cela peut ne pas faciliter les choses ou même être possible pour votre scénario et votre environnement particulier (ASP.NET hébergé).

  bonne chance, s'il vous plaît laissez-nous savoir si vous avez réussi!

On dirait que ce n'est pas possible - Visual Studio examinera uniquement le GUID mentionné dans la référence, cela ne se soucie pas du chemin qui y est allongé.

Nous avons eu un problème similaire avec notre serveur de construction quotidien - le client COM ne compilait pas si le serveur COM n'est enregistré. Nous avons juste ajouté l'enregistrement / la non-enregistrement à la séquence de construction - Compacteurs informatiques (REGSV32) (REGSV32), alors vs est exécuté à partir de la ligne de commande et immédiatement après l'achèvement de VS, il n'enregistre pas le composant (REGSVR32 -U). Fonctionne bien.

Lorsque vous référence à une COM DLL, Visual Studio génère automatiquement un ensemble Interop pour celui-ci. Je trouve que la prise de contrôle manuel de ce processus est un excellent moyen de découpler les bâtiments COM et .NET.

1. Créez votre propre ensemble Interop pour la DLL COM avec tlbimp.exe . Voir MSDN pour les paramètres de ligne de commande. < / li>
2. Référencez votre assemblage Interop dans le projet .NET au lieu de la DLL COM.

   Une fois que vous faites cela, vous n'avez plus besoin que la COM dll enregistrée sur la machine lorsque vous construisez la solution .NET, seule votre assemblage interop est requis.

   L'assemblage interop peut s'asseoir dans un dossier inchangé pour toujours jusqu'à ce que (a) la COM dll brise la compatibilité binaire, ou (b) une modification de l'interface COM est effectuée que le code .NET utilise réellement.

   Si vous avez des versions différentes du COM DLL qui sont toutes compatibles binaires, compilez ensuite l'assemblage Interop contre la version la plus ancienne contenant les interfaces requises par le code .NET. Vous n'aurez alors pas à mettre à jour l'assemblage Interop pour différentes versions.

   En outre, vous n'avez pas besoin d'inclure la DLL COM dans votre installateur si vous êtes en mesure de supposer que le COM DLL sera déjà installé sur la machine cible.