Quantcast
Channel: Developer Express Inc.
Viewing all articles
Browse latest Browse all 2370

.NET — Automatic Upgrade of .NET and External Dependency Versions, Converting Assembly to Package References and More (v24.2)

$
0
0

Reducing Issues with Target Framework/3rd Party Dependency Upgrades

Based on research, a more effective/automated .NET framework and 3rd party dependency upgrade process is high on the priority list for our customers (without appropriate automation, major version upgrades require many hours of manual/tedious work).

The most time-consuming upgrade problem involves correctly matching non-vulnerable 3rd-party dependencies (such as Entity Framework Core or System.Text.Json). This a multi-faceted issue and involves matters such as...

  • Each external dependency must be compatible with both the target .NET and DevExpress product version. For example, if using Microsoft.EntityFrameworkCore.SqlServer v7.0.3, you also need a matching System.Drawing.Common v7.0.0 package for .NET 6 or 7.
  • Upgrading to .NET 8 also means upgrading Microsoft.EntityFrameworkCore.SqlServer to v8.0.6 and System.Drawing.Common to v8.0.0 (and so on for dozens of other transitive packages). Yes, the "version" puzzle is not easy to solve and requires a lot of time-consuming/manual effort.
  • Unfortunately, NuGet's built-in Package Manager (with its Update command) or the .NET Upgrade Assistant (at least at this stage) do not help much when dozens of inter-dependent projects and hundreds of external dependencies require updates.

Based on these realities, we have taken steps to address the upgrade/update process in our v24.2 release cycle.

1-Click Conversion Process 

To simplify the migration/upgrade process, the DevExpress Project Converter will attempt to automate two very time-consuming project-related modifications. These automations should save hours of manual effort especially for teams with large .NET Framework or .NET solutions. Non-DevExpress projects (without DevExpress packages) will NOT be touched. Developers who prefer manual updates will NOT be affected.

#1 - Re-target DevExpress-based projects to .NET 8 and .NET Framework 4.6.2 

Our converter automatically updates TargetFrameworkVersion, TargetFramework, and TargetFrameworks settings (from .NET Framework 4.5.2 / .NET 6 and earlier) in csproj/vbproj and *.config files. Uncheck the Update Target Framework option if you want to update the target framework in your DevExpress projects manually.

#2 - Automatically update 3rd party packages to the latest compatible versions

Our converter automatically updates 3rd-party NuGet packages for projects with DevExpress dependencies based on the latest version compatible with the target framework (for example, System.Text.Json, Microsoft.AspNetCore.*, Microsoft.EntityFrameworkCore.*, etc. - approximately 200 known dependencies in our Directory.Packages.props file). Again, Non-DevExpress projects (without DevExpress packages) will NOT be touched.  Uncheck the Update 3rd-party Dependencies option if you want to update DevExpress projects manually.

The source Directory.Packages.props file will be updated by DevExpress based on known security advisories from https://github.com/advisories (valid on the release date, so these screenshots can be outdated in the future).

If your team already uses props files and Central Package Management (CPM) or does NOT wish to automate the conversion process, you can update everything manually. Within the converter, simply uncheck the Update Target Framework and Update 3rd-party Packages options and proceed with a standard version upgrade. These two options are enabled by default, but our converter always makes backup files (*.bak) should you accidentally leave these options checked.

Example of How It Works

Before

To illustrate the automatic conversion process, I used a complex solution with multiple projects and dozens of external dependencies (our Outlook-Inspired Demo on GitHub v24.1.3).

After

Once I ran the attached Project Converter v24.2.1, DevExpress projects were all automatically converted to v24.2. The Target Framework was set to .NET 8 and all dependencies were updated to match this .NET version as well. Solution projects were built correctly and both Blazor and WinForms .NET 8 apps started as well. Just like magic :-)

As expected, a few test projects without DevExpress references were left untouched. I converted these projects from .NET 6 to .NET 8 manually. To be frank, after manually converting these projects, I regret the fact that we did not build an automation tool for non-DevExpress projects. It's easy to fall in love with automation and once used to it, it's hard to go back to `manual` mode :-) 

Test It Yourself Before the Official Release in December

To test our updated Project Converter today, please use the attached ZIP archive. NOTE: This DevExpress Project Converter is from a recent nightly build and is NOT the same tool available in our EAP v24.2.1 build. Your DevExpress packages will use a custom version (like v24.2.1.24281 or similar) after running the tool as well.

If you installed EAP v24.2.1 via the DevExpress Download Manager, replace 24.2.1.24281 with v24.2.1.X. To update, either run the old v24.2.1.X Project Converter again (recommended) or update the project and configuration files manually.

You can also await our Beta in mid-November or RTM in early December for testing, so no hurry.

Bonus: Updated Tools and Docs for Easier Upgrade to .NET from .NET Framework

Our Project Converter can now convert DevExpress assembly references in your solution (or specific projects) to corresponding DevExpress NuGet packages. By selecting the Convert DevExpress assembly references to NuGet packages option under Advanced settings, you can easily transition to NuGet-based project management. 

Once DevExpress assemblies are converted, complete the upgrade process by using the Microsoft .NET Upgrade Assistant (to migrate your application to the most recent version of .NET). New help topics include step-by-step instructions with screenshots for both DevExpress and Microsoft tools: Migrate a .NET Framework App to .NET | Choose Suitable NuGet Feed | Install NuGet Packages in the IDE.


 Your Feedback Matters

Let me quote one of our customers, because I could not agree more:

"I think it is the most suitable period for a developer to upgrade his project to new .NET. A year ago they didn't exist so many tools for migration, also most of 3d party libraries that most developers have wasn't full compatible with new .NET. Another thing was the experience someone had to have with the new framework to take the next step. I mean learning over time more things and techniques made the transition to it that much easier."

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


Viewing all articles
Browse latest Browse all 2370

Trending Articles