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

Notification

Icon
Error
NCRunch console: Multiple assemblies with equivalent identity have been imported
Options
Previous Topic Next Topic
GreenMoose
#1 Posted : Wednesday, November 8, 2017 2:20:47 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/17/2012(UTC)
Posts: 507

Thanks: 145 times
Was thanked: 66 time(s) in 64 post(s)
[NCrunch Console Tool v3.11.0.9]

I am in the process of upgrading a dotnetCore solution and it builds/runs fine with NCrunch locally, but build server results in some NCrunch issues. (it builds fine with dotnet build in an earlier build step).

What is the best approach here? Simply ditch the .nuget folder and avoid building netStandard1.3 projects?

Quote:

[14:59:18][Step 2/3] [14:59:17.9236-LocalBuildTask-15] ERROR (Build): Utils.Common: D:\TeamCity\buildAgent\work\3b86814d719339c4\_Tmp\_NCrunch\WC\6276\1\Common\src\Utils.Common\CSC (0): Multiple assemblies with equivalent identity have been imported: 'C:\Users\tcagent\.nuget\packages\netstandard.library\2.0.0\build\netstandard2.0\ref\System.Xml.XDocument.dll' and 'C:\Users\tcagent\.nuget\packages\system.xml.xdocument\4.0.11\ref\netstandard1.3\System.Xml.XDocument.dll'. Remove one of the duplicate references.
[14:59:18][Step 2/3]


Thanks.
Back to top
Remco
#2 Posted : Wednesday, November 8, 2017 8:54:00 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Hi, thanks for sharing this problem.

What I find particularly interesting about this problem is that it's happening during build of the project. NCrunch doesn't really do much manipulation of dependencies during the build of .NET Core projects, most of this is handled downstream in the runtime environment. I suspect this may actually be a genuine issue with your project that is being swallowed outside NCrunch due to unknown or variable factors (such as build sequence).

Does this project depend on any other projects that might cause obscurity in the version of System.Xml.XDocument being used? Are you performing multi-targeting with this project?
Back to top
GreenMoose
#3 Posted : Wednesday, November 8, 2017 9:06:40 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/17/2012(UTC)
Posts: 507

Thanks: 145 times
Was thanked: 66 time(s) in 64 post(s)
Remco;11474 wrote:
Does this project depend on any other projects that might cause obscurity in the version of System.Xml.XDocument being used? Are you performing multi-targeting with this project?

No this is the first isolated project I started with to upgrade. No multi-targeting.

*Edit: Well it does reference nuget packages, I can look into those tomorrow and see if that might be the cause of it.
Back to top
 |  Edit by user
Remco
#4 Posted : Wednesday, November 8, 2017 9:35:20 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
GreenMoose;11476 wrote:

*Edit: Well it does reference nuget packages, I can look into those tomorrow and see if that might be the cause of it.


I'm thinking there is a good chance that there is inconsistent versioning of this binary between the Nuget packages being referenced (the new DLL hell?). I'm not sure where else the clash could be coming from.
Back to top
GreenMoose
#5 Posted : Thursday, November 9, 2017 7:41:20 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/17/2012(UTC)
Posts: 507

Thanks: 145 times
Was thanked: 66 time(s) in 64 post(s)
Update: It was not building latest git versions of the files. It works fine now after building with correct versions. Sorry.
(weird though that dotnet build worked fine for the same file versions, oh well :))
Back to top
1 user thanked GreenMoose for this useful post.
Remco on 11/9/2017(UTC)
GreenMoose
#6 Posted : Thursday, November 9, 2017 12:31:41 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/17/2012(UTC)
Posts: 507

Thanks: 145 times
Was thanked: 66 time(s) in 64 post(s)
Jumped into conclusion to quick on this one, the error was still there. However after half a day of troubleshooting the issue is resolved by defining
env var MSBuildSDKsPath to C:\Program Files\dotnet\sdk\2.0.2\Sdks (open issue https://github.com/Microsoft/msbuild/issues/2532 with MsBuild).

Troubleshooting result details (excluding all the time consuming steps not helping resolving the issue :P):
Quote:

* We have 2 TC build agents building this project, NCrunch built successful on agent1 but not agent2.
* Ensured the netCore SDKs were identical by uninstalling 1.0.1 and 1.0*preview SDKs on agent2, those steps resulted in new error from NCrunch:
System.Exception: An exception was thrown in the remote environment: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Microsoft.Build.Exceptions.InvalidProjectFileException: The SDK 'Microsoft.NET.Sdk' specified could not be found.
* Setting above MSBuildSDKsPath environment variable resolved the issue.


I have not yet found a reason it builds fine on agent1 without MSBuildSDKsPath but not on agent2. Both vs2017 build tools versions are the same, but agent2 also has vstudio2015 IDE installed which might interfere I guess.

HTH
Back to top
 |  Edit by user
Remco
#7 Posted : Thursday, November 9, 2017 9:16:59 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
GreenMoose;11483 wrote:

I have not yet found a reason it builds fine on agent1 without MSBuildSDKsPath but not on agent2. Both vs2017 build tools versions are the same, but agent2 also has vstudio2015 IDE installed which might interfere I guess.
HTH


Nice work figuring this out. This problem falls into the same bucket as a range of other oddities I've discovered where the whole runtime seems to behave differently between environments, even when the same things are installed and the same version of the runtime is used. I can only hope that over time these issues will be pinned down and ironed out.
Back to top
GreenMoose
#8 Posted : Monday, November 13, 2017 10:08:30 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/17/2012(UTC)
Posts: 507

Thanks: 145 times
Was thanked: 66 time(s) in 64 post(s)
FWIW: The ".net core build tools" checkbox was not checked as workload in the vs 2017 build tools installer. Since it has worked fine previously (with net core 1.0) I guess that this checkbox somehow became unchecked during some ms build tools upgrade process.
Back to top
1 user thanked GreenMoose for this useful post.
Remco on 11/13/2017(UTC)
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.046 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download