how to maintain revit plug-ins for multiple versions

image by archi-lab

One thing that we all have a love/hate relationship with is API breaking changes. Yes, we all love shiny new toys, but they usually break our old reliable tools. What about that one user in the office who still works on a project from 5 years ago, and refuses to update to latest Revit 2018? Do I have to maintain a version of my plug-in for that guy too? The answer is probably yes. How can we go about maintaining code for multiple versions of Revit, and easily building it for any version at any time. Below is a few tips and tricks:

I start off my every Revit plug-in project by creating a Post-Build Event that copies my freshly minted DLL to Autodesk/Addins folder. That usually saves me a few seconds every time I want to launch Revit to see my new tool in action. Now, how can we connect our Post-Build Events with our Configurations settings so that we can build these tools for different version on a fly? Here’s an example of conditional statements embedded into Post-Builds so that we can quickly change between versions:

Let’s break that down a little bit first:

  • echo” is used here to print something to the console. In this case the selected Configuration name.
  • if $(Configuration) == 2017 goto 2017” basically means that if I select Configuration named “2017” please jump over to piece of code that starts with “:2017
  • Here we print another message to the console.
  • Here we check if folder exists at Revit\Addins\2017\OpenAEC since that’s the location we want to copy our new DLLs into. If it doesn’t exist create it first.
  • Notice use of %ALLUSERPROFILE% shortcode for C:\Users\user\AppData\ location. That way we can build our code on any machine under any user name.
  • Finally we have “goto exit” statement so that our code jumps to “:exit” and since that’s the last line, it will just exit out.

Here’s how to create the appropriate Configuration settings:

First open the Configurations Manager:

Then create a new settings by copying/renaming an old one:

If you want to launch the appropriate version of Revit for debugging you can set that under properties:

This can be set for each Configuration, so you can launch different version of Revit for every Configuration. That’s pretty handy when debugging. Next, we can set the Configuration’s Conditional compilation symbols. What is that? I will show you an example in a second but first let’s create one:

Here’s how to use one:

What happens here is that when you build your code, it will omit certain parts of it, based in the conditional statement. This is how you can create a single plug-in that supports multiple versions of Revit.

Finally, each one of these plug-ins needs to have a different reference of RevitAPI.DLL and RevitAPIUI.DLL. How do we load one that we need on demand? We can add some conditional statements to our *.csproj file.

That’s it! Now, depending on what Configuration we select, Visual Studio will reference in the appropriate Revit API DLL, omit certain parts of the code from compiling, and finally copy our DLLs into the appropriate Addin folder. All pretty smooth so that we can focus on writing code.

6 Comments

  1. Troy Gates says:

    Same method I use. Great write up.

  2. Deyan says:

    Super super useful as always, Konrad.

  3. Daniel Viero says:

    Great post Konrad.
    My question is though: do you have any preferred method then to deploy the *.dll and .addin files onto each user’s computer?
    Do you use a bat routing which you launch from each computer or do you use some professional IT tools like “GoverLAN”?

    thanks a lot

    • Well, I am usually writing them, and I leave deployment to IT. I think they have some BAT scripts that image everyone’s drive every night to one location on a network. that way i am only worried about getting the DLLs and Addin file to that location when they are ready for deployment. IT takes care of it from there on.

    • Troy Gates says:

      I place all of our addin files on a network share. Then use a bat file that contains an xcopy command to copy newer files to the user computers programdata folder at login via GPO.

      This allows me to update the network share and the users get the new addins the next time they login to their computer.

    • Daniel Viero says:

      Konrad,
      Good point and I do totally support it.
      Each one of us, should take care about his own tasks and responsibilities. However, and that is the main reason why I brought it up, sometimes (sadly) the roles overlap a bit and I find myself taking care also about IT.

      Troy,
      It does totally make sense and that was the main reason why I thought a simple .bat file would do the job nicely and tidy. I will try and attach it to the Task Scheduler and run it on a fortnightly basis so whenever I update the file(s) they will get copied also onto each user’s computer.

      Thanks a lot to you both again.

Leave a Comment