Revit API: Understanding the Role of SeriesMin and SeriesMax in Plugin Deployment

By Naveen Kumar

If you’re developing a Revit plugin with the goal of ensuring compatibility across multiple Revit versions (e.g., 2023 through 2026), you’ve likely come across the SeriesMin and SeriesMax attributes in the PackageContents.xml file.

This article explains what these attributes are, why they are important, and the key limitations to be aware of when distributing your plugin.

What Is the SeriesMax Attribute?

In a Revit plugin package, the PackageContents.xml file defines the plugin’s metadata and how it integrates with Revit. Inside this file, the <RuntimeRequirements> element uses the SeriesMin and SeriesMax attributes to specify which Revit versions the plugin is intended to run on.

Example:

<RuntimeRequirements OS="Win64" Platform="Revit" SeriesMin="R2023" SeriesMax="R2025" />

• SeriesMin=”R2023″: Minimum supported Revit version.
• SeriesMax=”R2025″: Maximum supported Revit version (inclusive? Not exactly—more on this below).

What Actually Happens in Revit?

Here’s the tricky part: contrary to common assumptions, Revit doesn’t use SeriesMax the way you might expect.

• Revit only checks the SeriesMin value.
• If SeriesMin matches the current Revit version (e.g., R2023), the plugin will load in that version.
• If SeriesMin doesn’t match, the plugin won’t load in other versions(e.g., R2024,R2025,R2026), even if it’s compatible.
• The SeriesMax attribute is effectively ignored by Revit.

This is unlike other Autodesk products like Inventor, which support broader compatibility in a single XML entry without needing multiple version-specific elements.

What Works: One Entry Per Version

To ensure your plugin loads across versions like Revit 2023, 2024, 2025 and 2026, you must create separate <ComponentEntry> and <RuntimeRequirements> elements for each Revit version, even if your plugin binary is the same.

Example of a working (but repetitive) PackageContents.xml:

<?xml version="1.0" encoding="utf-8"?>
<ApplicationPackage>
<Components>
<RuntimeRequirements OS="Win64" Platform="Revit" SeriesMin="R2023" />
<ComponentEntry AppName="FileUpgrader" Version="4.5.0"
AppType="ManagedPlugin"
ModuleName="./Contents/AddinFileName.addin" />
</Components>
<Components>
<RuntimeRequirements OS="Win64" Platform="Revit" SeriesMin="R2025" />
<ComponentEntry AppName="FileUpgrader" Version="4.5.0"
AppType="ManagedPlugin"
ModuleName="./Contents/AddinFileName.addin" />
</Components>
</ApplicationPackage>

This might seem redundant, but it is currently the only reliable way to ensure that your plugin loads across multiple Revit versions. With the above PackageContents.xml, the plugin will load in both Revit 2023 and Revit 2025.

What Doesn’t Work: Omitting SeriesMax in a Single Entry

Some developers try to simplify the XML by removing SeriesMax and using just one ComponentEntry, hoping Revit will load it across all versions.

Unfortunately, this approach fails:

<?xml version="1.0" encoding="utf-8"?>
<ApplicationPackage>
<Components>
<RuntimeRequirements OS="Win64" Platform="Revit" SeriesMin="R2023" />
<ComponentEntry AppName="FileUpgrader" Version="4.5.0"
AppType="ManagedPlugin"
ModuleName="./Contents/AddinFileName.addin" />
</Components>
</ApplicationPackage>

This file only works in Revit 2023. Revit 2024 and 2025 will skip it because SeriesMin doesn’t match.

What About Using .NET Framework Across Versions?

Plugins built with older Revit DLLs (for example, 2023) targeting the .NET Framework may still run on newer Revit versions such as 2024, 2025, and 2026—provided the Revit API method signatures remain unchanged between these versions.

That said, Autodesk recommends recompiling your plugin with the Revit API assemblies for the specific version you’re targeting—especially if you plan to share it publicly—to ensure long-term compatibility.

Also, while .NET Framework plugins might load in Revit versions based on .NET 8.0+ (such as Revit 2025), it’s not a best practice. For better stability and support, migrate and recompile your plugin using the latest .NET Core 8.0 SDKs.

Takeaway: Best Practice for Revit PackageContents.xml file

• Add a separate ComponentEntry and RuntimeRequirements elements for each Revit version.
• Match the SeriesMin value exactly to the Revit version you want to target.
• Don’t rely on SeriesMax—Revit doesn’t respect it.

Final Thoughts

Although repetitive, version-specific elements in PackageContents.xml remain the most reliable way to register plugins across multiple Revit versions. Until Revit supports a more flexible system, maintain these elements and recompile as needed.