Using Isolator’s Auto-Deploy

Michael Braude wrote about evaluating Typemock to hook into the code. His problem was that he felt he can’t make people install it prior to running their tests.

Well, first, why not? If you’re using Isolator’s API in your tests, and you want to run them, you need to have it installed. Sometimes you don’t want it installed on your build server, (for keeping the registry clean for example), but still want to run your tests.

So here’s auto-deploy. You can use this option from your build script to deploy Isolator from a single folder. To do this, copy all the DLLs from the Isolator directory. Also, from the x86 folder, copy the 2 dlls into that folder as well.

Then use the Register task (this example works with MSBuild, but also for the NAnt task) you specify the following:

<Import Project ="$(TypeMockLocation)TypeMock.MSBuild.Tasks"/>

<Target Name="RegisterTypeMock">
<TypeMockRegister Company ="Typemock" License="TypemockLicense" AutoDeploy="True"/>
</Target>

You call this target prior to the Start task, which you call before running your tests. And the you undeploy by:

<TypeMockStop Undeploy="True"/>

That’s it. The deployment process takes care of registering the COM object, and the undeploy process un-registers it. So this is a way to run multiple versions of Isolator on a build server.

  • Travis Illig

    A couple of gotchas when using the auto-deploy feature to watch out for:

    First, if you run this on your build server and you have multiple concurrent builds doing auto-deployment, you may run into a situation where Isolator gets uninstalled out from under a build. For example…
    * Build 1 auto-deploys Isolator
    * Build 2 auto-deploys Isolator
    * Build 1 runs tests
    * Build 1 undeploys Isolator
    * Build 2 fails to run tests because Isolator got undeployed

    You can fix this by either serializing your builds or by using something like build queues in CruiseControl.

    Second, if you auto-deploy on a system that already has Isolator installed, it corrupts your local installation of Isolator. It might continue working for a while, but I always end up having to repair my local installation if that happens. It’s worse if you try undeploying on a machine that has Isolator actually installed.

    To fix this, add conditions to the TypeMockRegister and TypeMockStop task so they only run on the build server. (You may need two instances of the TypeMockStop task – one that undeploys and only runs on the build server, one that doesn’t undeploy and only runs on developer machines.)

    Finally, be careful of the situation where you have one version of Isolator installed on your machine but a different version that your project is building against. Things might build fine, but you will run into inexplicable failures when the tests try to execute. This generally happens when you have a project where your third-party dependencies (like Isolator) get checked in for the benefit of the build server, but you also have some of these components installed so you can use them during development.

  • Gil Zilberfeld

    Travis,

    Thanks for the detailed description.
    Some of the problems will get corrected when we have side by side Isolator installations.
    Issue 2 was fixed a while ago (v5.0) but we’ll check this again. Since the undeploy happens on the Stop task – maybe in some cases it doesn’t get called and then the problem appears.

TOP