Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include updated Http and Compression libraries for .NET 4.7.1 if necessary #1667

Closed

Conversation

dsplaisted
Copy link
Member

@dsplaisted dsplaisted commented Oct 19, 2017

Fixes #1647. .NET 4.7.1 has support for .NET Standard 2.0 built-in, so most of the facades aren't necessary. However, the assembly versions of System.Net.Http and System.IO.Compression in .NET 4.7.1 are still 4.0.0.0. This means that the versions from the contract NuGet packages (which are versioned 4.1.0.0 or higher) would be preferred to the in-box version (which is newer). So if there is a dependency on the "contract" version of these DLLs, or on netstandard.dll, we use the 4.2.0.0 version of the DLLs from the .NET Standard 2.0 "facades". (Though these DLLs are not actually facades, they contain the implementation.)

Also updates the stage 0 version of the CLI, and fixes a failure it caused with our FilterCopyLocal targets, as described here.

With dotnet#1618, conflict resolution now depends on TargetFrameworkDirectory property, and the
GetReferenceAssemblyPaths target to set it.  However, the custom FilterCopyLocal target in our
projects was causing GetReferenceAssemblyPaths to run before GetFrameworkPaths, and when
GetFrameworkPaths was subsequently run, it reset the TargetFrameworkDirectory property to
v4.0.30319.

This change adds a dependency to PrepareForBuild so that both targets run in the right
order.
@dsplaisted dsplaisted changed the title WIP: Include updated Http and Compression libraries for .NET 4.7.1 if necessary Include updated Http and Compression libraries for .NET 4.7.1 if necessary Oct 19, 2017
@dsplaisted
Copy link
Member Author

@ericstj and @nguerrera for review. Please give this a good look as it would have been easy to make a mistake with these changes (though I think I've got them right and the tests help give me confidence).


DependsOnNETStandard |= dependsOnNETStandard;
DependsOnNuGetCompression |= dependsOnNuGetCompression;
DependsOnNuGetHttp |= dependsOnNuGetHttp;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider a short-circuit path once everything is set to true.

// .NET Standard facade version: 4.2.0.0

private const string SystemIOCompressionAssemblyName = "System.IO.Compression";
private static readonly Version SystemIOCompressionMinVersion = new Version(4, 1, 0, 0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here you use 4.1.0.0, but below you say 4.0.1.0. Which is it?

@ericstj
Copy link
Member

ericstj commented Oct 20, 2017

@alexghi @weshaggard PTAL as well.

@@ -22,6 +22,17 @@ public partial class GetDependsOnNETStandard : TaskBase
private const string SystemRuntimeAssemblyName = "System.Runtime";
private static readonly Version SystemRuntimeMinVersion = new Version(4, 1, 0, 0);

// Encountered conflict between 'Platform:System.IO.Compression.dll' and 'CopyLocal:C:\git\dotnet-sdk\packages\system.io.compression\4.3.0\runtimes\win\lib\net46\System.IO.Compression.dll'. Choosing 'CopyLocal:C:\git\dotnet-sdk\packages\system.io.compression\4.3.0\runtimes\win\lib\net46\System.IO.Compression.dll' because AssemblyVersion '4.1.2.0' is greater than '4.0.0.0'.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What value are these comments providing?

@@ -34,7 +41,22 @@ internal static bool GetFileDependsOnNETStandard(string filePath)
{
if (referencedAssembly.Name.Equals(NetStandardAssemblyName, StringComparison.Ordinal))
{
return true;
dependsOnNETStandard = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More potential for short-circuiting here, and below.

contain the implementation.)
-->
<ItemGroup Condition="'$(_TargetFrameworkVersionWithoutV)' == '4.7.1'">
<_NETStandardLibraryNETFrameworkLib Include="$(MSBuildThisFileDirectory)\net461\lib\System.Net.Http.dll" Condition="'$(DependsOnNuGetHttp)' == 'true' Or '$(DependsOnNETStandard)' == 'true'"/>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth the extra complexity to try and detect references to these? Why not just always include them in 4.7.1 like we do for the earlier versions?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1. I don't like that we're adding all this code to workaround a framework bug.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the case where DependsOnNETStandard==false (which is actually system.runtime >= some-ver or netstandard) but DependsOnNugetXxx==true. Which test covers that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@weshaggard @nguerrera

Is it worth the extra complexity to try and detect references to these? Why not just always include them in 4.7.1 like we do for the earlier versions?

Should we include these libraries in .NET 4.7.1 apps that don't reference .NET Standard assemblies at all? That's what this prevents. We can't just use the existing logic to detect usage of .NET Standard >= 1.5, because we need the updated libraries if they are used by a .NET Standard 1.4 or lower library too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should use whatever logic we are using to detect netstandard for both 2.0 and for earlier.

@alexghi will give you more data but we believe this set might be larger now.

@nguerrera
Copy link
Contributor

nguerrera commented Oct 20, 2017

Aside, but important: The change that broke our build (worked around in 13989f1) might also break IIS debugging in VS, which also has some custom targets that look at resolved publish assemblies.

EDIT: This is not an issue. I just tested with latest VS build having the Extensions changes in question and IIS debugging is working fine.

dependsOnNETStandard = true;
}
else if (referencedAssembly.Name.Equals(SystemRuntimeAssemblyName, StringComparison.Ordinal) &&
referencedAssembly.Version >= SystemRuntimeMinVersion)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why didn't this code path check systemRuntimeMinVersion already? Bug?

Copy link
Contributor

@nguerrera nguerrera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's offline discussion about the direction here.

@dsplaisted
Copy link
Member Author

Closing this in favor of #1712

@dsplaisted dsplaisted closed this Nov 8, 2017
JL03-Yue pushed a commit that referenced this pull request Mar 19, 2024
…719.9 (#1667)

[main] Update dependencies from dotnet/arcade
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants