Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
_SplitProjectReferencesByFileExistence caused by global.json asking for an uninstalled .NET Core SDK
Options
Previous Topic Next Topic
FrankShearar
#1 Posted : Saturday, September 19, 2020 5:19:30 PM(UTC)
Rank: Member

Groups: Registered
Joined: 1/20/2015(UTC)
Posts: 17
Location: United Kingdom

Was thanked: 2 time(s) in 2 post(s)
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.c...bal-json?tabs=netcore3x) looks like a thing that is for .NET Core CLI commands.
Back to top
Remco
#2 Posted : Saturday, September 19, 2020 11:35:58 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
FrankShearar;14975 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;14975 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.c...bal-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.
Back to top
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.031 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download