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

Notification

Icon
Error
Target Framework defined in Directory.Build.props causes ncrunch to fail
Options
Previous Topic Next Topic
edfrey
#1 Posted : Wednesday, January 8, 2020 3:27:18 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 1/8/2020(UTC)
Posts: 1
Location: United States of America
Good morning!

We have a large number of c# projects and have been upgrading frameworks very quickly and it was very human error prone so we broke the target framework out into a property in our Directory.Build.props. I added the Directory.Build.props file to the ncrunch config to copy over as a needed file but still ncrunch gives me an error about unknown framework. For now I've explicitly defined the framework as a custom build property on every project but I'd like to remove that if possible. This appears to only be an issue with building in ncrunch as the rest of our build / deployment pipeline works. Does anyone have any ideas how to resolve this issue?

Ncrunch 4.2, optimized engine.

Thank you!

Quote:
ENGINE - [10:21:51.4127-InitialisationQueueTask-76] ERROR (Load): Error occurred during load of component at
UnitTests.csproj: 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 "ResolvePackageAssets" task failed unexpectedly.
NuGet.Frameworks.FrameworkException: Invalid framework identifier ''.
at NuGet.Frameworks.NuGetFramework.GetShortFolderName(IFrameworkNameProvider mappings)
at Microsoft.NET.Build.Tasks.LockFileExtensions.GetTargetAndThrowIfNotFound(LockFile lockFile, NuGetFramework framework, String runtime)
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheWriter..ctor(ResolvePackageAssets task)
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader.CreateReaderFromDisk(ResolvePackageAssets task, Byte[] settingsHash)
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader..ctor(ResolvePackageAssets task)
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ReadItemGroups()
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ExecuteCore()
at Microsoft.NET.Build.Tasks.TaskBase.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
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)


From csproj:
Quote:

<PropertyGroup>
<TargetFramework>$(AppFrameworkVersion)</TargetFramework>
</PropertyGroup>


From Directory.Build.props
Quote:
<Project>
<PropertyGroup>
<AppFrameworkVersion>netcoreapp3.1</AppFrameworkVersion>
<LibraryFrameworkVersion>netstandard2.1</LibraryFrameworkVersion>
</PropertyGroup>
</Project>


works if I override ncrunch with this

Quote:
<ProjectConfiguration>
<Settings>
<CustomBuildProperties>
<Value>TargetFramework = netcoreapp3.1</Value>
</CustomBuildProperties>
</Settings>
</ProjectConfiguration>
Back to top
 |  Edit by user
Remco
#2 Posted : Thursday, January 9, 2020 9:20:21 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 957 times
Was thanked: 1286 time(s) in 1193 post(s)
Hi, thanks for sharing this issue.

This is a known limitation with the way we handle the TargetFramework(s) property under NCrunch.

At present, we haven't found a feasible way to solve this problem. Unfortunately, you'll need to have each project explicitly declare its target framework using NCrunch configuration.

Note that if you are using NCrunch's advanced configuration mode, you can also set the Custom Build Properties configuration at solution level and the projects will inherit the setting value. This could save you from needing to specify it for each individual project.
Back to top
UppSol
#3 Posted : Thursday, January 9, 2020 1:06:09 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 3/21/2019(UTC)
Posts: 41
Location: Austria

Thanks: 30 times
Was thanked: 7 time(s) in 7 post(s)
edfrey;14323 wrote:
Good morning!

We have a large number of c# projects and have been upgrading frameworks very quickly and it was very human error prone so we broke the target framework out into a property in our Directory.Build.props. I added the Directory.Build.props file to the ncrunch config to copy over as a needed file but still ncrunch gives me an error about unknown framework. For now I've explicitly defined the framework as a custom build property on every project but I'd like to remove that if possible. This appears to only be an issue with building in ncrunch as the rest of our build / deployment pipeline works. Does anyone have any ideas how to resolve this issue?

Ncrunch 4.2, optimized engine.

Thank you!

Quote:
ENGINE - [10:21:51.4127-InitialisationQueueTask-76] ERROR (Load): Error occurred during load of component at
UnitTests.csproj: 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 "ResolvePackageAssets" task failed unexpectedly.
NuGet.Frameworks.FrameworkException: Invalid framework identifier ''.
at NuGet.Frameworks.NuGetFramework.GetShortFolderName(IFrameworkNameProvider mappings)
at Microsoft.NET.Build.Tasks.LockFileExtensions.GetTargetAndThrowIfNotFound(LockFile lockFile, NuGetFramework framework, String runtime)
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheWriter..ctor(ResolvePackageAssets task)
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader.CreateReaderFromDisk(ResolvePackageAssets task, Byte[] settingsHash)
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader..ctor(ResolvePackageAssets task)
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ReadItemGroups()
at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ExecuteCore()
at Microsoft.NET.Build.Tasks.TaskBase.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
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)


From csproj:
Quote:

<PropertyGroup>
<TargetFramework>$(AppFrameworkVersion)</TargetFramework>
</PropertyGroup>


From Directory.Build.props
Quote:
<Project>
<PropertyGroup>
<AppFrameworkVersion>netcoreapp3.1</AppFrameworkVersion>
<LibraryFrameworkVersion>netstandard2.1</LibraryFrameworkVersion>
</PropertyGroup>
</Project>


works if I override ncrunch with this

Quote:
<ProjectConfiguration>
<Settings>
<CustomBuildProperties>
<Value>TargetFramework = netcoreapp3.1</Value>
</CustomBuildProperties>
</Settings>
</ProjectConfiguration>


Starting with VS 16.4 you no longer need to specifiy the target framework for each project --> therefore you can remove it from every csproj file an add it to the directory.build.props file (I have done this with my solutions and it works with R# Build, VS Build and also with NCrunch (without any extra effort).

e.q:

Directory.Build.props:

<Project>
<PropertyGroup>
<AppFrameworkVersion>netcoreapp3.1</AppFrameworkVersion>
<LibraryFrameworkVersion>netstandard2.1</LibraryFrameworkVersion>
<TargetFramework>$(AppFrameworkVersion)</TargetFramework> // I don't know if you can use the variable $(AppFrameworkVersion) here, but you could replace it with netcoreapp3.1 (the only drawback when the variable does not work is that you have the string netcoreapp3.1 added twice, but I think that's not too bad.
</PropertyGroup>
</Project>
Back to top
 |  Edit by user
Remco
#4 Posted : Thursday, January 9, 2020 10:45:22 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 957 times
Was thanked: 1286 time(s) in 1193 post(s)
UppSol;14332 wrote:

Starting with VS 16.4 you no longer need to specifiy the target framework for each project --> therefore you can remove it from every csproj file an add it to the directory.build.props file (I have done this with my solutions and it works with R# Build, VS Build and also with NCrunch (without any extra effort).


Yes. Unfortunately, under NCrunch the mechanics of our integration with the build system require us to know the target frameworks well in advance of loading the project. Thus we need to establish this by parsing the project files or via a configuration setting. Specifying target frameworks indirectly outside the project file would require us to rebuild the entire parsing logic of the build system, which just isn't feasible for us. So at the moment, if you specify your target frameworks in the directory.props, you must also specify it in your NCrunch configuration.
Back to top
UppSol
#5 Posted : Friday, January 10, 2020 6:01:35 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 3/21/2019(UTC)
Posts: 41
Location: Austria

Thanks: 30 times
Was thanked: 7 time(s) in 7 post(s)
Remco;14335 wrote:
UppSol;14332 wrote:

Starting with VS 16.4 you no longer need to specifiy the target framework for each project --> therefore you can remove it from every csproj file an add it to the directory.build.props file (I have done this with my solutions and it works with R# Build, VS Build and also with NCrunch (without any extra effort).


Yes. Unfortunately, under NCrunch the mechanics of our integration with the build system require us to know the target frameworks well in advance of loading the project. Thus we need to establish this by parsing the project files or via a configuration setting. Specifying target frameworks indirectly outside the project file would require us to rebuild the entire parsing logic of the build system, which just isn't feasible for us. So at the moment, if you specify your target frameworks in the directory.props, you must also specify it in your NCrunch configuration.


@Remoco it's working on my end without specifing the framework in my NCrunchConfig, it's working in all my current solutions (about 10 different solutions).
I can send you a sample solution, can it be coincidence? We are using .Net 4.7.2

Br
Back to top
Remco
#6 Posted : Friday, January 10, 2020 10:30:56 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 957 times
Was thanked: 1286 time(s) in 1193 post(s)
UppSol;14336 wrote:

@Remoco it's working on my end without specifing the framework in my NCrunchConfig, it's working in all my current solutions (about 10 different solutions).
I can send you a sample solution, can it be coincidence? We are using .Net 4.7.2


Are these multi-targeted projects? If not, there may be a fallback in place that can work for this situation.
Back to top
UppSol
#7 Posted : Friday, January 10, 2020 11:53:21 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 3/21/2019(UTC)
Posts: 41
Location: Austria

Thanks: 30 times
Was thanked: 7 time(s) in 7 post(s)
Remco;14338 wrote:
UppSol;14336 wrote:

@Remoco it's working on my end without specifing the framework in my NCrunchConfig, it's working in all my current solutions (about 10 different solutions).
I can send you a sample solution, can it be coincidence? We are using .Net 4.7.2


Are these multi-targeted projects? If not, there may be a fallback in place that can work for this situation.


They are single targeted, maybe that's the reason. Thx for clarifying.
Br
Back to top
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.097 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download