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?