Installing VSTO Add-in for “Some” users

There have been great discussions around how a VSTO add-in can be deployed for “All Users”. Misha described a workaround here and Saurabh also talked about a hotfix for Office 2007 for this issue in this blog post.

Another requirement that mostly concerns corporates is to make an application or functionality, in this case a VSTO add-in, available for some users of a machine in an automated way. Basically, the idea is to have the add-in available based on the user credential. Of course the first solution that comes to mind is to install the add-in for all users and have the add-in decides who should have access to it. You should not be concerned about deployment if you are using this approach, however, you need to add the logic for authentication/authorization and decision making to grant/revoke access to users. I would say this is best if you want to filter functionalities in your add-in based on the user’s credential rather than making the whole add-in unavailable.

If you are using ClickOnce as your deployment method, I should say your hands are kind of tight for one-step installation, since the add-in gets installed in the ClickOnce cache which is a per-user storage. For instance, all add-ins installed under my credential lives under “C:\Users\hamed\AppData\Local\Apps\2.0”. That is why Thony could not get his add-in work just by copying the registry keys. In this case, you need to install the add-in for each user on your “have access” list. This does not seem easy in companies with great number of computers and users. However, do not let this solvable issue take all the great features of ClickOnce deployment away. An active directory group can be created and access to the installer on a shared server could be granted to the group. Therefore, each user on the list can install the add-in on her machine under her user account.

Using Windows Installer (MSI) gives you the option to choose where your add-in gets installed and, therefore, you can just have a batch file to copy the required registry keys to different users registry, having the add-in live on a shared path for those users. I am personally not in favor of this approach though, if I do not have specific reason to follow that. Customizing an MSI needs some degree of expertise and is sometimes error-prone, at least for novice users. The major drawback would be not having the auto-updating feature of the ClickOnce, which could be a pain point in big companies (read Enterprise level deployment by Kris for more information).

Always look for your environment limitations and needs comparing different approaches and find out which one gives you the best bang for your buck, especially in the long run.

Good luck.