Answers

Yeah, I got the problem where the tests would run in "Debug" mode, but not in normal "Run" mode, and it was related to code coverage and assembly signing. In order to perform code coverage, it seems VS has to modify the assembly with some sort of tracking hooks. If your assemblies are signed, this means VS needs to resign them for them to load properly.

What isn't as obvious is that while you specify the original SNK file for the assembly by going to Project => Properties => Signing, you have to go to Test => Edit Test Run Configuration => [your configuration] => Code Coverage to specify the resigning key for code coverage purposes. In my case, these two keys didn't match. Pointing them both at the same key fixed the problem.

Can you please provide the following information:- What exactly is the problem you are seeing?- How did you create VSTSDemo project, where did you download it from, and how did you modify it? If you tried to use .config file redirection for data source, you can find an example of .config file in this post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=215723&SiteID=1&mode=1- What does your .config file contain? (email to me is fine)- Fusion log is successful, it found the assembly. Do you see fusion errors?

Thank you,Michael

Monday, January 23, 2006 5:23 PM

All replies

I've seen this exception on two occasions so far. First time was when I was using code coverage, and I didn't specify a key for assembly re-signing. This would work in debug mode because code coverage by design is disabled in debug mode.

Second time was when I tried to run a unit test in which my [ClassInitialize] and [ClassCleanup] methods were not defined as static.

Please provide more information:- Do you see any run level warnings when you have this error? To see them click on "test run finished"/"test run warning"/"test run error" link in Test Results Window toolbar.- Is your test assembly strongly signed or are any of your assemblies it references strongly signed?- Is code coverage enabled?- Are there any tests shown in Test Viewer/Manager as Disabled (with icon that has red "Cancel" circle)?- Please run fuslogvw.exe, clear all messages, then run your test so that it fails, refresh messages in fuslogvw.exe and include all logged entries to your reply. Normally the error should come from vstesthost.exe process. Your original email had error entry for MS.VS.QT.Common.dll from devenv.exe, you should have another successful entry for this assembly from devenv.exe in your fuslog.

I am experiencing a similar problem and was hoping that you could help. I created the VSTSDemo project from MSDN and tried to hook up a datasource and got the same error. I have the released Visual Studio 2005 for Software Developers 8.0.50727.42 (RTM.050727-4200)

Can you please provide the following information:- What exactly is the problem you are seeing?- How did you create VSTSDemo project, where did you download it from, and how did you modify it? If you tried to use .config file redirection for data source, you can find an example of .config file in this post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=215723&SiteID=1&mode=1- What does your .config file contain? (email to me is fine)- Fusion log is successful, it found the assembly. Do you see fusion errors?

After some searching it turned out that a drive containing the external assembly which it complained about was not available, although compilation did just work.. probably because of copy-local.

I experimented some more and found that the easiest way to detect the assembly is to first perform a "Clean solution" in Visual Studio and then perform a "Rebuild All". This way, all dependencies wil be re-checked with compilation, and the compiler will simply complain about the missing assembly. Of course you could also use fuslogvw.exe, but I think this solution is often easier.

I ran into this error after another user renamed the project folder in TFS. The problem was the test run configuration had code coverage enabled for the assembly in the old folder. I changed that in the Test->Edit Test Run Configurations->Local Test Run dialog under Code Coverage by unchecking the assembly referenced in the old path and checking the assembly in the correct path.

And I ran into this error on our TFS server when I accidently entered an absolute path to the key file used for instrumentation. The absolute path worked fine on my local developer box, but of course a relative path was needed to make it work on the build server.

And in my case, I have a shared SNK file two levels above the solution folder. So the value I specified to work things out was "..\..\mykey.snk", instead of the full path "c:\....".

I guess this only applies to build environments where the developer machines doesn't use the same folder structure as the build server. If you have the same folder structure in both places, absolute paths would probably work as well as the relative ones.

Yeah, I got the problem where the tests would run in "Debug" mode, but not in normal "Run" mode, and it was related to code coverage and assembly signing. In order to perform code coverage, it seems VS has to modify the assembly with some sort of tracking hooks. If your assemblies are signed, this means VS needs to resign them for them to load properly.

What isn't as obvious is that while you specify the original SNK file for the assembly by going to Project => Properties => Signing, you have to go to Test => Edit Test Run Configuration => [your configuration] => Code Coverage to specify the resigning key for code coverage purposes. In my case, these two keys didn't match. Pointing them both at the same key fixed the problem.