How To Maintain Revit Plugins For Multiple Versions Continued - Archi-Lab PDF

6/20/2020 how to maintain Revit plugins for multiple versions continued… | archi-lab
Home
About me
Services
Examples
Portfolio
Reading
Membership
how to maintain Revit plugins for multiple

versions continued…
By Konrad K Sobon / 25 May 2020 / 3 Comments
image by archi-lab
Obviously, I wrote about this topic some time ago. Here’s the original post: Post. Basically, the issue was that
I needed to maintain multiple versions of my Revit plugin, to match multiple versions of Revit that I wanted
to support. At the time I thought that Configurations was the right way to go, but as you can guess, I no
https://archi-lab.net/how-to-maintain-revit-plugins-for-multiple-versions-continued/ 1/9
longer think that’s true. The only reason I am even touching this subject is because I have recently saw a post
on Speckle Blog, that discussed this same approach, and they opted for Configurations. Now, don’t take this
as I am telling you that Matteo is wrong. Far from it. This in fact might be the best solution for their unique
problem, but I thought that I share another approach that I have learned recently.
Shared Projects. This has been added as a new feature back in Visual Studio 2015, but I haven’t really heard
of it until few months ago. Let’s first examine what a Shared Project is. From the sound of it, you might
think that it’s some DLL that is shared across multiple projects, and that it contains code that would be used
by these projects. That’s not the case. A Shared Project, is basically shared source code. The way it works is
that each project (DLL) that references the Shared Project would have the code contained in it, incorporated
right into it. How is that different than Configurations:
Configurations build different versions of the same code, based on the selected Configuration. There is
still just a single project (DLL), that is compiled and post processed based on whatever Configuration
is currently selected.
Shared Project approach actually allows you to build different DLLs for each version, where each DLL
has the Shared Project embedded into it, but now instead of using Configurations to control Post Build
events, References, Dependencies, Setup projects etc. you can just do that in different projects.
Let me show you an example. I have recently switched Archi-lab.net Dynamo package to use this approach.
Now, whether this is the “correct” approach for Dynamo is a completely different discussion, because as we
all know it, Dynamo doesn’t make anything easy, but let’s assume it was the correct approach. What does
that look like:
As you can see above there is an “archilabSharedProject” project, and there are different projects for
“archilab2021”, “archilab2020” etc. The idea is that all shared code, is contained in the
archilabSharedProject, but all resources that are unique to specific version would be contained in that
version’s project. This approach makes it easy for me to have post build events that copy resources (*.addin
manifest files) to specific location, and I don’t have to use “if Configuration == 2020 copy to 2020 location”
type code. Someone might say: “Well that’s nothing special. If statements are not that hard. Is there a real
benefit to this approach?”
The answer is, YES! OK, so I agree, a Post Build event or Target FrameworkVersion configuration that looks
like the one below might not be sexy, but it’s not end of the world.
1 <PropertyGroup>
2 <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
3 <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
4 <ProjectGuid>{8F2BB60A-09BC-41EC-A013-2AE8BE5BCEC9}</ProjectGuid>
5 <OutputType>Library</OutputType>
6 <AppDesignerFolder>Properties</AppDesignerFolder>
7 <RootNamespace>HOK.MissionControl</RootNamespace>
8 <AssemblyName>HOK.MissionControl</AssemblyName>
9 <TargetFrameworkVersion Condition="'$(Configuration)' == '2015'">v4.5.2</TargetFrameworkVersion>
14 <FileAlignment>512</FileAlignment>
15 <TargetFrameworkProfile />
16 <NuGetPackageImportStamp>
17 </NuGetPackageImportStamp>
18 </PropertyGroup>
configVersions.cs hosted with ❤ by GitHub view raw
1 <Reference Include="RevitAPI" Condition="'$(Configuration)' == '2015'">

