Bug with typemock.tfs2013.dll and autodeployment?

Up to now we have used TFS2012 based build process templates, but we are moving to the 2013 generation ones, tidying then as we go, just bring over the customisations we use.

An important one is Typemock using AutoDeployment. This has been working fine for our customised TFS2012 generation build process templates, we set the TypemockAutoDeployDir parameter in the TypemockSettings, pass this to the TypemockRegister activity and the required files are deployed to the build agent and my tests pass. Using TM 7.5.6.0 for a 2012 build template in the diagnostic log I see

Source AutoDeploy location is '$/BM/BuildProcessTemplates/TypemockAutoDeploy'
AutoDeploy translated to 'C:B3RSourcesTypemockAutoDeploy'
TypeMockRegister, Company='BlackMarble_5xDev', License='XXXXXXXX', AutoDeploy=True

All As I would expect, the source control $/ path is converted to a location on the agents working disk

However when I do the same with the 2013 version (only change is swapping to Typemock.TFS2013.DLL, we are on the same TFS 2013 build agents) in our 2013 generation build process template my TypemockRegister fails. This is what I have done
1. In the TFS build controllers customactivities folder (that is used by my build controller) place the files Configuration.dll, TypeMock.CLI.Common.dll, TypeMock.Integration.dll, Typemock.Interceptors.dll, TypeMock.TFS2013.dll (I also have the typemock.tfs2012.dll so my 2012 build process templates work as discussed above this is all working)
2. Put all the contents of the Typemock autodeployment folder (and sub folder) into source control (in a folder other than the customactivities one) - again this is the same folder that is being used by the 2012 build process template without error
3. In my build definition set the TypemockAutoDeployDir for the TypemockRegister activity (with the correct license keys)

When I run my build I get the error
Exception Message: Could not load file or assembly 'TypeMock, Version=7.5.6.0, Culture=neutral, PublicKeyToken=3dae460033b8d8e2' or one of its dependencies. The system cannot find the file specified. (type FileNotFoundException) Exception Stack Trace: at TypeMock.CLI.Common.TypeMockStartInfo.Execute()

So it looks like I now need Typemock.dll in the same folder as the Typemock.TFS2013.dll

If I do this the typemock registration seems to work, but the log shows

Source AutoDeploy location is '$/BM/BuildProcessTemplates/TypemockAutoDeploy'
Setting deploy directory to: C:UsersTFSBuildAppDataLocalTempBuildAgent3Assemblies
Typemock AppDomain base C:UsersTFSBuildAppDataLocalTempBuildAgent3Assemblies
TypeMockRegister, Company='BlackMarble_5xDev', License=xxxx', AutoDeploy=True

So it knows about the $/ autodeployment folder, but has not done the translation to the local disk location as it used to for 2012. It is trying to use the main TFS custom build activities folder

The test then fail with

Exception Message: Exception has been thrown by the target of an invocation. (type TargetInvocationException)
Exception Stack Trace: at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
Inner Exception Details:

Exception Message: *** Typemock Isolator Cannot be deployed, following file is required:
C:UsersTFSBuildAppDataLocalTempBuildAgent3Assemblies amespaces.dat
C:UsersTFSBuildAppDataLocalTempBuildAgent3Assemblies ypemockconfig.xml
C:UsersTFSBuildAppDataLocalTempBuildAgent3AssembliesTypeMock.Configuration.exe
C:UsersTFSBuildAppDataLocalTempBuildAgent3AssembliesTypemock.ArrangeActAssert.dll
C:UsersTFSBuildAppDataLocalTempBuildAgent3AssembliesTypemock.Isolator.VisualBasic.
....

I think confirming the runner is trying to use the customactivies folder and not the autodeployment one

I get the same issue if you use your provided TFS2012 (.12 version) template) so it is not my customisation.

If I drop all the contents of the typemock autodeployment folder into the customactivities folder all my tests work. So I do have a work around, but it is not a neat as your 2012 implementation

Is this a bug?

Richard