Hi. I'm on version 2.23.0.2. I just updated my solution to use NuGet 3 and project.json for all projects, and now I'm getting the following exception on build all 3 of my Azure worker/webrole projects:

System.NullReferenceException: Object reference not set to an instance of an object.
at nCrunch.Common.IO.DiskPath.DoRebase(DirectoryPath originalBase, DirectoryPath newBase)
at nCrunch.Core.BuildManagement.BuildEnvironment.(FilePath , DirectoryPath , DirectoryPath )
at nCrunch.Core.BuildManagement.BuildEnvironment.(BuildOutput , IList`1 )
at nCrunch.Core.BuildManagement.BuildEnvironment.Build(SnapshotComponent snapshotComponentToBuild, IList`1 referencedComponents, GridClientId gridClientId, IList`1 customEnvironmentVariables)

All of the projects build fine via msbuild on command line and in Visual Studio.

Tail of the detailed log:

15:00:51.3162 [6] - Building from working directory: D:\ncrunch\28768\38\<redacted>
15:00:54.1601 [6] - Build successful
15:00:54.1621 [6] - Found output assembly: D:\ncrunch\28768\38\src\<redacted>
15:00:54.2182 [6] - Instrumenting output assembly: D:\ncrunch\28768\38\src\<redacted>
15:00:54.3283 [6] - Resolved assembly mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 to path C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\mscorlib.dll
15:00:54.4023 [6] - Resolved assembly <redacted>, Version=1.15.0.0, Culture=neutral, PublicKeyToken=null to path D:\ncrunch\28768\4\src\<redacted>
15:00:54.4774 [6] - Resolved assembly <redacted>, Version=1.15.0.0, Culture=neutral, PublicKeyToken=null to path D:\ncrunch\28768\1\src\<redacted>
15:00:54.4904 [6] - Scanning for tests using frameworks configured with static analysis
15:00:54.4904 [6] - 0 tests were discovered with static analysis

[15:00:54.5595-LocalBuildTask-24] Task processing complete for [LocalBuildTask: [SnapshotComponent: Service, 39, 5836656], BeingProcessed, (local)], processing time: 00:00:00
[15:00:54.56-LocalBuildTask-24] Publishing Event: [ :[LocalBuildTask: [SnapshotComponent: Service, 39, 5836656], BeingProcessed, (local)]]
[15:00:54.56-LocalBuildTask-24] Event [ :[LocalBuildTask: [SnapshotComponent: Service, 39, 5836656], BeingProcessed, (local)]] is being published on thread CoreThread to subscriber: ProcessingQueue.
[15:00:54.56-LocalBuildTask-24] Event [ :[LocalBuildTask: [SnapshotComponent: Service, 39, 5836656], BeingProcessed, (local)]] is being published on thread UIThread to subscriber: SharedEventPump.


I can send you the full log offline if necesary.

Thanks

Hi,

Thanks for sharing this issue.

Unfortunately, Azure projects are not currently supported by NCrunch. There has been no QA work done to examine any of the edge cases around how these project types behave or how to make NCrunch work reliably for them. For this reason, I'm sorry but I can't offer proper support for this problem, but I can offer a limited analysis of what seems to be happening here.

This seems to be the result of cross-drive activity inside your build system. There is a resource file related to this project that is being somehow sourced from or copied to a different drive than the project file itself. This creates a blocking issue for NCrunch, as project atomicity constraints are such that NCrunch cannot build a coherent workspace from a project that spans multiple drives.

I recommend examining the build system behind this project to see how resource files are being used and referenced. It's possible that the upgrade to Nuget 3 resulted in an implicit dependency to resources in an SDK somewhere.

The exception you're receiving from NCrunch is being thrown from the code that copies resource files from referenced projects into projects with the 'Copy referenced assemblies to workspace' setting enabled. Turning off this setting will likely suppress the issue, though I assume you have the setting enabled for a reason and likely will experience other problems if it is disabled.

Moving your projects from D drive onto C drive may also suppress this issue and allow the project to build, but you will then still experience strange behaviour around the copying of resource files that may create malformed workspaces (giving other problems downstream).

I was able to work around this issue by disabling the 'Copy referenced assemblies to workspace' setting and getting the required files to the output directory in another way. Thanks.