.NET Framework 4.7.1 provides built-in support for .NET Standard 2.0

[terrajobst]

Summary

.NET Framework 4.7.1 will have built-in support for .NET Standard 2.0. This means that you don't have to deploy any additional files or use binding redirects to use .NET Standard 2.0 libraries.

For a demo, check out this video.

Details

While libraries targeting .NET Standard 2.0 can be consumed by applications and libraries targeting .NET Framework 4.6.1 and higher, not all files that are required for .NET Standard libraries were part of .NET Framework 4.6.1. In fact, .NET Framework 4.6.1 was shipped before .NET Standard 2.0 was even designed. That's why building an application targeting .NET Framework 4.6.1 (as well as 4.6.2 and 4.7) will have to deploy additional files.

• If you use Visual Studio 2017 15.3 or higher, these files are automatically copied to the application's output folder.

• If you use Visual Studio 2015 and use NuGet 3.6, we'll prompt you to install a support package which will handle copying the files to the output directory.

Starting with .NET Framework 4.7.1 these files no longer have to be deployed with the application -- they are built right into the .NET Framework itself.

.NET Framework 4.7.1 also adds about 200 missing APIs that were part of .NET Standard 2.0 but not actually implemented by .NET Framework 4.6.1, 4.6.2 or 4.7.

This also removes the need for binding redirects when using .NET Standard libraries on .NET Framework because the CLR automatically unifies version numbers of assemblies that are part of the platform.

[mungojam]

Good news. But it's unfortunate that it probably won't be available for older versions of Windows 10. That's been the case with previous .net releases that could not be deployed to 1511. It would be be good if it was available for all supported versions including Anniversary Update.

[terrajobst]

I'll forward the feedback, but I don't think we can influence the way Windows 10 is updated with respected to .NET Framework.

[mungojam]

Thanks, it's more that there is an installer for Windows 7/8 (which we still run too), but it doesn't support older (supported) versions of Windows 10. Seems like an arbitrary restriction, not technology related.

[mungojam]

As an example .net 4.7 installer here only supported Anniversary Update and beyond despite Windows 10 1511 being a supported version. 1511 is soon going out of support, so as long as Anniversary Update is also supported by 4.7.1, it will be ok.

[mungojam]

Looks hopeful, the early access preview was available for Anniversary Update. I expect it's ok :)

[terrajobst]

My understanding is that Windows 10 will generally not backport features to previous versions of Windows 10. Instead, it's a continuous path forward. I don't know enough about how Windows updates work, but it's completely possible that at this point it's not just policy but also a technical restriction in the way their release branches/update channels are implemented. Either way, I'll forward the feedback but based on previous discussions, I don't think we're likely to push .NET Framework 4.7.1 to earlier versions of Windows 10.

[mungojam]

It's no problem if it isn't pushed through Windows Update, because as you say that is linear on Windows 10. The important thing is that the installer works on supported versions, which it looks like it will from the preview.

[barnson]

FWIW, it is a technology limitation, not just an arbitrary one.

[mungojam]

OK, cool. Apologies for jumping to that conclusion. .net standard is a great concept and things are all heading in a very nice direction, thank you for all the hard work!

…

On Thu, 28 Sep 2017, 03:58 Bob Arnson ***@***.***> wrote: FWIW, it is a technology limitation, not just an arbitrary one. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#514 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADAiyw-cT75q766TnSOkHAMwxN4qMvy_ks5smwtcgaJpZM4PmTDB> .

[henkmollema]

@terrajobst I was trying out the native support for .NET Standard 1.3 in .NET Framework 4.6.1. It works as you described when I reference a .NET Standard 1.3 library from a .NET 4.6.1 app. However, if the library targets both .NET Standard 1.3 and 2.0 it restores the 2.0 version which pulls in all the assemblies from .NET Standard 2.0. Is there a way to configure this? (beside updating to .NET 4.7.1 😄)

[terrajobst]

@henkmollema

However, if the library targets both .NET Standard 1.3 and 2.0 it restores the 2.0 version which pulls in all the assemblies from .NET Standard 2.0.

That is expected behavior and follows the developer's intuition. Let's say you're targeting .NET Framework 4.6 and you reference a NuGet package that supports both .NET Framework 4.0 and 4.5. You'd expect NuGet will use the .NET Framework 4.5 library as it's closer to what you're targeting and likely has more features. Since we changed NuGet to consider .NET Framework 4.6.1 as implementing .NET Standard 2.0 it will now prefer 2.0, 1.6, and 1.5 over 1.4. There is (AFAIK) no way to configure this differently.

[lextm]

@terrajobst I can see that NuGet guys have a test site to illustrate how NuGet algorithm picks up the final assembly. It should be made more obvious to developers, so you don't need to answer a million times.

I learned it from here and hope such useful information can be promoted to the documentation instead of hiding in comments.

[henkmollema]

@terrajobst makes sense, thanks! 👍