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:
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.
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:
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.
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:
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
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
Your add-in may avoid instability by matching the version of these key components used by the Revit 2025 release:
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.
Here are some common issues you may encounter when upgrading to .NET 8:
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: <FrameworkReference Include="Microsoft.WindowsDesktop.App"/>
Build Error CA1416If 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 8Your .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
Your .NET 4.8 application may need updates to help it find and load assemblies:
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 StringIf 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.CompareString.Compare behavior has changed, see .NET globalization and ICU and Use Globalization and ICU.
Windows Dialogs May Change AppearanceYour 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.
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.
If you see different orderings of items in sorted lists after updating to .NET 8, this may be because List<T>.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 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 UpdatesIf 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 <Nullable>disable</Nullable>. Beginning with .NET 6, new projects include the <Nullable>enable</Nullable> element in the project file.
You can set <Nullable>disable</Nullable> if you want to revert to .NET 4.8 behavior.
Environmental VariablesIf 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.