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

Notification

Icon
Error

Issue Building .NET Core Project in VS2017 with 3.6
FubarCoder
#1 Posted : Wednesday, March 29, 2017 8:49:16 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/2/2015(UTC)
Posts: 4
Location: Germany

Thanks: 1 times
Hi,

I get the following error for some projects when enabling NCrunch 3.6 with my WebDAV server (https://github.com/FubarDevelopment/WebDavServer):

Code:
System.Exception: An exception was thrown in the remote environment: System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> nCrunch.Common.UserException: Errors occurred while trying to load the project file: 
Your project is not referencing the ".NETFramework,Version=v4.0" framework. Add a reference to ".NETFramework,Version=v4.0" in the "frameworks" section of your project.json, and then re-run NuGet restore.
   bei nCrunch.Compiler.RemoteBuildRunner.(FilePath , LoadTimeQuery , String , String , DirectoryPath , String , String )
   bei nCrunch.Compiler.RemoteBuildRunner.AnalyseComponentBuild(ComponentLoadParameters parameters)
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   bei nCrunch.TaskRunner.Ipc.IpcMessageProcessor.(CallMethodMessage )
   bei nCrunch.TaskRunner.Ipc.IpcMessageProcessor.ProcessMessageReturningResult(Byte[] data)
   bei nCrunch.TaskRunner.Ipc.RemoteInstance.(Byte[] )
   bei nCrunch.TaskRunner.Ipc.RemoteInstance.Invoke(IMessage msg)
   bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   bei nCrunch.Compiler.IRemoteBuildRunner.AnalyseComponentBuild(ComponentLoadParameters parameters)
   bei nCrunch.Core.BuildManagement.BuildProcessLauncher..(IRemoteBuildRunner )
   bei nCrunch.Core.BuildManagement.BuildProcessLauncher.(Action`1 , FilePath , String , ExternalProcess )
   bei nCrunch.Core.BuildManagement.BuildProcessLauncher.(Action`1 , ProcessorArchitecture , GridClientId , BuildSystemParameters , IList`1 )
   bei nCrunch.Core.BuildManagement.BuildProcessLauncher.AnalyseComponentBuildInExternalProcess(ComponentLoadParameters parameters, IList`1 customEnvironmentVariables)
   bei nCrunch.Client.ComponentLoader.SnapshotComponentLoader.(ProcessorArchitecture , String )
   bei 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)


The projects in question are built for the target frameworks netstandard1.3 and net451:

Code:
<TargetFrameworks>netstandard1.3;net451</TargetFrameworks>


Any idea why this happens?

Kind regards,
Mark
Remco
#2 Posted : Wednesday, March 29, 2017 11:47:38 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,145

Thanks: 960 times
Was thanked: 1290 time(s) in 1196 post(s)
Hi Mark,

Thanks for sharing this issue.

The exception you're seeing above is what happens when NCrunch tries to build a shared project. Right now support for shared projects is still a work in progress, so it isn't very tidy yet, though it does still work. Shared projects themselves only act as containers for files that are to be included in other projects, so they technically shouldn't be built directly by NCrunch. The normal practice for these project types is to ignore them using the 'Ignore this component completely' setting.

Because your shared projects have the same name as other projects in your solution, it's impossible to configure them separate from your other projects, because NCrunch always generates its config files using the format 'project.v3.ncrunchproject'. This means that it isn't possible for you to ignore your shared projects using NCrunch without also ignoring everything else.

I've noticed that you're also using multi-targeting across this solution. A couple of the projects I looked at seemed as though they were both multi-targeted and referencing shared projects. Is it possible that now you are using the multi-targeting, the shared projects are now redundant?

To remove the errors under NCrunch, you'll need to either remove the shared projects from your solution, or give them different names to your other projects (i.e. FubarDev.WebDavServer.Shared.shproj) so that you can ignore them.
1 user thanked Remco for this useful post.
FubarCoder on 3/30/2017(UTC)
FubarCoder
#3 Posted : Thursday, March 30, 2017 6:17:31 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/2/2015(UTC)
Posts: 4
Location: Germany

Thanks: 1 times
Thank you for your quick response.

The shared projects are only for the projects under src-doc/, because - annoyingly - docfx cannot handle the new style csproj files and so I created old style csproj files which are using the shared projects to avoid linking all files for a project manually.

I'll follow your recommendation and rename the shared projects.

Kind regards,
Mark
Users browsing this topic
Guest
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.039 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download