Reference changed to wrong version of assembly

[josefblaha]

During F# project build, an assembly reference could be changed to a wrong version of the same assembly from Reference Assemblies.

Repro steps

1. Create a new F# console app project targeting .NET 4.6.1.
2. Install System.Net.Http NuGet package version 4.3.2. Note that it contains System.Net.Http.dll with assembly version 4.1.1.1.
3. Build the project.

Expected behavior

The reference to System.Net.Http assembly should still point to the correct assembly in packages\System.Net.Http.4.3.2\lib\net46.

Actual behavior

The reference was changed to point to C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Net.Http.dll, which has assembly version 4.0.0.0 (it's older). This file is also copied to the project output directory.

Known workarounds

None.

Related information

Win10 1511, .NET 4.6.1, VS 15.2 (26430.16), Visual F# 4.1

When I do the same with C# console app, it behaves as expected keeping the right assembly.

[idg10]

This looks like another instance of an issue that has been around for at least a couple of years now, which the NuGet and F# teams both seem to think that that other team will fix.

This was reported back in September of 2015 in https://github.com/dotnet/corefx/issues/3103 as a Core FX bug, then shortly after that in October 2015 as a NuGet bug in NuGet/Home#1510 - both describe it as a problem with System.Numerics.Vectors but it looks like the broader issue that if a NuGet package contains a DLL with a Simple Name that is the same as an existing framework assembly, you end up with a reference to the framework assembly even if the version in the NuGet package is newer.

This seems to have been around as a bug for a very long time, but it is becoming increasingly problematic now that we're seeing more out-of-band releases of updates to framework DLLs via NuGet.

Unfortunately there seems to be a bit of a muddle on who should fix it. The timeline so far as far as I can see is:

• 2015/09/04: bug reported for first time (that I can see) as dotnet/corefx#3103
• 2015/10/02: bug reported as System.Numerics.Vectors fails to install in an F# project NuGet/Home#1510 then closed on same day by @yishaigalatzer who said "assuming at this point that the fix will happen in the F# project system" but did not open a corresponding F# issue
• 2015/10/14: @mellinoe closed dotnet/corefx#3103 on grounds that "this is an F# project system bug" (and also failed to create corresponding F# issue)
• 2016/02/07: bug reported again as NuGet bug System.numerics.vectors does not install properly in F# projects NuGet/Home#2072 then closed on same day as dup of System.Numerics.Vectors fails to install in an F# project NuGet/Home#1510 (which was also still closed at this point)
• 2016/02/07: bug reported as System.numerics.vectors package does not install properly #939
• 2016/02/07: previously-closed System.Numerics.Vectors fails to install in an F# project NuGet/Home#1510 reopened by @yishaigalatzer (so we went from having no open bug tracking this to having open bugs for this in both the NuGet and F# repos)
• 2016/02/08: @dsyme states in comment on System.Numerics.Vectors fails to install in an F# project NuGet/Home#1510 that "I believe the fix will be on the F# side, rather than getting into a cat-and-mouse game of mutual fixes" although without fully embracing the position that NuGet is without fault here
• 2016/02/09: @yishaigalatzer now seems open to possibility that F# might not necessarily be the place to fix this: "Moved to discussion milestone, until we (fully) decide where the fix should go."
• 2016/09/14: If reference assembly exists for nuget library, no HintPath is added NuGet/Home#3443 opened, and then on the same day by @yishaigalatzer said "This is a duplicate of a known bug in the F# project system. We discussed with Don Syme and agreed that the fix will need to go there." apparently forgetting that back in February 2016 this had been explicitly left unresolved (although the issue was at least left open)
• 2017/02/02: @dsyme asks on System.Numerics.Vectors fails to install in an F# project NuGet/Home#1510 "What was the decision about this?" and gets no reply
• 2017/05/10: @dsyme closed System.numerics.vectors package does not install properly #939 on the grounds that this is a NuGet issue, not an F# one, despite having apparently agreed in the discussion on System.Numerics.Vectors fails to install in an F# project NuGet/Home#1510 on 2016/02/08 that F# would fix this, leaving us in a state where the NuGet issue has a statement that F# will fix this, but the only remaining F# issue for this just got closed without it being fixed
• 2017/08/03: the issue on this page is opened, because someone ran into this again and it's now really quite difficult to track down all the other issues that have covered this, and the one that should be tracking it (System.numerics.vectors package does not install properly #939) was closed back in May 2017; this is currently the only open F# issue relating to this problem
• 2017/08/17: I ran into this in a real project and spent about an hour trying to find the issues I knew already existed to cover this but which were now very hard to find, and eventually ended up writing this timeline to help anyone else who runs into this

So in short, @dsyme said back in February 2016 that F# should fix this (even though it looked like NuGet also had an issue, and a NuGet fix might fix it for more people sooner). But the relevant issue #939 got closed without it apparently being fixed.

We're going to start seeing a lot more examples of this I think, with the way .NET is evolving - it's now quite common to come across newer versions of assemblies that are also in the reference assemblies.

[dsyme]

@idg10 Is there a workaround by using a direct reference to the DLL in the package?

[dsyme]

So the workaround would be "delete the reference and add a direct DLL reference to packages\System.Net.Http.4.3.2\lib\net46\System.Net.Http.dll". However I don't know if that is robust under further package add/remove

Another workaround is to use Paket.

[idg10]

If you modify references directly in the .fsproj that came from a NuGet reference, Visual Studio seems to overwrite them any time you make any sort of NuGet change - it seems to reset all NuGet-originated references.

It's possible I'm not doing exactly what you've suggested. I'm not 100% sure what a "direct DLL reference" really is. Looking at the docs for the <Reference> element at https://docs.microsoft.com/en-us/visualstudio/msbuild/common-msbuild-project-items the only way I see to specify the exact location of a file is through <HintPath>

Is that what you meant? If so, then I can confirm that Visual Studio will delete the <HintPath> the next time you do add or update any package in the project.

I'm looking into Paket - a few people have mentioned it. But where I really want to get to is to be able to use <PackageReference> - the only reason I have a reference to System.Net.Http at all is that my F# project uses a NuGet package that in turn depends on it. In C# projects in the same solution that are using the new type of project file I don't have any direct references to System.Net.Http at all because the transitive reference handling picks it up automatically. Will a move to Paket make it harder to migrate to the new project file approach? (The main thing stopping me using the new format already is that if you open an F# project with an MSBuild 15 style .fsproj IntelliSense starts reporting spurious errors.)

[forki]

Paket works fine with the new fsproj format but VS does not yet Am 18.08.2017 9:52 vorm. schrieb "Ian Griffiths" <[email protected]>:

…

If you modify references directly in the .fsproj that came from a NuGet reference, Visual Studio seems to overwrite them any time you make any sort of NuGet change - it seems to reset all NuGet-originated references. It's possible I'm not doing exactly what you've suggested. I'm not 100% sure what a "direct DLL reference" really is. Looking at the docs for the <Reference> element at https://docs.microsoft.com/en- us/visualstudio/msbuild/common-msbuild-project-items the only way I see to specify the exact location of a file is through <HintPath> Is that what you meant? If so, then I can confirm that Visual Studio will delete the <HintPath> the next time you do add or update *any* package in the project. I'm looking into Paket - a few people have mentioned it. But where I *really* want to get to is to be able to use <PackageReference> - the only reason I have a reference to System.Net.Http at all is that my F# project uses a NuGet package that in turn depends on it. In C# projects in the same solution that are using the new type of project file I don't have any direct references to System.Net.Http at all because the transitive reference handling picks it up automatically. Will a move to Paket make it harder to migrate to the new project file approach? (The main thing stopping me using the new format already is that if you open an F# project with an MSBuild 15 style .fsproj IntelliSense starts reporting spurious errors.) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3415 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNIsG9nW3f0jcWv6fnRqAQKG2bxWKks5sZUKqgaJpZM4OsW3U> .

[idg10]

So, 2 hours of attempting to convert to Paket and it appears that for some reason when I move my project over to that, Paket adds two separate references to System.Net.Http each in Choose/When/ItemGroup sections conditional on $(TargetFrameworkIdentifier) == '.NETFramework' And $(TargetFrameworkVersion) == 'v4.7', one with just a single <Reference> to System.Net.Http and one that shares the group with System.Net, System.Net.Http.WebRequest, System.Runtime.Serialization and Microsoft.Rest.ClientRuntime. Presumably this has something to do with me using a couple of Azure management APIs.

And even after all this I'm getting this warning:

warning MSB3243: No way to resolve conflict between "System.Net.Http, Version=4.1.1.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Choosing "System.Net.Http, Version=4.1.1.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" arbitrarily.

And this despite my paket.dependencies containing this specific version reference nuget System.Net.Http 4.3.2 (and the paket.references for my F# project also includes System.Net.Http explicitly).

If in VS's Solution Explorer I delete one of the relevant entries under the References node for the project, and change the other to require a specific version, the warning goes away, but then I'm back in much the same situation as I was with the NuGet workaround: you can make the problem go away by editing the .fsproj but the next time you update your package references, the workaround may be overwritten.

So unfortunately Paket doesn't appear to solve my particular instance of this problem. I don't have a good workaround either with NuGet or Paket.

Update: and yes, the manual edit does indeed get overwritten next time you change anything in Paket.

Update 2: although I've now worked out what was making it do that. I've created an issue over at Paket: fsprojects/Paket#2629 - this means I can now use Paket to work around this issue, but the bug described in this issue remains if you can't use Paket.

[forki]

We had reports about system.http recently in paket. I'm planning to look at this today or over the weekend. Something changed around it and I need to investigate. So please don't give up on us here ;-) Am 18.08.2017 12:20 schrieb "Ian Griffiths" <[email protected]>:

…

So, 2 hours of attempting to convert to Paket and it appears that for some reason when I move my project over to that, Paket adds two separate references to System.Net.Http each in Choose/When/ItemGroup sections conditional on $(TargetFrameworkIdentifier) == '.NETFramework' And $(TargetFrameworkVersion) == 'v4.7', one with just a single <Reference> to System.Net.Http and one that shares the group with System.Net, System.Net.Http.WebRequest, System.Runtime.Serialization and Microsoft.Rest.ClientRuntime. Presumably this has something to do with me using a couple of Azure management APIs. And even after all this I'm getting this warning: warning MSB3243: No way to resolve conflict between "System.Net.Http, Version=4.1.1.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Choosing "System.Net.Http, Version=4.1.1.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" arbitrarily. And this despite my paket.dependencies containing this specific version reference nuget System.Net.Http 4.3.2 (and the paket.references for my F# project also includes System.Net.Http explicitly). If in VS's Solution Explorer I delete one of the relevant entries under the References node for the project, and change the other to require a specific version, the warning goes away, but then I'm back in much the same situation as I was with the NuGet workaround: you can make the problem go away by editing the .fsproj but the next time you update your package references, the workaround may be overwritten. So unfortunately Paket doesn't appear to solve my particular instance of this problem. I don't have a good workaround either with NuGet or Paket. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3415 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNAD3VcUltZoBk-8e3jw1KvzWBVHQks5sZWVugaJpZM4OsW3U> .

[forki]

see fsprojects/Paket#2628

[cartermp]

Since this is a legacy project system + packages.config issue, with both technologies being deprecated due to intractable problems with their design, this will be closed. I'd encourage any issues of this sort with SDK-style projects to be filed here if they exist: https://github.com/dotnet/project-system (though I doubt they do given how robust it is and how robust packagereference is)