Upgrade best practice question

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.

Thanks for the excellent reply, Travis.
Richard, how were your builds linked to 5.2? was it a copied assembly reference?

Doron
Typemock Support

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

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

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.