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
I have a PC that is used to provide a CI build for a number of projects that require Typemock Ioslator.

This PC was running Isolator 5.2 but I recently upgraded it to 5.3 (and it removed 5.2 in the process of running the MSI). This broke some of my builds as they were bound to 5.2

What is considered the best practice for this type of PC?
asked by rfennell (6.8k points)

5 Answers

0 votes
What we have done in these situations is to use the "auto-deploy" feature that Typemock Isolator has.

Instead of installing Isolator on the continuous build box, check in the subset of required libraries (listed on the doc page) with your code. You can even change your project references to point to these checked in versions rather than the ones installed on everyone's local development machine.

When your build script runs, use the "TypeMockRegister" build task with "AutoDeploy" set to "true." That will install Isolator long enough to run your build. At the end of your build (fail OR success) use the "TypeMockStop" build task with "Undeploy" set to "true."

The net result of that is the proper version of Isolator will be installed "just in time" for your CI build and then uninstalled once it's done.

The drawback to this is that you can't have multiple builds running simultaneously that all auto-deploy Isolator because when one build finishes it could undeploy out from under the other build.

I have a blog article showing an example of this bringing NUnit, NCover and Typemock Isolator all together via MSBuild.
answered by tillig (6.7k points)
0 votes
Thanks for the excellent reply, Travis.
Richard, how were your builds linked to 5.2? was it a copied assembly reference?

Typemock Support
answered by doron (17.2k points)
0 votes
It was a reference to an assembly in the gac. So I was wondering was if a side by side GAC install was an option?

However, Travis's solution is a model I have used for other DLLs (bar the auto-depoly bit) i.e. make DLLs solution items and set the project reference hint path to a folder under source control - I will give that try as I like to minimise what I have to install on a build PC
answered by rfennell (6.8k points)
0 votes
I tried the 'register as I need it' model on the build server and the change to the build script is minor. Nice.

However do you have any thoughts on when there is 32bit/64bit issue e.g. a development PC has a 64bit OS (with Typemock 64bit on GAC) and the build box is a 32bit. If I put a 32bit Isolator DLLs under source control with a solution, reference that assembly in my project and register in MSBUILD as suggested all is fine on the build box. However on my developer PC when I run a test I
get System.FieldAccessException: TypeMock.MockManager.s. , type mock is confused by the 64bit .NET runtime

At least the method where MSBuild got the Typemock assembly from an installed copy in the GAC meant it resolved the correct 32/64 issues.

I am right in thinking that you cannot install 32bit Isolator on a 64bit box.

or is there some trick with reference hint path s I don't know
answered by rfennell (6.8k points)
0 votes
If you're developing in 64-bit for a 64-bit OS, the build box needs to be 64-bit. You can build 32-bit stuff on a 64-bit OS, but you can't go the other way around.

You can install 32-bit Isolator on a 64-bit box - we're doing that right now - but you can't have both 64- and 32-bit running at the same time.

The whole "bitness" aspect of things is something we're struggling with right now and I don't have a good answer for. We are working on a product that will target both 64- and 32-bit OS. Unfortunately, the TypeMockRegister task doesn't take a parameter saying which bitness to deploy, so we can't easily say "deploy the 32-bit version when the 32-bit build runs, undeploy that, then deploy the 64-bit version when the 64-bit build runs." The problem, as you noticed, being that you'd have to change the .csproj assembly references on the fly.

You could probably do some crazy fancy on-the-fly switcheroo by passing customized parameters into the "MSBuild" task that builds the .sln or .csproj file(s), but I've not gone down that path and it seems a little convoluted. You could also possibly do some file copy/replacement to switch the Isolator .dll files that sit in the same folder as the build task assembly so the appropriate version gets registered at the right time, but again, I've not gone down that path, either, so I don't know if you'll run into trouble.

The 64-bit vs. 32-bit problem is similar to the side-by-side installation problem (how do you have two different versions of Isolator installed at the same time?). I haven't seen a good solution for either of them.
answered by tillig (6.7k points)