2 <HintPath>..\..\..\..\..\..\..\Program Files\Autodesk\Revit 2015\RevitAPI.dll</HintPath>
3 <Private>False</Private>
4 </Reference>
5 <Reference Include="RevitAPIUI" Condition="'$(Configuration)' == '2015'">
6 <HintPath>..\..\..\..\..\..\..\Program Files\Autodesk\Revit 2015\RevitAPIUI.dll</HintPath>
8 </Reference>
12 </Reference>
16 </Reference>
20 </Reference>
24 </Reference>
28 </Reference>
32 </Reference>

36 </Reference>
40 </Reference>
referenceConfiguration.cs hosted with ❤ by GitHub view raw
The real benefit of Shared Projects comes into play when we start dealing with things like Setup projects aka.
installers (MSIs). These allow you to reference an asset or a project. If you are using things like
Configurations, then you really have just a single DLL/project, but you might want to have your installer
reference different versions as you would want it to copy them to different locations. That’s the whole point
of an installer. Now, you have a pickle because you have to do that in two steps:
build all of your Configurations, copy these DLLs to different locations based on a Configuration
build your MSI, referencing assets (DLLs) from folders on a drive, rather then dynamically linking
them from Visual Studio solution directly.
Another thing that greatly annoyed me with Configurations was the fact that now I basically either had to
give up the idea of having a Debug/Release Configurations, or I had to create them for each version of Revit.
That might be as many as 8 Configurations if I need to carry Debug/Release for 2021/2020/2019/2018. Why
do I care for Debug/Release? You might want to do things like disable XML/PDB file creation for Release
builds. If you are not planning on debugging them, then why clutter that bin folder with them? Also, every
now and then I am asked to obfuscate the code (I know, don’t ask why), but if that’s part of the Release
routine, then I CAN’T debug the Release code, and that necessitates that I have Debug and Release
configurations.
Now, you might also be wondering, but can I still do the good old “#if Release2015 #else #endif”
statements? The answer is, yes, of course. You can put all of the version specific code into the Shared
Project. It works just like the old Configuration’s method.
In summary, the Shared Project approach has all of the same benefits that Configurations do, plus it avoids
potential issues with things like MSI’s and Debug/Release Configurations. In my opinion it also makes it
explicit that there is support for different versions of Revit, which then makes all version specific code and
resources obvious and much easier to maintain. It might not be a revolutionary approach, but I think it’s a
little bit better than Configurations.
Again, I used it with archi-lab.net project here. Please check it out, and let me know if you have any
questions.
Support archi-lab on Patreon!
Share this:
 Twitter  Facebook  LinkedIn  Pinterest  Print
Posted in: C# / Tagged: addins, C++, revit, shared project, versions, visual studio, vs
3 Comments
1.
richard says:
May 25, 2020 at 9:32 pm · Reply
that makes sense, I have recently been struggling with having to reference two different version of cef
sharp between revit 2019 and 2020 (revit forces a specific version of cef sharp to be used by any
addin). I assume you can install one version of cef in the shared project and then install any other
version for the individual versions? Thanks as again
Konrad K Sobon says:

