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
Welcome to Typemock Community! Here you can ask and receive answers from other community members. If you liked or disliked an answer or thread: react with an up- or downvote.
0 votes
Hi there,
I'd just like to make some observations (NOT critisisms!) about my installation experience for TypeMock.net - maybe it will help make a great product better...

1) My dev box is a 64bit machine, my build server is 32 bit. When installing on a 64bit machine, TypeMock wants to install into "Program Files (x86)", and on a 32bit machine it wants to install into "Program Files".

When I add an assembly reference to the TypeMock.dll, on my dev box, it references the TypeMock DLL in the x86 folder, but this breaks the build on the build server, as it cannot find the DLL.

I tried to change the installation dir on the 64bit machine to be "Program Files", but the dialog would not let this happen.

To get over this issue, I needed to add a "Lib" folder to my Team project, copy the DLL into that folder and reference that DLL. So that when the build server pulls the source and lib folders from TeamSystem, it will find the referenced DLL.

2) I modified my TFSBuild.proj to use the <TypeMockStart> and <TypeMockStop> tasks as recommended in the documentation, however it neglected to mention that the TypeMock.MSBuild.tasks needs to be imported into the TFSBuild.proj file.

However, the .tasks file is in the TypeMock installation folder, which due to issue 1 above, poses problems for 64bit vs 32bit machines. The standard approach for task definition files is to install and reference them from the $(MSBuildExtensionsPath) folder, which is (from the POV of the .proj file) platform independent. IF this was the case, then the following could be added:

<Import>


But this is not the case.

To get over this issue, I needed to add both the TypeMock.Msbuild.DLL and TypeMock.MSBuild.tasks to my TeamBuildTypesuildtype folder. I was then able to add the following to my TFSBuild.proj file:

   <Import>
   <Target>
      <TypeMockStart>
   </Target>
   <Target>
      <TypeMockStop>
   </Target>


Anyway, these are minor issues to overcome compared to the benefits that TypeMock is brining to my testing.

Sincerely
Pete
________
Vaporizer forums
asked by pmcevoy (4.7k points)

2 Answers

0 votes
Hi Pete,
Thank you for sharing your experience, We will take your points seriously.

:idea: BTW, the msbuild task is platform dependant and is included in both 32 and 64 bit for conveniance. You can map the tasks files if you perfer in $(MSBuildExtensionsPath), and this will work for all platforms.

:arrow: I am glad that TypeMock.NET helps you create better code.
answered by scott (32k points)
0 votes
After trying out the scenario myself and rereading your post, I think that the scenario you wrote is expected behaviour as on the x64 machine all x32 applications are installed in "Program Files (x86)".

The problem you are seeing is a different one. As each developer can install TypeMock or any other product at different locations, the build proceeder might fail on different machines. You must define a company policy on how to solve this.
Here are some examples of known policies, most are a combination

:arrow: One Policy is for eveyone to install the software at the same location.
:arrow: Another is to create a 'Lib' directory and to put all referenced dll's in this directory (this gives an advantage of easily keeping these in a source control system and ensuring that the builds can be replicated without many prerequisit installations)
:arrow: A Third is by using System Envrionment Variables to point to the locations on each system.
answered by scott (32k points)
...