CODEWITHSUNDEEP
revit-apirevitrevitpythonshellpyrevit
Yongjoon Kim
Yongjoon Kim

Reputation: 127

Revit API: Maintaining a code for multiple API versions

I have some Revit add-ins that are written for Revit 2019 or the versions below. Now I'm trying to upgrade the tools for Revit 2020, but it seems like there are some significant changes in API methods. Fortunately, some of them are backward compatible so I can just update the code with new API methods and use it for Revit 2020 and 2019. However, some of them only works for Revit 2020. (ex) ImageInstance.Create(Document, View, ElementId, ImagePlacementOptions)

In this case, what would be the best way to keep the same code base compatible with different Revit versions? I can easily imagine using If Statement to determine a proper API method for each Revit version, but it doesn't seem ideal for the maintenance of the tool.

Any advice would be appreciated!

Upvotes: 1

Views: 525

Answers (2)

Mikołaj Frankiewicz
Mikołaj Frankiewicz

Reputation: 31

I start with Revit 2017 and until 2021 I had good run with Library that have basic method for almost everything. I did in a way of adding new platforms to project(Revit2017, Revit2018 itd..). With every year there was more and more compilation options and less memory on my disk from all these revits(for moment i had like 7 revits). It works until they start not only change some minor things or adding new methods, the problem start when they start to remove some options without any way of going around this. Now it is even harder when they change Id from int to long, and they did this even for enums, this make casting some problems and it sometimes don't work properly, compiler just can't swallow thought that sometimes this enum is from int and in different version from long(not sure why this is happening but resolving int need like stupid amount of casting) Another problem was all this families and templates that I had to save in every version, some templates take like 15 min to save in new version and it is only 100mb files. Biggest problem was going from enums to ForgeTypeId, in past you could have like one nice switch for enum, now you have shit load of if statment and you need to know with ForgeTypeId it is, and class that have them are badly describe and they even make a colossal fopa by making a String class and Integer class.

But going back to point it is possible, but it will be a lots of work, what you need is to make it most acceptable for your sanity is:

  • In project make your own default platforms, you will need to write it in project file by your self.
  • set up statement in project file to change reference to Revitapi dll when you change platform, this will help you find problems with api easier
  • set up symbol for every platform
  • most method will have a compilation options for every version
  • build your library in way that make dll for every version, in your application reference to your needed version(checking version in revit is not hard) it at the base works like these framework that have folder x64 x86.

remember: this will work well if your project is not big(less then 2000 lines), if you have big project it is better to left one for oldest version(for me it is 2017) and just keep up with two last versions of Revit.

Upvotes: 0

Callum
Callum

Reputation: 588

Ive been writing and managing Addins since Revit version 2015 and use if statements to make sure things are backwards compatible. They havent gotten too out of control yet...

Its worth writing a small function to return the Revit version as a string for your if statement:

def revitVersion(): # returns '2020'
     return app.VersionName[-4:]

You can also put lists together to help check for functionality:

revitsWithoutBIM360 = ['2015', '2016', '2017', '2018']

if revitVersion() in revitsWithoutBIM360:
     print 'This version or Revit can't access BIM360 projects'
else:
     # your code here

Might not be the most elegant way to handle it, but works for me.

Upvotes: 1

Related Questions