But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

Running Typemock Isolator based tests in TFS vNext build

Typemock Isolator provides a way to ‘mock the un-mockable’, such as sealed private classes in .NET, so can be a invaluable tool in unit testing. To allow this mocking Isolator interception has to be started before any unit tests are run and stopped when completed. For a developer this is done automatically within the Visual Studio IDE, but on build systems you have to run something to do this as part of your build process. Typemock provide documentation and tools for common build systems such as MSBuild, Jenkins, Team City and TFS XAML builds. However, they don’t provide tools or documentation on getting it working with TFS vNext build, so I had to write my own vNext build Task to do the job, wrapping Tmockrunner.exe provided by Typemock which handles the starting and stopping of mocking whilst calling any EXE of your choice.

tmockrunner <name of the test tool to run> <and parameters for the test tool>

Microsoft provide a vNext build task to run the vstest.console.exe. This task generates all the command line parameters needed depending on the arguments provided for the build task. The source for this can be found on any build VM (in the [build agent folder]\tasks folder after a build has run) or on Microsoft’s vso agent github repo. I decided to use this as my starting point, swapping the logic to generate the tmockrunner.exe command line as opposed to the one for vstest.console.exe. You can find my task on my github. It has been developed in the same manner as the Microsoft provided tasks, this means the process to build and use the task is

  1. Clone the repo https://github.com/rfennell/vNextBuild.git
  2. In the root of the repo use gulp to build the task
  3. Use tfx to upload the task to your TFS or VSO instance

See http://realalm.com/2015/07/31/uploading-a-custom-build-vnext-task/ and http://blog.devmatter.com/custom-build-tasks-in-vso/ for a good walkthroughs of building tasks, the process is the same for mine and Microsoft’s tasks.

IMPORTANT NOTE: This task is only for on premises TFS vNext build instances connected to either an on premises TFS or VSO. Typemock at the time of writing this post does not support VSO’s host build agents. This is because the registration of Typemock requires admin rights on the build agent which you only get if you ‘own’ the build agent VM

Once the task is installed on your TFS/VSO server you can use it in vNext builds. You will note that it takes all the same parameters as the standard VSTest task (it will usually be used as a replacement when there are Typemock Isolator based tests in a solution). The only addition to the parameters are the three parameters for Typemock licensing and deployment location.


Using the task allows tests that require Typemock Isolator to pass. So test that if run with the standard VSTest task give


With the new task gives


Strange TFS build process template editing issue with Typemock

Had a strange issue today while editing our standard TFS 2013 XAML build process template to add an optional post drop script block to allow a Release Management pipeline to be triggered via REST. Our standard template includes a block for enabling and disabling Typemock, after editing our template to add the new script block (nowhere near the Typemock section) our builds failed with the error

TF215097: An error occurred while initializing a build for build definition \BM\ISS.Expenses.Main.CI: Exception Message: Cannot set unknown member 'TypeMock.TFS2013.TypeMockStart.DisableAutoLink'. (type XamlObjectWriterException) Exception Stack Trace: at System.Xaml.XamlObjectWriter.WriteStartMember(XamlMember property) 

It took ages to find the issue, we hunted for badly formed XAML, but the issue turned out to be that when ever we opened the template in Visual Studio 2013 it added the highlighted property


<If Condition="[UseTypemock = True]" DisplayName="If using Typemock" sap2010:WorkflowViewState.IdRef="If_8">
   <Sequence DisplayName="Enabling Typemock" sap2010:WorkflowViewState.IdRef="Sequence_16">
      <tt:TypeMockRegister AutoDeployDir="[TypemockAutoDeployDir]" Company="[TypemockCompany]" sap2010:WorkflowViewState.IdRef="TypeMockRegister_1" License="[TypemockLicense]" />
      <tt:TypeMockStart DisableAutoLink="{x:Null}" EvaluationFolder="{x:Null}" Link="{x:Null}" LogLevel="{x:Null}" LogPath="{x:Null}" ProfilerLaunchedFirst="{x:Null}" Target="{x:Null}" Verbosity="{x:Null}" Version="{x:Null}" AutoDeployDir="[TypemockAutoDeployDir]" sap2010:WorkflowViewState.IdRef="TypeMockStart_1" />

It should have been

