The Bundled Addin Blues: C4R & Dynamo

C4R is quickly becoming the goto solution for inter-firm collaboration, addressing the massive disconnect between Revit Server licensing and, well, the reality of how projects get delivered. However, C4R has been a right mess from an install and management standpoint.

The first thing to be aware of is the various relationships and interactions that make up Collaboration for Revit. C4R itself is implemented as a Revit addin. A single year addin, meaning there are different addins for 2015, 2016, 2017 and now 2018. This C4R addin is tied very tightly to a specific build of Revit as well as year, and updating one without the other can cause stability or functionality problems.
In addition to the actual C4R addin, there is a shared component called Personal Accelerator. This is shared by all versions of C4R, across all installed years of Revit. And while updates don’t have to be in lockstep the way C4R & Revit builds need to be, it is best if C4R is at least working with a relatively recent version of Personal Accelerator, and never a newer version. You can see these build coordination requirements in this table, with most current build of Personal Accelerator in bold.

What this means is that, in order to keep all the myriad components in sync, you really need to wait until all the updates for the years of Revit you support are available, and then update all at once. And you lose the ability to, as an example, install Revit 2018 while keeping Revit 2017 at 2017.1.1 and keeping Revit 2016 at R2U6. Given that updating project teams to a new build can be something that needs to happen on a rolling schedule, it really makes the entire situation extremely painful, if not untenable.

In addition, Autodesk is pushing Dynamo in 2017 & 2018 Deployments, 2017 updates (and I assume 2018 updates once 2018.1 drops) as well as including Dynamo in the C4R 2015 & 2016 installers. This is really problematic because who in their right mind expects Dynamo to get installed with the totally unrelated C4R? Autodesk marketing, that’s who. And to make matters worse (yes, it gets worse), the version of Dynamo included in every single Autodesk resource that isn’t the actual Dynamo installer; Revit Deployments, Revit 2017 & later updates and C4R 2015 & 2016 installs, is outdated the day it ships. So using the ADSK resources as provided just means one more step to get Dynamo up to current stable build where it belongs. And if that isn’t bad enough, the Dynamo installer that was included in Revit 2017.1 actually UNINSTALLED Dynamo for 2015 & 2016. Let that sink in for a moment. Installing a Revit 2017 update would break Dynamo in previous years of Revit? Hope no one did that to a team with a pending Dynamo requiring deadline in Revit 2016.

So, even when manually installing things or depending on Autodesk Desktop App (no one seriously DEPENDS on ADA do they?) the situation is a mess. But wait, there’s more! If you have any sort of deployment/management automation, only some of the 2017 updates can be installed silently as provided, and none of the 2015 & 2016 C4R installs can be automated.

Now there is a shred of good news, with a caveat to follow. The good news is that C4R 2015 & 2016 installers can be “unpacked”, as can Revit 2017 updates. The unpack processes are different, but the net result is you can dig down and find the MSIs and MSPs you actually need, discard the ones you don’t (Dynamo, since you’ll be installing that silently from the official Current Stable Build download), then install using silent install strings. The caveat is that all the 2015 & 2016 C4R MSIs need you to uninstall the previous version before you can install the new version. And while the early 2017 installers seem to install over the previous versions fine, the C4R install from the Revit 2017.2.1 update and the Personal Accelerator install for Revit 2018 will fail to install without uninstalling first. This need to uninstall first throws a bit of a spanner in the works, as they say, and makes your automation much more complex, whether you are using SCCM, PrismDeploy, your own BAT files, Px Tools or any other solution.

Now, what does this mean for Px Tools users? Well, first off it’s a big part of the delay in getting 2018 recipes published. I had really hoped to deliver those recipes along with complete info on managing C4R and Dynamo. But the uninstall requirement makes for a rather nasty definition using Px Tools 3.3. Px Tools 4.0 includes some new functionality in the Execute, Install & Uninstall tasks to improve the situation a bit. But in the meantime, I will be publishing recipes for use in Px Tools 3.X, and the Unbundled Addins workflow will be considered experimental until we can validate the process in a number of (brave) offices and be confident it really does work consistently.

 
Last updated: July 11, 2017 at 15:03 pm