Just so I don’t forget how to do it…
The command-line sequence is as follows:
- Instrument the assemblies that you want to provide code coverage information using VSInstr.exe (32-bit version at %VSInstallDir%\Team Tools\Performance Tools\VSInstr.exe, or 64-bit version at %VSInstallDir%\Team Tools\Performance Tools\x64\VSInstr.exe) with the /COVERAGE switch.
This will write two new files for the instrumented assembly (if PDB’s are available) named after the instrumented assembly and its PDB file with the pdb.instr extension. The original assembly is renamed to AssemblyName.Extension.orig and the original PDB is left unchanged.
A side effect of this instrumentation is that your assembly will now have a dependency on VSCoverX.dll (where X is 80, 90, or 100, depending on the Visual Studio version). This dependency is what sends your coverage information to the performance profiler. - Start the performance profiler using VSPerfCmd.exe (32-bit version at %VSInstallDir%\Team Tools\Performance Tools\VSPerfCmd.exe, or 64-bit version at %VSInstallDir%\Team Tools\Performance Tools\x64\VSPerfCmd.exe) so that it can begin collecting code coverage information. The command-line is /START:COVERAGE /WAITSTART /USER:”%USERDOMAIN%\%USERNAME%” /TARGETCLR:vn.n.nnnn /OUTPUT:”pathToCodeCoverageResultFile”.
- Perform your tests (using the same bit-ness that you’re profiling, 32-bit or 64-bit), either manually or using whatever automated testing framework you wish.
- Stop the performance profiler using VSPerfCmd.exe with the /SHUTDOWN switch.
- As a last step, rename your *.orig assemblies back to their original names, either deleting or renaming the instrumented versions.
You should now be able to open the code coverage file at pathToCodeCoverageResult in Visual Studio to examine the code coverage information, or create an XML report using VSPerfReport.exe.
No comments:
Post a Comment