Sorry, this is actually what I was coming here is ask about - https://forum.ncrunch.net/yaf_postst2910_TargetInvocationException-Looping.aspx was just a minor annoyance I've been encounting for months that made it hard to make a test case for this issue.
Something odd is happening with a csproj that looks like this:
The build for netcoreapp3.0 succeeds, but the build for netcoreapp2.1 fails with:
NCrunch: If you are experiencing problems in getting this project to build, have a look at http://www.ncrunch.net/documentation/troubleshooting_project-build-issues
NCrunch: This project was built on server '(local)'
C:\Program Files\dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets: The FrameworkReference 'Microsoft.AspNetCore.App' was not recognized
Which seems supper odd, considering this is a .Net Core 2.1 project, before FrameworkReference existed.
Digging deeper, it appears this build target is failing only if netcoreapp3.0 is included in the framework target list. This makes me think NCrunch is possibly leaking project build state (if that's a thing) between target builds.
Which seems supper odd, considering this is a .Net Core 2.1 project, before FrameworkReference existed.
Unfortunately, the new tooling introduced with .NET Core 3.0 has replaced the existing build system for .NET Core 2.1. Merely by having the new tooling installed, your system for 2.1 will also change.
I'm not completely sure what is happening here. The build system is doing something very unexpected under the hood here. We'll need to do some digging to try and figure this out. The good news is that we're able to reproduce the issue consistently using your code sample, so hopefully it should just be a matter of time.
Sorry, the holidays and the resulting context switch had me space on this.
I did try those builds (3 months ago), no change. I've since updated to newer release, and the issue does still exist. It's not 100% consistent though, and sometimes works. I think it's related to https://forum.ncrunch.net/yaf_postst2910_TargetInvocationException-Looping.aspx - since it only occurs after csproj modifications.
Silvenga wrote:Sorry, the holidays and the resulting context switch had me space on this.
I did try those builds (3 months ago), no change. I've since updated to newer release, and the issue does still exist. It's not 100% consistent though, and sometimes works. I think it's related to https://forum.ncrunch.net/yaf_postst2910_TargetInvocationException-Looping.aspx - since it only occurs after csproj modifications.
I'm sorry to hear this. Do you have a sample solution you can share with us that can reproduce the problem, even inconsistently? You can submit small sample projects in ZIP form through the NCrunch contact form.
It may also be worth clearing out the 'obj' directories under your projects to see if that resolves the inconsistency. It could be old data doing this to you.
I am so sorry, I never got a notification email from YAF. I just dropped by wondering how that investigation was going.
I tried the builds, same issue.
NCrunch: This project was built on server '(local)'
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.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.RemoteInstance.(Byte[] )
at nCrunch.TaskRunner.Ipc.RemoteInstance.Invoke(IMessage msg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at nCrunch.Compiler.IRemoteBuildRunner.AnalyseComponentBuild(ComponentLoadParameters parameters)
at nCrunch.Core.BuildManagement.BuildProcessLauncher..(IRemoteBuildRunner )
at nCrunch.Core.BuildManagement.BuildProcessLauncher.(Action`1 , FilePath , String , ExternalProcess )
at nCrunch.Core.BuildManagement.BuildProcessLauncher.(Action`1 , EffectiveProcessorArchitecture , GridClientId , BuildSystemParameters , IList`1 , Nullable`1 , GridAddress )
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, VisualStudioVersion vsVersion, ComponentUniqueName componentName, TaskSettings componentTaskSettings, Exception parseException, String targetFramework)
Well, also a good time to remember I needed to renew.
Tentatively, looks like 4.4.0.9 resolves the bug, I can no longer reproduce it by modifying the csproj.
I've been committing a lot of broken tests over the past couple of months, because the status icon was permanently in a fail state, so very happy to finally see green again.