Visual Studio add-ins are not very friendly when trying to auto-update them (at least as of Visual Studio 2008), so when deploying an add-in for internal use within an organization, one creative idea is to put the assembly dll in a shared network folder and register the add-in from there in each computer without copying it to the hard disks. You can do this putting the XML .AddIn file in that same folder and adding that folder to the list of locations that VS uses when searching for add-ins (Tools, Options menu, Environment, Add-in/Macros security). During the day you won’t be able to update the add-in assembly because it will be in use by the developers, but chances are that you will be able to do it at night (with some automated mechanism).

There is still a problem, though. As of .NET Framework 3.5 (without SP1) and below, by default assemblies in shared network folders lack FullTrust permission required to run add-ins, because shared folders belong to the LocalIntranet_Zone, which has a LocalIntranet permission set, not a FullTrust permission set. This was an incovenience not only for add-ins, but also for general .NET applications, and since configuring the .NET runtime security policy is not trivial, I guess that Microsoft got tired of support calls and complaints from developers and IT staffs and in SP1 of .NET Framework 3.5 they changed things to allow .NET assemblies to run with FullTrust permission from shared network folders (you can revert back this change if you want the old behavior).

Note: .NET Framework 3.5, 3.0 and 2.0 share the same CLR, so it’s CLR 2.0 what matters for security and add-ins, not the .NET Framework. 

So, the question I was wondering is: can then a .NET 2.0 add-in run from a shared network location without further security configuration changes? I did the test, and I got this nice COM error: 8013150A (not very helpful as usual). If I changed the permissions to FullTrust in that shared network location, it worked, so I have enhanced my article about troubleshooting with a mention to this error:

HOWTO: Troubleshooting Visual Studio and Office add-ins
http://www.mztools.com/articles/2007/MZ2007009.aspx

The only remaining thing to clarify is why the security policy change doesn’t work with add-ins. Well, it happens that this is by “design”, it doesn’t work with ClickOnce applications or applications that are designed to run on a host:

Running Intranet Applications in Full Trust
http://msdn.microsoft.com/en-us/library/cc713717.aspx