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

Notification

Icon
Error

Could not locate the assembly "System.ValueTuple"
NuvasiveIOS
#1 Posted : Tuesday, December 18, 2018 6:02:32 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/18/2018(UTC)
Posts: 6
Location: United States of America

Thanks: 1 times
My project has a dependency on System.ValueTuple that is downloaded with NuGet. Everything builds fine in Visual Studio and our build server but fails to build with NUnit.

It appears that the NCrunch logic is removing the reference to System.ValueTuple within the csproj because of the "System" part of the name. If I rename the dll and update the reference to "Test.ValueTuple", it now sees it and compile just fine. Is there a configuration to make all references be included?
Remco
#2 Posted : Tuesday, December 18, 2018 11:02:16 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 737 times
Was thanked: 944 time(s) in 899 post(s)
Hi, thanks for sharing this issue.

NCrunch has no special logic targeting this Nuget package. There must be something else in your build system causing this. Do you have any binding redirections in place? Can you confirm which version of NCrunch you are using?

Out of interest, how are you adding the reference to System.ValueType? This package doesn't seem to exist for me under Nuget .. I think it's an implicitly handled platform dependency.
NuvasiveIOS
#3 Posted : Tuesday, December 18, 2018 11:30:47 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/18/2018(UTC)
Posts: 6
Location: United States of America

Thanks: 1 times
It's ValueTuple, not ValueType. Here's the nuget package in reference:

https://www.nuget.org/packages/System.ValueTuple/

It comes by default with .net 4.7 but since I'm using 4.6.1 it needs to be referenced by the nuget package. What's curious is if i simply rename the DLL and the reference in the csproj, then it is referenced in the csproj that NCrunch creates in AppData. I believe it's tied to the fact that it has "System" as part of its name and thus filters it out but I cannot confirm that.
Remco
#4 Posted : Tuesday, December 18, 2018 11:46:20 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 737 times
Was thanked: 944 time(s) in 899 post(s)
My apologies. I've been staring at value types so long that I was completely confused.

Are you able to build a sample project that can produce this problem? I can't seem to get this to happen on my end with a standard project template. You can submit code via https://www.ncrunch.net/support/contact.
NuvasiveIOS
#5 Posted : Monday, February 25, 2019 7:46:04 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/18/2018(UTC)
Posts: 6
Location: United States of America

Thanks: 1 times
Sent. My apologies for the delayed response.

As far as I can tell, there two cases where it works and one that does not.

1. A relative path is used to the dll. This is the normal case if getting from nuget.
2. when using a variable, like $(SolutionDir), and the word "System." is not part of the dll.

When it fails is the combination of $(SolutionDir) and "System." is included in the name of the dll. When I renamed the dll to reference "$(SolutionDir)\Bin\Test.ValueTuple" that seemed to work just fine.
Remco
#6 Posted : Tuesday, February 26, 2019 12:06:30 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 737 times
Was thanked: 944 time(s) in 899 post(s)
Thanks for sending this through. We'll take a look and will let you know as soon as we have more information.
michaelkroes
#7 Posted : Wednesday, February 27, 2019 10:40:11 AM(UTC)
Rank: NCrunch Developer

Groups: Registered
Joined: 9/22/2017(UTC)
Posts: 124
Location: Netherlands

Thanks: 53 times
Was thanked: 24 time(s) in 22 post(s)
Hi,

Sadly there is no automatic way for us to support this.

If you don't want to use the nuget package directly and want to use the $(SolutionDir) method inside your solution for this DLL you will need to set the "Additional files to include" setting. There you can select the DLL and it will be copied correctly. You can find this setting under the NCrunch Configuration=>Solution settings (either shared or my settings)=>General=>Additional files to include.

NuvasiveIOS
#8 Posted : Wednesday, February 27, 2019 6:38:33 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/18/2018(UTC)
Posts: 6
Location: United States of America

Thanks: 1 times
michaelkroes,

I tried that. It's not that the dll is not being copied over into the _ncrunchreferences directory, because it is, it is that the resulting .csproj file within %localappdata%\NCrunch\#####\#\<PROJECT>\ does not update the path. In the solution I provided, you can see the working version updates the include path:

