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

Notification

Icon
Error

Build issue net90
Dirk Maegh
#1 Posted : Monday, October 14, 2024 10:43:12 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 11/30/2016(UTC)
Posts: 55
Location: Belgium

Thanks: 8 times
Was thanked: 8 time(s) in 8 post(s)
Hi,

I wanted to upgrade my projects from net8.0 to net90.
I did a complete search/replace over all my projects, had them rebuilt and everything seemed to work fine.

Until I noticed nCrunch was complaining.

I reduced it to a simple project (and a simple test project) working fine in net8.0.
NCrunch is happy, builds and tests my single unittest (doing an assert.True(true))

Then I change the unittest project (either with the main project, either only the unittest project) - I change the TargetFramework from net8.0 to net90 (or net9.0 - effect is the same)
Resharper and VS2022 build and test all fine.
nCrunch won't build the project(s) that have net90 (or net9.0).

The error shown is
Quote:

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 FrameworkReference 'Microsoft.NETCore.App' was not recognized
The FrameworkReference 'Microsoft.AspNetCore.App' was not recognized
at nCrunch.Compiler.ComponentAnalysisContext.()
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.(CallMethodMessage )
at nCrunch.TaskRunner.Ipc.IpcMessageProcessor.ProcessMessageReturningResult(Byte[] data)
at nCrunch.TaskRunner.Ipc.RemoteProxyCommunicator.(Byte[] )
at nCrunch.TaskRunner.Ipc.RemoteProxyCommunicator.Invoke(String methodName, Object[] args)
at nCrunch.Compiler.RemoteBuildRunnerProxy.AnalyseComponentBuild(ComponentLoadParameters parameters)
at nCrunch.Core.BuildManagement.BuildProcessLauncher..(IRemoteBuildRunner )
at nCrunch.Core.BuildManagement.BuildProcessLauncher.(Action`1 , FilePath , String , DirectoryPath , ExternalProcess )
at nCrunch.Core.BuildManagement.BuildProcessLauncher.(Action`1 , EffectiveProcessorArchitecture , GridClientId , BuildSystemParameters , IList`1 , Nullable`1 , GridClientDescription , DotNetCoreSdkVersion  )
at nCrunch.Core.BuildManagement.BuildProcessLauncher.AnalyseComponentBuildInExternalProcess(ComponentLoadParameters parameters, IList`1 customEnvironmentVariables)
at nCrunch.Client.ComponentLoader.SnapshotComponentLoader.(EffectiveProcessorArchitecture , String )
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)

Remco
#2 Posted : Monday, October 14, 2024 11:08:27 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Hi, thanks for sharing this issue.

The .NET platform and MSBuild do some odd things in their resolution logic around preview builds of .NET. It's designed in such a way that we can't safely replicate it in NCrunch, and this causes confusion inside the build system.

To resolve this, you'll need to make sure you use the Build SDK config setting to select the .NET 9 preview SDK under NCrunch.

This applies to all preview builds of .NET. As soon as .NET 9 is no longer in a preview state, there should be no need to mess with this setting. My early testing of this platform suggests that we are forwards compatible with it. If you find any other problems with it, please do share them as I believe it's quite close to hitting RTM now.
Dirk Maegh
#3 Posted : Monday, October 14, 2024 11:11:10 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 11/30/2016(UTC)
Posts: 55
Location: Belgium

Thanks: 8 times
Was thanked: 8 time(s) in 8 post(s)
Thanks for your reply. It is clear to me.
It would be nice however if the tool could maybe in the output refer to some documentation page explaining this ? (optional of course, I can always create an issue on this forum :))
Remco
#4 Posted : Monday, October 14, 2024 11:19:50 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
Dirk Maegh;17677 wrote:
It would be nice however if the tool could maybe in the output refer to some documentation page explaining this ? (optional of course, I can always create an issue on this forum :))


Ideally, yes. Actually, it would be best if it could just align itself and work without any configuration.

The root problem here is that the build tools are actually doing a memory test to try and identify when they are running under a preview version of VS. If no preview VS is hosting them, they instead will ignore preview installations of .NET and just use the latest instead (most likely .NET 8.0 in this case). I can't feasibly fake the memory test, and identifying when it would lead to preview tooling isn't practical to do ... so it just bugs out.

I'd like to detect the failure and report a meaningful message, but as the failure is a weird cross-version bug that could also mean other things, there's no safe way to do it. At the time a build of NCrunch is finalised, there's no way to tell how the platform will bug out for versions of .NET that are not released or are still under development.

So it's not ideal. But I'm grateful for the fact that we're able to work with .NET 9 without needing to make changes to NCrunch, or release a special version just for it. MS deserve much credit for that, actually.
1 user thanked Remco for this useful post.
Dirk Maegh on 10/14/2024(UTC)
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.045 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download