_SplitProjectReferencesByFileExistence caused by global.json asking for an uninstalled .NET Core SDK

I just found another reason why _SplitProjectReferencesByFileExistence might not be found. My project used a fork of libphonenumber-dotnet (https://github.com/jarroda/libphonenumber-dotnet/) with some minor modifications: we had cross-targeted net45;netstandard1.0.

I hadn't touched the project in quite some time, and since that last time Something Changed(tm) and NCrunch refused to load the project.

It turned out that the global.json file (https://github.com/jarroda/libphonenumber-dotnet/blob/master/csharp/global.json - the file hasn't changed) required a .NET Core SDK that wasn't installed on the machine. (Diagnostic logging and a bit of luck is how I found this out.) Deleting the file fixed the problem.

So that's the FYI bit.

My follow-on question: if there is a library project that targets netstandardX, and there is a global.json file, should NCrunch even bother looking in the global.json file? My reasoning is that .NET Standard is meant to be agnostic as regards ".NET Framework or .NET Core", and global.json (according to https://docs.microsoft.com/en-us/dotnet/core/tools/global-json?tabs=netcore3x) looks like a thing that is for .NET Core CLI commands.

FrankShearar wrote:I just found another reason why _SplitProjectReferencesByFileExistence might not be found. My project used a fork of libphonenumber-dotnet (https://github.com/jarroda/libphonenumber-dotnet/) with some minor modifications: we had cross-targeted net45;netstandard1.0.

This particular error is actually quite an old one. It's kicked up by MSBuild when the .targets files for the selected platform can't be resolved by the build system. Maybe we should trap it and replace it with something more informative.

FrankShearar wrote:
My follow-on question: if there is a library project that targets netstandardX, and there is a global.json file, should NCrunch even bother looking in the global.json file? My reasoning is that .NET Standard is meant to be agnostic as regards ".NET Framework or .NET Core", and global.json (according to https://docs.microsoft.com/en-us/dotnet/core/tools/global-json?tabs=netcore3x) looks like a thing that is for .NET Core CLI commands.

You could probably make a pretty good argument for this, but sadly it isn't really an NCrunch argument. Right now we don't have any special logic in place for loading parameters out of the global.json file. Instead, we simply pull the details out of MSBuild, which does its own traversal of the foreground solution (and happens to include global.json in this). The more we can lean on the platform for this kind of thing, the less we need to rebuild every time MS release a new version of the platform. Right now the MS tooling around netstandard cares about global.json, which means we end up loading the file .. whether we think it's sensible or not.