Where is the appropriate file installation locations for Release and Test/Debug Revit Addin components?
I have noticed a variety of locations where Revit Addin components are deployed for Release and Test/Debug purposes. For example, the Hello World sample for Revit 2017 recommends installing "HelloWorld.addin" to "C:\ProgramData\Autodesk\Revit\Addins\2017\" whereas the Addin Wizard generates a script that automatically loads the "*.addin" file to "C:\UserName\AppData\roaming\AppData\Roaming\Autodesk\Revit\Addins\2017/".
I have also noticed that the official release addin installation programs that I have historically gotten back from the Autodesk Revit team seem to install *.Addin, *.dll, and other supporting files in numerous locations depending on:
* Revit version(s) supported
* All users vs. current user installation
* Roaming profiles vs. non-roaming profiles
* Version of Windows (?)
* Possibly other criteria
First, is there documentation that describes how this should be done for commercial products. Note that I would prefer to do my own Revit Addin installation in the future.
Second, in the specific example of installing a Addin for Revit 2017 running on Windows 10 for the current user only without roaming where would I install the production components (myaddin.addin, myaddin.dll, myaddindependent.dll)? Can I utilize the location for the .addin file for Test and Debug? I assume that I will need to point the myaddin*.addin file to the Debug version of the myaddin.dll file in order to Debug?
Regards,
Eric
Dear Eric,
The official documentation for this can be found in the Revit API developer guide:
Revit online help
http://help.autodesk.com/view/RVT/2017/ENU
Developers
Revit API Developers Guide
http://help.autodesk.com/view/RVT/2017/ENU/?guid=GUID-F0A122E0-E556-4D0D-9D0F-7E72A9315A42
Introduction
http://help.autodesk.com/view/RVT/2017/ENU/?guid=GUID-C574D4C8-B6D2-4E45-93A5-7E35B7E289BE
Add-In Integration
http://help.autodesk.com/view/RVT/2017/ENU/?guid=GUID-4BE74935-A15C-4536-BD9C-7778766CE392
Add-in Registration
http://help.autodesk.com/view/RVT/2017/ENU/?guid=GUID-4FFDB03E-6936-417C-9772-8FC258A261F7
Here is some additional documentation on additional undocumented add-in folder paths (please excuse the pseudo-pun):
Cheers,
Jeremy
Hi Eric,
I can understand your concern of noticing a variety of locations where Revit Add-in components are deployed, it has a reason for it. Let me explain a bit...
1) Location: %AppData%\Autodesk\Revit\Addins\<year>- This location is for per-user only, and it is recommended for per-user specific applications.
2) Location: %ProgramData%\Autodesk\Revit\Addins\<year> - This location is for multiple users, so all the users can have access to the application.
Few apps are placed in Program Files too depending on the need.
In the Autodesk App Store, we normally recommend below paths for the addin.
%ProgramData%\Autodesk\ApplicationPlugins (for multiple users) and %AppData%\Autodesk\ApplicationPlugins (for per user) in order to use these paths you need to use the bundle format. Wherein the addin and its dependent files are stored in a bundle folder, Autodesk Revit autoloads the addin module based on the entries in the PackageContents.xml file placed in the bundle folder. You can refer to ppt (from slide No.6 onward) for bundle format.
You can utilize these locations for Testing and Debugging, and yes you can point to the myaddin*.addin file to the Debug version of the myaddin.dll file in order to Debug.
If you need any help on the bundle format, please feel free to email@ appsubmissions@autodesk.com
Thank you very much for sharing this important additional information.
I captured it for future reference in The Building Coder blog as well:
http://thebuildingcoder.typepad.com/blog/2018/10/revit-add-in-locations-and-bim360-eu.html#4
Cheers,
Jeremy
Why would you deploy your addins anywhere for testing / debugging and why would it be different than production?
I don't deploy my addins anywhere while I'm developing / testing / debugging them. I just leave them in their "bin\debug" folder where they build to, and point the addin manager at that folder. Debugging / testing / developing without using the addin manager is just a monumental waste of time constantly closing and reopening Revit, imho.
It doesn't test your ribbon buttons, but I typically just ignore those until the end, and then do some testing with the full installer on a fresh VM that mimics our standard users as if it was being deployed to a production environment. And in those tests I test the installer, general user experience, and ribbon buttons / revit startup.
I also always code my addins to use the per user Appdata folder and think that most people should generally be doing the same thing. In my mind no application should be requiring admin privileges unless it *actually* needs them to run, Revit Addins included, and the vast vast vast majority should only require user privileges.
Just my thoughts, why we need to have admin privileges.
Big Firms will not recommend any installation without admin privileges, most IT companies will not give admin access to the employees to prevent unwanted malware attack/security reasons. Hence placing the addin in programdata with admin rights will enable the IT to install the application once to support all users. I have experienced many companies restricting usage of good plugins, just because they don't have admin privileges.
As mentioned in your post, would you be able to elaborate on what needs a company may have that leads them to place their Addins in the Program Files folder?
Thanks in advance!
Hi @Anonymous
\Program Files\ is trusted by default, the unsigned add-in residing in this location will not display a security warning.
Few publishers utilize this location to treat the addin as trusted.
The custom installers provided by the publisher for Autodesk App Store which are utilizing Program Files location need to make sure the custom installers / dll are digitally signed.
Also, consider below necessities while submitting a custom installer:
Note: Autodesk App Store will not use the %PROGRAMFILES% location to create an installer for third-party apps.
Can't find what you're looking for? Ask the community or share your knowledge.