<Reference Include="C:\Users\<USERNAME>\AppData\Local\NCrunch\13580\2\_ncrunchreferences\Test.ValueTuple.dll" />

Where the non working version does not:

<Reference Include="System.ValueTuple">
<HintPath>$(SolutionDir)\Bin\3rd-Party\System.ValueTuple\lib\net461\System.ValueTuple.dll</HintPath>
</Reference>
Remco
#9 Posted : Wednesday, February 27, 2019 8:53:29 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 737 times
Was thanked: 944 time(s) in 899 post(s)
The main issue here actually comes from a little known redirection system that Microsoft introduced in a minor update to VS2017 around the middle of last year.

System.ValueTuple is one of a number of assemblies that can be redirected internally inside the MSBuild system to a different location. MS did this to try and retroactively introduce support for .NET Standard in older versions of .NET Framework, and it really made a terrible mess of the build system because suddenly the version of an assembly being used at build/run time is not always the same as the one being referenced on disk.

Because the redirection is internal to MSBuild and we found no way to integrate with it, we instead try to organise the dependencies around it. Assemblies that can be redirected by the system we avoid tampering with and moving into _ncrunchreferences because by doing this we risk breaking the build system in any number of unpredictable ways.

System.ValueTuple is one of these assemblies. In most scenarios (actually, all known ones except yours), this works fine, because people reference this assembly using a Nuget package or from an established framework location. By copying this assembly into your solution directory and referencing it using a <Reference>, you've managed to expose a hole in the system that we can't plug without breaking something else.

So to solve this, you'll need to either use the 'Additional Files To Include' setting to ensure the referenced file exists in the workspace (without _ncrunchreferences sandboxing), or you'll need to reference the file from its Nuget package. Sorry, but this isn't something we can fix in the product. The design of the platform has really tied our hands here.
1 user thanked Remco for this useful post.
NuvasiveIOS on 2/27/2019(UTC)
NuvasiveIOS
#10 Posted : Wednesday, February 27, 2019 10:26:49 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/18/2018(UTC)
Posts: 6
Location: United States of America

Thanks: 1 times
Remco,

Thanks for the explanation. In my case, adding the dll to 'Additional Files To Include' didn't change anything since the dll with or without it is found within _ncrunchreferences. The only thing that was different was the csproj. Unfortunately, I cannot update our build/reference process so we'll just have to disable NCrunch for projects that use ValueTuple until we target a version that has native support.
Remco
#11 Posted : Wednesday, February 27, 2019 11:29:47 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 737 times
Was thanked: 944 time(s) in 899 post(s)
NuvasiveIOS;13148 wrote:

Thanks for the explanation. In my case, adding the dll to 'Additional Files To Include' didn't change anything since the dll with or without it is found within _ncrunchreferences. The only thing that was different was the csproj. Unfortunately, I cannot update our build/reference process so we'll just have to disable NCrunch for projects that use ValueTuple until we target a version that has native support.


This doesn't sound quite right to me, as NCrunch will only copy this assembly into _ncrunchreferences if it's able to adjust the .csproj file to point to the copied file. When we tested this using your sample solution, we were able to make this work using 'Additional files to include'. Basically, we just included the assembly in its original location using this setting. Your search logic uses $(SolutionDir) to find the assembly, so as long as it's included in the workspace in the same relative path, your build system should be able to find it as usual.
NuvasiveIOS
#12 Posted : Thursday, February 28, 2019 12:47:52 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/18/2018(UTC)
Posts: 6
Location: United States of America

Thanks: 1 times
Actually, trying it again once more 'Additional Files To Include' did allow me to build. In either case, the dll is being added to _ncrunchreferences. I sent a gif showing this.
Remco
#13 Posted : Thursday, February 28, 2019 9:51:35 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 737 times
Was thanked: 944 time(s) in 899 post(s)
Thanks, this is quite interesting. Probably the logic to 'sandbox' the DLL is still running while the redirection is not taking place. Regardless, it shouldn't be something you need to be worried about. This workaround shouldn't have any side-effects and should allow the engine to work normally with the binary referenced using your relative path.
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.061 seconds.