Solution to 'error MSB4175: The task factory 'CodeTaskFactory' could not be loaded from the assembly'

2015-07-11

Updated: 12 July 2015 - It seems that this is all incorrect… Upon running my tests again this morning I find that the x64 task runner also fails to run VS2010 correctly and so the environment differences are unlikely to be the cause…

So, having decided that my continuous integration system could be better, and having looked at JetBrains’ TeamCity and decided that it doesn’t quite fit I’m looking back at some code that I wrote back in 2008 when I last thought about this kind of thing…

I have some code which works with trees of dependant tasks and triggers sub tasks once the tasks they depend on complete successfully. The code uses CreateProcess() and Win32 Jobs to control the tasks and it can run builds and tests using the various flavours of Visual Studio installed on the box in question.

So far, so good as a starting point for an agent that can run multiple builds on a machine…

My problem, well, one of them, being that when using VS2010 by running a project into devenv.com I get the following error message:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(214,5):
error MSB4175: The task factory "CodeTaskFactory" could not be loaded from the assembly 
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Build.Tasks.v12.0.dll".
Could not load file or assembly 'file:///C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Build.Tasks.v12.0.dll'
or one of its dependencies. The system cannot find the file specified.

This is annoying, to say the least, VS2005, 2008 and 2012 and 2013 all work fine, it’s just 2010 that fails. I googled the issue and the general consensus is that once you’ve installed VS2013 a different version of MSBuild is used. Of course that doesn’t answer the question of why it ‘works on my machine’ except when my task runner is running the command…

Eventually I got the task runner to dump the environment and did the same from the command prompt where the command worked. The difference being that the command prompt that worked had an ‘x64’ environment and the task runner had a different, ‘x86/win32’ environment… This was because the task runner was a Win32 process. Running the task runner as x64 fixed the issue. So there’s probably a bug in the VS2013 installation code that fails to set some environment variables for the Win32 command prompt that are required once it’s “screwed with” the existing MSBuild installation on the box…

I’m expecting that manually adding the missing bits to the ‘x86’ environment will mean that the task runner will work as a Win32 build AND an x64 build…