<If Condition="[UseTypemock = True]" DisplayName="If using Typemock" sap2010:WorkflowViewState.IdRef="If_8">
    <Sequence DisplayName="Enabling Typemock" sap2010:WorkflowViewState.IdRef="Sequence_16">
       <tt:TypeMockRegister AutoDeployDir="[TypemockAutoDeployDir]" Company="[TypemockCompany]" sap2010:WorkflowViewState.IdRef="TypeMockRegister_1" License="[TypemockLicense]" />
       <tt:TypeMockStart EvaluationFolder="{x:Null}" Link="{x:Null}" LogLevel="{x:Null}" LogPath="{x:Null}" ProfilerLaunchedFirst="{x:Null}" Target="{x:Null}" Verbosity="{x:Null}" Version="{x:Null}" AutoDeployDir="[TypemockAutoDeployDir]" sap2010:WorkflowViewState.IdRef="TypeMockStart_1" />

All I can assume is that this is due to some assembly mismatch between the Typemock DLLs linked to the XAML build process template and those on my development PC.

The fix for now is to do the editing in a text editor, or at least checking the file to make sure the property has not been edited before it is checked in.

Getting the Typemock TFS build activities to work on a TFS build agent running in interactive mode

Windows 8 store applications need to be built on a TFS build agent running in interactive mode if you wish to run any tests. So whilst rebuilding all our build systems I decided to try to have all the agents running interactive. As we tend to run one agent per VM this was not going to be a major issue I thought.

However, whilst testing we found that any of our builds that use the Typemock build activities failed when the build agent was running interactive, but work perfectly when it was running as a service. The error was


Exception Message: Access to the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\TypeMock' is denied. (type UnauthorizedAccessException)
Exception Stack Trace:    at Microsoft.Win32.RegistryKey.Win32Error(Int32 errorCode, String str)
   at Microsoft.Win32.RegistryKey.CreateSubKeyInternal(String subkey, RegistryKeyPermissionCheck permissionCheck, Object registrySecurityObj, RegistryOptions registryOptions)
   at Microsoft.Win32.RegistryKey.CreateSubKey(String subkey, RegistryKeyPermissionCheck permissionCheck)
   at Configuration.RegistryAccess.CreateSubKey(RegistryKey reg, String subkey)
   at TypeMock.Configuration.IsolatorRegistryManager.CreateTypemockKey()
   at TypeMock.Deploy.AutoDeployTypeMock.Deploy(String rootDirectory)
   at TypeMock.CLI.Common.TypeMockRegisterInfo.Execute()
   at TypeMock.CLI.Common.TypeMockRegisterInfo..ctor()   at System.Activities.Statements.Throw.Execute(CodeActivityContext context)
   at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
   at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)


So the issue was registry access. Irrespective of whether running interactive or as a service I used the same domain service account, which was a local admin on the build agent. The only thing that changed as the mode of running.

After some thought I focused on UAC being the problem, but disabling this did not seem to fix the issue. I was stuck or so I thought.

However, Robert Hancock unknown to me, was suffering a similar problem with a TFS build that included a post build event that was failing to xcopy a Biztalk custom functoid DLL to ‘Program Files’. He kept getting an ‘exit code 4 access denied’ error when the build agent was running interactive. Turns out the solution he found on Daniel Petri Blog also fixed my issues as they were both UAC/desktop interaction related.

The solution was to create a group policy for the build agent VMs that set the following

  • User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode - Set its value to Elevate without prompting.
  • User Account Control: Detect application installations and prompt for elevation - Set its value to Disabled.
  • User Account Control: Only elevate UIAccess applications that are installed in secure locations - Set its value to Disabled.
  • User Account Control: Run all administrators in Admin Approval Mode - Set its value to Disabled.

Once this GPO was pushed out to the build agent VMs and they were rebooted my Typemock based build and Robert Biztalk builds all worked as expected

TF900548 when using my Typemock 2012 TFS custom build activity

Using the Typemock TFS 2012 Build activity I created I had started seen the error

TF900548: An error occurred publishing the Visual Studio test results. Details: 'The following id must have a positive value: testRunId.'

I thought it might be down to having patched our build boxes to TFS 2012 Update 1, maybe it needed to be rebuild due to some dependency? However, on trying the build activity on my development TFS server I found it ran fine.

I made sure I had the same custom assemblies and Typemock autorun folder and build definition on both systems, I did, so it was not that.

Next I tried running the build but targeting an agent not on the same VM as the build controller. This worked, so it seems I have a build controller issues. So I ran Windows update to make sure the OS was patched it to date, it applied a few patches and rebooted. And all was OK my test ran gain.

It does seem that for many build issues the standard switch it off and back on again does the job

Cannot run Microsoft Fakes based test if Typemock Isolator enabled

With Microsoft Fakes moving to the Premium SKU of Visual Studio in 2012.2 (CTP4 is now available) more people will be looking at using them.

I have just installed CTP4 and have seen a behaviour I don’t think I have not seen in the previous version of Visual Studio (I need to check because as well as CTP4  I have recently installed the new version of Typemock Isolator 7.3.0 that addresses issues with Windows 8 and Visual  Studio 2012).

