Here is a bunch of long overdue news items to round off this hot week:
We had an extensive discussion on the topic of equipping each Revit add-in with a trusted signature in order to avoid the warning presented before loading it that otherwise pops up and needs to be manually confirmed by the user.
It started off in the Revit API discussion forum thread on code signing of Revit add-ins even before the initial customer release.
I continued adding new material to it as various more specific queries came in from developers over time.
I hope it now includes a clear explanation of all aspects of the situation.
The latest addition is probably the most complete and succinct summary:
Question: "When Revit 2017 opens with my in-house developed add-in, it prompts the user for an action: always load, load once or do not load. Since the app is in-house developed, I wonder: is it always necessary to have a certificate also for in-house trusted area?"
Answer: The answer is yes; the warning will always be issued.
Our security architect adds:
The add-in must be signed with an approved cert or it will display the popup on first load.
We've documented the process of creating a self-signed cert that can be used for your own internal use.
You can push the cert to machines in your domain using group policy.
If you both sign the add-in and push the cert to domain machines, users can use the add-in without the popup.
Next, here is the rather overdue publication of the Revit 2017 API news presentations from the DevDays conferences around the turn of the year:
As usual, the training material used by the Autodesk Developer Network ADN for hands-on Revit API introductory trainings has been updated for Revit 2017 and is available from GitHub in the Revit API Labs Training Material repository.
Many thanks to Ryuji Ogasawara for the migration and clean-up for Revit 2017!
I also migrated the ADN Xtra Labs to Revit 2017.
It includes the same training material as the official ADN version mentioned above, plus a series of so-called Xtra labs containing the material we before restructuring and documenting the labs in a more didactical fashion.
The older labs have a different history and approach, provide some alternative insights, and include a couple of tools and utilities that I still find worthwhile to preserve and maintain.
The migration to Revit 2017 is very straightforward.
The first step is to update the .NET target framework from 4.5 to 4.5.2 and update the Revit API assembly references to point to the new Revit.exe folder.
Doing so produces zero errors for this add-in, just a couple of warnings.
Here are my migration steps with all the intermediate releases, differences between each step and the previous one and log files listing the warnings produced at that point:
19 warnings about use of the obsolete and deprecated automatic transaction mode remain, so I am still not completely done.
In any case, these diffs and logs should give you a very clear idea of how to approach any migration issues that you may encounter.