How do I manage deployment item references that may either be on an x86 install, or x64 install for an MSTest-based project?

Question

Much related to this question, we have a scenario on my team where we need to copy the contents of a folder for a suite of libraries and configuration files for said libraries to our folder where our test code is running from, as part of the test's deployment step.

Due to the installation size, and other factors, checking in this install folder into source control for sharing between team members just isn't viable.

The install path for the folder is either /Program Files/InternalTool/ or /Program Files (x86)/InternalTool/ depending on the installed environment. I want to setup my .testrunconfig file such that when a person gets the latest version of the solution, they don't have to worry about fixups for the path to the shared internal library suite.

Is there a way to make this seamless for all members involved, and if so, how could one accomplish this?

Restrictions are as follows:

• can't check in shared suite
• shared suite has no override for installation path

Is this possible, or am I asking for too much?

Answer 1

We handle this sort of issue (our issues are not the same but are similar) by having different config files with different names and copying the correct one over when it is needed.

In some cases we automate this within the batch job that gets the latest version.

Answer 2

This was actually way, way easier than I expected.

While the UI doesn't support many things with the local test run config file, I was able to set the path using the standard %ProgramFiles%.

• On x86 systems, this resolves, on most systems, to C:\Program Files\.
• On x64 systems, this resolves, on most systems, to C:\Program Files\.

But! If the caller is 32-bit, and not 64-bit or set to MSIL, %ProgramFiles% will resolve to C:\Program Files(x86)\. Since there is no 64-bit mstest, the resolution should happen seamlessly. For an example, this is ripped from my LocalTestRun.testrunconfig file, and then properly sanitized:

  <Deployment>
    <DeploymentItem filename="%ProgramFiles%\InternalSuite\" />
  </Deployment>

While I haven't had the chance to fully test this yet, this should resolve our issue just fine. I have tested this on my 32-bit system, and have found that it resolves right as rain.

Hope this helps someone else!