Dependency conflicts

[ploeh]

Description

I'm not quite sure if this is a paket issue, or an FsCheck issue, but I chose to report it here because I can't repro the issue with Visual Studio's NuGet package manager console.

When adding FsCheck.Xunit, Visual Studio gives a compiler warning about conflicts in dependencies I don't even understand why they're there.

I'm not sure if the issue is related to FsCheck.Xunit at all, or if it's wider, but so far, I've only seen it in connection to FsCheck.Xunit.

Repro steps

1. Create a new F# library project using Visual Studio 2015.
2. Create a .paket directory: $ mkdir .paket
3. Copy paket.bootstrapper.exe into .paket.
4. Run the bootstrapper: $ .paket/paket.bootstrapper.exe
5. Initialise paket: $ .paket/paket init
6. Add FsCheck.Xunit to the project: $ .paket/paket add nuget FsCheck.Xunit project ConflictRepro
7. From within Visual Studio, rebuild all.

Expected behavior

The project should compile without errors or warnings. This is also the case if, instead of using paket, you use the Package Manager Console built into Visual Studio. Adding FsCheck.Xunit via the Package Manager Console does not cause the issue.

Actual behavior

The project compiles, but with a warning:

Severity	Code	Description	Project	File	Line	Suppression State
Warning		Found conflicts between different versions of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed.	ConflictRepro	C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets	1820	

Turning on diagnostics logging, the relevant information seems to be this:

There was a conflict between "System.Security.Cryptography.Algorithms, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Security.Cryptography.Algorithms, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
    "System.Security.Cryptography.Algorithms, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was chosen because it was primary and "System.Security.Cryptography.Algorithms, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was not.
    References which depend on "System.Security.Cryptography.Algorithms, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [C:\Users\mark\Desktop\ConflictRepro\packages\System.Security.Cryptography.Algorithms\lib\net461\System.Security.Cryptography.Algorithms.dll].
        C:\Users\mark\Desktop\ConflictRepro\packages\System.Security.Cryptography.Algorithms\lib\net461\System.Security.Cryptography.Algorithms.dll
          Project file item includes which caused reference "C:\Users\mark\Desktop\ConflictRepro\packages\System.Security.Cryptography.Algorithms\lib\net461\System.Security.Cryptography.Algorithms.dll".
            System.Security.Cryptography.Algorithms
    References which depend on "System.Security.Cryptography.Algorithms, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [].
        C:\Users\mark\Desktop\ConflictRepro\packages\System.Security.Cryptography.OpenSsl\lib\netstandard1.6\System.Security.Cryptography.OpenSsl.dll
          Project file item includes which caused reference "C:\Users\mark\Desktop\ConflictRepro\packages\System.Security.Cryptography.OpenSsl\lib\netstandard1.6\System.Security.Cryptography.OpenSsl.dll".
            System.Security.Cryptography.OpenSsl

It seems that paket adds all those System.Security.Cryptography.* assemblies as references to the project, even though they don't seem to be required. The Package Manager Console doesn't add those references.

Known workarounds

Remove the System.Security.Cryptography.* references.

This isn't the best workaround, however, because every time I ask paket to update packages, or do other work, it re-adds those references.

[forki]

I tried to reproduce, but Paket 5 beta behaves correct. No warnings shown.

Library1.zip

Please retry with Paket 5 beta. (BTW: in the zip you can just copy the .paket folder and paket magic mode is enabled with prerelease channel)

[ploeh]

I agree that the library you've posted doesn't have the issue, but I can still reproduce the issue with the above steps and Paket 5.0.0-rc001.

One difference that I've noted is that the library you've posted is an F# 3.1 library, whereas the one I'm creating is an F# 4.1 library.

I tried going through the steps with an F# 3.1 library, but somehow, it turns into an F# 4.1 library along the way...

[forki]

One difference that I've noted is that the library you've posted is an F# 3.1 library, whereas the one I'm creating is an F# 4.1 library.

can you please upload a zip with the repro? I'm not really sure what I'm doing differently

[ploeh]

can you please upload a zip with the repro?

I'd love to, but GitHub will not let me upload an 85 MB .zip file. Should I remove the packages directory?

[forki]

yes packages dir can be restored (given that it's a public url) 2017-06-06 14:29 GMT+02:00 Mark Seemann <notifications@github.com>:

…

can you please upload a zip with the repro? I'd love to, but GitHub will not let me upload an 85 MB .zip file. Should I remove the packages directory? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2383 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNEr9-Vh8TlPg05b_8mIXxxwgO1fOks5sBUYvgaJpZM4NrvzK> .

[ploeh]

Here we go, then: Library2.zip

[forki]

I can't repro. I don't see any warnings in the build.
@matthid can you please try to repro?

[ploeh]

It could be environment-specific (doesn't work on my machine). I'll see if I can reproduce on my other machine...

[ploeh]

The plot thickens...

I tried downloading the above Library2.zip to another machine. The same problem also manifests on that other machine.

Then I tried going through the repro steps I originally described. On that other machine, I can't reproduce the issue from first principles...