Side-by-side exécution et MS Test Unit

Question

environnement ici est C# /. Net 4.

Dans mon MS Unité projet de test unitaire test Je teste un morceau de code qui utilise une dll COM pour une date calculs de conversion (cela utilise à son tour d'autres DLL COM dans les trois DLL COM sont impliqués). Lors de l'exécution normale d'une application/d'un service, je n'ai aucun problème à faire fonctionner l'exécution côte à côte en utilisant des manifestes liés aux identités d'assemblage des DLLs COM, mais en essayant de faire la même chose à partir de mon projet de test unitaire, je reçois toujours un échec en raison d'exceptions de «classe non enregistrée».

Maintenant, je l'ai essayé ce déjà:

• Intégrer le test DLL manifeste
• Intégration à la fois le manifeste de DLL de test, les COM dll manifestes + les DLL COM eux-mêmes

Mais en vain. Je me demande donc: comment est-ce que je pourrais rendre l'environnement de test unitaire conscient de la liaison COM à travers les manifestes? Pour moi, il semble que le lien manifeste DLL ne fonctionne pas tout à fait (les manifestes EXE fonctionnent bien), mais généralement ce genre de pensées équivaut à faire quelque chose de mal ...

Je suis généralement assez efficace dans la recherche de des trucs comme ça, mais sur celui-ci, j'ai eu très peu de hits, et rien qui ressemble à ça, alors s'il vous plaît, si vous avez des idées ou des commentaires, partagez :) Et si une élaboration est nécessaire, faites le moi savoir. (Je sais que l'utilisation des dlls COM pourrait probablement être évitée par une injection de dépendance au bon endroit, mais pour l'instant je voudrais explorer ce cas en ce qui concerne les tests unitaires d'une configuration côte-à-côte).

Cordialement

Jesper

Answer 1

Je ne suis pas familier avec le test MS Unit, donc c'est juste devinettes.

Dans votre configuration d'application normale, vous avez fait référence aux manifestes de serveur COM via le manifeste de votre application, de sorte que le «contexte d'activation de processus» général inclut les références appropriées.

Dans le scénario de test unitaire, vous ne contrôlez pas l'application, donc le contexte d'activation du processus n'a pas les références appropriées. Vous avez incorporé le manifeste de test dll dans votre DLL, mais tout ce que cela fait, à moins que vous n'effectuiez un travail supplémentaire, permette de résoudre les dépendances DLL statiques par rapport au manifeste. Le contexte d'activation du manifeste n'est pas "actif" lorsque votre code dll est actif; vous devez gérer ce contexte vous-même, en créant manuellement et en activant le contexte autour de vos appels dans le serveur COM.

Pour un exemple, jetez un oeil à CSRegFreeCOMClient à partir du projet OneCode sur CodePlex.