Build/Test Issues

The "ResolvePackageAssets" task failed unexpectedly.

Started by gieniowski on 8,089 views

Whenever I enable ncrunch (5.20.0.2) in the project in the latest visual studio 2026 insiders version (Insiders [11605.296]) I get this error immediately:

System.Exception: An exception was thrown in the remote environment: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> nCrunch.Common.UserException: Errors occurred while trying to load the project file:
The "ResolvePackageAssets" task failed unexpectedly.
System.NullReferenceException: Object reference not set to an instance of an object.
at NuGet.ProjectModel.LockFile.<>c__DisplayClass39_0.<GetTarget>b__0(LockFileTarget t)
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
at Microsoft.NET.Build.Tasks.LockFileExtensions.GetTargetAndReturnNullIfNotFound(LockFile lockFile, String frameworkAlias, String runtimeIdentifier)
at Microsoft.NET.Build.Tasks.LockFileExtensions.GetTargetAndThrowIfNotFound(LockFile lockFile, String frameworkAlias, String runtimeIdentifier)
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheWriter..ctor(ResolvePackageAssets task)
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader.CreateReaderFromDisk(ResolvePackageAssets task, Byte[] settingsHash)
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader..ctor(ResolvePackageAssets task)
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ReadItemGroups()
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ExecuteCore()
at Microsoft.NET.Build.Tasks.TaskBase.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
at nCrunch.Compiler.ComponentAnalysisContext.queryValuesFromMSBuild()
at nCrunch.Compiler.ComponentAnalysisContext.AnalyseComponentBuild()
at nCrunch.Compiler.RemoteBuildRunner.AnalyseComponentBuild(ComponentLoadParameters parameters)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at nCrunch.TaskRunner.Ipc.IpcMessageProcessor.processCallMethodMessage(CallMethodMessage callMethodMessage)
at nCrunch.TaskRunner.Ipc.IpcMessageProcessor.ProcessMessageReturningResult(Byte[] data)
at nCrunch.TaskRunner.Ipc.RemoteProxyCommunicator.readMessage(Byte[] returnedData)
at nCrunch.TaskRunner.Ipc.RemoteProxyCommunicator.Invoke(String methodName, Object[] args)
at nCrunch.Compiler.RemoteBuildRunnerProxy.AnalyseComponentBuild(ComponentLoadParameters parameters)
at nCrunch.Core.BuildManagement.BuildProcessLauncher.<>c__DisplayClass4_0.<AnalyseComponentBuildInExternalProcess>b__0(IRemoteBuildRunner remoteBuildRunner)
at nCrunch.Core.BuildManagement.BuildProcessLauncher.executeTaskUsingExternalProcess(Action`1 task, EffectiveProcessorArchitecture processorArchitecture, GridClientId client, BuildSystemParameters buildSystemParameters, IList`1 customEnvironmentVariables, Nullable`1 taskId, GridClientDescription clientDescription, DotNetCoreSdkVersion dotNetCoreSdkVersion)
at nCrunch.Core.BuildManagement.BuildProcessLauncher.AnalyseComponentBuildInExternalProcess(ComponentLoadParameters parameters, IList`1 customEnvironmentVariables)
at nCrunch.Client.ComponentLoader.SnapshotComponentLoader.analyseComponentBuild(EffectiveProcessorArchitecture buildProcessorArchitecture, String targetFrameworkForMSBuild)
at nCrunch.Client.ComponentLoader.SnapshotComponentLoader.CreateComponentFromXml(FilePath projectFilePath, ParsedBuildXml projectXml, FilePath solutionFilePath, String[] additionalFilesToIncludeAtSolutionLevel, Boolean isLoadedFromFile, IDEVersion ideVersion, BuildEngineId buildEngineId, ComponentUniqueName componentName, TaskSettings componentTaskSettings, Exception parseException, String targetFrameworkForMsbuild, String visibleTargetFramework)


You do not even have to have test project, it is enough to create slnx with class library template.
Thanks for sharing this issue. Could you confirm whether it still happens for you in the build below?

