Referring to Why use the full .NET Framework with ASP.NET Core?, it appears .NET 4.7.2 is the way to go forward?
Our existing application targets .NET 4.6.1 using ASP.NET Boilerplate.
Is it mandatory to migrate to .NET 4.7.* in order to leverage ASP.NET Core 2.1 features?
To use .NET Core 2.1 features, you need to target .NET Core 2.1
There is .NET Standard, which is an intersection of features that are available in a range of implementations, including .NET Core and .NET Framework. If you target .NET Standard (some specific version), then you can use the features available in that version of .NET Standard, and it should run on either .NET Framework 4.7.2 or .NET Core 2.1.
As a general guide: libraries (such as Aspnet Boilerplate) should now - where possible - target .NET Standard, but will often have a multi-target build to allow them to internally exploit target-specific features of specific frameworks (perhaps using the enhanced "span" or SIMD capabilities in .NET Core).
Application code should (and must, if it is an executable) target a specific framework such as .NET Framework or .NET Core.
No, it is not necessary to migrate to .NET 4.7.* in order to leverage ASP.NET Core 2.1 features.
ASP.NET Core 2.x is made up of .NET Standard libraries. Apps written with .NET Standard 2.0 run anywhere that .NET Standard 2.0 is supported.
ASP.NET Core 2.x is supported on .NET Framework versions compatible with .NET Standard 2.0:
- .NET Framework 4.7.1 and later is strongly recommended.
- .NET Framework 4.6.1 and later.
You only need to migrate to .NET 4.7.2 if you need features in Announcing .NET Framework 4.7.2:
- ASP.NET – Dependency Injection in WebForms
- ASP.NET – SameSite Cookie
- ClickOnce – Per-monitor support for WPF and HDPI-aware ClickOnce deployed apps
- ClickOnce – Enable SHA256 timestamping of Deployment Manifests
- SQL – Azure AD Universal and Multi-factor Authentication Support
- BCL – Cryptographic Improvements
- BCL – ZLib decompression support to DeflateStream
- BCL – Additional Collection APIs
- WorkflowDesigner High Contrast Improvements
- WPF – Finding ResourceDictionaries by Source
- WPF – Finding ResourceDictionary owners
- WPF – Finding StaticResource references
References:
For real, if you're building an application using .NET Core/Standard, but in your application, you may have some reference that using .NET Framework, it must be a big problem.
A story: I'm building a web application using ASP.NET Core, in this application, I want to have an extension that converting HTML to pdf.
I've tried to searched on Google and found a plugin that is called: itextsharp. And the problem comes from here.
itextsharp is using .NET Framework while my main project is using .NET Core. Since I want to create a class library to build this extension, I have 3 options:
Using .NET Core class library.
Using .NET Standard class library.
Using .NET Framwork class library.
All of them can be refered to the main project. BUT:
I cannot use itextsharp references (itextsharp.dll, itextsharp.xtra.dll, itextsharp.pdfa.dll, itextsharp.xmlworker.dll...) in .NET Core/Standard class libray. All of them can run only on target .NET Framework.
(I haven't mentioned about how to convert the code to target .NET Standard or Core because of license yet)
And my solution is: Build a .NET Framework app and publish it to exe file before appending to the main project as a reference.
P/S: For now, itextsharp has a Core version but I think it's not good enough (problems about: displaying images, fonts with unicode text, style tag...).
Totally, if you want to build some app that is using target .NET X, you must make sure all of the references can use target .NET X, too.
Another example: if you want to build a class library that using Razor class library. You must make sure that all of the references are using target .NET Core/Standard. Because Razor class library cannot refer to .NET Framework class library.
