Build/Test Issues

Slow Cheetah Causing Build Failure

Started by moffatdm on 14,593 views

I am using the SlowCheetah .config transformation build tool.

Getting the following build error from NCrunch (builds fine when using VS2012 and MSBuild via Jenkins)

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#0
..\packages\SlowCheetah.2.5.5\tools\SlowCheetah.Transforms.targets (92)#1: The "SlowCheetah.Xdt.TransformXml" task failed unexpectedly.
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Web.XmlTransform, Version=1.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.Web.XmlTransform, Version=1.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at SlowCheetah.Xdt.TransformXml.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__20.MoveNext()


I have put Ncrunch into "compatibilty mode" and installed the Microsoft.Web.Xdt NuGet package as per http://stackoverflow.com/questions/14776659/error-doing-web-config-transformation-for-different-enviroments

If I look at the workspace, the Microsoft.Web.XmlTransform.dll has been copied over.

Any assistance much provided

Thanks David

p.s Great tool, will be purchasing when trial expires!
Hi David -

Thanks for posting, and for your interest in NCrunch!

It looks to me like this Nuget package is making use of a custom build step, requiring an extra dependency in the NCrunch workspace that isn't being copied there.

Try adding the following to your 'Additional files to include' setting at solution level: ..\packages\SlowCheetah.2.5.5\**.*



Cheers,

Remco

Edited

Perfect, that's what I was missing.

Cheers

David
Is there maybe also a way of including any version of a package?
Now I have to change this setting every time an included package is upgraded.

I expected

packages\SlowCheetah*\**.*


to be accepted, but to no avail. Is this to prevent version collisions?

Edited

Hi,

At the moment, unfortunately, I think the best way is to include the version number of the package in the additional files to include. It IS possible to include the entire nuget packages directory ("packages\**.*"), although this will add quite a bit of weight to each workspace.

The 'packages\SlowCheetah*\**.*' expression won't work because of the design of the algorithm that evaluates it. This design is restricted only by simplicity of implementation and not by any kind of real intention, so I've noted it down to be looked at to see if there is room for improvement. It seems to me that it would be quite a nice thing to be able to specify multiple wildcards in the expression.

Cheers,

Remco

Post a reply

Log in to reply.