.NET — .NET Standard 2.0 Deprecation, Support for .NET 6 or .NET 8 (LTS) in DevExpress Libraries (v23.2)

What Will Change in v23.2

Once we release v23.2, our libraries will no longer support .NET Standard 2.0. I’ve outlined the reasons for this decision below. 

For our v23.2 release cycle (December 2023), the following DevExpress .NET Core-based products will also – at a minimum – require .NET 6 and Visual Studio 2022:

• WinForms
• WPF
• Blazor
• ASP.NET Core
• Reporting
• Office File API
• BI Dashboards
• XAF WinForms/Blazor UI
• Web API Service
• XPO ORM

This change affects cross-platform libraries such as DevExpress.Data, DevExpress.Printing.Core, etc., and other libraries that targeted .NET Standard 2.0 in our v23.1 release. Worth noting - our ASP.NET Core Blazor-based product line (Blazor Components, XAF UI and Web API Service) already requires .NET 6 and Visual Studio 2022. Of course, our customers will also be able to use our .NET Core-based assemblies in .NET 7 or .NET 8-based apps.

Reasons for Change: Motivation to Drop .NET Standard Support in Our v23.2 Release Cycle

1. While .NET Standard was widely used in the pre-.NET 5 era, it has now become obsolete: To quote Microsoft, ".NET Standard has been superseded by a new approach to uniformity” (The future of .NET Standard). For those curious about .NET Standard 2.1 - Unfortunately, we are not in position to support the more "modern" .NET Standard 2.1 (released in 2018), because it does not support .NET Framework.
2. As you may know, Microsoft no longer accepts bug submissions for .NET Standard nor are they willing to evolve the platform in any meaningful manner (including - but not limited to - issuing security updates). As you may also know, .NET Standard 2.0 support is being dropped by Microsoft and many third-parties as well. For instance, EF Core 6 or recent versions of WCF libraries do not support .NET Standard. The .NET MAUI team chose to drop support for .NET 6 and opted to target .NET 8 instead. If you’re like me, you’ve read many articles in this regard: Microsoft Forms Service’s Journey to .NET 6 and .NET Standard Problems are just two examples.
3. Visual Studio 2022 supports .NET 6 natively - which is at its peak popularity. For teams still using Visual Studio 2019, .NET 6 support is also possible with a bit of tweaking (How to target .NET 6.0 with Visual Studio 2019?). Though Visual Studio 2017 does not support .NET 6 (the oldest version of Microsoft’s IDE which can compile .NET Standard libraries), Visual Studio 2017 usage numbers are quite low. And of course, Visual Studio 2015 cannot compile .NET Standard projects.
4. Dropping .NET Standard support will simplify our Unified Component Installer and NuGet package structure. This will also improve the developer experience and eliminate unnecessary installation artifacts. For example: no more confusion about which assembly to reference from the NetCore or Standard folder within "c:\Program Files\DevExpress 2X.X\Components\Bin\" (for projects targeting different platforms).
5. By having fewer packages (60 less in v23.2 vs 23.1), we’ll have fewer complex "#if NET || NETSTANDARD" statements in our code. Supporting multiple targets with the same code complicates product maintenance and evolution (for instance, DateOnly, TimeOnly and other modern framework features). For you, it also means fewer risks and easier maintenance (for example: fewer DevExpress packages means fewer packages to update should a security vulnerability be discovered in third-party dependencies).
6. .NET Standard has prevented us from using DynamicallyAccessedMembersAttribute and/or DynamicDependencyAttribute for trimming in Blazor WebAssembly/WASM components (there are other linker-related issues/limitations due to .NET Standard in Blazor).
7. Just like Blazor, our .NET MAUI product line is being actively developed and we do not want .NET Standard-compatibility to stop our momentum. This dependency arises from DevExpress.Data and other cross-platform libraries (including but not limited to Reporting, Office File API, etc). Without .NET Standard, we will be able to leverage .NET 8 features and apply appropriate performance enhancements (for both .NET MAUI and Blazor).

Impact on Existing Apps / How to Update Existing Apps

Unfortunately, these changes will affect a small fraction of DevExpress .NET Framework customers – particularly those who shared code between their .NET Framework and .NET Core apps. For instance, if you maintain a .NET Framework app (WinForms or ASP.NET WebForms) that shares a Class Library (.NET Standard 2.0) containing business logic, reports, and other artifacts with other apps (such as a .NET Core app), you will need to take action.

