1

Environment here is C#/.Net 4.

In my MS Unit Test unit test project I'm testing a piece of code which uses a COM dll for some date conversion calculations (this in turn uses some other COM DLLs so in all three COM DLLs are involved).

When running in a normal application/service set-up, I have no problem getting the side-by-side execution to work through use of manifests linking to the COM dlls' assembly identities, but when trying to do the same from my unit test project, I always get failure due to 'class not registered' exceptions.

Now, I've tried this already:

  • Embedding the test DLL manifest
  • Embedding both the test DLL manifest, the COM dlls manifests + the COM DLLs themselves

But to no avail. So I'm wondering: how could I make the unit test environment aware of the COM linking through the manifests? To me, it seems like the DLL manifest linking isn't quite working (the EXE manifests are working fine), but usually those kinds of thoughts equals doing something wrong ...

I'm usually pretty successful in searching for stuff like this, but on this one, I've had very few hits, and nothing which resembles this, so please, if you have any thoughts or input, do share :) And if elaboration is needed, please let me know.

(I know, that the use of the COM dlls could probably be avoided by some dependency injection the right place, but for now I'd like to explore this case regarding unit testing a side-by-side setup).

Kind Regards

Jesper

Jesper
  • 51
  • 2

1 Answers1

0

I'm not familiar with MS Unit test, so this is just guesswork.

In your normal application setup, you've referred to the COM server manifests through your app manifest, so the general "process activation context" includes the proper references.

In the unit test scenario, you don't control the application, so the process activation context doesn't have the proper references. You've embedded the test dll manifest in your DLL, but all that does, unless you do extra work, is allow static DLL dependencies to be resolved against the manifest. The manifest activation context isn't "active" whenever your dll code is active; you have to manage this context yourself, by manually creating and activating the context around your calls into the COM server.

For an example, take a look at CSRegFreeCOMClient from the OneCode project on CodePlex.

Eugene Talagrand
  • 2,214
  • 1
  • 14
  • 16