2017-08-28 4 views
2

J'ai plusieurs bibliothèques d'assemblage C#, qui ne sont pas fortement nommées (signées). Je voudrais faire un wrapper SxS COM sur ces composants en utilisant le tlbexp.exe à consommer dans les programmes natifs. Est-il nécessaire de les signer ou existe-t-il un autre moyen de le faire?Assemblage nommé fort nécessaire pour l'interopérabilité COM?

Merci

+0

Pourquoi avez-vous le tag C++? Je ne vois aucune référence au langage C++ dans votre message. En outre, les assemblys et COM ne font pas partie du langage standard C++. –

Répondre

0

Lorsqu'un ensemble est fortement nommé, ses types ne peuvent être utilisés à partir d'autres assemblées fortement nommés. Étant donné que vos assemblys ne sont pas fortement nommés, il n'est pas nécessaire de signer votre wrapper COM.

La signature d'un ensemble permet de le placer dans le Global Assembly Cache (GAC). Cela a l'avantage de garder plusieurs versions côte à côte, sans casser les clients existants.

L'alternative consiste à utiliser le registre Windows via regasm/codebase. De la même manière que les composants COM classiques sont configurés, cette option enregistre votre assembly COM-visible sur l'ensemble du système. Puisque vous souhaitez déployer votre wrapper COM via l'activation de SxS/Registration-Free, en ignorant complètement le registre et le GAC, il est inutile de le signer.

2

Il existe de fortes idées fausses dans cette question, il confonds les rôles de deux programmeurs. Vous êtes l'auteur de la bibliothèque, quelqu'un d'autre utilise votre bibliothèque et travaille probablement pour une autre entreprise et n'a aucune idée de qui vous êtes. Le programmeur client. Vous n'avez aucune idée de la façon dont le programmeur client utilise votre bibliothèque, du nombre de programmes qu'il a écrits et de ce qu'il fait pour déployer votre bibliothèque sur les machines de ses utilisateurs. Vous exécutez Tlbexp.exe uniquement pour l'aider à écrire son code.

Ceci est une recette pour les problèmes, comme c'est n'importe quelle langue ou outil que vous utilisez lorsque vous créez des bibliothèques. Ce problème commence lorsque vous effectuez un changement dans la bibliothèque et le programmeur client doit reconstruire et redéployer ses programmes qui utilisent votre bibliothèque.

Des problèmes supplémentaires se produisent dans une bibliothèque COM car, par défaut, l'enregistrement s'applique à l'ensemble de la machine. Ce qui est plutôt sympa si la modification apportée est une correction de bogue, tous les programmes clients qui utilisent votre bibliothèque obtiennent automatiquement le correctif. Mais ce n'est pas bien si le changement se casse et fait échouer l'ancien programme client. Le désastre standard est que le programmeur client reconstruit certains de ces programmes mais oublie ou ignore certains anciens qu'il ne maintient plus. L'utilisateur final est souvent la vraie victime, il a un programme qui plante mais deux programmeurs qui ne pensent pas que c'est leur problème à résoudre.

Ce qui est nécessaire, c'est que les programmes que le programmeur client ne met pas à jour conservent l'ancienne version de votre bibliothèque afin qu'elle ne soit pas affectée par la modification. En d'autres termes, il doit y avoir plusieurs copies de votre DLL sur la machine de l'utilisateur et un programme doit automagiquement choisir le bon.

Heureusement, c'est facile à faire pour un assemblage [ComVisible] .NET. Le programmeur client, son utilisateur ou un installateur que vous lui fournissez peut mettre l'assembly dans le GAC. Ce qui permet à plusieurs copies d'un assemblage d'exister côte à côte et le CLR peut automatiquement trouver le bon. Cela a deux exigences. Vous devez augmenter la [AssemblyVersion] de votre bibliothèque, c'est la norme. Et l'assemblage doit avoir un nom fort afin qu'il puisse être mis dans le GAC. C'est trivial à faire par vous, en utilisant Project> Properties> Signing et en cochant la case "Sign the assembly". Cela n'a aucune incidence sur la sécurité, donc la clé n'a pas d'importance et un mot de passe est totalement inutile.C'est pas facile à faire par le programmeur client donc c'est quelque chose que vous devez faire. Toujours.

Le programmeur client a également la possibilité d'utiliser COM isolé avec un manifeste (aka "regfree COM"), probablement ce que vous vouliez dire avec "SxS COM-wrapper". Avec l'avantage que chaque programme qu'il écrit a sa propre copie de la DLL, la façon dont cela fonctionne par défaut dans .NET. Les correctifs de bogues doivent être déployés manuellement, mais une modification de votre bibliothèque ne peut pas interrompre un programme client non maintenu. Mais c'est entièrement son choix, il n'y a rien que vous puissiez faire pour que cela soit fait. Vous devez supposer qu'il ne l'utilise pas, et il ne sera certainement pas au premier abord, de sorte que vous ne pouvez pas contourner le besoin de nommer fort.