Anyway the error you see when you run a fakes based test is ‘UnitTestIsolation instrumentation failed to initialialize, Please restart Visual Studio and rerun this test’


The solution is to disable Typemock Isolator (Menu Typemock > Suspend Mocking), when this is done, without a reboot, the Fakes based test run.

Does mean you can’t have a solution using both Fakes and Isolator, but why would you?

For those hard to mock moments - Microsoft Fakes or Typemock Isolator?

About a year ago I wrote a post ‘Now that VS11 has a fake library do I still need Typemock Isolator to fake out SharePoint?’. Well this discussion becomes relevant for more people as with Visual Studio 2012.2 (currently available as a CTP) the Microsoft Fakes move from the Ultimate SKU to the Premium SKU.

From my experience the Ultimate SKU is not present on too many developer’s PCs. It is most commonly found on the PCs of the team leads, software architects or test developers (managing coded UI/load testing etc. efforts). If a team was historically going to use Microsoft Fakes then they had to buy more Ultimate SKUs; as what is the point of a unit test using a mocking framework that only part of the team can run?

The Premium SKU of Visual Studio is far more common, I would go as far as to say it is the corporate standard for development. Now as this SKU contains Test Manager (since 2012 RTM) it covers most jobs most developers do. Ultimate is just needed for the specialists in the team. Adding fakes to the Premium SKU really makes sense if Microsoft want to drive adoption.

So now the question of whether to use Microsoft Fakes or Typemock Isolator (or Telerik JustMock a product I have to admit I have not used in anger) is rebalanced as there is a fair chance a development team may all be licensed for Microsoft Fakes as they have the premium SKU. The question becomes is the cost of Isolator justified by the features it offers over and above Microsoft Fakes?

This is not an uncommon form of question for any third party add-in to Visual Studio. Visual Studio offers refactoring, but I think few would argue that Resharper or RefactorPro! don’t offer more features that justify their cost.

For me the big advantage of Typemock is ease of use and consistent syntax across all usage patterns. This could be just due to familiarity, but the fact I don’t need to manually generate the fake assembly is a bonus. Also that Isolator’s fluent API is basically the same as Moq and FakeItEasy so causes less friction when coming to advanced mocking from these tools. A team can use the free basic version of Typemock Isolator until they need the advanced features when they need to license it.

Fakes is a different way of working to most other frameworks, working at a different level inside Visual Studio. A disadvantage of this is that it does not lend itself well to refactoring, you are probably going to have to regenerate the fake assemblies after any refactor, which can be slow. Also this makes refactoring a bit more risky, as you also have to touch unit tests, a manual operation.

I think at this time for me Isolator still offers advanced features and easy of use advantages that justifies the license cost. However, as with all tools this is an ever changing field, I expect to see new features and changes for all the players in the fakes market as they all aim to better address the problems cause by the poorly architecture of applications/frameworks such as SharePoint and of course our own poorly designed legacy code.

New release of Typemock Isolator

Typemock have released a new version of Isolator (7.3) that addresses some problems they have been having with Visual Studio 2012 and Windows 8

  • Resolved all issues concerning the breaking MS update
  • Boosted performance across the board (up to 44% faster)
  • Enhanced SmartRunner UI
  • Improved mocking capabilities
  • Better integration with .NET development ecosystem

You can download this release, or a free trial if you don’t have an Isolator license, from the Typemock site

Release of Typemock Isolator Basic edition

Some great news today from Typemock, there is now a free basic edition of Typemock Isolator. The addresses a key historic problem with Isolator, that of its cost when you don’t need the advanced features of Isolator all the time.

Now if you need the cool advanced mocking features of Isolator, such as mocking sealed private classes, then the cost is not really a factor, you buy the product or don’t get the features. However what do you do if you just want to do just do ‘normal mocking’ in a project ? e.g. mock out an interfaces. Do you use Typemock as you already have it, or swap to a different mocking framework, only using Typemock when you have to use its advanced features?

This is a particular problem for consulting/bespoke development companies such as mine, we write code for clients that in the future they will have to maintain themselves, they are not that happy with us passing over code with a dependency on a licensed mocking framework unless it is essential to their project. This means in the past I have tended to use other mocking frameworks, usually FakeItEasy as its syntax is very similar to Typemock Isolator, unless I need its advanced features of Typemock such as in SharePoint projects.

However with this new basic edition release from Typemock this is no longer an issue. I can use Typemock in all my projects. If a client need to run the tests, as long as they are ‘normal mocking’ ones, all they need to do is install this new free version of Typemock and the project builds and the tests run. There is only a need to purchase a license if the advanced features of Typemock are required.

