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

Notification

Icon
Error

.NET Core 2.0 Support with re-located build folder
robmen
#1 Posted : Monday, June 4, 2018 9:11:43 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/6/2015(UTC)
Posts: 19
Location: United States of America

Thanks: 1 times
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)
Remco
#2 Posted : Monday, June 4, 2018 9:20:42 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
Hi, thanks for posting.

With the amount that .NET Core has moved, I don't have high expectations on a release as old as v3.12 working correctly. I'd be willing to bet that we've already fixed this in a later build.

I've just dropped a short evaluation license on your website account. You're welcome to take the new version for a spin and see if it works for you :)
robmen
#3 Posted : Monday, June 4, 2018 9:34:10 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/6/2015(UTC)
Posts: 19
Location: United States of America

Thanks: 1 times
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)

Remco
#4 Posted : Monday, June 4, 2018 10:09:16 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
It looks like this problem is being caused by a custom build override inside the Directory.Build.Props file:

<BaseIntermediateOutputPath>$(RootFolder)Build\obj\$(MSBuildProjectName)\</BaseIntermediateOutputPath>

Do you know why this has been redirected to a different location? By placing the MSBuildProjectName in the path, NCrunch isn't able to create a parallel project to load your project via MSBuild. Removing the override resolves the issue.
robmen
#5 Posted : Monday, June 4, 2018 10:17:54 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/6/2015(UTC)
Posts: 19
Location: United States of America

Thanks: 1 times
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).
Remco
#6 Posted : Monday, June 4, 2018 11:44:17 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
It should still be possible to redirect your OutputPath without introducing any problems. The issue here is caused by the location of the generated files inside the 'obj' directory. The problem is caused by technical limitations with MSBuild, basically:

- We need to be able to run MSBuild over your project file to learn what is required to build your project (dependencies, platform, etc).
- This can't be done using your normal project file, because we need to make modifications to the project file
- MSBuild does not support us doing this in-memory, so it must be done on disk
- Thus we need to create a modified project file adjacent to your own project file that can share all the same resolution logic (the nCrunch 'Temp' file)
- This means that out of necessity, the modified project file must have a different name on disk
- As a result, the $(MSBuildProjectName) returns a different name, so the build system expects to find the project.assets.json file in a different place
- We rely on VS to generate the project.assets.json file for us prior to loading the project, as trying to do this ourselves creates hideous concurrency issues and poor performance
- This means that using your override, VS places the project.assets.json file in a different location to that which is expected by MSBuild when NCrunch tries to load the modified project

I haven't been able to come up with a way that we can accommodate this use case without introducing a serious risk of breaking the integration for other users. Due to MSBuild limitations, it isn't possible for us to override the MSBuildProjectName property, and by introducing different behaviour for NCrunch vs Visual Studio, we end up losing the project.assets.json file anyway. Project.assets.json is actually just the tip of the iceberg here, as there is a multitude of files generated in the obj directory that are required by MSBuild.

TLDR; We can't fix this in NCrunch. If you want to use NCrunch on these projects, please do not override BaseIntermediateOutputPath with a file path containing your project name.
robmen
#7 Posted : Monday, June 4, 2018 4:49:12 PM(UTC)
Rank: Member

Groups: Registered
Joined: 5/6/2015(UTC)
Posts: 19
Location: United States of America

Thanks: 1 times
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.
Remco
#8 Posted : Monday, June 4, 2018 9:43:41 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
It doesn't look like we have any environment variables of that description during the load of projects .. at least not right now. It occurs to me though that with the new CPS project systems inferring many of the build properties from the project file name that we should be trying to add something here, or trying to override what we can to mask the name of the modified project. Unfortunately I won't be able to provide anything on this over the next few days, but I'll take a look to see what we can do here.

I also feel your pain around the changes to the build workflow in MSBuild. The minimal project XML files are really nice, but the way that project.assets.json works has taken quite a bit of effort from our part to properly support. I guess we should count our blessing though - it could have all been in json!
robmen
#9 Posted : Thursday, August 9, 2018 5:49:08 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/6/2015(UTC)
Posts: 19
Location: United States of America

Thanks: 1 times
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.
Remco
#10 Posted : Friday, August 10, 2018 5:13:51 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
Hi Rob,

I'm glad you picked up on this one :) This change was triggered by your support request. I've created a short evaluation license and placed this on your account on this website, if you'd like to give the new build a try.
robmen
#11 Posted : Friday, August 10, 2018 7:21:34 AM(UTC)
Rank: Member

Groups: Registered
Joined: 5/6/2015(UTC)
Posts: 19
Location: United States of America

Thanks: 1 times
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?
Remco
#12 Posted : Friday, August 10, 2018 7:26:01 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
Thanks for sending through the bug report and the link to the sample project. I've immediately managed to reproduce the issue over here and I'm looking into the problem. I think this may be related to the move to .NET Core 2.1 rather than your build customisations. I'll let you know when I have more information.
1 user thanked Remco for this useful post.
robmen on 8/10/2018(UTC)
Remco
#13 Posted : Friday, August 10, 2018 7:54:30 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
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.
Users browsing this topic
Guest (2)
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.079 seconds.