2035/2078

Migrating from .NET 4.8 to .NET Core 8

Originally Published in

The Revit 2025 API is based on .NET Core 8, a significant upgrade from the previous .NET 4.8 framework underlying the Revit 2024 API and previous:

.NET Core Migration Webinar Recording

The development team held a webinar in January on the topic of the Autodesk Desktop API .NET Core Migration – Embracing Modern .NET.

The one-and-a-quarter-hour Autodesk desktop API .NET Core 8.0 migration webinar recording ↗ has now been published for public access:

In addition, here is the presentation slide deck PDF.

My colleague Madhukar Moogala also shared the recording together with AutoCAD API migration guides in his article on Autodesk desktop API update .NET Core migration ↗.

Revit API .NET Core Migration Guide

For Revit 2025, the guide on Migrating from .NET 4.8 to .NET 8 is included as a section in the Revit 2025 API help file RevitAPI.chm, provided in the Revit 2025 SDK that is available from the Revit developer centre ↗.

I printed it out in PDF format, available in migrating_to_net_core_8.pdf.

Better still, though, the CHM file contains native HTML formatted text. For your convenience and to facilitate web searches, here it is:

Revit 2025 API

Migrating from .NET 4.8 to .NET 8

Revit 2025 is built on .NET 8. In this release, the Revit API is .NET 8 only, and Revit add-ins need to be recompiled for .NET 8.

The move from .NET 4.8 is to .NET 8 is a relatively large jump. .NET 8 comes from the .NET Core lineage, which has significant differences from .NET 4.8.

Upgrade Process

There are many Microsoft documents and tools to help application developers migrate from .NET 4.8 to .NET Core/5/6/7/8. Following is a list of some helpful documents:

Basic upgrade process for projects

For C# projects (CSPROJ)

For C++/CLI projects (VCXPROJ)

Refer to Microsoft’s guide for migrating C++/CLI projects to .NET Core/5+: https://learn.microsoft.com/en-us/dotnet/core/porting/cpp-cli ↗

  • Replace true with NetCore. This property is often in configuration-specific property groups, so you may need to replace it in multiple places.

  • Replace A property with net8.0-windows.

  • Remove any .NET Framework references (like ) and add FrameworkReference when needed . .NET Core SDK assemblies are automatically referenced when using NetCore support.

  • Add FrameworkReferences:

    • To use Windows Forms APIs, add this reference to the vcxproj file:

    • To use WPF APIs, add this reference to the vcxproj file:

    • To use both Windows Forms and WPF APIs, add this reference to the vcxproj file:

  • Remove any for cpp files. It will be set as NetCore by default. Any other values may cause issues.

  • Then address incompatible packages, library references and obsolete (unsupported) code.

Global.json

You may need to set net8.0-windows as the target in your global.json, if you have one. Refer the link for global.json overview: https://learn.microsoft.com/en-us/dotnet/core/tools/global-json ↗

Component Versions

Your add-in may avoid instability by matching the version of these key components used by the Revit 2025 release:

  • CefSharp
    • “cef.redist.x64” Version=“119.4.3”
    • “cef.redist.x86” Version=“119.4.3”
    • “CefSharp.Wpf.HwndHost” Version=“119.4.30”
    • “CefSharp.Common.NetCore” Version=“119.4.30”
    • “CefSharp.Wpf.NetCore” Version=“119.1.20”
  • Newtonsoft Json
    • “Newtonsoft.Json” Version=“13.0.1”

Supporting Multiple Revit Releases

A single code base can support older Revit releases on .NET 4.8 as well as Revit 2025 on .NET 8. See this discussion on the Autodesk forums ↗ for ideas on configuring your projects and code to support multi-targeting.

Common Issues

Here are some common issues you may encounter when upgrading to .NET 8:

Build Warning MSB3277

When building code that references RevitAPI or RevitUIAPI, you will see the build warning MSB3277 ↗. To fix this, add a reference to the Windows Desktop framework:

Build Error CA1416

If your application uses functions that are only available on Windows systems, you may see a CA1416 ↗ error. This can be fixed for the project by adding [assembly: System.Runtime.Versioning.SupportedOSPlatformAttribute(“windows”)] to AssemblyInfo.cs.

Obsolete Classes and Functions with .NET 8

Your .NET 4.8 application may see compile time or runtime errors if it uses classes or functions that are obsolete or deprecated in .NET Core/5/6/7/8.

Lists of breaking changes for .NET Core/5/6/7/8 are here: https://learn.microsoft.com/en-us/dotnet/core/compatibility/breaking-changes ↗

Assembly Loading

Your .NET 4.8 application may need updates to help it find and load assemblies:

Assembly Properties

After updating your application to .NET 8, you may see build errors for your assembly properties. Many assembly properties are now auto-generated and can be removed from AssemblyInfo.cs ↗.

Double Numbers To String

If you have unit tests or integration tests that compare doubles as strings, they may fail when you upgrade to .NET 8. This is because the number of decimal places printed by ToString() for doubles is different in .NET 4.8 and .NET 8 ↗. You can call ToString(“G15”) when converting doubles to strings to use the old .NET 4.8 formatting.

String.Compare

String.Compare behavior has changed, see .NET globalization and ICU ↗ and Use Globalization and ICU ↗.

Windows Dialogs May Change Appearance

Your dialogs may change appearance with .NET 8.

Process.Start() May Fail

If your application is having trouble starting new processes, this may be because System.Diagnostics.Process.Start(url) has a behavior change ↗. The ProcessStartInfo.UseShellExecute Property ↗ defaults to true in .NET 4.8 and false in .NET 8. Set UseShellExecute=true to workaround this change.

Encoding.Default Behaves Differently in .NET 8

If your application is having problems getting the text encoding used by Windows, it may be because Encoding.Default behaves differently in .NET 8. In .NET 4.8 Encoding.Default would get the system’s active code page, but in .NET Core/5/6/7/8 Encoding.Default is always UTF8 ↗.

Items Order Differently in Sorted Lists

If you see different orderings of items in sorted lists after updating to .NET 8, this may be because List.Sort() behaves differently ↗ in .NET 8 than .NET 4.8. The change fixes a .NET 4.8 bug which affected Sort() of items of equal value.

System.ServiceModel

System.ServiceModel has been ported to .NET Core through CoreWCF ↗, which is now available through Nuget packages. There are various changes, including _<System.ServiceModel>_not being supported in configuration files.

C# Language Updates

If you are building code from .NET 4.8 in .NET 8, you may see build errors or warnings about C# nullable types.

C# has introduced nullable value types ↗ and nullable reference types ↗. Prior to .NET 6, new projects used the default disable. Beginning with .NET 6, new projects include the enable element in the project file.

You can set disable if you want to revert to .NET 4.8 behavior.

Environmental Variables

If you use managed .NET to run native C++ code, be aware that environmental variables, including the path variable for DLL loading, are not shared from managed .NET code with native C++ code.

Send comments on this topic to Autodesk

Migration