Since a week or so, one project in a solution I have (Visual Studio 2022 Enterprise) has started to fail after changing Visual Studio version from Pro to Enterprise. I don't imagine this in itself affects NCrunch, but I had to reinstall both VS and NCrunch and maybe som new SDK or whatever was added or uppdated in the process. Anyway, the NCrunch build fails with this error:



All other building attempts (DevOps, local etc.) work fine - it's only the NCrunch build that fails.

I have a global.json file that specifies the SDK to be 6.0.100. Allowing roll-forward or completely removing the global.json file makes everything compile with NCrunch again. There's nothing in the solution itself, as far as I can tell that targets the 7.0.200 SDK version. In fact, originally the latest SDK available in my system was v.7.0.102, and the error message was reflecting this. After installing the latest SDK version, the error message followed to reflect this change as well.

Hence, I gather "something" is ignoring the global.json resolving the latest available SDK in the system, which happens to clash with the SDK 6 version specified in the global.json file.

This problem only occurs specifically in one project in the solution, that is an Azure Function project. All other projects are building just fine, in the same solution.

All projects in the solution are targeting dotnet 6.

Hi, thanks for getting back to me :)

It's reported by NCrunch to be a status = build failure. I submitted a report, as requested. Named it "Build failure in 'ResolvePackageAssets'" and put a link to this thread as reference.

The build fails every time. It does not seem to be (hasn't been so far) an intermittent problem. Including the global.json file through the "Additional files to include" option does not have any visual impact. The problem persists - build fails - and the error message and stack trace remains identical each time the build fails, both before and after adding the global.json file to NCrunch.

I also tried re-initializing NCrunch after adding the global.json file, but to no avail.

I will give it a shot. Can I try anything else that would enlighten us, if I can't reproduce the error in an isolated solution?

I managed to get a "working" minimum example together, that reproduces the error (at least for me f(^_ ^); I uploaded a zip file with a solution.

I tried resubmitting the zip file through the form under Support - Contact, but when I hit submit, I end up on a 404 page -> https://www.ncrunch.net/error/http404

What can I do instead?

I see. Kind of my bad, i guess f(^_^); - removed the obj and bin folders and resubmitted only 14 KB zipped project files. Thanks for the feedback!

Thanks for your patience with this issue. I've managed to more or less get to the bottom of it now, and although I haven't yet found a way to resolve the problem in the NCrunch codebase, there is a solid workaround you can use.

In your NCrunch 'Custom environment variables' setting, you need to set two environment variables:
DOTNET_MSBUILD_SDK_RESOLVER_SDKS_DIR = C:\Program Files\dotnet\sdk\6.0.100\Sdks (or the equivalent 'Sdks' directory for the dotnet SDK you are targeting)
DOTNET_MSBUILD_SDK_RESOLVER_SDKS_VER = 6.0.100 (or the equivalent version to match the above environment variable)

This will force MSBuild to resolve the dotnet SDK according to your chosen version, disregarding other logic.

The root of the issue is a component inside MSBuild/VS called Microsoft.DotNet.MSBuildSdkResolver. This component implements logic that considers a range of variables including preview SDKs, configuration files, VS, and the global.json file. The component has a special super magic check that performs a memory test to see if Visual Studio is responsible for the build. If so, it behaves differently. We don't have a feasible way to fake the memory test and the environment variables above are the only way to override the behaviour. We could probably duplicate the behaviour of this component under NCrunch (by parsing the global.json file) and performing the SDK selection ourselves by overriding the environment variables (which actually we do already for some specific cases), but the problem with this approach is that MS change the component all the time and we can't guarantee we'll get it right for all versions.

So in summary, if you're using global.json to specify an SDK version and NCrunch isn't rolling well with it, just specify the above environment variables. This is the best way to ensure a correct result in the build.

Thanks :)



We try to be very thorough with the release notes in each build. I realise skimming them is a pain, but if we do implement a fix for this, it'll definitely be in the notes.


[/quote]

The environment variable workaround should also work for the NCrunch console tool. If you use the shared version of the 'Custom environment variables' setting, it should automatically be picked up by the console tool as the setting will be shared.

Sorry, I should have clarified. I get so used to working in advanced configuration mode that I tend to forget the simple mode is on by default. Inside the configuration windows you'll see a checkbox at the top for 'Use Simplified Configuration Settings'. Turn this off, and you'll be able to set this at solution level so it won't affect your other projects.