Csvhelper: Using of ValueTuple

[screamingworld]

Hello,
csv helper is using the value tuple extra package 4.5 for .net 4.5, so it will be installed too when using .net 4.7, but in this version the value tuple is already in the .net framework. So this fact can occur problems (Assembly redirecting isn a real solution for this)... It would be nice if there is an extra port for 4.7 without the valuetuple package.

[JoshClose]

That stinks... When you say Assembly redirecting isn a real solution for this do you mean that doesn't work, or you like don't that solution? Can you reference the netstandard2.0 assembly instead?

[screamingworld]

I mean both. I think a library should not use an other lib which is already included in the .NET Framework (>= 4.7). With the CSV helper we do not get any crashs or something, but I think it is not a very clean way... However... I only open an issue here because I thought it is maybe a solution for removing the useless extra valuetuple package. It was the same with the automapper package. The guys resolved it. Some users had problems with the automapper in 4.7, caused of the valuetuple package...

[mibe94]

For me, creation of CsvReader fails with exception:

Could not load file or assembly 'System.ValueTuple, Version=4.7.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.

[michaelkhalsa]

Hi,
Have traced the dependency graph for problems on a build using net 4.7.2 to this (CsvHelper) package because of its dependency on System.ValueTuple nuget package
Have tried all sorts of things, such as binding redirects, excludes in package manager, etc. And they do not work. I can do a cntrl-f5 build fine and run it.
However when building it within an installer using microsoft project installer .91 it installs fine, but gets a run time error first time it hits a use of native value tuple (which conflicts with the nuget valuetuple namespace).

Could you make a 4.7+ version, or else remove the dependency.
Any other suggestions very welcome.
Thanks

[remcoros]

Any update on this issue? Is a new nuget package release planned?

[michaelkhalsa]

Progress Update on my previous comment: At least for me, Binding Redirects make the problem worse. (ignore entry did nothing). This took some experimentation. If an assembly binding redirect to system.valuetuple is in the config file, then it will always throw on the namespace conflict.

In the case of using Microsoft Project Installer (desktop installer), if i do a build directly after changing the Product GUID (i.e., change the version number for the installer), then it will install fine. However, if i do a installer build without doing this first, then it will add in an assembly binding redirect into the app .exe.config file automatically, which then results in a run-time error when the app is run after installation.

If in such a corrupted installation, I manually edit the executable config file for the app in the c:/Program Files/... directory and removed the unasked for binding redirect to System.ValueTuple, then it works again. (or course that is not a practical solution for customers).

Another factor is that this large project used to be in .net 4.6.1 with System.Values from NuGet. When i upgraded to 4.7.2, i removed these nuget package references (there is a bunch of them for various things that later got folded back into framework), and also migrated to storing nuget references in the *.vbproj and *.csproj files instead of nuget project files. I also deleted the bin/object folders to force a clean rebuild. I did this for all of my library solutions as well.

I am not sure if this is an issue unique to microsoft project installer, or not (will try Wix when get the bandwidth) - however hope including it here might be of value to someone else using this.

In summary, when using Installer Project, as long as the install version is upgraded each time before the 'installer' is built, then an install works fine. There are probably other nuances have not looked at yet.

[tjmoore]

Has this got anything to do with this? https://github.com/dotnet/corefx/issues/32610

I'm hitting this issue myself where I get the assembly load failure with System.ValueTuple on Windows Server 2019, though not on Windows 10. Difference is 2019 has .NET 4.7.2 and Win 10 has 4.8 installed (plus developer environment).

On 2019, if I manually remove the autogenerated redirect binding for ValueTuple, then it works. I've tried setting AutoGenerateBindingRedirects in my project to false, but this leads to project warnings about version conflicts. I've also tried PackageReference and referencing either CsvHelper or System.ValueTuple, but that doesn't seem to help.

This is a showstopper for me as I'm trying to release a product that's been updated to target .NET 4.7.2 and it now fails due to this dependency.

[tjmoore]

Actually, I have got something to work.

If I put PackageReference to System.ValueTuple in my project...

  <ItemGroup>
    <PackageReference Include="System.ValueTuple" Version="4.5.0" />
  </ItemGroup>

But then also remove the System.ValueTuple reference in packages.config and make sure App.config in the solution doesn't have the binding redirect entry, then it doesn't add System.ValueTuple as an output, or add the binding redirect on compile, but keeps CsvHelper happy it seems with the package reference.

This works on both my test platforms.

[AbdulQader-m]

can't the csvHelper just take dependency on Net Standard System.ValueTuple instead of net framework?

[remcoros]

CsvHelper needs an explicit target for net47 where it does not require the ValueTuple package (as it is inbox in .net 4.7), should be straightforward change to csproj file

[Jehoel]

@AbdulQader-m that would be the best long-term solution, but many people still need to target platforms that don't support .NET Standard 2.0.

[dmcbride]

Another alternative is to install CsvHelper, and then force-remove ValueTuple without removing dependencies on it. This is still a workaround, however, and getting a CsvHelper out without the dependency on ValueTuple when using net47 would be very handy.

[JoshClose]

I just released version 12.1.3 that has a separate net47 build that doesn't use System.ValueTuple. Let me know if it's still a problem.

[drvic10k]

I still have the problem

Unable to uninstall 'System.ValueTuple.4.5.0' because 'CsvHelper.12.2.3' depends on it.

I also tried the older version with same result

Unable to uninstall 'System.ValueTuple.4.5.0' because 'CsvHelper.12.1.3' depends on it.

[drvic10k]

so the solution was to uninstall the nuget and install again, then it came without the dependency, just updating didn't work

[JoshClose]

Good to know. Thanks!