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 04, 2018 9:11:43 AM(UTC)
Rank: Member

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

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 04, 2018 9:20:42 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 691 times
Was thanked: 843 time(s) in 803 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 04, 2018 9:34:10 AM(UTC)
Rank: Member

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

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 04, 2018 10:09:16 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 691 times
Was thanked: 843 time(s) in 803 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 04, 2018 10:17:54 AM(UTC)
Rank: Member

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

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 04, 2018 11:44:17 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 691 times
Was thanked: 843 time(s) in 803 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 04, 2018 4:49:12 PM(UTC)
Rank: Member

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

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 04, 2018 9:43:41 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 691 times
Was thanked: 843 time(s) in 803 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!
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.067 seconds.