Composant COM + appelant d'autres composants COM + - "Impossible de charger le type"

Question

J'ai deux assemblys .NET qui sont enregistrés en tant que composants COM + et je les teste à partir d'un harnais de test d'application console standard;

Dim objFirst As New MyFirstComponent() 'COM+ initialisation 
Dim RC As Boolean = objFirst.GetValue() 

L'appel de méthode est exécuté avec succès. C'est la définition de MyFirstComponent;

<ProgId("MyFirstComponent")> _ 
<Guid("...")> _ 
<ClassInterface(ClassInterfaceType.None)> _ 
<Transaction(TransactionOption.Supported)> _ 
Public Class MyFirstComponent 
    Inherits ServicedComponent 
    Implements IMyFirstComponent 

    Public Function GetValue() As Boolean Implements IMyFirstComponent.GetValue 
     Dim objSecond As New MySecondComponent() 'COM+ initialisation 
     Dim RC As Boolean = objSecond.GetValue() 
     Return RC 
    End Function 

End Class 

Au point où MySecondComponent est initialisés, je reçois un RemotingException avec le message suivant;

Impossible de charger le type 'MySecondComponent', ..., Version = ..., Culture = neutral, PublicKeyToken = ... »

Tous les assemblages sont fortement nommés aussi. Je n'arrive pas à comprendre pourquoi je peux lancer avec succès un appel de méthode au premier composant, mais quand il essaie de charger le deuxième composant lui-même, il ne peut pas résoudre le type. En tant que sidenote, si je cours le code du corps de "GetValue()" dans mon harnais de test, il s'exécute comme prévu. Le problème semble surgir seulement une fois que les choses se sont déplacées dans le domaine des composants COM + appelant d'autres composants COM +.

Mise à jour

Je pense que je suis rétrécissement sur le problème maintenant. Il semble que COM + persistait quelque chose dans le processus, et j'ai dû fermer manuellement les applications COM + à partir de la fenêtre Services de composants avant d'exécuter mon client par rapport à cela. Le problème était que je testais le client chaque fois que je changeais quelque chose (comme ajouter l'assembly au GAC), et pour une raison quelconque, COM + croyait toujours que l'assemblage ne pouvait pas être trouvé. La fermeture de l'application, l'ajout des assemblys requis au GAC et l'exécution du client ont de nouveau fonctionné comme prévu.

Cela a été bon pour mon petit client preuve de concept. Donc je suis retourné à mon vrai code et l'ai essayé, mais maintenant je reçois un autre problème étrange. Mes applications COM + semblent incapables de localiser leurs références de projet normales maintenant. Je ne veux pas vraiment aller dans le sens d'ajouter TOUT ce qu'ils font référence au GAC, donc j'essaie maintenant de comprendre pourquoi mes références normales, non-COM + ne sont pas résolues.

Answer 1

J'ai enfin trouvé une solution au problème décrit ci-dessus. Je suis moi-même en train de répondre à la question pour sauver la douleur que j'ai éprouvée.

• Aller à Services de composants> COM + Applications> YourComApplication

• Apportez la fenêtre des propriétés pour YourComApplication et passez à l'onglet Activation. Sous "Répertoire racine de l'application", indiquez le chemin d'accès de vos DLL dans le champ "Répertoire racine de l'application".

• Créez une "application.manifeste de fichier "pour votre application COM + et le mettre dans le même répertoire que ci-dessus un exemple de fichier ressemble à ceci:.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" 
manifestVersion="1.0"> 
</assembly> 

• Cette dernière étape est ce que j'avais manqué avant et cette solution ne fonctionnera pas sans elle.

aussi, assurez-vous que vous avez un répertoire distinct pour e de vos applications COM +. Cette approche vous permettra d'avoir plusieurs applications COM + basées sur des assemblys .NET qui s'appellent les uns les autres sans que rien ne doive être dans le GAC.

Answer 2

Avez-vous envisagé d'utiliser regasm pour enregistrer les assemblys d'accès avec COM. Je ne suis pas sûr mais cela peut avoir à faire avec le paramètre/codebase étant passé lorsque vous enregistrez l'assembly. Ça vaut le coup. J'espère que cela t'aides.

Answer 3

Bien que vous ayez clairement résolu le problème avec les étapes incluses dans la réponse, ce problème peut également se produire si vous avez une version de PowerShell qui n'est pas compatible avec l'assembly que vous essayez de charger. Par exemple, vous pouvez avoir un assembly ciblant .NET framework 4.5.1, mais la version de PowerShell que vous exécutez est la version 2.0. Si vous mettez à niveau la version vers 4.0 ou 5.0, vous ne devriez avoir aucun problème.