What Will Change in v23.2
DevExpress .NET libraries will no longer support .NET Standard 2.0 in v23.2. 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.
Below is a table of supported .NET versions for DevExpress assemblies in v23.2 (green - supported, red - unsupported):
Reasons for Change
Our motivation to drop .NET Standard support in our v23.2 release cycle includes the following:
- 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.
- 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.
- 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.
- 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).
- 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). - .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).
- 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
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. We cannot apply such serious changes automatically for you, because we can easily break things.
How to Update Existing Apps
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+.
Code<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 net8.0 and net48 assemblies -->
<TargetFrameworks>net8.0;net48</TargetFrameworks>
</PropertyGroup>
</Project>
Attached are also complete sample projects for your reference.
Frequently Asked Questions
Should I multi-target my libraries for .NET Framework 4.5, 4.6, 4.7, or 4.8?
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). You can use any version that Microsoft has yet to retire
- .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)
For more information in this regard, see Microsoft’s end of life on this page. (Here is another recommendation 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.
Are my apps still secure if DevExpress compiles its products against .NET Framework 4.5.2?
Yes, if you’re targeting the latest versions of the .NET Framework in your own apps (see above). 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.
Why does DevExpress compile its products against .NET Framework 4.5.2?
We have chosen to compile our assemblies against 4.5.2 (and not 4.8) for maximum coverage and to minimize frustration – as many customers continue to use older, non-retired versions of the .NET Framework. We also believe that changing the target version of DevExpress assemblies (in the current .NET Framework lifecycle) offers minimal benefits to our users (because of small variances between .NET Framework 4.5.2 and 4.8.1).