Revit 2025 API migration step-by-step guide – from .NET Framework to .NET 8

Revit 2025 comes with a big change in API: upgrade from .NET Framework to .NET. As a result, the Revit add-ins’ code must be migrated to .NET 8.

There are several helpful official resources on the migration:

• Autodesk Desktop API Updates: .NET Core 8.0 Migration | Webinar recording
• Migrating from .NET 4.8 to .NET 8 on the Building Coder blog

However, while upgrading my add-ins, I encountered some issues not described in the resources. Therefore, I decided to report my process.

This post is a step-by-step guide on migrating add-ins created for previous Revit versions (utilizing .NET Framework) to Revit 2025 (utilizing .NET 8).

Migration is a big step for the project solution. It is a good idea to commit (if you have version control) and/or copy the solution before the migration.

As always during the Revit add-in upgrade, we need to reference the new version of Revit DLLs (e.g., RevitAPI.dll).

For my add-ins, I don’t reference the DLLs directly from the Revit installation folder but store them in a separate folder included in the solution. Therefore, I had to replace the older Revit DLLs with the newest. If you reference Revit DLLs directly from the Revit installation folder, you have to change the references in projects.

Reference the new DLLs now, before upgrading, to omit additional errors.

.NET Upgrade Assistant greatly facilitates the process. We will use it in the next step.

Now we will use the “upgrade” functionality of the .NET Upgrade Assistant on our project(s).

You need to upgrade all the projects based on .NET framework (since .NET Framework is not compatible with .NET). If your solutions contain projects based on .NET Standard, they will not need an upgrade, since .NET Standard is compatible with .NET.

If you have more than one project to update, it is important to upgrade them in the proper order – starting at the bottom of the projects’ dependency hierarchy. It means you should start with a project not referencing other projects in the solution.

Example: Let’s say you have Project A, Project B, and Project C. Project A does not reference other projects in the solution. Project B references Project A, and Project C references Project B. You should first upgrade Project A, next Project B, and then Project C.

The rule applies also to test projects – as they surely reference other projects, upgrade them after “normal” projects.

Click on a project and select Upgrade.

Select Upgrade project to a newer .NET version.
(Note: this window does not always appear.)

Select .NET 8.0.

In the next window, select all the components (if not selected, by default) and click Upgrade Selection.

After the upgrade, click on the Project to open its .csproj file.

It should contain such a line:

<TargetFramework>net8.0</TargetFramework>

Add “-windows”, so that the line is:

<TargetFramework>net8.0-windows</TargetFramework>

Also, for WPF projects, the .csproj should contain:

<UseWPF>true</UseWPF>

And for Windows Forms:

<UseWindowsForms>true</UseWindowsForms>

Perform these steps for all your projects, following the projects’ dependency hierarchy.

Copying the manifest file (.addin) to the new Revit version add-ins folder is a typical step.

BUT, we have a small catch due to .NET migration: the targeting folder path (the “build” folder) has another “layer”. Therefore, you have to change the assembly path in the manifest file.

For example:

<Assembly>c:\MyRevitProject\bin\Debug\RevitProject.dll</Assembly>

Needs to be changed to:

<Assembly>c:\ MyRevitProject\bin\Debug\net8.0-windows\RevitProject.dll</Assembly>

The migration might break some code, so it will need to be addressed. Also, some references might need to be changed. This step is individual, depending on the used packages and the codebase.

After addressing these issues, the solution can be rebuilt and the add-in should work in Revit 2025.

Side note: There is a possibility for a more advanced approach, like targeting multiple Revit versions with one code base. It can be beneficial when the code base needs to be maintained with the previous Revit version. Nonetheless, it is unlikely the next versions will use .NET framework anymore.