Code Coverage for Strong Named Assemblies with Visual Studio Premium

Question

I am getting the following error when I run my unit tests for our enterprise level application with code coverage enabled in Visual Studio 2010:

Strong name verification failed for the instrumented assembly 'MyTestableLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0e9ec37537d29286'. 
Please ensure that the right key file for re-signing after instrumentation is specified in the test settings.   

Simplifying The Issue

So I've created a simple solution with one class library and one test project in Visual Studio 2010. We have strong named assemblies so I have used Visual Studio to create a new pfx file and associated the same one with the class library and test project.

This generates the same error. See below.

Simple Test

The unit tests run fine without the code coverage enabled.

Add Code Coverage

Add some Code Coverage Detail...

Code Coverage Enabled Test Run

Then run the tests...

Help

Of course the tests execute fine with Code Coverage enabled but the strong name signing removed from both projects and the Instrument assemblies in place unticked.

I've tried selecting the pfx in the Code Coverage Re-signing key file. I've tried generating the strong named key from the pfx using sn command:

sn -p MyStrongNameKey.pfx MyStrongNameKey.snk

It does not seem to matter what file I select in the Code Coverage Detail Re-Signing Key file - I can select my .sln file and I get the same error.

I've added solution here if any one wants to look:

One Drive VS2010 Solution

The pfx password is:

fernado1

I am keen to get the code coverage working for this but I can't see it - even such a simple solution like this.

Answer 1

OK. I now have a working Test Code Coverage for my problem.

At this point I've extracted the public key from my assembly using the following commands:

sn -p input.pfx output.publickey
sn -tp output.publickey

This gives me the following public key text in the command line:

0024000004800000940000000602000000240000525341310004000001000100595757733513185e3dc44b958c76cdc1e56b73d5bd1c05a8a2b208311126cc1bc8e234a244cb1dcc3f3a25fbd82474911ce671cfd155242659a258c51d5fee8263a6a12d7a82cb98f1b5af0ac6e58afd2f02d1a8b9b34b5a4e8aa63a754830826caef3de5efe8ccbef81210a3dea0f977746b4f1d3335c1ca68d6a1894e47cb0

I then came across this post which triggered some thought MSDN Social Forum.

Fair to say it did not work. The interesting thing with that post is there is a 32 and 64 bit version of the sn tool. When adding assemblies to the registry using sn -Vr then it matters which sn.exe you run. So if you use the 32 bit version of sn.exe with -Vr to add assemblies you want to skip the verification process then verify it with the 64 bit version using sn -Vl then it will not show the entries you have just registered. Curious.

I used the following command lines to register my assembles I want to try and get rid of the error message for as follows:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyTestableLib.Tests\bin\Debug\MyTestableLib.dll" * "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyStringNameKey.Public"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyTestableLib.Tests\bin\Debug\MyTestableLib.Tests.dll" * "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyStringNameKey.Public"

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyTestableLib.Tests\bin\Debug\MyTestableLib.dll" * "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyStringNameKey.Public"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyTestableLib.Tests\bin\Debug\MyTestableLib.Tests.dll" * "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\MyStringNameKey.Public"

NOTE: I have done this for both 32 and 64 bit versions of sn.exe. I don't think the registering for the test project is required but I have left it in.

So at this point my tests still don't run.

I used the Fusion Log tool to see what was going on. I did a file content search (using Agent Ransack) of its output logs to see where my DLLs were being used. I noticed a process named QTAgent32.exe which I didn't know what it was. I thought this was some Quick Time agent but it turns out it is the Visual Studio/Microsoft Testing Agent.

Still the logs didn't reveal much. I decided to use SysInternals ProcMon. I then ran the tests to reveal 1000s of lines of activity. I looked for my DLL MyTestableLib.dll. A fair way down I noticed that the Test Agent was using it's own folder located in my solution path:

E:\Code Workbench\UnitTesting\UnitTestingStrongNames\TestResults\paul.anderson_PAULANDERSON 2015-06-26 11_43_07\Out

I looked in this folder and there were my MyTestableLib.dll and mytestablelib.tests.dll files. I thought I'd use Assembly Information tool to have a quick peak and lone behold, I got the same error as the test. The test project loaded ok (as I did not have the check against it in MSTest settings)

OK, now back to the sn.exe -Vr registration.

I ran the following command line:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\TestResults\paul.anderson_PAULANDERSON 2015-06-26 11_43_07\Out\MyTestableLib.dll"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe" -Vr "E:\Code Workbench\UnitTesting\UnitTestingStrongNames\TestResults\paul.anderson_PAULANDERSON 2015-06-26 11_43_07\Out\MyTestableLib.dll"

Both 32 and 64 bit to be on the safe side. The registrations were added (verify with sn.exe -Vl - for both 32 and 64 bit).

I then re-ran the tests and they ran fine. I can now view my code coverage information.

Hope this helps someone else struggling. There is probably a shortcut somewhere as I have been around the mill so to speak.