Upgrading code from Revit 2016 to support Revit 2018

[Anonymous]

We have an Add-In codebase running well on Revit 2015, 2016.

We wish to offer it for Revit 2018 however in the 2018 SDK I see many namespace changes, enum changes etc.

Question:

What is to preferred method to support Revit 2016 and Revit 2018?  I am hoping to avoid having to build 2 different installs.

  Adam

[Troy_Gates]

Each year when the new Revit releases, I test my addins by...

1) copying my VS project to another location

2) running a "clean solution" on the project to remove previous build files

3) adding the new Revit dll library references

4) build the solution

5) if there are warnings or errors, something has changed in the API

6) review and adjust the errored code

[JimJia]

Dear Adam, If you want to have only one installer for Revit 2016 and 2018, you need to do some additional work. Here is a workaround way: Build Revit 2016 and 2018 separately, and put them into installer, then modify your installer, install right version depend on user selected when installing your add-in. By the way, if you want to only keep one copy of your add-in code, you can add some "build condition" in your code. Hope this workaround way can resolve your problem.

[Anonymous]

Sure, but then I have 2 codebases to maintain / 2 codebases to bug fix.  And when Revit 2019 comes out I have 3 code bases.

What I'm looking for is how to support multiple versions of Revit from a single codebase.

Adam

[JimJia]

Adam,

If you want to have a single codebase, you can define some compilation symbols like "REVIT2016","REVIT2018". You can set symbol as picture shows

Here is a sample of get a face normal in a single codebase using compilation symbol:

XYZ normal = null;
#if REVIT2015
            normal = face.ComputeNormal(UV.Zero);
#else
            normal = face.FaceNormal;
#endif

In that case, if you want to build different version, you only need to change the compilation symbol in project's property.

[RPTHOMAS108]

It's not impossible but I doubt you are going to get an answer that it is supported because the best practice is to use the version of the API relevant to the Revit version.

I've found that you can support later versions of Revit if you use previous versions of the API and don't need the latest features. I've also found you can build with the latest version of the API and use with previous Revit versions.

You have to test it and focus on where the interactions with the API are. You'll get missing member exceptions in some instances where you are calling something that doesn't exist in a previous version. These errors will be runtime because according to your incorrect references you are ok at design time.

Generally on the first year something will become obsolete but still available and the following year it is taken out. So if you wrote based on 2017 you have some confidence that the same members will still be available in 2018 but in 2019 you have to look again. I've considered taking this approach in the past but it generally isn't a huge task to update each year.