Automapper: System.ValueTuple package should not be referenced for .NET 4.7+ projects

Created on 7 Aug 2018  Â·  27Comments  Â·  Source: AutoMapper/AutoMapper

Version: 7.0.1

Expected behavior

System.ValueTuple dependency should not be included in projects that target .NET 4.7 and up.

Actual behavior

System.ValueTuple dependency is added and causes our web projects, which target .net 4.7.2, to require the following web.config binding redirect:

<dependentAssembly>
    <assemblyIdentity name="System.ValueTuple" publicKeyToken="CC7B13FFCD2DDD51" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.3.0" newVersion="4.0.3.0"/>
</dependentAssembly>

Which is in turn leading to a System.ExecutionEngine exception for us in w3wp.exe that I've been unable to track down. Our projects are a mix of .NET 4.7.2 and .NET Standard 2.0 projects and the dependency is likely causing a binary compatibility issue between the different implementations. We've experienced similar issues with System.Net.Http in the past.

With AutoMapper 7.0.0, the dependency is not there, and all works well.

Most helpful comment

I'm also experiencing troubles with System.ValueTuple versions conflict when referencing AutoMapper v8.0.0 package in net472-targeted projects.

I've got the following weird build warning:

There was a conflict between "System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" and "System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51".
"System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was chosen because it was primary and "System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was not.

There were no such problems with AutoMapper v7.0.0 package.

Just curious, what the overhead for you will bring adding an extra net47 build target to AutoMapper?

I think dropping net461 build target will work for me also :-)

All 27 comments

If you have the binding redirect you should have only one version of the dll so maybe the problem is elsewhere.

What I believe is happening is that the reference to ValueTuple is causing the nuget package version to be included in my bin folder, and that version, it seems, may not be fully binary compatible with the built-in .net framework version. I compared our bin folder with 7.0.0 and 7.0.1 and the only differences are: 1) the binary differences in AutoMapper.dll (obviously), and 2) the existence of System.ValueTuple.dll when 7.0.1 is used.

All that is of no consequence once you have only one version loaded.

That's a reasonable position, and the one I would have taken previously as well, but it's not the case. See this: https://github.com/dotnet/corefx/issues/28833 for an example where that's not the case. The tooling does some funky stuff under the hood, especially when you have mixed .net framework and .net standard targeted code used in asp.net project that targets .net framework.

OK, then :) I want a repro with AM and the binding redirect that doesn't work.

Unfortunately, I'm having trouble narrowing it down to a minimal reproducible solution. Something in our codebase is triggering it somehow, and the stack trace is not helpful in tracking it down.

You may close this issue for now if you want, and if I can come up with something that repros it, I will re-open.

FWIW, I still think it's more correct to not include the System.ValueTuple package reference for projects that target .net standard 2+ or .net framework 4.7+

@mscrivo I think you're right there anyway on the package reference, we can easily move that package reference to only the frameworks that target it. However, it might mean adding an additional target for net471 vs. net45.

I think it would get messy :) For little benefit. I've opened that PR for what I think can be easily done.

Thanks guys

It does not appear that this was resolved. Why not add a Net 4.7 target that does not add a System.ValueTuple dependency?

Because we don't want to have an extra target just to workaround a bug in the framework.

I pinged @terrajobst to see if there are any recommendations here

But at this point, maybe drop .net 4.6.1 and stick with .Net Standard 2.0?

I'm also experiencing troubles with System.ValueTuple versions conflict when referencing AutoMapper v8.0.0 package in net472-targeted projects.

I've got the following weird build warning:

There was a conflict between "System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" and "System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51".
"System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was chosen because it was primary and "System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was not.

There were no such problems with AutoMapper v7.0.0 package.

Just curious, what the overhead for you will bring adding an extra net47 build target to AutoMapper?

I think dropping net461 build target will work for me also :-)

I have trouble too with this value tuple... Why no port without valuetuple for 4.7? The binding "solution" does not work in our case.

@lbargaoanu I'm reopening this since we've enough people with the issue - I think we have two options here:

  • Add a net47 target
  • Remove all usages of System.ValueTuple

Personally I'd vote option 2 here. The benefit of using tuples isn't worth the pain of having two full .NET frameworks to support.

What can I say, you can have the same issue without using AM, .Net Standard is simply broken before 4.7.2. But I guess not using ValueTuple is just an inconvenience. So dropping 4.6.1 and just going with .Net Standard 2.0 is not cool? :)

@screamingworld The binding redirect _always_ works.

Ha no I have many clients still on 4.6

On Wed, Feb 20, 2019 at 10:48 AM Lucian Bargaoanu notifications@github.com
wrote:

What can I say, you can have the same issue without using AM, .Net
Standard is simply broken before 4.7.2. But I guess not using ValueTuple is
just an inconvenience. So dropping 4.6.1 and just going with .Net Standard
2.0 is not cool? :)

—
You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/2750#issuecomment-465660646,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGYMtys_7gu6QKxMgrbECiaalrLkZmVks5vPXxNgaJpZM4Vy4Ke
.

Great news. Thanks!

Hi all. Does anyone know when a version might be released that doesn’t require System.ValueTuple? Thanks!

I think with the last PR we’re ready. Next day or so?

On Wed, Apr 17, 2019 at 12:03 PM SkinnySackboy notifications@github.com
wrote:

Hi all. Does anyone know when a version might be released that doesn’t
require System.ValueTuple? Thanks!

—
You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/2750#issuecomment-484176980,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGYMmxCG1_cycULpdubh_FMfjHch66Nks5vh1PegaJpZM4Vy4Ke
.

Wow that would be awesome, thank you!

Do you think we are still able to have a new official version released soon?

Yep!

On Wed, Apr 24, 2019 at 9:45 AM SkinnySackboy notifications@github.com
wrote:

Do you think we are still able to have a new official version released
soon?

—
You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/2750#issuecomment-486272974,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAZQMRXRVPAIYGYQJN7ZXTPSBXA7ANCNFSM4FOLQKPA
.

Thank you very much - this has saved me so much pain.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

zolakt picture zolakt  Â·  4Comments

gmarokov picture gmarokov  Â·  6Comments

colin-young picture colin-young  Â·  6Comments

vivainio picture vivainio  Â·  6Comments

sajithk picture sajithk  Â·  7Comments