Suggestions for Revit API changes year to year

[bwinemiller]

I develop in-house addins for my company using C# across Revit versions 2024-2027. I keep on coming across errors in my tools due to methods, classes, etc. becoming obsolete because of api changes across revit versions. Identifying these discrepancies and rewriting my code to handle these changes have become cumbersome. Does anyone have insight on how they handle situations like these?

[RLY_15]

I don't check this often enough to know if it's a 'it's happening today' thing or a 'it's never been there' thing, but each version of Revit came with an API changelog...except 2027's is throwing a 500 error:

https://www.revitapidocs.com/2026/news

https://www.revitapidocs.com/2027/news

[GaryOrrMBI]

You're likely to get a lot of the more experienced developers to kick in all kinds of advanced ideas and concepts with or without links to other discussions, and if your goal is development they are good and worth investing the time in learning.

With that being said: I'm an Architectural Tech/Designer/Detailer that, like you, creates a set of custom utilities specifically for my firm's use that I started with in 2020 and have continued since.

I tried as many of those advanced techniques as I could understand and implement effectively for a while but, eventually, I gave most of that up. I now duplicate my project for each release, change my references as needed and build it for the new version. If it builds cleanly then I may let that one cover a couple of releases with some of the easier path redirects for the Revit version based on build configurations but that's about it.

I let the older versions become static unless I create some new function that everyone really wants me to try to include in a couple of the older versions and when that comes up, I copy the newly created elements into those older projects on a case by case basis.

This "simplification" is the only way that I can stay on top of the annual releases and still maintain my project chargeability ratios, and even then I sometimes get called out.

My cent and a half (sorry, can't afford Two Cents these days 🙂 )

-G

[bwinemiller]

I agree with ya Gary. So hard to balance billable hours with keeping in house tools running smoothly (I need to invent a way to measure the profitability of the time I save everyone with my coding work haha) although, my firm has been pleasantly supportive of my efforts.

Ive previously tried using runtime compilers to be ablet to keep one dll I can deploy to each version, but that unfortunately has not been working. I think I may have to use your workflow moving forward. We also need to make a petition for autodesk to stop making things obselete 😞

[ricaun]

I guess gonna depend how are you handling multiple Revit versions in you project.

I'm usually use Configuration or TargetFramework to select the set the RevitVersion property and with that I can enable Defines for REVIT2021 and REVIT2021_OR_GREATER...

I did create a package to help create all the Define logic.

• https://github.com/ricaun-io/RevitVersion.DefineConstants/

With some code like this as example to get the Label for Meter

public static string GetMeterLabel()
{
#if REVIT2021_OR_GREATER
    return LabelUtils.GetLabelForUnit(UnitTypeId.Meters);
#else
    return LabelUtils.GetLabelFor(DisplayUnitType.DUT_METERS);
#endif
}

The RevitVersion.DefineConstants package gonna be archive because I'm creating an Sdk that gonna include the same define logic.

• https://www.nuget.org/packages/ricaun.Revit.Sdk#readme-body-tab

Most of the time I create extensions with define inside depending of the Revit version, that approach works well for my projects.

[bwinemiller]

I typically publish only publish code once for 2024 and deploy it to all my Revit versions and haven't really had any issues. Ive tried using runtime compilers, but they conditional is not triggered by the active version of Revit running, only by the version I publish in. For reference, I'm using nice point's template and his runtime conditionals. 

                                        ElementId ElemId;
#if (REVIT2025_OR_GREATER)
                                        ElemId = new ElementId(headerLong);
#else
                                        ElemId = new ElementId(headerInt);

#endif

 my deployed code in 2026 still catches the integer input instead of the long format input that is compatible. I thought this would be the fix to only maintain one file, but I may be wrong

[ricaun]

In ElementId case I use some extension to convert everything to long like this:

public static long GetValue(this ElementId elementId)
{
#if REVIT2024_OR_GREATER
    return elementId.Value;
#else
    return elementId.IntegerValue;
#endif
}
public static ElementId ToElementId(this long value)
{
#if REVIT2024_OR_GREATER
    return new ElementId(value);
#else
    return new ElementId((int)value);
#endif
}

---

 wrote:

I typically publish only publish code once for 2024 and deploy it to all my Revit versions and haven't really had any issues. Ive tried using runtime compilers, but they conditional is not triggered by the active version of Revit running, only by the version I publish in. For reference, I'm using nice point's template and his runtime conditionals. 

my deployed code in 2026 still catches the integer input instead of the long format input that is compatible. I thought this would be the fix to only maintain one file, but I may be wrong

---

The Value was added in Revit 2024, don't know why you are using IntegerValue.

Is possible to select the available constructor and value depending of the Revit version using some reflation.

https://github.com/ricaun-io/ricaun.Revit.DB/blob/73a33f70863c1cfd950450fa32f3b35518aa30ef/ricaun.Re...

Are you build one assembly for each Revit version right?!

[AEC_Revit_Lab]

Those #if checks happen at compile time, so copying the DLL into another Revit version cannot select a different branch. Build each version’s configuration separately from the same codebase, using matching API references and target frameworks; Revit 2027 uses .NET 10. Hope this helps. If it solves the issue, you’re welcome to mark it as a solution so others can find it more easily.

[frankiewicz63WYH]

what @GaryOrrMBI wrote is sadly true. I work with api for more then 10 years. 

I try different approach and nothing really work, if your team is not bigger then 3 people, then just gave up with keeping your code for every version.
At best you can keep up to last 3 release, but more then that is just way to much work, and with them going from framewrok to core it was even harder.
My suggestion is to make code for last two versions and when new revit version appear just make branch for this last two versions and leave it. 
There is just way to much changes that happens(last 3 years was especially terrible). Not only you have to follow changes, but you need to search for changes that they didn't wrote in 'what change'(there are more of them then you thing).

But if you really what to implement one project for all, prepare to learn how to write project file. Here is link that you will need:
https://www.eagle-swift.com/net-notes/net-10-project-files-explained
Last time i check, code for 'revit lookup' did it kind of well. 

I did not test it what @ricaun make but just from quick look it seems to be ok, Im a little concern that there is no info about how to setup reference for every version of revit(maybe i miss it).

Some IDE will gonna have problems witch changing from framework to core, so be ready for many closing and opening edytor. We do not what false errors.

Another thing is that you need to know what you use for building your project, VisualStudio will use msbuild and I thing visual code use dotnet, they are similar but have different defaults value, so get use ignoring some Warnings that are specific for one or another.
Oh and you resources will brake like a lot, this is just part of life.

And do not forget about documenting every thing, with revit api, no comments is to obvious(I regret not doing it so much, it is one of the reason that going back to older versions is hard, there is just to much exceptions). 
Of course if you app is not really that complicated or you just  do some simple things, it will be not that bad.
But if you planing on working In:
Family document, creating and editing in project, or interacting witch connection of elements, get ready for hell.

Good luck, you will need it.

[ricaun]

---

@frankiewicz63WYH wrote:

I did not test it what @ricaun make but just from quick look it seems to be ok, Im a little concern that there is no info about how to setup reference for every version of revit(maybe i miss it).

---

 There is a property RevitVersion that is set by the sdk, you can use to select a nuget package with the Revit references.

<ItemGroup>
  <PackageReference Include="Revit_All_Main_Versions_API_x64" Version="$(RevitVersion).*-*" IncludeAssets="build; compile" PrivateAssets="All" />
</ItemGroup>

I create a video showing the sdk and basically how works the custom target framework.