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 also emailed this information to your support group.

We are attempting to upgrade our team to Isolator 5.1.1 from 4.2.4. Part of that upgrade includes upgrading our build server, which is running Windows Server 2003 R2 Standard x64 Service Pack 2. Instead of installing the new version, I decided to uninstall the previous release and then to update our automated build scripts (using MSBuild) to use the Auto-Deploy (<TypeMockRegister>) feature. An excerpt from my MSBuild script is included below:

<Import Project ="$(TypeMockLocation)TypeMock.MSBuild.Tasks"/>
<TypeMockRegister Company="our company" License="our license" AutoDeploy="true" />
<TypeMockStart Target="2.0" LogLevel="9" LogPath="$(NUnitOutputPath)" />

<exec Command="$(NUnit) $(NUnitAssemblyName) /xml $(NUnitOutputPath)$(NUnitResultsFile) /exclude:DatabaseIntegrationTest"/> 
<TypeMockStop />

The register task appears to run ok. However, when I execute the unit tests, many of them fail with the following exception:

TypeMock.TypeMockException : *** Typemock Isolator needs to be linked with Coverage Tool to run, to enable do one of the following: 1. link the Coverage tool through the Typemock Isolator Configuration 2. run tests via TMockRunner.exe -link 3. use TypeMockStart tasks for MSBuild or NAnt with Link For more information consult the documentation (see Code Coverage with Typemock Isolator topic)

at TypeMock.MockManager.Init(Boolean collectAllCalls)
at TypeMock.MockManager.e(Type A_0)
at TypeMock.MockManager.Mock(Type type, Constructor mockConstructors)
at TypeMock.MockManager.MockObject(Type type, Constructor mockConstructors, Object[] args)
at TypeMock.RecorderManager.CreateMockedObject(Type typeToMock, Constructor mockConstructor, StrictFlags strictFlags, Object[] args)
at TypeMock.RecorderManager.CreateMockedObject[TMockedType](Constructor mockConstructors, StrictFlags strictFlags, Object[] args)…

We are not attempting to run the NCover tool, nor is it installed on our build server. I’ve done some web searches and have seen that others have had a similar error (see below) but I haven’t been able to find a resolution. ... 15d5686e87

Some further, possibly helpful, information is that, to get the TypeMock x64 assemblies to use for the auto-deploy option, I first installed it on the build machine, made copies of the assemblies, and then uninstalled it. After that, I created a “TypeMockAssemblies.1” folder to use as the location for the auto-deploy files and copied in the files indicated in the TypeMock documentation, first taking MockWeaver.dll and ProfileLinker.dll from the x64 folder of the install directory. When I ran the first test of this setup, it resulted in some type of error when it attempted to register MockWeaver.dll. (I can get you detailed error information, if need be.) So, since the documentation says to use the x86 version of that and the ProfileLinker assemblies, I then copied the x86 versions over the x64 versions in my “TypeMockAssemblies.1”. The registration completed and it began to execute the unit tests and that is when I encountered the “Coverage Tool” issue.

I spoke with a coworker that had encountered the same issue when first setting up TypeMock on our build server. She said that to resolve the issue she had to remove the <TypeMockStop> instruction. However, I just tried this and it did not solve the issue.

One thing I should also note is that the assembly containing the unit tests was compiled with the 4.2.4 release of Isolator. I realize this will be a problem but I expect to get a different error message for that reason. I will resolve that issue shortly.
asked by RonRatz (3k points)

4 Answers

0 votes
Hi Ron

I just wrote you an an answer to the support mail :)

This problem happens when the Isolator is enabled a different context than the test runner.
e.g The Isolator is enabled in 64 bit and the runner runs as 32 bit process.

Some versions of NUnit use different runners for 32 bit and 64 bit.
For example NUnit 2.4.8 uses nunit-console.exe for running in 64 bit and nunit-console-x86.exe for 32 bit.

If the NUnit version you are using has two runners try using the 32 bit version. This will fit the msbuild context since it runs as 32 bit process as well.
answered by ohad (35.4k points)
0 votes
We are running NUnit 2.4.6 and my MSBuild task is running “nunit-console.exe”.

Ok, so I changed the build job to execute nunit-console-x86.exe and now I’m getting the mismatched version error that I expect. So, using the x86 version seems to have resolved the issue. Is this working as you would expect – having to run the x86 version on a x64 box?

Not sure if this is relevant but, as I mentioned in my initial post, when I initially tested, I tried to use the x64 versions of MockWeaver.dll and ProfileLinker.dll and encounter and error so I then used the x86 versions as the documentation indicates. That seemed strange to me since I’m running on an x64 box.
answered by RonRatz (3k points)
0 votes
Hi Ron

The mismatch version exception is a result of a difference between the
installed version and run time loaded version (The version in the GAC)

Please check the GAC to see if there multiply versions of TypeMock.dll
than delete them from the GAC. (The auto deploy task should register the right dll)

As for your second question:
When the OS is 64 bit the processes can run as 64 bit OR as 32 bit.
Managed processes that are built with AnyCPU flag (default in Visual Studio)
can be run as both depends on a bit flag in their binary header.
You can set this flag by using the Corflags utility that comes with Visual Studio tools.
On the other hand if a process is built with the 64 bit flag it will always run as 64 bit.
This is the problem that you saw.
msbuild runs as 32 bit started a 64 bit process (NUnit) and the Isolator was enabled only in the 32 bit context (msbuild)

I think that our documentation is not accurate regarding the auto deploy:
On 64 bit machines you can copy the MockWeaver.dll and ProfileLinker.dll to a sub directory under the auto deploy directory and use Regsvr32.exe to register them.

Note that it would not solve your problem since msbuild is 32 bit process.

Hope it clears things up a bit :)
answered by ohad (35.4k points)
0 votes
I had expected the version mismatch issue and quickly fixed that once I got everything else working. We've now successfully upgraded and are using the auto-deploy feature for our build process.

I look forward to trying out the new AAA interface!

Thanks for your help.
answered by RonRatz (3k points)