Build/Test Issues

The FrameworkReference 'Microsoft.WindowsDesktop.App.WPF' was not recognized

Started by eriove on 10,943 views

First of all thanks for an amazing product!

We've had a problem for a while with some of our WPF projects targeting .NET Framework 4.8 and .NET Core 3.1. I've been hoping that it would have been a WPF on .NET Core problem but the more patched .NET Core get the more I suspect that it is something nCrunch related. We are using C# 8.0 and nullable reference types with .NET 4.8 which isn't supported so that could also be the culprit.

The problem is intermittent and is most often triggered when changing branches (even if the project files doesn't change) and is always resolved by restarting the nCrunch engine. I have not managed to trigger it with a small solution but I will e-mail you our project files.

Here's the stack trace:


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.WindowsDesktop.App.WPF' 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)


Interestingly enough projects depending on the one that has a "Load failure" fails like types were missing in the referenced assembly instead of failing because the referenced assembly failed to compile.

I'm e-mailing you the projects (without any code)

Edited

Hi, thanks for sharing this problem.

I'll take a look at the sample solution and will get back to you. Can you confirm that you're running the latest version of NCrunch? (v4.3).
I'm running 4.4.0.2, I was hoping that that version would solve the problem. Had the same problem on 4.3.
Could you try the build below and confirm whether this solves the issue for you?

NCrunch_Console_4.4.0.7.msi
NCrunch_Console_4.4.0.7.zip
NCrunch_GridNodeServer_4.4.0.7.msi
NCrunch_GridNodeServer_4.4.0.7.zip
NCrunch_LicenseServer_4.4.0.7.zip
NCrunch_VS2008_4.4.0.7.msi
NCrunch_VS2010_4.4.0.7.msi
NCrunch_VS2010_4.4.0.7.zip
NCrunch_VS2012_4.4.0.7.msi
NCrunch_VS2012_4.4.0.7.zip
NCrunch_VS2013_4.4.0.7.msi
NCrunch_VS2013_4.4.0.7.zip
NCrunch_VS2015_4.4.0.7.msi
NCrunch_VS2015_4.4.0.7.msi.7z
NCrunch_VS2015_4.4.0.7.zip
NCrunch_VS2017_4.4.0.7.msi
NCrunch_VS2017_4.4.0.7.msi.7z
NCrunch_VS2017_4.4.0.7.zip
NCrunch_VS2019_4.4.0.7.msi
NCrunch_VS2019_4.4.0.7.msi.7z
NCrunch_VS2019_4.4.0.7.zip
Thanks! I will test during the day. Looking good for the first 20 minutes, but the error has been intermittent. Will try to provoke it by branch changes and edits to project files.
Unfortunately I triggered the error again at the first switch of branch. Exactly the same stack trace as in the first post.
I've experimented throughout the day. These are my conclusions:
- "Reload and rebuild selected component" does not help resolving the problem, I have to "Restart the nCrunch engine" to resolve the problem.
- The .NET Core builds never fail only the .NET Framework builds.
- Switching branch is the best way to trigger the problem but working in a single file has triggered it at least once.
Thanks for the extra info. I'm still trying to work out what is happening here ... I was so sure I'd fixed this one. Can you confirm the version number of NCrunch that you have showing in the 'About' window?
The version in the about window says 4.4.0.7. The nCrunch.BuildHost48.x86.exe and nCrunch.TestHost48.x86.exe is has the Product and File version 4.4.0.7.

My feeling is that the error occurs much less often with 4.4.0.7 than the previous version. Perhaps there are two ways of reaching the same stack trace and you have found one of them?

I just got the error for a test project that has <Project Sdk="Microsoft.NET.Sdk"> and not <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop"> on the first line of the project file (FOI.ShipDes.Tests in the files I sent you). Posting the tack trace again in case I missed a subtle difference somewhere. I got the error from switching branch this time as well.

Noteworthy with the branches is that the one I switched to uses version 4.10.0 of Dirkster99.AvalonDock but the one I switched from uses version 3.6.2. What's special about this switch is that 4.x has the same DLL name but different namespaces. Now and then when switching branches I have to delete the bin and obj folders for the project to run in Visual Studio.


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.WindowsDesktop.App.WPF' was not recognized
The FrameworkReference 'Microsoft.WindowsDesktop.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)

Got the error again while switching between two branches with Dirkster99.AvalonDock version 3.6.2 on both branches, so that might be unrelated.
Remco wrote:Could you try the build below and confirm whether this solves the issue for you?

NCrunch_Console_4.4.0.7.msi
NCrunch_Console_4.4.0.7.zip
NCrunch_GridNodeServer_4.4.0.7.msi
NCrunch_GridNodeServer_4.4.0.7.zip
NCrunch_LicenseServer_4.4.0.7.zip
NCrunch_VS2008_4.4.0.7.msi
NCrunch_VS2010_4.4.0.7.msi
NCrunch_VS2010_4.4.0.7.zip
NCrunch_VS2012_4.4.0.7.msi
NCrunch_VS2012_4.4.0.7.zip
NCrunch_VS2013_4.4.0.7.msi
NCrunch_VS2013_4.4.0.7.zip
NCrunch_VS2015_4.4.0.7.msi
NCrunch_VS2015_4.4.0.7.msi.7z
NCrunch_VS2015_4.4.0.7.zip
NCrunch_VS2017_4.4.0.7.msi
NCrunch_VS2017_4.4.0.7.msi.7z
NCrunch_VS2017_4.4.0.7.zip
NCrunch_VS2019_4.4.0.7.msi
NCrunch_VS2019_4.4.0.7.msi.7z
NCrunch_VS2019_4.4.0.7.zip


Cool, thanks, fixed it for us as well. Just a quick report from us, we had similar problems with IpcConnectionClosedException, also with WPF projects as well:

nCrunch 4.3.0.13
- solution with 30 projects, around 3500 tests, no wpf, tried 3 times, loads without any errors.

- solution with 60 projects, around 10 of them with wpf, loaded 3 times, first almost all projects fail to load with "nCrunch.TaskRunner.Ipc.IpcConnectionClosedException: The connection has been closed", then again, about 2-3 fail, then all compile

- solution with mostly wpf projects randomly fail and work, for some reason seems to be better with smaller solutions (<20 projects) than our 60 project solution.

- using a solution filter or unloading wpf projects makes it immediately work and is repeatable.

Tried nCrunch 4.4.0.7 and all of the above issues seem to be gone. It is a bit difficult to be 100% sure as once the problems are fixed, they don't come back until the next merge or project reload (reloaded a few times and tested different solutions, all without problems right now).
DeltaEngine wrote:
Remco wrote:Could you try the build below and confirm whether this solves the issue for you?
...


Cool, thanks, fixed it for us as well. Just a quick report from us, we had similar problems with IpcConnectionClosedException, also with WPF projects as well:

nCrunch 4.3.0.13
- solution with 30 projects, around 3500 tests, no wpf, tried 3 times, loads without any errors.

- solution with 60 projects, around 10 of them with wpf, loaded 3 times, first almost all projects fail to load with "nCrunch.TaskRunner.Ipc.IpcConnectionClosedException: The connection has been closed", then again, about 2-3 fail, then all compile

- solution with mostly wpf projects randomly fail and work, for some reason seems to be better with smaller solutions (<20 projects) than our 60 project solution.

- using a solution filter or unloading wpf projects makes it immediately work and is repeatable.

Tried nCrunch 4.4.0.7 and all of the above issues seem to be gone. It is a bit difficult to be 100% sure as once the problems are fixed, they don't come back until the next merge or project reload (reloaded a few times and tested different solutions, all without problems right now).


Sadly it happened again, but only on 2 of the test projects that also have WPF dependencies, reloading also does not make the problem go away, so we excluded the projects from NCrunch for now (via Ignore this component completely):

An error occurred while analysing this project after it was built: NCrunch encountered an unexpected error occurred while building an environment to analyse an assembly: nCrunch.TaskRunner.Ipc.IpcConnectionClosedException: The connection has been closed
at nCrunch.Core.ProcessManagement.ExternalProcessManager.(EffectiveProcessorArchitecture , ProcessLoadParameters )
at nCrunch.Core.ProcessManagement.ExternalProcessManager.LoadExternalProcess(ProcessLoadParameters parameters, GridClientId client)
at nCrunch.Core.TestManagement.TestRunnerProcess..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.TestManagement.TestRunnerProcess.(Nullable`1 , FilePath , GridClientId , CustomVariable[] )
at nCrunch.Core.TestManagement.TestRunnerProcess..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.TestManagement.TestRunnerProcess.LoadTestRunnerProcessForProjectReturningProcessId(SnapshotComponent snapshotComponent, IList`1 componentsInProcess, TestFrameworkDescription[] testingFrameworks, Nullable`1 newProcessTag, FilePath solutionFilePath, GridClientId client, CustomVariable[] customEnvironmentVariables)
at nCrunch.Core.Processing.AnalysisTaskLogic.DoProcessTaskAndReturnSuccessFlag()
Could you try the build below and let me know how it goes for you? I realise this issue is very intermittent and not easy to pin down .. so many try it for a couple of days and see how you go.

NCrunch_Console_4.4.0.8.msi
NCrunch_Console_4.4.0.8.zip
NCrunch_GridNodeServer_4.4.0.8.msi
NCrunch_GridNodeServer_4.4.0.8.zip
NCrunch_LicenseServer_4.4.0.8.zip
NCrunch_VS2008_4.4.0.8.msi
NCrunch_VS2010_4.4.0.8.msi
NCrunch_VS2010_4.4.0.8.zip
NCrunch_VS2012_4.4.0.8.msi
NCrunch_VS2012_4.4.0.8.zip
NCrunch_VS2013_4.4.0.8.msi
NCrunch_VS2013_4.4.0.8.zip
NCrunch_VS2015_4.4.0.8.msi
NCrunch_VS2015_4.4.0.8.msi.7z
NCrunch_VS2015_4.4.0.8.zip
NCrunch_VS2017_4.4.0.8.msi
NCrunch_VS2017_4.4.0.8.msi.7z
NCrunch_VS2017_4.4.0.8.zip
NCrunch_VS2019_4.4.0.8.msi
NCrunch_VS2019_4.4.0.8.msi.7z
NCrunch_VS2019_4.4.0.8.zip

Note: This includes a change to the grid protocol, so you'll need to update your nodes if you're running distributed processing.

Edited

I've switched branches multiple times and just when I wrote this message I got the error for the first time. But, it disappeared by itself after 10 seconds so the only reason I saw it was that I looked at the nCrunch window. Even if the problem isn't solved to 100% the error is certainly occurring less often. I will post an update next week letting you know if I see the error again.
eriove wrote:I've switched branches multiple times and just when I wrote this message I got the error for the first time. But, it disappeared by itself after 10 seconds so the only reason I saw it was that I looked at the nCrunch window. Even if the problem isn't solved to 100% the error is certainly occurring less often. I will post an update next week letting you know if I see the error again.


The build above contains a separate workaround for an issue where we weren't detecting project file changes under VS2019.16.5. This is/was due to a bug present in the IDE. It's quite possible that a number of these issues are actually related to NCrunch becoming desynchronised with the state of the project and not being able to update itself. If the error goes away on its own, this means that NCrunch tried to load the project while it was in an inconsistent state (i.e. the project.assets.json file was still being updated by VS). Because it should now respond to project changes again, I hope that this class of problem should be resolved.

Edited

While I was traversing the history, checking out commit after commit and rerunning all tests I found what seems to be a similar issue. I was doing the checkouts from the command line this time and I imagine that there are less events for you to listen on from Visual Studio in that case.

Unless you think of an immediate solution for this I wouldn't worry about it. Visual Studio doesn't handle it that particularly well either, so I don't mind NCrunch failing one time in ten as well for this edge case. Just wanted to let you know for completeness sake.

Here's the stack trace (note the difference at the first line, but the similarities after that):

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: 
Unable to find project information for 'C:\xxx\xxx\xxx.csproj'. If you are using Visual Studio, this may be because the project is unloaded or not part of the current solution so run a restore from the command-line. Otherwise, the project file may be invalid or missing targets required for restore.
   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)




Other than that it has been working without problems, thanks for excellent support!

Edited

Thanks for sharing this information! I would tend to categorise this particular situation as by design, as with the project XML we're totally reliant on VS to feed us with the correct data. For projects that have been loaded into the IDE, we disregard the contents of the file system and instead align ourselves with what VS has in memory. There is huge potential for short term inconsistencies here because VS has several long steps involved in loading a project that has changed on disk (including the restore of packages and generation of project.assets.json). We've tried very hard to make it rock solid, but there's hard limits to what we can do when the IDE doesn't cooperate. I would just recommend hitting the reset button if you end up in an incomplete state after doing checkouts or switching branches.
Hey, just gonna hijack this thread for a lil bit.

I always regret upgrading something, guess 4.8 is still fairly new..

Tried 4.4.0.8 still getting the

An error occurred while analysing this project after it was built: NCrunch encountered an unexpected error occurred while building an environment to analyse an assembly: nCrunch.TaskRunner.Ipc.IpcConnectionClosedException: The connection has been closed
at nCrunch.Core.ProcessManagement.ExternalProcessManager.(EffectiveProcessorArchitecture , ProcessLoadParameters )
at nCrunch.Core.ProcessManagement.ExternalProcessManager.LoadExternalProcess(ProcessLoadParameters parameters, GridClientId client)
at nCrunch.Core.TestManagement.TestRunnerProcess..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.TestManagement.TestRunnerProcess.(Nullable`1 , FilePath , GridClientId , CustomVariable[] )
at nCrunch.Core.TestManagement.TestRunnerProcess..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.TestManagement.TestRunnerProcess.LoadTestRunnerProcessForProjectReturningProcessId(SnapshotComponent snapshotComponent, IList`1 componentsInProcess, TestFrameworkDescription[] testingFrameworks, Nullable`1 newProcessTag, FilePath solutionFilePath, GridClientId client, CustomVariable[] customEnvironmentVariables)
at nCrunch.Core.Processing.AnalysisTaskLogic.DoProcessTaskAndReturnSuccessFlag()

exception mentioned in here. Also tried 4.4.0.10.

Thanks for making Ncrunch :)
Hi, thanks for sharing this issue.

The IPC connection closed exception is a catch-all exception thrown by NCrunch when the test process suddenly disappears without warning or provided reason.

There is a near limitless range of things that can cause this. In your situation, the process is terminating before NCrunch can even establish a connection to it.

Check the following:
- Make sure you are able to build a .NET 4.8 console program with the same platform settings and that you can execute this from the command prompt (i.e. test your .NET 4.8)
- Check your windows event logs for error information
- Try disabling any virus scanners
- Browse to your NCrunch installation path (usually something like C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions\Remco Software\NCrunch for Visual Studio 2019), then run the nCrunch.TestHost48.x86.exe and nCrunch.TestHost48.x64.exe programs directly to see if they bomb out with any error information. If they are working as they should be, they should quietly self terminate and do nothing.
This post has been deleted.

Post a reply

Log in to reply.