Unit testing Problems
Hi all,
In one of my unit test i keep getting
"System.IO.FileNotFoundException: The specified module could not be found", while loading a managed C++.Net. This dll in-turn links to other dlls (Unmanaged) statically and all files are in same folder.
During running the tests I found out that dlls are first getting copied to some location (C:\Documents and Settings\Administrator\Local Settings\Application Data\VSEqtDeploymentRoot\...) and then loaded. Since my unmanged dlls are not present in that location, my c++.Net module fails to load and hence the exception.
My questions
- Why are the dlls getting copied to other location?
- Is there any way to prevent it from copying ?
Thanks
Ash
[742 byte] By [
ash927] at [2008-2-4]
We always deploy our tests -- this gives a more consistent experience between remote & local execution. Sometimes It's annoying, sometimes it's really helpful (being able to start a run, but continue to change dlls etc).
However, we automatically detect Managed dependancies, but I don't think that we detect unmananged dependancies.
How can you work around this? Add the Unmanaged DLLs as deployment items -- either with the run config (Edit it, and look at deployment items tab), or as
| |
[DeploymentItem("dllPath")]
|
on your test methods.
Other topics in this forum suggest that the DeploymentItem path is relative to whatever path is in relativePathRoot in localtestrun.testrunconfig. But this seems to leave a large gap in handling various testing modes. For instance, my test assembly has culture-specific resources, one of which is en-AU. The test assembly is called TestByuUtilities, so my DeploymentItem looks like this:
[DeploymentItem(@"TestByuUtilities\bin\Debug\en-AU\TestByuUtilities.resources.dll", "en-AU")]
Do you see how this is a poor binding to
A) the project directory name
B) the scenario that we're testing a Debug version
C) The assembly name
There really ought to be some variables that we could stick into this string, so that it might look more like:
[DeploymentItem(@"$ProjectName$\bin\$BuildMode$\en-AU\$TargetAssemblyName$.resources.dll")
Or something like that. Right now, if I test a release assembly, I'll be testing against the (older) Debug resource assembly.
Is there a way for me to fix this now, or is this yet to be implemented in VS 2005?
There is a sub-optimal workaround for this.
a) Specifiy the build output directory for your satalite assemblies to be \bin\en-AU rather than bin\debug
or
b) Have a post-build step that copies the DLLs to a well-known directory where you can pick them up.
I know these are not optimal, but they remove some of the pain you are experiancing here.
If you could log a bug in MSDN Feedback, that would be great -- this allows us to see where it came from, and also let other users vote on it's importance.
Yours,
Dominic
dhopton MSFT wrote: