La signature de mon assemblage avec un nom fort l'empêche de fonctionner

Un collègue créé un assemblage dans VB.net pour être utilisé avec JScript via interop COM. L'assemblage fonctionnait bien, mais nous l'avons signé et maintenant il semble fonctionner sur les machines Windows 7. J'ai testé 2 machines Windows 7 et 2 machines Windows Vista.

Lorsque nous avons signé l'assemblage et que nous essayons d'instancier l'objet ActiveX dans JScript, une erreur est renvoyée sans message et seulement un nombre:

Erreur:
Numéro d'erreur: -2146234304

Une recherche sur Google pour le numéro d'erreur n'a pas renvoyé beaucoup.

Si nous supprimons le nom fort de l'assemblage, cela fonctionne très bien. Des idées sur ce qui pourrait être le problème? Je ne sais pas si cela fait une différence, mais l'assemblage est compilé et signé avec VS 2010.

Avez-vous recréé le COM Interop après la signature de l'assemblage? Comment enregistrer la nouvelle version de l'assemblée? Avez-vous effacé le cache d'Internet Explorer?

En général, l'erreur -2146234304 (0x80131040) signifie FUSION_E_REF_DEF_MISMATCH : "La définition de manifeste de l'assembly situé avec le nom [yourAssembly] ne correspond pas à la référence d'assemblage". Vous devez donc mettre à jour le manifeste d'assemblage qui utilise votre assemblage signé. Ce que cela signifie exactement dans votre situation, vous devriez trouver. Le renvoi à l'assemblage est également enregistré sous la valeur de l' Assembly de HKEY_CLASSES_ROOT\CLSID\{YOUR_GUID}\InprocServer32 et non seulement dans le manifeste réel.

Vous pouvez essayer d'enquêter sur le problème avec Fuslogvw.exe (Assembly Binding Log Viewer) (ou http://msdn.microsoft.com/en-US/library/ms229864(v=VS.80).aspx ). Certaines modifications dans le registre sous HKLM\Software\Microsoft\Fusion pourraient être nécessaires avant (comme EnableLog, LogFailures,

Si vous ne résolvez pas le problème de la manière dont vous pouvez publier un lien vers un projet qui pourrait être utilisé pour reproduire votre problème.

Le code d'erreur ix 0x80131040. C'est un code qui correspond à une exception .NET, très courante.

La définition de manifeste de l'assemblage local ne correspond pas à la référence d'assemblage.

Je suis surpris que vous ne receviez pas un message, vous voudrez peut-être examiner votre code de gestion des erreurs. Anyhoo, vous avez un peu de DLL Hell en cours, le CLR trouve un assemblage dont [AssemblyVersion] ou PublicKeyToken ne correspond pas à l'assembly de référence qui a été utilisé pour construire le code. Étant donné que cela est associé à un assemblage nommé fort, vous avez peut-être signé l'assemblage après avoir construit le code. Dans ce cas, il suffit de supprimer la référence d'assemblage de votre projet et de l'ajouter, maintenant le choix de l'assemblage nommé fort, réparera le problème.

Mais pas besoin de deviner cela, l'utilitaire Fuslogvw.exe vous dira exactement ce qui ne va pas. Exécutez-le d'abord pour obtenir une trace de la tentative de liaison et la raison pour laquelle il a échoué.

Utilisez le revendeur de dépendance pour ouvrir votre dll signé sur la machine problématique. Il devrait vous dire pourquoi la DLL ne peut pas être chargée. Il pourrait être dépendant d'une dll qui est différente entre les versions de Windows, ce qui est plus un problème après la signature.

Andy, je ne sais pas si cela est pertinent . La solution là-bas dit:

J'ai oublié de mettre à jour l'adxloader.dll (du nouveau dans \ Add-in Express .NET \ Redistributables) dans le chemin – je suppose qu'il a été mis à jour …

Votre nombre ressemble beaucoup au début de la gamme entière!

 Signed: −2,147,483,648 to +2,147,483,647, -(2^31)~(2^31-1) 

Peut-être que vous avez une erreur de casting ou un nombre vraiment important que vous essayez d'augmenter et si cela atteint le maximum (+2,147,483,647), il commence à compter à partir de -2,147,483,648

Juste une conjecture!

Utilisez-vous les blocs de code Microsoft Enterprise Library du tout? J'ai vu ce problème apparaître avec les gens n'ajouteant pas de référence aux bibliothèques signées correctes lorsqu'ils compilent leur code.

Voici un peu plus d' arrière – plan si vous utilisez EnterpriseLibrary.

Essayez de signer votre assemblage à partir d'une configuration XP fonctionnelle (ou de la zone Vista). CAPICOM n'est pas pris en charge dans Windows 7, peu importe ce que l'outil de signe peut faire pour signer votre assemblage, il est possible qu'il ne soit pas compatible avec Vista. Maintenant, j'ai vu CAPICOM fonctionner très bien, mais je l'ai également vu échouer sans raison, et "non pris en charge" signifie que c'est ce que vous obtenez du support Microsoft si vous essayez d'appeler.

Accédez à la console de configuration .Net Framework et jouez avec les paramètres de Stratégie de sécurité Runtime sur votre machine.