If you used .NET Standard 2.0 to share code between .NET Framework and all other .NET implementations, Microsoft and DevExpress recommend that you use Multi-targeting. Here is a simple change that you will need to make to your cross-platform library that supported .NET Standard in v23.1 (or earlier versions), when you upgrade its DevExpress dependencies to v23.2+. Attached are also complete sample projects for your reference.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <!-- BEFORE (v23.1 and older)-->
    <!-- <TargetFramework>netstandard2.0;/TargetFramework> -->
    <!-- AFTER (v23.2 and newer) -->
    <!-- Your shared Class Library will output net6.0 and net472 assemblies -->
    <TargetFrameworks>net6.0;net472</TargetFrameworks>
  </PropertyGroup>
</Project>

We may add an option into our Project Converter to address simple scenarios for you, should you opt in explicitly during the upgrade process. We cannot apply such serious changes automatically for you, because we can easily break things. Of course, users who want to control everything manually, will be able to do this with v23.2 as well.

Other Considerations

.NET 6 or .NET 8 for v23.2?

After analyzing .NET and .NET Core release lifecycles (end of support for .NET 6 in particular) we asked ourselves a simple question: "Isn't it better to jump to .NET 8 directly instead of moving to .NET 6?" After all, we already have many customers using .NET 7 (STS) successfully with DevExpress products (and upgrading to .NET 8 would not be much of an issue for those using .NET 7).

As you might imagine - while some customers are ready for .NET 8, many of our enterprise/corporate customers are not (for numerous reasons – all of which we fully appreciate). Accordingly, we chose to support .NET 6 at a minimum in our .NET Core-based product line. Of course, our customers will also be able to use our .NET Core-based assemblies in .NET 7 or .NET 8-based apps.

This decision notwithstanding, I’ve included a small survey below to collect additional feedback. Though we feel our decision represents a reasonable compromise between competing interests, we are willing to modify our position where appropriate. Your feedback will help us validate and/or refine our decisions.

.NET Framework 4.5.2 vs .NET Framework 4.8?

Before I wrap up, a word or two about the .NET Framework and its end of life (from Microsoft): 

".NET Framework covers a broad set of Windows technologies including the .NET Framework Base Class Libraries, ASP.NET Web Forms, WCF, and more. Support for .NET Framework follows the Lifecycle Policy of the parent Windows operating system. The .NET Framework is updated machine-wide automatically by Windows Update. .NET Framework 4.8 is the latest version of .NET Framework and will continue to be distributed with future releases of Windows. As long as it's installed on a supported version of Windows, .NET Framework 4.8 will continue to also be supported." 

As you probably know, Microsoft "retired" .NET Framework 4.5.2, 4.6, and 4.6.1 more than a year ago (on April 26, 2022). As you may also know, DevExpress .NET Framework libraries are still compiled against .NET Framework 4.5.2 (for maximum coverage).

Some of you may be asking (or have already asked) an obvious question: "Are my apps still secure if DevExpress compiles its products against .NET Framework 4.5.2?" The short and concise answer to this question is “Yes, if you’re targeting the latest versions of the .NET Framework in your own app." You can use .NET Framework 4.6.2 (set to "retire" on Jan 12, 2027), .NET Framework 4.7.2, .NET Framework 4.8.1 (and other versions) – any version that Microsoft has yet to retire (see Microsoft’s end of life on this page for more information in this regard).

We have chosen to compile our assemblies against 4.5.2 (and not 4.8) to minimize frustration – as many customers continue to use older, non-retired versions of the .NET Framework. Thanks to high compatibility between .NET Framework versions, you can safely target a higher version in your projects and freely leverage recent .NET Framework updates (which we highly recommend anyway) as desired. This decision is entirely up to you. Again, we highly recommend the use of the most recent version of the .NET Framework.

We also believe that changing the target version of our assemblies (in the current .NET Framework lifecycle) offers minimal benefits to users (because of small variances between .NET Framework 4.5.2 and 4.8.1).

Your Feedback Matters!

Thanks,
Dennis Garavsky
Principal Product Manager
dennis@devexpress.com

Free DevExpress Products - Get Your Copy Today