Build issue against OpenWrap'd solution

I have a solution that I'm using OpenWrap v2 beta to integrate against. It builds fine in Visual Studio and `o build-wrap`. It follows this structure:

/Foo.sln
/src
--/Foo.csproj
--/Foo.cs
/testing
--/Foo.Tests.csproj
--/FooFacts.cs
/wraps
--/_cache
----/DependencyLibrary
------/bin-net20
--------/DependencyLibrary.dll
--/openwrap
----/<all the openwrap stuff - msbuild targets, tasks, etc>

I have set AdditionalFilesToInclude to

..\..\wraps\openwrap\**.*
..\..\wraps\_cache\**.*

(the forum has used pipes, but I used backslashes)
per the build-issues wiki page, but I still get an error when ncrunch attempts to build & run.

........\AppData\Local\NCrunch\9296\18\wraps\openwrap\build\OpenWrap.CSharp.targets (41): The "InitializeOpenWrap" task failed unexpectedly.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at OpenWrap.Build.BuildInitializer.Initialize(String projectFile, String currentDirectory) in c:\src\openwrap\src\OpenWrap\Build\BuildInitializer.cs:line 23
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeType typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeType typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
at OpenWrap.Build.InitializeOpenWrap.Execute() in c:\src\openwrap\src\OpenWrap.Build.Bootstrap\InitializeOpenWrap.cs:line 41
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult)

I was just wondering whether anyone else had solved this problem?

By the way, when fiddling with the project settings, I found:
* it was confusing that the property editor allowed me to expand the AdditionalFilesToInclude node-tree and edit each string, but not reflect that in the actual setting
* it was difficult to know whether ncrunch had saved my property change and re-tried the build - the only feedback I could see was the path that it tried at increment a number
* on right-click rebuild in the ncrunch tests window, I couldn't tell whether ncrunch had actually rebuilt (I have a _fast_ computer, and the library I'm trying to crunch is tiny) - perhaps a timestamp on the output window?

Hi Peter,

Thanks for posting with this issue. I'm afraid I can only be of very limited use in troubleshooting OpenWrap issues due to the level of build customisation involved in it. I did manage to get an earlier version of OpenWrap working with NCrunch by ensuring that all OpenWrap resources were included in the NCrunch workspace (using AdditionalFilesToInclude), though I understand that OpenWrap v2 does a large amount of dynamic work - so I'm not 100% sure if this is still possible.

A useful way to troubleshoot issues like this one is to right click the failing project in the Tests Window, then choose the' Browse to last used workspace' option. This will allow you to inspect the workspace used by NCrunch as part of its build process, and you can run msbuild against the generated project file using the command line. By comparing this workspace against the project in its original location on your disk, you may be able to see which files are missing and still need to be included.

Also thanks for highlighting these usability issues. The AdditionalFilesToInclude config option is due for a bit of a dress up (the multi line text box is error prone and tacky). I'll have a look at the idea of adding a timestamp into the build to see if there's a clean way to do this. Note that NCrunch will automatically rebuild any project that has had a configuration change.


Cheers,

Remco