May 26, 2020 at 1:41 pm · Reply
You would actually install all of the references (different version of cef) in individual projects.
So plugin2021 would have a reference to revitapi2021, while plugin2020 would have a
reference to revitapi2020. You only keep CODE in the shared project.
2.
m-sterspace says:
May 26, 2020 at 6:01 pm · Reply
Personally I found a lot of the difficulties of maintaining different versions in one code base to just not
be worth it.
I’ve switched to just using git branches when there’s breaking api changes and then use git’s merging /
cherry picking features if I ever need to bring code between them.
Leave a Comment
Name *
Email *
Website
Save my name, email, and website in this browser for the next time I comment.
Upload Attachment (Allowed file types: jpg, gif, png, pdf, doc, docx, ppt, pptx, pps, ppsx, odt, xls, xlsx, rar, zip, mp3,
m4a, ogg, wav, wma, mp4, m4v, mov, wmv, avi, mpg, ogv, 3gp, 3g2, flv, webm, apk, maximum file size: 2MB.
Choose File No file chosen
Notify me of follow-up comments by email.
Notify me of new posts by email.
Submit Comment
Search
To search type and hit enter
Categories
Select Category
Recent Posts
Comparing View Templates in Dynamo June 18, 2020

how to maintain Revit plugins for multiple versions continued… May 25, 2020
create ceiling plan by room April 19, 2020
In depth look at Dynamo and Revit relationship w/ Bimbeats March 28, 2020
creating curtain wall plans/elevations pt2 March 18, 2020
Calendar
June 2020
M T W T F S S
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
« May
Tags
AEC archi-labarchitecture autodesk automation BIM C++ coding community computation

computational computational BIM computational design curtain wall d3 data delete design development
dynamo excel grasshopper hackathon mandrill mantis shrimp open source

documentation html parsing
programming python revit revit api revit plug-in rhino schedules scripting symposium tags technology
view template visualization visual programming visual studio warnings

← create ceiling plan by room
Comparing View Templates in Dynamo →
archi-lab tweets:
RT @archikaos: @arch_laboratory Absolutely a win! It's such a pleasure working with

@arch_laboratory and honor to contribute to open source19 Jun 2020
Comparing View Templates inDynamo https://t.co/sxWkyu4zmV18 Jun 2020
RT @Gytaco: Pretty cool when some of the tech you've been working on makes the local news. Been
great to build the backend platform to inte12 Jun 2020
RT @MGortat: https://t.co/jdYIUo2rjU polecam ! Cala prawda o czowieku zarzdzajcym Polska
koszykwka. 03 Jun 2020
@gtalarico Yours is one of a kind...sorry, but no documentation for one offs. Next time try and order at
least two. Congrats! 31 May 2020
@60secondrevit @DynamoBIM Yeah, I agree. Its useless and quite heidious too.27 May 2020
Project Gallery
Membership:
Search:
To search type and hit enter
Categories:
Select Category
Tags:
AEC archi-labarchitecture autodesk automation BIM C++ coding community computation

computational computational BIM computational design curtain wall d3 data delete design development
dynamo excel grasshopper hackathon mandrill mantis shrimp open source

documentation html parsing
programming python revit revit api revit plug-in rhino schedules scripting symposium tags technology
view template visualization visual programming visual studio warnings
© Copyright 2020. Powered by WordPress
Viewport Theme by ThemeZilla

How To Maintain Revit Plugins For Multiple Versions Continued - Archi-Lab PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

How To Maintain Revit Plugins For Multiple Versions Continued - Archi-Lab PDF

Uploaded by

Copyright:

Available Formats

6/20/2020 how to maintain Revit plugins for multiple versions continued… | archi-lab

how to maintain Revit plugins for multiple

configVersions.cs hosted with ❤ by GitHub view raw

1 <Reference Include="RevitAPI" Condition="'$(Configuration)' == '2015'">

33 <Reference Include="RevitAPI" Condition="'$(Configuration)' == '2019'">

referenceConfiguration.cs hosted with ❤ by GitHub view raw

Support archi-lab on Patreon!

 Twitter  Facebook  LinkedIn  Pinterest  Print

Konrad K Sobon says:

Choose File No file chosen

Notify me of follow-up comments by email.

Notify me of new posts by email.

To search type and hit enter

Comparing View Templates in Dynamo June 18, 2020

AEC archi-labarchitecture autodesk automation BIM C++ coding community computation

dynamo excel grasshopper hackathon mandrill mantis shrimp open source

view template visualization visual programming visual studio warnings

RT @archikaos: @arch_laboratory Absolutely a win! It's such a pleasure working with

To search type and hit enter

AEC archi-labarchitecture autodesk automation BIM C++ coding community computation

dynamo excel grasshopper hackathon mandrill mantis shrimp open source

view template visualization visual programming visual studio warnings

© Copyright 2020. Powered by WordPress

Viewport Theme by ThemeZilla

You might also like