RevitLookup Hotfix and The Revit 2025 SDK

RevitLookup HotFix 2025.0.1 has been released, and I continue the exploration of the Revit 2025 API, installing the Revit 2025 SDK and performing the following steps:

RevitLookup Hotfix 2025.0.1

RevitLookup hotfix 2025.0.1 has been released to handle the fixed search bar crashing Revit (issue 214).

This version includes further improvements:

Many thanks to @SergeyNefyodov for contributing and to Roman @Nice3point Karpovich, aka Роман Карпович, for maintaining RevitLookup!

Revit 2025 SDK Download

The Revit 2025 SDK has been published to the Revit Developer Centre:

SDKs and tools > Revit .NET SDK > View documentation and over 100 code samples to start developing with the Revit API. Version 2025 (updated April 2, 2024).

Comparison with Previous SDK

I downloaded the new SDK and compared the directory structure and individual files with the Revit 2024 version, noting the following changes:

Four new SDK samples:

Folders Removed:

Modified:

Added:

Here are my exact comparison steps and details:

Integration into RevitSdkSamples

Before making any changes to my local installation of the SDK samples, I prefer to integrate it into the RevitSdkSamples GitHub repository to track and share my modifications.

In order to preserve as much as possible of the Git history from the previous version to the new SDK release, instead of just deleting and overwriting everything, I integrated the new SDK into RevitSdkSamples in two steps, based on the differences detected in the steps described above:

The result is captured in RevitSdkSamples release 2025.0.0.

Compiling the Revit 2025 SDK Samples

My first attempt to rebuild the solution skipped all 201 solutions.

I searched for an explanation and looked at how to determine why Visual Studio might be skipping projects when building a solution.

I ended up selecting the build target x64 in the Configuration Manager to match the targets listed for each one of the individual solutions.

With that setting in place, it reported 'Rebuild started at 9:09 AM...' and did not skip the projects, but it did not seem to do anything else either except endlessly consume more and more memory until I cancelled the build after more than 15 minutes:

Visual Studio memory consumption growing

Visual Studio memory consumption growing

Next, I removed the .vs folder and changed the build output verbosity to detailed in Visual Studio > Tools > Options > Projects and Solutions > Build and Run.

The increased verbosity still gives no information about what is happening, beyond the message saying 'Rebuild started at 9:46 AM...'

Although... the status bar does list one project after another, reporting 'Restored ...csproj in 3.05 s'. Multiplying 200 projects by 2 seconds each should still complete in a manageable time, though, but I see no hint of progress.

Switching the output to 'Package Manager' shows what is going on... Generating MSBuild file, Writing cache file to disk, Persisting dg, Writing assets file to disk etc.... half an hour waiting and still going... completed after 34 minutes!

I am probably running a suboptimal setup here...

So, I continued waiting. After 1 hour and 46 minutes, the compilation completed, partially, with 177 succeeded, 24 failed, 0 skipped, 30 errors and 5 warnings.

A new record time, slower than all previous versions by a factor of about 25.

Looking at the error list, two errors are caused by code in ExternalResourceDBServer:

I fixed those by commenting out the two offending lines, since the methods referred to are not defined anywhere.

The remaining errors and warnings have to do with external references, such as:

Possibly, some of these errors are caused by not installing Microsoft Office in my virtual machine, so I went ahead and installed Microsoft Office.

I noticed this message in the build output window:

Another possible culprit explaining why Visual Studio keeps rebuilding my projects for no good reason:

Resource is set to “Copy always”: Copy always means just what it says, and there’s never a good reason for that. There is another option to "Copy if newer" instead of “Copy always”.

In the newer SDK-style projects, go to the .csproj file and look for

<CopyToOutputDirectory>Always</CopyToOutputDirectory>

Change that to

<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>

I found and fixed that setting in six projects: CloudAPISample, DockableDialogs, FreeFormElement, GetSetDefaultTypes, InCanvasControlAPI and SinePlotter.

Recompiling again from scratch resulted in 181 succeeded, 20 failed, 23 errors, 5 warnings, in 1 hour and 26 minutes.

Definitely not something I want to repeat on a daily basis. Maybe my virtual machine running Windows in Parallels on a Mac is slowing things down?

My current SDK installation is captured in RevitSdkSamples release 2025.0.1.

Custom Add-In Context Menu

As hinted at by the new ContextMenu SDK sample mentioned above, the Revit API 2025 enables an add-in to create a custom right-click context menu:

This sample demonstrates how to create customized context menu for Add-In and how to create different types of menu items: CommandMenuItem, SeparatorItem, SubMenuItem.

Ricaun, aka Luiz Henrique Cassettari, shares his take on that functionality in his ContextMenuExtension gist and a nine-minute video on Revit API 2025 RegisterContextMenu:

Thank you very much, Luiz!