This year a lot of our work has transitioned to .NET Core (2.0 and very soon 2.1) from .NET Framework v4.5. We're finding NCrunch v3.12 does not handle our .NET Core projects. Our license expired end of last year so I've been unable to test if NCrunch's support for .NET Core has improved after version v3.12.0.15.

Is there a way we can get a trial license to see if the latest version of NCrunch works with .NET Core? Alternatively, I've uploaded a very stripped down example that is a prototypical project for us that reproduces the failures: https://github.com/robmen/PrototypicalProject

Those projects work properly under VS's "Live Unit Testing" but I much prefer the NCrunch development experience. So I would like to renew our company's licenses if a newer version of NCrunch works properly with .NET Core.


The current error we're seeing with NCrunch v3.12.0.15 (in VS2017 v15.7.3) is the following:

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:
Assets file 'C:\src\PrototypicalProject\Build\obj\nCrunchTemp_e242c397-3ec1-46bb-b484-9a544e78ea4d\project.assets.json' not found. Run a NuGet package restore to generate this file.
at nCrunch.Compiler.RemoteBuildRunner.(FilePath , LoadTimeQuery , String , String , DirectoryPath , String , String )
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 , ProcessorArchitecture , GridClientId , BuildSystemParameters , IList`1 , Nullable`1 , GridAddress )
at nCrunch.Core.BuildManagement.BuildProcessLauncher.AnalyseComponentBuildInExternalProcess(ComponentLoadParameters parameters, IList`1 customEnvironmentVariables)
at nCrunch.Client.ComponentLoader.SnapshotComponentLoader.(ProcessorArchitecture , 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)

Thanks. I updated to v3.17.0.2 and I got a new failure.

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:
Assets file 'C:\src\PrototypicalProject\Build\obj\nCrunchTemp_09639a73-8b7d-4af1-9617-31a65f24bea1\project.assets.json' not found. Run a NuGet package restore to generate this file.
at nCrunch.Compiler.RemoteBuildRunner.(FilePath , LoadTimeQuery , String , String , DirectoryPath , String , String )
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 , ProcessorArchitecture , GridClientId , BuildSystemParameters , IList`1 , Nullable`1 , GridAddress )
at nCrunch.Core.BuildManagement.BuildProcessLauncher.AnalyseComponentBuildInExternalProcess(ComponentLoadParameters parameters, IList`1 customEnvironmentVariables)
at nCrunch.Client.ComponentLoader.SnapshotComponentLoader.(ProcessorArchitecture , 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)

We root all of the builds in a single folder in the root of the project for many reasons. For one, it co-locates the various build outputs (not all are .csproj) into a single folder that matches our deployment shape (so debugging is possible). Another example, it makes it very easy to ensure a build is clean without losing .user files like a "git clean -fdx" would.

This "relocated Build root" works correctly with .NET Framework projects and NCrunch. Is it difficult or impossible for NCrunch to support it for .NET Core projects?

Note: we could probably use a different structure under the Build root folder if that was necessary. The $(MSBuildProjectName) is included in the intermediate folder to prevent collisions of same named files between projects (like project.assets.json).

Understood. We're used to struggling with VS and MSBuild designs (particularly at their integration points).

Would it work if there was an $(NCrunchOriginalMSBuildProjectName) that we could conditionally use in our Directories.Build.props file to cause the files in NCrunch to use the same intermediate folders as VS? Something like:

<BaseIntermediateOutputPath Condition="'$(NCrunchOriginalMSBuildProjectName)'!=''">$(RootFolder)Build\obj\$(NCrunchOriginalMSBuildProjectName)\</BaseIntermediateOutputPath>
<BaseIntermediateOutputPath Condition="'$(NCrunchOriginalMSBuildProjectName)'==''">$(RootFolder)Build\obj\$(MSBuildProjectName)\</BaseIntermediateOutputPath>

In general, it would be great if there were $(NCrunchOriginalXxx) for all the built-in MSBuild properties that are overridden by the temporary NCrunch project. I know the $(NCrunchOriginalProjectDir) saved us once before.

I just saw the release notes for v3.18 and this item piqued my interest:

> Adjusted the NCrunch project load system so that the ProjectName, AssemblyName and ProjectFileName properties will be set to the
> correct name of the project rather than the NCrunch temp file. This should help to enable better compatibility with customised
> build systems.

This looks like it may solve my problems so I'm very excited. Is there a way I could try out v3.18 to verify these changes do what I think they'll do for us? If so, I look forward to renewing our license and getting back on NCrunch.

Yes, I'm very excited to try to get NCrunch working with our projects. I've updated my "prototypical example project" (https://github.com/robmen/PrototypicalProject) with what I *think* is the correct way to use the new properties. The behavior is different but, unfortunately, still not working.

First, I see:

> NCrunch was unable to restore Nuget packages required to build a test environment for this solution,
> due to an unspecified failure when invoking 'msbuild.exe /t:restore'
>
> The following packages do not exist under the Nuget packages folder for the active user profile, yet
> they have been flagged by NCrunch as potentially needed for normal operation. NCrunch has attempted
> to restore these files via an MSBuild restore step, which has either failed or not returned the expected
> result. It's possible that these packages may not be needed for building projects or running tests in
> your environment. If you experience downstream problems with NCrunch on this solution, it is recommended
> you restore or download the packages manually.
>
> Microsoft.NETCore.Platforms v1.1.0
> Microsoft.NETCore.Targets v1.1.0
> System.Collections v4.3.0
> System.Collections.NonGeneric v4.3.0
> System.Diagnostics.Debug v4.3.0

And many more.

I can do a manual "msbuild.exe /t:Restore" from the command prompt and then the test project ("ExampleTests" a netcoreapp2.1 using xunit 2.4.0) fails with:

> 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.(ProcessorArchitecture , 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()

Verbose logging didn't show anything that I could discern. Again, you can see my stripped down example project at: https://github.com/robmen/PrototypicalProject

Suggestions?

Sorry, I was wrong. It's not related to .NET Core 2.1. This looks to be a continuation of the same problem. There is just too much implicit MSBuild behaviour around the name of the project file itself for us to be able to handle this use case. The abstractions in place just don't give us enough control over the build system to be able to load projects in this structure. I'm sorry, but even with the new property overrides, there's no way we can support overriding the base obj directory for .NET Core projects under NCrunch.

Thank you so much for the persistence. My (second) evaluation key had expired but I appreciate the effort you've done so much I upgraded our keys. Great news is that v3.19 does address my "prototypical project". I'm going to slowly adapt my other "real" (thus more complex) .NET Core projects to work properly under NCrunch. I think we can call this issue resolved with v3.19. Should I encounter any new problems (with my more complex projects), I'll open a new discussion topic.

Again, thank you for finding a way through. I forgot how much I more enjoyable testing is under NCrunch. It is a great product (once the projects get configured).