System.Net.Http and System.IO.Compression .NET Standard facades need to be included when targeting .NET 4.7.1

[dsplaisted]

.NET 4.7.1 ships with support for the .NET Standard 2.0 APIs, as well as the necessary facades. So it's not supposed to need any facades injected by the ImplicitlyExpandNETStandardFacades target.

However, the in-box assembly versions of System.Net.Http and System.IO.Compression are less than the OOB and facade versions of those libraries. This will be fixed in .NET 4.7.2, however for 4.7.1, we still need to inject just those two facades as necessary.

[dasMulli]

@dsplaisted @nguerrera as @JPhilC reported, this may also be needed for System.ComponentModel.Annotations which shipped as 4.0.0.0 in 4.7.1 but the reference assembly shipped via NuGet has version 4.2.0.0 (see dotnet/standard#555 (comment))

[livarcocc]

This has now been fixed.

[steevcoco]

Hi. I have had trouble getting a project working for reasons surrounding these binding issues. I wanted to add a comment now that the project seems to work: it was not simple to get it working, and I had to find the right recipe.

• It is Framework 4.7.1.
  • References a NetStandard 2.0 project.
    • That one references NuGet System.Configuration.ConfigurationManager 4.4.1

VS would not build, and eventually I get "you need to reference System.Configuration.ConfigurationManager 4.0.0.0". --- Version is interesting?

When I add to the Framework project, NuGet ConfigurationManager 4.4.1, that project file now contains:

<Reference Include="System.Configuration.ConfigurationManager, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">
  <HintPath>..\..\..\..\..\packages\System.Configuration.ConfigurationManager.4.4.1\lib\net461\System.Configuration.ConfigurationManager.dll</HintPath>
</Reference>

... Which are odd version numbers?

Eventually I had to also add

<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>

And now it is working. And there is another similar thing in the same project:

• This Framework 4.7.1.
  • References a NetStandard 2.0 project.
    • That one references System.ComponentModel.Annotations 4.4.1

... And I added NuGet System.ComponentModel.Annotations 4.4.1. And the Framework project file now contains:

<Reference Include="System.ComponentModel.Annotations, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
  <HintPath>..\..\..\..\..\packages\System.ComponentModel.Annotations.4.4.1\lib\net461\System.ComponentModel.Annotations.dll</HintPath>
</Reference>

I just wanted to add a comment because it was not simple to get it working: if you do or don't add the AutoGenerateBindingRedirects, and do or don't add the NuGet references, you get different failures, and different suggestions. I had to come to this recipe to see it working.

[eriawan]

@livarcocc

This has now been fixed.

Fixed in which version? Could you please elaborate and clarify?
On Visual Studi side, VS 2017 15.4.1, 15.4.2, 15.5.2, 15.5.3, 15.5.4 still have this issue.
On .NET Core SDK side, version 2.1.1, 2.1.2 still have this issue as well.

[steevcoco]

I am not having issues anymore myself; but its because in ALL possible projects, I migrated to the "new" project format --- where the "new" format is like:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>netstandard2.0</TargetFramework>
    </PropertyGroup>
    <Import Project="..\..\..\Build\LibraryConfiguration.targets" />
</Project>

Where in my LibraryConfiguration.targets import, I actually explicitly include:

<Project>
    <PropertyGroup>
        <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
        <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
    </PropertyGroup>
</Project>

... They may be actually set that way in this project format by default; but I ensure that all projects, for any target, do get set up that way consistently.

And I do that for all target framework types; and it's important that an e.g. net471 project is for sure set up with the binding redirects; and possibly also important to have the PackageReference. ONLY WPF projects that require the designer use the "older" project format ... Because I believe those project types will not support WPF features and need to be defined with the "older" project format:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

... And, for sure in these projects I also either include or explicitly define AutoGenerateBindingRedirects and PackageReference. This is the only recipe I have found to be sure to run smoothly in a large solution.

If there is a single deviation from this recipe in a large solution, then you can actually begin to see cryptic failures in transitive projects that take a moment to track down where the configuration breaks the build. You can have a very hard time with an error message from a second or third branched referenced project, from a mis-configuration back up the project reference tree and back out again to a different transitive reference!

[livarcocc]

@eriawan VS 15.6. SDK will be 2.1.100.