So longer do I need to swap mocking framework for only licensing reasons, hence reducing the friction I have had in the past changing mocking syntax.

Getting Typemock Isolator running within a TFS 2012 build – part 2

I posted previously on getting Typemock 7.x running in a TFS 2012 RC build process . Well it seems the activities I previously published did not work on the TFS 2012 RTM build i.e if you do nothing other than upgrade your TFS server from RC to RTM a previously working build fails, no attempt was made to run any tests and I got the unhelpful error

TF900546: An unexpected error occurred while running the RunTests activity: 'Executor process exited.'.

Note: TF900546 seems to be the generic – test failed error number. If you see it you will usually have to look elsewhere for anything helpful.

So I assumed that the problem must be some difference with the TeamFoundation assemblies I was referencing between the RC and RTM versions, so I rebuilt my activities, all to no effect, I got the same error. So I did some more digging into the code. I found a number of issues, why these had not caused an issue before I don’t know:

Target property

If you do not specify a .NET version via the Target property of the TypeMockRegister activity it does not attempt to start interception. As setting this property every time you want to use the activity is a pain, I modified the activity so that if no Target property is passed then the value v4.0.30319 is used, the version of .NET 4.5 as it appears in the c:\windows\Microsoft.Net\framework folder.

Note Missing of the leading v if the Target value causes the TFS build agent to hang, I have no idea why.

Once this change was made the build ran and it tried to run all my tests, but the ones involving Typemock failed, with the message

Test method BuildProcessValidation.Tests.MSTestTypemockTests.DirtyTrickMockingWithTypemock_Email_is_sent_when_client_order_is_processed threw exception:
System.TypeInitializationException: The type initializer for 'f5' threw an exception. ---> System.TypeInitializationException: The type initializer for 'TypeMock.InterceptorsWrapper' threw an 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)

On looking in the build box’s event log I saw the message

.NET Runtime version 4.0.30319.17929 - Loading profiler failed during CoCreateInstance.  Profiler CLSID: '{B146457E-9AED-4624-B1E5-968D274416EC}'.  HRESULT: 0x8007007e.  Process ID (decimal): 2068.  Message ID: [0x2504].


Basically the issue was the Typemock interceptor, the profiler, was not being started because Typemock was not installed on the build box. To prove this I manually installed Typemock on the build box and the error went away, all my tests ran. So happy my activity basically worked, I removed Typemock from the build box and the problem returned, so I know I had an autodeployment issue.

On checking the activity code again I found I was not handling the nullable boolean correctly for the AutoDeploy build argument of the type TypemockSettings. As soon as this was fixed and deployed by build leapt into life.

In summary

So I am please to say I have a working activity again, as I said in my previous post I see this as stopgap measure until Typemock Release their official version. This set of activities have had minimal testing and I am not sure the undeploy logic is working fully, but as I don’t need this feature I am not worrying about it for now.

Hope you find it useful in its current state.

Using an internal Nuget server to manage the Typemock assembly references.

In my last post I discussed the process I needed to go through to get Typemock Isolator running under TFS 2012. In this process I used the Auto Deploy feature of Isolator. However this raised the  question of how to manage the references within projects. You cannot just assume the Typemock assemblies are in the GAC, they are not on the build box using auto deploy. You could get all projects to reference the auto deployment location in source control. However, if you use build process templates across projects it might be you do not want to have production code referencing build tools in the build process are directly.

For most issues of this nature we now use Nuget. At Black Marble we make use of the public Nuget repository for tools such as XUnit, SpecFlow etc. but we also have an internal Nuget repository for our own cross project code libraries. This includes licensing modules, utility and data loggers etc.

It struck me after writing the last post that the best way to manage my Typemock references was with a Nuget package, obviously not a public one, this would be for Typemock to produce. So I create one to place on our internal Nuget server that just contained the two DLLs I needed to reference (I could include more but we usually only need the core and act assert arrange assemblies).

[Update 6th Aug PM] – After playing with this today seems I need the following in my Nuget package


If you miss out the configuration.dll it all works locally on a developers PC, but you get a ‘cannot load assembly error’ when trying to run a TFS build with Typemock auto deployment. Can’t see why obviously but adding the reference (assembly to the package) is a quick fix.



IT IS IMPORANT TO NOTE that using a Nuget package here in no way alters the Typemock licensing. Your developers still each need a license, they also need to install Typemock Isolator, to be able to run the tests and your build box needs to use auto deployment. All using Nuget means is that you are now managing references in the same way for Typemock as any other Nuget managed set of assemblies. You are internally consistent, which I like.

So in theory as new versions of Typemock are released I can update my internal Nuget package allowing projects to use the version they require. It will be interesting to see how well this works in practice.