次の方法で共有

Getting rid of Warning VSP2013 in MSBuild

  • [アーティクル]

Running instrumentation and tests as part of the build machine could produce the VSP2013 warning. Our build machine is 64 bit and the VSInstr.exe tool seems to only work on platform dependent assemblies instead of just platform diagnostic as usually your assemblies are built using the platform (Any CPU).

The default vsinstr.exe used is the 32bit version even if you are instrumenting on a 64bit machine. This is because MSTest.exe and Visual Studio are both 32bit applications. So, if MSTest is going to run your tests it should operate on a 32bit or platform independent assemblies. Yet, you can change the default to use the 64bit version of vsinstr.exe by changing this registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\InstalledProducts\Instrumentation\Location

to point to the x64 folder. In my machine it’s: C:\Program Files (x86)\Microsoft Visual Studio 9.0\Team Tools\Performance Tools\x64

This should remove the warning. But as I said, if you are running your tests using MStest.exe as part of the build machine, this won’t allow your tests to run.

Off course, the easiest way to fix the warning without any hacks is to build your assemblies using the platform x86. If you don’t want to do that because you still want to produce platform independent assemblies, you can do this simple hack.

Write a command line file in the same folder of the VSInstr.exe tool that calls VSInstr.exe with –nowarn:2013.

Here are the steps:

  1. Create the file “VsInstrNoWarn2013.cmd” under “C:\Program Files (x86)\Microsoft Visual Studio 9.0\Team Tools\Performance Tools”
  2. Write the following in the command file:
         "%~dp0\VsInstr.exe" -NOWARN:2013 %1 %2 %3 %4 %5 %6 %7 %8 %9
  3. Change the key value of “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\InstalledProducts\Instrumentation\VSInstr” from VsInstr.exe to VsInstrNoWarn2013.cmd

In this way, MSTest will execute VSInstrNoWarn2013.cmd instead and all arguments will be forwarded.

I tested this and seems to work fine as part of a build machine. I haven’t tested this as part of a regular Visual Studio run.