I’m using a post-build step on my C# assembly to expose a function signature from my dll. This step uses the ExportDll tool from http://www.codeproject.com/KB/dotnet/DllExport.aspx. However, if I run my dll through mstest and attempt to get a code coverage report, I get the following error:
Instrumentation error while trying to process the file MyAssembly.dll
Error VSP1011 : Unable to obtain debug information. Link with the /Profile linker switch.
This is odd, considering that there is no unmanaged code in the assembly (other than a few P/Invoke signatures). If I take the post-build step out, my code is instrumented properly and I can get a code coverage report. Therefore, I can only conclude that it must be this post-build step and not something in the code itself.
I’m leaning on the idea of running my unit tests through the non-ExportDll version of the code while building and distributing the post-ExportDll version. Since I’m mainly interested in whether or not the code is tested rather than if other components can find the function through the DLL export, I don’t see this as a bad solution. However, I feel that it just might be a nightmare in build management and having to explain to the team “use this assembly, not that assembly”.
Has anyone had experience unit testing a dll that has been run through this tool? Or perhaps does anyone have experience instrumenting an assembly that has been compiled, decompiled, and reassembled using ildasm/ilasm?
The ExportDll utility rewrites the original assembly but it is probably not updating the PDB to take account of the new instrumentation when it recompiles using ilasm.The article doesn’t seems to say that this is possible but if you use the /pdb switch with ilasm, then this should produce a PDB that is compatible with your newly instrumented assembly.
Looking at the source code you need to add the switch to program.cs line 348 such that ilasm is then instructed to produce a new PDB.