My project has a dependency on System.ValueTuple that is downloaded with NuGet. Everything builds fine in Visual Studio and our build server but fails to build with NUnit.

It appears that the NCrunch logic is removing the reference to System.ValueTuple within the csproj because of the "System" part of the name. If I rename the dll and update the reference to "Test.ValueTuple", it now sees it and compile just fine. Is there a configuration to make all references be included?

It's ValueTuple, not ValueType. Here's the nuget package in reference:

https://www.nuget.org/packages/System.ValueTuple/

It comes by default with .net 4.7 but since I'm using 4.6.1 it needs to be referenced by the nuget package. What's curious is if i simply rename the DLL and the reference in the csproj, then it is referenced in the csproj that NCrunch creates in AppData. I believe it's tied to the fact that it has "System" as part of its name and thus filters it out but I cannot confirm that.

Sent. My apologies for the delayed response.

As far as I can tell, there two cases where it works and one that does not.

1. A relative path is used to the dll. This is the normal case if getting from nuget.
2. when using a variable, like $(SolutionDir), and the word "System." is not part of the dll.

When it fails is the combination of $(SolutionDir) and "System." is included in the name of the dll. When I renamed the dll to reference "$(SolutionDir)\Bin\Test.ValueTuple" that seemed to work just fine.

Hi,

Sadly there is no automatic way for us to support this.

If you don't want to use the nuget package directly and want to use the $(SolutionDir) method inside your solution for this DLL you will need to set the "Additional files to include" setting. There you can select the DLL and it will be copied correctly. You can find this setting under the NCrunch Configuration=>Solution settings (either shared or my settings)=>General=>Additional files to include.

The main issue here actually comes from a little known redirection system that Microsoft introduced in a minor update to VS2017 around the middle of last year.

System.ValueTuple is one of a number of assemblies that can be redirected internally inside the MSBuild system to a different location. MS did this to try and retroactively introduce support for .NET Standard in older versions of .NET Framework, and it really made a terrible mess of the build system because suddenly the version of an assembly being used at build/run time is not always the same as the one being referenced on disk.

Because the redirection is internal to MSBuild and we found no way to integrate with it, we instead try to organise the dependencies around it. Assemblies that can be redirected by the system we avoid tampering with and moving into _ncrunchreferences because by doing this we risk breaking the build system in any number of unpredictable ways.

System.ValueTuple is one of these assemblies. In most scenarios (actually, all known ones except yours), this works fine, because people reference this assembly using a Nuget package or from an established framework location. By copying this assembly into your solution directory and referencing it using a <Reference>, you've managed to expose a hole in the system that we can't plug without breaking something else.

So to solve this, you'll need to either use the 'Additional Files To Include' setting to ensure the referenced file exists in the workspace (without _ncrunchreferences sandboxing), or you'll need to reference the file from its Nuget package. Sorry, but this isn't something we can fix in the product. The design of the platform has really tied our hands here.

This doesn't sound quite right to me, as NCrunch will only copy this assembly into _ncrunchreferences if it's able to adjust the .csproj file to point to the copied file. When we tested this using your sample solution, we were able to make this work using 'Additional files to include'. Basically, we just included the assembly in its original location using this setting. Your search logic uses $(SolutionDir) to find the assembly, so as long as it's included in the workspace in the same relative path, your build system should be able to find it as usual.

Thanks, this is quite interesting. Probably the logic to 'sandbox' the DLL is still running while the redirection is not taking place. Regardless, it shouldn't be something you need to be worried about. This workaround shouldn't have any side-effects and should allow the engine to work normally with the binary referenced using your relative path.