Innovative Revit Add-in development (part 1)

Innovative Revit Add-in development (part 1)

In this three-part post, I want to introduce some of the advantages to innovative Revit Add-in development. Topics I’ll cover include the benefits to the new Visual Studio project format, the use of IoC containers and solutions for add-in cross-version conflicts when using third party software libraries.

Current development with .NET 4.8

Since the launch of the 2021 version, Revit has supported add-in development with .NET Framework v4.8, the final version of the .NET Framework series. The .NET Framework successor, .NET 5+ (.NET version 5 or newer) is not currently supported by the Revit API.

With the launch of the new .NET Framework, the project format for Visual Studio projects has also been updated. This new format is also known as SDK Style Project and offers a whole host of benefits compared to the previous format:

  • Clarity
    The new format no longer requires a list of files that belong to the project. The files just need to be saved in the project folder or a subfolder. Then the files are automatically accounted for during the build.

  • Improved integration of NuGet packages
    The new project format also supports package references. Only directly referenced packages are listed in the project file, while all dependencies needed to be entered in the previous format. A file named package.config was also previously required to manage the packages. This is also not necessary when using the new format.

  • Auto reload
    Project files in the new format can be directly opened and modified in Visual Studio by double clicking on the project entry in the solution explorer. Modifications to the file are immediately reloaded when the file is saved. As a result, there is no longer any need to unload the project file.

Creating a project in the new format

Unfortunately, Microsoft has opted to not provide templates for .NET Framework projects in the new format in Visual Studio. Due to this, I would like to show you how you can easily create .NET Framework projects in the new format. All you need to do is follow the steps below:

Create a new project in Visual Studio. Select ‘Class Library’ under project template. Be careful to not select the ‘Class Library (.NET Framework)’ template. This would result in you creating a project in the old format. Once you've selected the correct template, pick a name and storage location for the project and set ‘.NET Standard 2.0’ as the framework. Now create the project and open the project file by double clicking on the project entry in the solution explorer.

<Project Sdk="Microsoft.NET.Sdk">



You can now easily update the target framework by replacing ‘netstandard2.0’ in the ‘TargetFramework’ element with ‘net48’ and saving the file. Once the target framework has been updated, Visual Studio needs to reload certain framework references. This does not happen automatically and the simplest way to do it manually is by restoring the package. You also need to complete this step if you have not added any packages to the project. Alternatively, you can also unload the project and reload it again.

In order to use the latest C# language features and create your own WPF interfaces, you can edit the project file as described below.

<Project Sdk="Microsoft.NET.Sdk">



Instructions for migrating existing projects are available for existing projects. However, often the easiest approach is to first create a project file in the new format and then replace the old file with the new one.

Assembly info

The AssemblyInfo.cs file where version numbers, copyright notices and other information on the product or manufacturer can be stored is part of .NET Framework projects. While this file can also be used for projects in the new format, I would not encourage it. Instead, all required information can either be added to the project file directly or transferred to automated build processes.

Package references:

NuGet packages can also be added to projects in the old format. With this approach, all packages and dependencies are managed in the package.config file. The project file also still contains the references to the assemblies.


  <package id="Scotec.Extensions.Linq" version="0.9.3" targetFramework="net472" />
  <package id="Scotec.Math" version="0.9.3" targetFramework="net472" />


    <Reference Include="Scotec.Extensions.Linq, Version=, Culture=neutral, processorArchitecture=MSIL">
    <Reference Include="Scotec.Math, Version=, Culture=neutral, processorArchitecture=MSIL">

Visual Studio offers a function for migrating the package.config file. When this function is executed, the assembly references found in the project files are converted into package references. As the packages are now also managed in the project file, the package.config is deleted once the migration is complete. Only the package references are entered in the project file for migration. Project files are not automatically converted to the new format. Although you could view this as an intermediate step and copy the newly created package references into your new project file.


    <PackageReference Include="Scotec.Extensions.Linq">
    <PackageReference Include="Scotec.Math">


The new project format offers a wide range of advantages compared to its predecessor. Honorable mentions go to the improved clarity and successful integration of NuGet package references. Project files in the new format have a neater, clearer appearance, making them easier to maintain. Converting to the new project format is also a good idea for existing projects. However, it's important to keep factors like the amount of time and costs required for conversion into account. That being said, if major modifications or enhancements are planned for your project, converting to the new format would likely be a worthwhile investment.

An error has occurred. This application may no longer respond until reloaded. An unhandled exception has occurred. See browser dev tools for details. Reload 🗙