Difficulties in getting Code coverage information

I am testing ASP.NET web controls and am facing difficulties in getting code coverage information from my tests.

For testing our web controls, I am using the [HostType("ASP.NET")] and [UrlToTest("http://localhost/TestSite")] attributes in my test projects to either test a website that has these webcontrols, or dynamically add these controls to a empty test website and test their properties and methods.

So my project structure is like this
c:\>
    - InetPub
        -wwwroot
           -UnitTestWebSite
    - Dev
        - WebControl1Project
        - WebControl2Project
        - WebControl3Project
        - WebControl4Project
        - ...
        - TestForWebCtrl1Project
        - ...
       WebControls.Sln -> This includes all the webcontrolprojects, and the Test projects.

Now, when I do not ask for code coverage information, my tests run fine. However, when I click on the testrunconfig file and select WebControl*Project.dlls and also TestForWebCtrl*Projects.dlls in the code coverage pane and run the tests, I get the error message at the end of the test run in the Results file:
"The test started running in response to request 'http://localhost/UnitTestWebSite/Default.aspx', but an error occurred before the test finished executing: The remote server returned an error: (500) Internal Server Error.. The response from the request is stored in the file 'WebRequestResponse_ConstructorTest.html' with the test results; typically this file can be opened with a web browser to view its contents."

On opening WebRequestResponse_ConstructorTest.html, I see a wierd error message such as:
such as "System.InvalidCastException: Unable to cast object of type LibName.CustomType1 to LibName.CustomType1"

Source File: c:\Dev\WebControl2Project\ProxyClasses\DevServerProxy.cs Line:298

On clicking on the Code Coverage Results Pane, I see the following message:
Empty results generated: none of the instrumented binary was used. Look at test run details for any instrumentation problems.

How do I get code coverage for my project, and why am I seeing such error messages

Thanks.

Answer this question

Difficulties in getting Code coverage information

hughbert
You always have to use the private key for signing.
Edypion

For assemblies in the GAC, I recommend this approach:

1. Add the binaries as code coverage items from the directory, where they are built.
2. Create setup/cleanup batch files like that:

Setup one:

   gacutil -i %testdeploymentdir%\<Name of binary1>.dll
   ....

Cleanup should be like this:
   gacutil -u %testdeploymentdir%\<Name of binary1>
   ...
3. Add those files to test run configuration via run configuration editor.
4. Run your ASP.NET unit tests (ensure that Unit tests have HostType attribute set to "ASP.NET").

If the setup and cleanup scripts executed correctly (check run details), this should give you coverage data for the instrumented binaries.
Sai A
Hi Boris,

I am using RC1. The selected binaries are not strong name signed at this point, but will be soon. They are installed in the GAC.

I tried your suggestion - added the website to my solution, deselected all binaries from code coverage and selected the website instead. With this the error that I was getting at the end of the test run went away. But I still see no code coverage. In the code coverage panel, I still see "Empty results generated: none of the instrumented binary was used. Look at test run details for any instrumentation problems."

Thanks,
BBN11
You may need to force the removal of the GAC: gacutil -i -u. I recommend that you do this before running tests. Then try the web site/service to ensure that it is failing.

Also ensure that the binaries are really used by your tests. You may attach a debugger to IIS worker process.

If you are not using Windows XP: Are you using a remote desktop to connect to that machine Code coverage collection works only on the same session and IIS worker process runs usually on session 0.
POV Dev
I disabled the signing verification as you suggested. I now see that the binary gets instrumented and is put in the out directory of TestResults. It also gets added to the GAC based on the setup script. However my tests still seem to pick up the uninstrumented binary from the GAC. So, as part of the setup script I tried removing the original uninstrumented binary before adding the instrumented binary in the TestDeploymentDir to the GAC. My tests pass, but still no coverage results - I still see the "none of the instrumented binaries was used" in code coverage window...
Rosen M

I've got a similar situation here where I'm trying to get code coverage on a class library with unit tests:

Instrumentation warning: Cannot extract the public key from the key file 'C:\Projects\Common\Common\Public.snk': Bad Version of provider. (Exception from HRESULT: 0x80090007)
Check that the key file is not password protected. Password protected key files are not supported.
Code coverage instrumentation warning while processing file Common.dll:
Warning VSP2001 : C:\Projects\Common\Common\bin\Debug\Common.dll is a strongly named assembly. It will need to be re-signed before it can be executed.
Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.
.

When I use the public key to resign at the command prompt (sn -R <assembly> <key>) it returns:

Failed to extract public key from key pair -- Bad Version of provider.

When I use the private key to resign it works. Shouldn't I be able to use a public key for a delay re-signing

Thanks,
Colin
McAuliffe

Yes the assemblies were being picked up from the GAC.

Boris,

Thanks for your suggestions - I tried step 1 through 4.

I am however getting the following error (and also, my tests were not executed):
Code coverage instrumentation warning while processing file WebControls.dll:
Warning VSP2001 : C:\Program Files\Dev\WebControls.dll is a strongly named assembly. It will need to be re-signed before it can be executed.
Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.

I then realized that the binaries are actually delay signed with a .snk file. On resigning it with the .snk file in the code coverage pane, I get another error:
Instrumentation warning: Cannot extract the public key from the key file 'C:\Program Files\Dev\WebControls\PublicKey.snk': Bad Version of provider. (Exception from HRESULT: 0x80090007)
Check that the key file is not password protected. Password protected key files are not supported.
Code coverage instrumentation warning while processing file WebControls.dll:
Warning VSP2001 : C:\Program Files\Dev\WebControls.dll is a strongly named assembly. It will need to be re-signed before it can be executed.
Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.

What can I do at this point

Thanks
adil taqi
The following two warnings are normal and are expected:

Warning VSP2001 : C:\Program Files\Dev\WebControls.dll is a strongly named assembly. It will need to be re-signed before it can be executed.
This warning appears just to inform you that it is signed and you will need to resign it. Actually, you can also disable signing verification instead of resigning.

Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.
This warning appears because the managed binary is marked to run on an agnostic platform, but the instrumented binary can only run on X86. This warning appears almost always unless you build the managed binary for X86 (which is not the default)

There are two things to check here:
1. Is the key file okay
2. Does it work if you disable signing verification (sn -Vr <BinaryPath>) instead of resigning an instrumented binary
Wally_West
Hello,

Which version of VS2005 are you using Are selected binaries strong-name signed Are those binaries installed in the GAC

Can you also try this:

1. Add your the web site to your solution.
2. From test run configuration editor, Code Coverage pane deselect all binaries.
3. Select there the web site for code coverage.

In general, for ASP.NET unit tests you should select the web site itself, not the binaries.

Regards,
Boris
Sid Sidhartha

You can also check whether the key file is not corrupt by running the following command:

sn -R <any assembly> <The key file from above>
Ankur gupta -
The issue here might be that you are instrumenting the binaries in the bin folder of the website, while the binaries are being picked up from the GAC, which are not instrumented.

You can verify whether the instrumented or uninstrumented binaries are being loaded into the ASP.NET process by attaching a debugger to the ASP.NET worker process (w3wp.exe for Win2K3 or aspnet_wp.exe for WinXP/Win2K) and going to Modules view and looking at the path of your modules.

Can you check that and tell me what you find out

-Munjal (MS)
Difficulties in getting Code coverage information

Answer this question