Revit Multi Version Configuration

Revit Multi-Version Configuration

A Revit project builds one configuration per supported year. The Nice3point.Revit.Sdk derives the framework and the cumulative REVIT#### / REVIT####_OR_GREATER symbols from the active Debug.RNN / Release.RNN configuration.

When to use

• Declaring or changing which Revit years a project supports.
• Writing version-specific code for a real API difference.

When not to use

• Understanding what the SDK sets automatically per version — use revit-sdk-project-configuration.
• Adding the Revit API assembly references — use revit-api-references.

Workflow

Step 1: Declare the configuration matrix

<Configurations>Debug.R25;Debug.R26;Debug.R27</Configurations>
<Configurations>$(Configurations);Release.R25;Release.R26;Release.R27</Configurations>

Mirror the same Debug.RNN/Release.RNN set in the .slnx/.sln file.

Step 2: Add or remove a version

Add or remove the matching Debug.RNN / Release.RNN in the solution and the project's <Configurations>. For a newly released year, first update the SDK; set TargetFramework explicitly only when the SDK is not released with the latest Revit version support or the project uses the preview API package:

<TargetFramework Condition="$(RevitVersion) == '2027'">net10.0-windows7.0</TargetFramework>

Step 3: Add preprocessor directives for incompatible API

Write shared code first. Add a #if branch only where the Revit API genuinely differs; keep both branches independently compilable.

#if REVIT2024_OR_GREATER
    // API available from Revit 2024 onward
#else
    // legacy API
#endif

Step 4: Verify

Restore and build every declared configuration, and run version-specific tests for each branch that changed.

Validation

• The active solution matrix selects the intended project Debug.RNN/Release.RNN configurations.
• #if branches cover only genuine API differences, and both sides compile.
• Every declared configuration restores and builds.

Common Pitfalls