NCrunch_Console_5.21.0.7.msi
NCrunch_Console_5.21.0.7.zip
NCrunch_GridNodeServer_5.21.0.7.msi
NCrunch_GridNodeServer_5.21.0.7.zip
NCrunch_LicenseServer_5.21.0.7.zip
NCrunch_Rider_5.21.0.7.7z
NCrunch_Rider_5.21.0.7.zip
NCrunch_VS2010_5.21.0.7.msi
NCrunch_VS2010_5.21.0.7.zip
NCrunch_VS2012_5.21.0.7.msi
NCrunch_VS2012_5.21.0.7.zip
NCrunch_VS2013_5.21.0.7.msi
NCrunch_VS2013_5.21.0.7.zip
NCrunch_VS2015_5.21.0.7.msi
NCrunch_VS2015_5.21.0.7.msi.7z
NCrunch_VS2015_5.21.0.7.zip
NCrunch_VS2017_5.21.0.7.msi
NCrunch_VS2017_5.21.0.7.msi.7z
NCrunch_VS2017_5.21.0.7.zip
NCrunch_VS2019_5.21.0.7.msi
NCrunch_VS2019_5.21.0.7.msi.7z
NCrunch_VS2019_5.21.0.7.zip
NCrunch_VS2022_5.21.0.7.msi
NCrunch_VS2022_5.21.0.7.msi.7z
NCrunch_VS2022_5.21.0.7.zip
NCrunch_VS2026_5.21.0.7.msi
NCrunch_VS2026_5.21.0.7.msi.7z
NCrunch_VS2026_5.21.0.7.zip
Thank you for quick reaction! Unfortunately new build does not fix my issue...
Thanks for confirming this. I think that this problem must be specific to your setup or environment.

Are there any solutions that are working correctly for you under NCrunch?

Can you confirm which versions of .NET you have installed?

When did this problem start appearing for you?
I am on windows 11. Issue occurs only on VS2026 insiders (with the latest update too, because today I have installed it). I noticed this issue around 2 weeks ago. Usually I use two versions of VS, normal one and insiders. Whenever I need to focus on tests, I just open solution in not insiders instance where ncrunch works as a charm.

To reproduce it, I create new solution (slnx) with VS2026 insiders, choose Class Library and .net 10. Then I enable ncrunch with these settings: Allow parallel execution, Run all tests automatically, Disable runtime data inspection, Do not ignore tests by default. After that I have Load failure as a status for the project with stack trace mentioned before.

This is my dotnet configuration:
dotnet --info
.NET SDK:
Version: 11.0.100-preview.2.26159.112
Commit: 17d11de66c
Workload version: 11.0.100-manifests.8e2e246e
MSBuild version: 18.5.0-preview-26159-112+17d11de66

Runtime Environment:
OS Name: Windows
OS Version: 10.0.26200
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\11.0.100-preview.2.26159.112\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
Version: 11.0.0-preview.2.26159.112
Architecture: x64
Commit: 17d11de66c

.NET SDKs installed:
9.0.312 [C:\Program Files\dotnet\sdk]
10.0.100-rc.1.25451.107 [C:\Program Files\dotnet\sdk]
10.0.201 [C:\Program Files\dotnet\sdk]
11.0.100-preview.2.26159.112 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 11.0.0-preview.2.26159.112 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 11.0.0-preview.2.26159.112 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.14 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 11.0.0-preview.2.26159.112 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download
Thanks for these extra details. The info shown suggests a likelihood that it may be trying to build using .NET 11 preview. If you choose the .NET 10 SDK using your Build SDK configuration setting, do you see different behaviour?
This is funny, as I had to select .net 11 preview version to make it work :D Selecting 10.0.201 or VS2026 is causing this error.
I noticed that non-insiders version is using the same settings, but tests are not affected and they work too.

I consider my issue solved. I am still here if you want to investigate it a little bit more.

Thanks!
Great, thanks for confirming this. I think I now understand what is happening.

The resolution of preview builds is a bit odd in VS. If a preview version of VS is running, the MSBuild resolver is 'allowed' by the platform to make use of a preview version of .NET. It's possible the logic around this has changed, but when I last examined it there was an actual memory test inside the system that looked to see if it was running in the context of a preview VS, and this basically unlocks alternative behaviour.

NCrunch's environment doesn't fit this model (because it's not VS, and therefore cannot pass the memory test), so when it builds/loads your project, the resolver is pulling up a different version of .NET, which causes mayhem and unpredictable behaviour inside the platform. Most probably what we're seeing is a .NET 11 toolset that is running under .NET 10 (or maybe the other way around, but regardless it's bad).

The rule of thumb is that if you're ever using preview tooling, you'll most likely need to use the 'Build Sdk' setting to point to the version of .NET that is consistent with the toolset you're operating under. Otherwise really weird stuff happens.

Post a reply

Log in to reply.