We havea few projects where we use the Visual Studio SlowCheetah plugin to add transformations to our configuration files. SlowCheetah also provides a NuGet package to enable machines without the plugin to build the projects.
The problem is when NCrunch tries to build the project (we do have the same problem on our build servers though...):
NCrunch: If you are experiencing problems in getting this project to build, have a look at http://www.ncrunch.net/documentation/troubleshooting_project-build-issues
NCrunch: This project was built on server 'xxxx'
Properties\SlowCheetah\SlowCheetah.Transforms.targets (128): The "SlowCheetah.Xdt.TransformXml" task could not be loaded from the assembly C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.2\SlowCheetah.Xdt.dll. Could not load file or assembly 'file:///C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.2\SlowCheetah.Xdt.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
What I already did so far:
1) Checked the following articles:
Can you confirm that you've added the Nuget packages directory to the 'Additional files to include' setting under your NCrunch solution configuration? Looking at the path, it seems as though the build task is trying to access the DLL using a relative path from the workspace. Does it look as though the workspace on the grid node has arranged itself so it is structurally equivalent to the project in your original foreground solution?
I've also noticed that there is a new version of SlowCheetah (v2.5.10.3). I've just run a quick test against this with a dummy solution and it seems to work with the grid processing, though I doubt I have all the complexity required to recreate the same situation you're experiencing.
I also created a small standalone proof-of-concept, and it indeed seemed to be working.
So I updated our current solution to Slowcheetah v2.5.10.3, and it was still not working. Then I noticed 2 things:
- the SlowCheetah.Transform.Targets file deployed into the project by the package was still referencing 2.5.10.2 as its path (This is probably a bug in SowCheetah/Nuget update mechanism)
- The project file itself was pointing to a system directory. I edited the project file like this:
Now, everything seems to be running smoothly again. (after rechecking if the "Additional files to include" pointed to the correct directory)
So sorry to have bothered you, it was not a NCrunch issue, but a SlowCheetah/Nuget issue.