v6.4.0 breaks build under mono when targeting net48

Description

v6.4.0 and newer now depend on the System.Net.Http nuget package. This package is problematic under mono because it includes compiled versions of the System.Net.Http dll for .Net Framework that differ from the mono versions and will ultimately cause projects using mono to no longer build with FluentAssertions referenced.

This is a known problem with the System.Net.Http package, e.g. discussion at https://github.com/dotnet/runtime/issues/21777 The package is effectively abandoned and not recommended for use in new projects, so if possible can it be removed as a dependency in FluentAssertions and alternatives be used if necessary?

Complete minimal example reproducing the issue

Blank project targeting net48 with fluent assertions v6.4.0 or newer referenced & attempt to compile with mono.

Expected behavior:

Builds

Actual behavior:

Build fails with error:

CSC : error CS1705: Assembly 'FluentAssertions' with identity 'FluentAssertions, Version=6.5.1.0, Culture=neutral, PublicKeyToken=33f2691a05b67b6a' uses 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' which has a higher version than referenced assembly 'System.Net.Http' with identity 'System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' [/__w/xRetry/xRetry/test/UnitTests/UnitTests.csproj]
    1 Warning(s)
    1 Error(s)

Versions

• FluentAssertions 6.4.0, 6.5.0 & 6.5.1
• net468 under mono

Additional Information

Example of a PR with the CI build failing with the upgrade from FluentAssertions 6.3.0 => 6.4.0: https://github.com/JoshKeegan/xRetry/pull/114

[dennisdoomen]

Awesome. Thanks for reporting back.

[JoshKeegan]

Thanks both of you for taking the time to look into this. I think it can be closed without needing any change from FA because as @jnyrup found, builds do work out of the box with the latest version of mono. I tried building the code on my laptop and everything worked first time.

I looked at the differences between the environment on my laptop and the docker images and found that the issue was being caused by an environment variable: FrameworkPathOverride=/usr/lib/mono/4.5/. This used to be required for dotnet build to build .Net Framework projects on linux with mono (it couldn’t locate the mono csc compiler executable without this) but it seems to no longer be required and auto-locates csc itself. Once I unset that environment variable the build worked. I guess this must also have forced the .Net Framework 4.5 reference assemblies to be used even when trageting .Net Framework 4.8, causing the conflict over the System.Net.Http version.

I don’t know where this would leave anyone using mono and dotnet on linux that did still need to set FrameworkPathOverride for some reason, as 4.5 is the latest path you can target with later versions of .Net Framework being handled as updates to the API on top of 4.5, so there’s no 4.8 path with the csc executable to target. But that’s not a problem I have and with dotnet build no longer needing this, hopefully nobody will need to set it for any other reason.