chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male
0 votes
I have a project with a reference to TypeMock.dll. In the csproj file, the reference looks like this:
<Reference Include="TypeMock, Version=, Culture=neutral, PublicKeyToken=3dae460033b8d8e2">
<HintPath>C:Program FilesTypeMockTypeMock.NETTypeMock.dll</HintPath>

The reference is old. I'm currently using version 3.7.1. As long as the HintPath is valid, this resolves correctly. The automated testing machines have TypeMock installed on D: instead of of C: so the HintPath is not valid there. These machines can't build the project because the reference resolves to TypeMock.exe, not TypeMock.dll. Apparently, there's an ambiguity in the identification of these two files.

How can I fix this to correctly compile in the two environments? One choice would seem to be to modify the project reference to replace the HintPath with $(TYPEMOCKROOT)TypeMock.dll. If this works, I'll consider it. However, it will require hand-editing all projects that reference TypeMock. Another choice might be to convince the owners of these machines to install TypeMock on C: (fat chance!).

Can you suggest a better solution to this problem?

asked by stimsonr (2.1k points)

4 Answers

0 votes
This is actually a restriction of Visual Studio.
There are two possibilities

:arrow: 1. Use an Environment Variable as you suggested.
You will have to define the environment variable on all machines
<Reference Include="TypeMock...">

:arrow: 2. With the Enterprise Edition, you can use the AutoDeploy feature.
This will enable multiple versions and enable you to copy the TypeMock files to your source tree.
Once the dll's are in your source tree you can use the relative path.
<Reference Include="TypeMock...">

The second method will also work better with version upgrades, where the version used will be the one in the source tree.
This makes the upgrade much simpler, via checking in the new version into the source tree
answered by scott (32k points)
0 votes

What functionality do you "loose" by using the AutoDeploy feature? Do you get the same support for running TypeMock in VS if you do not run the physical .msi? Also, what about tool integration with TestDriven.NET?

Reason I am asking is that we need the ability to run different versions of TypeMock on the same machine for doing production fixes of older versions where the latest has moved onto a new version of TypeMock.

answered by cjlotz (3k points)
0 votes
Hi Carl
Basically you get all the functionality of mocking in your tests
but without the integration with visual studio.
See the details here
Hope it helps.
answered by ohad (35.5k points)
0 votes
There is an unsupported feature that will enable your scenario.

1. A version of TypeMock has been installed with visual studio intergration.
2. You AutoDeploy to another version.

This will run the auto deployed version in Visual Studio including TestDriven.NET support.
Remember to AutoDeploy back to installed version.

I hope this helps
answered by scott (32k points)