Running add-ins from a network drive

[Anonymous]

Hi,

I'm interested in deploying an add-in to more than 100 users. I previously deployed this add-in to some users with an installer package for testing purposes, but as you may imagine this can be a lot of work to deploy to everybody and keep it up to date. I would like to have all files centralized in a local server in the office and being able to update them anytime from one only place.

Editing revit.exe.config file and adding <generatePublisherEvidence enabled="false"/> between the <runtime></runtime> tags solves the problem and works just fine, but if only one person is using Revit I can't update the dll files because they get locked. This is the biggest issue because it would be really difficult to find a time when 100% of the users are out of Revit in order to update those files (they leave their machines on 24h a day with Revit open sometimes)

Does anybody know an alternative method to solve this issue or to update add-ins to multiple machines remotely?

I also read the following discussion but didn't help.

http://forums.autodesk.com/t5/Autodesk-Revit-API/Network-hosted-dll-files/m-p/3285915/highlight/true...

Thanks!

Marc

[Anonymous]

I am also at the stage of figuring out the best deployment strategies. I only have about 10 users but us coders do love to automate 

At present I just have an Install.bat file that copies the relevent addin files the user's local AppData ... Revit\Addins\... folder and then I manually send an email asking all users to upgrade. I'm hoping to do something a bit more elegant in future though.

A few ideas I have been considering:

- Have the users start Revit from a batch script that first updates the local addin files before opening Revit.

- If using 2014 API, code an additional addin for the sole purpose of updating the other addin, it should be possible to check for new versions then unload the main app's dll, update the local files and then reload it dynamically. For bonus points you could get your main addin to update the updater also 

- A simpler option could be to have your addin check for a new version of itself on the network and just pop up a window informing the user of the new version and give instructions on how to update.

[Anonymous]

Thanks for your help and ideas, all of them are good options.

I would like to automatically update the add-in in the background without the user knowing it. Usually users gets annoyed with popups or additional actions, they want the application up and running.

If this would be for Revit 2014 I would probably build a program that would programmatically unload the add-in sync files and load the add-in again but this needs to be done for 2013.

I'll keep looking for the best solution.

Thanks again

Marc

[Anonymous]

You could add an update procedure (batch file or similar) into the network login script for each user. This may not be ideal though as you said that they frequently leave their pc's logged in overnight, meaning that they could go several days / weeks without updating.

[Joe.Ye]

Hello，

Can you change each users' *.addin manifest file remotely by a program? 

If you can change the file. Then the solution is to change the file and point to a new updated revit plugin dll, you can change its name or put it to another folder.

In this way, when users restart revit, Revit will load the new plug-ins.

______________________________________________________________

If my post answers your question, please click the "Accept as Solution" button. This helps everyone find answers more quickly!

[Anonymous · Accepted solution]

Hi,

I ended up checking the updates when the addin is closing (when Revit is closing) and if there are updates available I start an external exe application (that I created) that waits for revit to completely close and copy all new files from the network to the user's computer. 

Now, every time that I have to update the addin for all users I just copy-paste the new files into the network location and when the users close Revit, it detects that the files in the network are newer and automatically gets the updates.

I'm planning to change this process for Revit 2014 since the new API allows to load addins dynamically.

Thanks for all your help!

Marc

[Anonymous]

Nice solution! I woudn't have thought of doing it at shutdown.

[Dale.Bartlett]

I use various acad.lsp, acaddoc.lsp network startup files with AutoCAD to "freshen" local copies of plugins. Achieving the same with Revit is more tricky. I like your idea of an application watching Revit.exe and updating local copies on close, however that necessitates an install on each user anyway. Or maybe a self-conained exe. Our systems are locked down so I am trying to avoid any IT involvement. I understand Revit's addins are loaded in alphabetical order, so am wondering if a primary bootstrap dll could load and run before loading subsequent addins. I am yet to experiment with this idea and am unsure whether the DocumentOpening event (or similar) can be used ahead of all addins being loaded. Dale

[Dale.Bartlett]

Quick update. I have built a simple bootstrap addin named AAA_...

It does get loaded first, so I use it to copy updated addins to the local drive ahead of them being called by Revit.

All works well (so far).

Dale

[Anonymous]

If you are worried about whether the loading order of the addins can be relied upon, the good news is that it is a documented feature and is well defined. I make use of this myself and was at first a little dubious about its long-term reliability so I searched a little and found this in the Developers Guide:

All files named .addin in these locations will be read and processed by Revit during startup. All of the files in both the user-specific location and the all users location are considered together and loaded in alphabetical order. If an all users manifest file shares the same name with a user-specific manifest file, the all users manifest file is ignored. Within each manifest file, the external commands and external applications are loaded in the order in which they are listed.

Full details Here. 

It's funny that I didn't know this earlier, but I guess once you learn how to build manifest files (usually by example), you never really look at that section of the guide and miss out on these little gems of important information.