(or how Office user and system settings work)
If you have installed Visual Studio 2010 Ultimate, an Excel add-in called “Load Test Report Addin” is installed. This add-in makes it possible to create load test performance reports in Excel and loads when you start Excel. The add-in is meant for Excel 2010 and works perfectly if you have installed and started Excel 2010. Excel 2007 on the other hand sees an inconsistency, i.e. the VSTO file (which is an XML file) related to the add-in (Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn.vsto) doesn’t contain the “addIn” XML element Excel 2007 is expecting. This element isn’t available in the VSTO file and is not needed for Excel 2010. The result is an error message from Excel 2007 at start (see the screenshot below, after clicking the “Details” button, showing more detailed information about what’s going on).
Side note: VSTO stands for Visual Studio Tools for Office and is an Office add-in framework supported by Visual Studio (but not every Office add-in is of the VSTO type!). A runtime exists for VSTO and is installed with Visual Studio, but it can be downloaded and installed as a separate package too; the runtime is needed to make VSTO add-ins be able to run (thus in Office applications). FYI, Visual Studio 2010 contains VSTO 4.0. The add-in being discussed in this blog post is obviously a VSTO add-in (for Excel in this case). Note that a VSTO add-in is actually a subtype of the COM add-in type; in Excel you can get a list of all the add-ins and a VSTO add-in will be shown as a COM add-in in that list.
The add-in is installed in
- for 32 bit Windows : %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies
- for 64 bit Windows: %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies
It consists of those files:
- Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn.dll: the actual implementation
- Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn.dll.manifest: the manifest file
- Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn.vsto: the VSTO file, which is the actual file used by Excel to localize the VSTO add-in code (the DLL)
- Other files are of course also necessary, but are not specific for this add-in
If you take a look at the add-in list of Excel you can indeed see we’re dealing with a registered add-in for Excel. Click the Office button, then the “Excel Options” button and select “Add-Ins” on the left side of the dialog “Excel Options” that pops up. At the right you see the add-in “Load Test Report Addin” under the “Inactive Application Add-ins” section. You can see it’s a COM add-in and when you select the add-in you can see its description and description file (in this case the VSTO file because it’s a VSTO add-in) mentioned. You see the “|vstolocal” string being appended to the actual file path to indicate the add-in resides locally. The add-in is inactive, meaning it’s not loaded: Excel obviously tries to load it at startup, but this fails (hence the error message) and thus the add-in isn’t loaded (active).
I’ve read about other troubles the add-in is casuing in Excel 2007. It seems spaces are ignored in the Visual Basic Editor in Excel 2007, but I haven’t checked that out myself.
Ok, enough chit-chat about the symptoms. What about a solution? Well, the add-in is just not mentioned for Excel 2007, so there is no real solution. But, there is a workaround to avoid the error message at Excel 2007’s startup, i.e. not letting Excel 2007 load this particular add-in. To achieve this, you have to know what determines the add-in list for Excel and how to manipulate it. Read on and digest some registry stuff J
Behind the scenes and what you can do there
When Visual Studio 2010 Ultimate is installed, it puts something for this add-in in the registry at the system level and it does so at different places, i.e. for a few Office versions. Let’s take a look at all those system level places where VS puts something (if a piece of the path doesn’t exist, it is created):
On 32 bit Windows:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\User Settings
On 64 bit Windows:
- HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\12.0\User Settings
- HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\User Settings
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\User Settings
The first 2 registry paths for each Windows architecture (minus “User Settings”) are the system level base registry keys for Office 2007 (12.0) and Office 2010 (14.0) respectively, both 32 bit. The third registry path for 64 bit Windows (minus “User Settings”) is the system level base registry path for Office 2010 (64 bit on 64 bit Windows). I don’t know why Visual Studio 2010 Ultimate places “something” for Load Test Report Addin for Office 2007 32 bit (by the way, there is no 64 bit Office 2007), as it causes troubles and doesn’t get loaded. Perhaps the troubles only occur with certain versions of the add-in and/or Excel 2007…? Could it be that the troubles only begin after Office 2007 has been updated to a certain point for instance? You could also wonder why VS should place a key for different versions and architecture types on a single system, while there can be only 1 Office instance installed. Well, simple: an Office instance version can always be uninstalled or installed at a later point. By placing “something” for different Office versions or architecture editions, the system is ready to support the add-in for all those Office instances without reinstalling VS again or fixing it some other way. Let’s say VS does it the future proof way J
All system level base registry keys for Office may contain a sub key called “User Settings”, containing stuff meant for the user level. It contains information about how things can be added to or removed from the user’s registry hive when you start an Office application of the right version and architecture type (it doesn’t matter which particular Office application though). Every sub key of “User Settings” bundles addition and/or removal information about a specific thing. All additions for that specific thing are bundled by another sub key “Create” and the same counts for the removals (but under a sub key “Delete”); those 2 sub keys are optional (for example, if there is no removal information, the Delete key is allowed, but not required). Beneath a hierarchy of keys defines the paths within the user hive that should be created or deleted; under each key named values can be defined along with their values. This way we can define stuff at system level for all users. This “stuff” includes (but is not limited to) add-ins, by using the user level registry paths for add-ins.
Anyway, let’s take a look at our “add-in key” in particular. Such a key is typically named with the add-ins’s name, technical name, GUID or something like that, in our case “Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn”. Then we see 1 sub key called “Create”, determining that one or more things should be added to the user’s registry hive, but that no removals are necessary. Then we have a series of keys that determines 1 path within the user’s registry hive (in our case it’s limited to indeed only 1 path): Software\Microsoft\Office\Excel\Addins\Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn. When a piece of the path doesn’t exist, it gets created.
HKCU\Software\Microsoft\Office is the user level base registry key for Office and it contains a few sub keys for specific Office applications (for example, HKCU\Software\Microsoft\Office\Excel is the user level base registry key for Excel). Under such an Office application key a sub key called “Addins” may exist, containing all the “user level” add-ins (with each add-in having its own sub key under “Addins”) for that Office application for the “current” user. So at the end this Addins key is the place that actually determines which user level add-ins an Office application gets, although it can be filled up/driven by information from the system level registry hive (HKLM). Of course this means you can add an add-in to the user level directly (manually in the registry, through a (logon) script, via the registry part of group policy preferences, from the default user (well, this works for new users, but not for existing users),…).
Our add-in key contains a few named values, like
• Description: a REG_SZ which contains the description for the add-in. This description is shown when you select an add-in from the add-in list you can see in an Office application.
• FriendlyName: a REG_SZ which contains the “friendly name” (display name) for the add-in. This name is shown when you select an add-in from the add-in list you can see in an Office application.
• LoadBehavior: a REG_DWORD that defines the way the add-in should be loaded. The different values of LoadBehavior can be checked at http://msdn.microsoft.com/en-us/library/bb386106.aspx. By default our add-in has the decimal value of 16, meaning it’s loaded at startup, but only the first time, after which it later only starts on demand. Technically this happens because after the first successful load the value of LoadBehavior is automatically changed to 9, which means it only starts on demand (this is obviously not the case in our scenario, as it loads every time at startup, meaning the value always stays 16). So the value of 16 means “load at startup and change the value to 9 (meaning it only loads on demand) after the first successful loading”. When an add-in loads successfully the add-in is active; when this attempt fails or no loading takes place, the add-in is inactive (note: when LoadBehavior is 1 the add-in is always shown as active, even when it’s inactive; but lets’ not talk about this value for LoadBehavior, because it’s outside the scope of this post).
• Manifest: a REG_SZ which contains the path to the file that actually gets the Office application started for getting and loading a VSTO add-in. It’s some description/config file (a .vsto file), that shows the way to the actual code file (DLL) and contains some configuration information for the add-in. The name of the named value is misleading, as it refers to the .vsto file and not to the .manifest file. The VSTO file is however a kind of manifest, different from the .manifest file. To be more precise: the VSTO file is the deployment manifest. So the named value’s name isn’t lying J
The first 3 named values are used for every kind of add-in that is defined at the user level (the “real” user level and thus of course the stuff under “User Settings” at the system level too). The last one, used as the “starting point” for the Office application towards the actual add-in (code and config files), is not used by every add-in type. For example, a Document Inspector add-in (don’t worry if you don’t know what it is, it’s just an example of another add-in type for some Office 2007 applications, including Excel) has a named value called “CLSID” to get Excel started and find out more about the add-in; CLSID contains the class ID (CLSID) of the Document Inspector add-in.
Side note 1: for some LoadBehavior values (but not for 16, which is the case with our add-in) Excel “degrades” the value (and thus the load type) of an add-in to. For example, an add-in that has a LoadBehavior value of 3 loads at startup. When this fails though, LoadBehavior will change to 2, meaning it doesn’t load anymore at startup because it failed before. The add-in still keeps appearing in the Inactive Application Add-ins list and not in the Disabled Application Add-ins list; it is said the add-in is soft-disabled, because it’s disabled in a way, but actually not completely as it can still be loaded manually or programmatically (with other words: it can still be called explicitly). The Disabled Application Add-ins list only contains add-ins that caused the whole of Excel to crash, which makes the add-in a hard-disabled add-in. Hard-disabled add-ins cannot be loaded in any way (even if their LoadBehavior value would make you expect so) and are mentioned in HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Resiliency\DisabledItems. The location tells us the disablement of an add-in is always a per user “setting”. It’s also possible to force disablement of an add-in by causing a series of certain “unexpected” ends of the application during add-in’s activity. For example, the add-in we’re dealing with in this article gives an error at Excel’s startup. If we kill Excel (via Task Manager for example) while the error is appearing and we start Excel again, a dialog will pop up and ask you if you would like to disable the add-in (because Excel thinks the add-in caused Excel to crash, even if this is not true!). This is actually the only way to disable an add-in “by force”, because the precise value of a disabled add-in under the just mentioned DisabledItems key is unpredictable and is even different for every user. This makes it impossible to centrally manage the “hard-disablement” of add-ins…
Side note 2: this “User Settings” mechanism configures things at system level, so they can be pushed to user level. So it’s like user settings being saved at system level and pushed to every user, so the application actually uses those settings from user level instead of from system level. This mechanism thus affects every user on the system, but not all the time (more about that later)… There is also a way to permanently force all users on a system to load an add-in, i.e. by configuring “real” system settings. Those “real” system settings are not pushed to the user level, they really stay at the system level and are always valid, for everyone on the system. A few places exist for such “real” system settings related to add-ins; for Excel 2007 these are a few examples:
on 32 bit Windows:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Excel\Document Inspectors
on 64 bit Windows:
for 32 bit Office:
- HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\12.0\Excel\Document Inspectors
for 64 bit Office:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Excel\Document Inspectors
The “Addins” keys are for Excel and meant for whatever Excel version you will have installed now or later. The other keys are for Excel 2007 only and are only destined for add-ins of the “Document Inspector” type, which should always reside under this key, implying they are always defined at “pure” system level.
Anyway, what you don’t know yet is when exactly add-in information at the system level and defined under “User Settings” is copied to the user level (like for our “Load Test Report Addin” VSTO add-in for example). Well, under the key for the add-in (and within the “User Settings” hierarchy) we can see a DWORD called “count” (some add-ins use “count”, others use “Count”, but as this is case-insensitive, it doesn’t really matter).
If the key HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\User Settings\Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn) doesn’t exist when an Office 2007 application is started (Excel or another one), it is created and filled up with a DWORD “Count” with the same value as “count”. If the key already exists though, it all depends:
- the DWORD “Count” doesn’t exist: the DWORD is created, again with the same value as “count”
the DWORD “Count” does exist:
- but with a different value than “count”: “Count” gets the same value as “count”
- with the same value than “count”: nothing happens
With other words: the key and the DWORD “Count” are created or changed, except when they both exist and Count has the same value as count. For another add-in Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn is replaced by another name of course and “12.0” should be replaced by another version if we’re not talking about a 2007 add-in.
If the start of an Office application creates or changes Count (so it always gets the value of count), it also (re)configures the add-in at the real user level. In the case of our add-in this means HKCU\Software\Microsoft\Office\Excel\Addins\Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn is created if it doesn’t exist yet. Every named value that exists under the add-in’s key in the User Settings Create-hierarchy is created under this key (or overwritten if it already exists), also preserving other named values and keys possibly residing under HKCU\Software\Microsoft\Office\Excel\Addins\Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn). Otherwise nothing happens. This way new “default” values for add-ins at user level can be enforced: user settings for add-ins can be changed at system level (under User Settings), their “count” value is typically incremented by 1 and those settings are propagated at the real user level the next time a user starts an Office application of the right version. The propagation takes place because the user level’s Count doesn’t exist or is different from the new count value of an add-in under User Settings. All this is NOT the same as “real” system level settings: “real” system level settings are always enforced, while the “User Settings” mechanism sets new default values, but the user can override those settings till new default values are enforced.
So what is the solution to our problem?
So, if we want to make sure our add-in doesn’t get loaded anymore by Excel, we can do one of the following:
- Change LoadBehavior, so it doesn’t get loaded anymore at startup, but we still see it in the Inactive Application Add-ins list. The add-in can still be called manually or programmatically. I don’t know if the Load Test Report Addin can be used this way in Excel 2007, but if that’s the case, that could be another reason why the next option, well, isn’t really an option J We could give LoadBehavior a value of 0, meaning it’s never loaded, except manually or programmatically. Other values do the same, but contextually refer to a situation where the value had to be different ideally (for example, a value of 2 does the same as 0, but actually refers to the fact that LoadBehavior ideally had to be 3, so I guess 0 is the best and “most honest” value we can assign to LoadBehavior when we want to soft-disable it).
- Remove the whole add-in from the user’s registry hive, so deleting HKCU\Software\Microsoft\Office\Excel\Addins\Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn. This way the add-in doesn’t get loaded anymore at startup and we don’t see it in any list anymore.
Which one you prefer, is up to you. Choice number 1 shows us this add-in exists and is assigned, which can be nice to know. On the other hand it can be a good thing to remove every sign of things that don’t work on your system. Anyway, you can implement both ways through logon scripts, in a manual way (hmmm, not very interesting), group policy preferences,… I would certainly go for group policy preferences! J
But… things are more complex… What if a user starts an Office application for the first time? Yup, this means he/she doesn’t have a Count value for the add-in at user level, so the whole configuration of the add-in is copied to the user level and Excel will show the error when started (OK, later this will be fixed when group policies are applied again, but still…). It’s obvious we shouldn’t just control the configuration of the add-in at user level, but also that Count value, so every user has it and it is equal the add-in’s count value at the “User Settings system level”! Again, I would do this through group policy preferences.
Sight… But what if a user visits different systems? On system 1 there could be another count value than on system B. So we have to adapt the user level’s Count value for the add-in to the count value of the system the user is logging in to. Again this can be done through group policy preferences, but it’s obvious all this can become quite complex. Yes, yes, I know, keep that count value equal across systems, but
- It’s very difficult to keep them 100% equal; the smallest thing you do differently can influence the count value of an add-in, so it’s very risky to bet on equal count values across systems.
- Sometimes systems (even in a pool) get updates and maintenance in pieces. This means there can be temporary differences between systems
- Sometimes some systems need an update or maintenance, while others don’t need them (for whatever reason)
Of course you can always set those “system level” count named values to the same value (manually, script based, group policy preferences,…), but it’s again an extra step of administration…
The bottom line is we have to do the following:
- Control LoadBehavior at the user level through group policy preferences (or delete the whole key of the add-in at user level, depending on what you prefer)
- Control the Count value at the user level through group policy preferences, so it’s the same as the count value at the “User Settings system level”
- Optional: control the count value of the add-in under “User Settings” (system level) through group policy preferences, so it’s the same across all systems. This is an extra step, but it makes the previous step simpler.
But… sorry, it’s not over yet. No, I don’t think this is the perfect solution…
- Suppose an update occurs, the count value is incremented by 1 and you don’t have controlled the count value (what I just called optional). Bingo! The user starts an Office application, Count differs from count, the new configuration (with a LoadBehavior indicating a loading at startup) is copied to the user level again and the error shows up again… So we have to adapt our control over Count (and optionally count) to avoid this.
- Suppose you do control that count value, an update occurs, the count value is incremented by 1 and a little bit later group policies are applied (periodically or at boot time). The count value is brought back to the value you have put into the group policy preferences. No problem, right? Ok, but what if a user starts an Office application after the update but before the group policies are applied again? Indeed, Count differs from count, the new configuration (with a LoadBehavior indicating a loading at startup) is copied to the user level again and the error shows up again… You see, it’s still not completely water proof, right? What you can do to avoid this, is to keep everything tight: do a gpupdate or reboot immediately after an update to minimize the time range within this can occur. Also, keep users off your systems when doing updates. On the other hand this is not always easy: sometimes it can happen an update must be executed very urgently, even when users are present on the system. So you should have policies and procedures to minimize the chance a user still gets the error, but it’s not always easy to exclude the possibility for 100%.
- If you don’t want the add-in key deleted at the user level and an update occurs you might probably want to get the latest settings at the user level, even if you don’t really use the add-in (or only when loaded explicitly). When Count and count are always kept the same, this isn’t possible.
So, if you want to keep the add-in key at user level, another and better possibility is to control LoadBehavior at the user and the “User Settings system level”, without controlling Count (and possibly count). This way the propagation always takes place in a normal way, you only have to control 1 user and 1 system value instead of 2 user values and optionally a system value (meaning better performance and less administration overhead) and you will never get the error again if you keep an eye on my recommendations in point number 2.
Another good solution could have been to disable the add-in for every user. The whole User Settings mechanism can go its own way, everything stays up to date, there is no need to control the settings (not at user level and neither at system level), updates don’t override this disablement and still the add-in is visible, although obviously disabled. Except when you don’t users to see this add-in to have this status, this would be perfect. The problem is every user should force this add-in to be disabled manually (see the procedure I’ve explained to achieve this), as it’s not possible to really manage that, as the item that’s added to the registry is different for every user and isn’t predictable at all (AFAIK). So in practice you could definitely forget about this option, except perhaps (!) when you’re dealing with a small amount of users or have all very knowledgeable users in the house (I bet this is a very rare scenario J).
You could also delete a user’s add-in key at user level AND the add-in key at “User Settings system level”. This way every sign of the add-in is removed of the system (if you want it to be THAT clean). Again this can be done through group policy preferences or another mechanism. A colleague of mine, Kristof Baetens, even had another idea. Through group policy preferences (or another mechanism) we could delete the Create key of an add-in every time it shows up (for example, after an update). This way nobody would get the add-in settings again. Well, we could also add a Remove key for the add-in, so users with the add-in settings at user level will get those removed. This variant is better for performance as it doesn’t affect the possibly many users all the time, but on the other hand there is a drawback too: the removal doesn’t delete the whole user level key if it includes named values not defined at the “User Settings system level”, possibly leaving traces you don’t want to have in your users’ profiles. Also, you need to be very aware of the possible content of the Remove key, containing all kinds of named values that could have been popped up over time.
I must tell you one last thing. The “User Settings” mechanism adds the add-in configuration to the user level. But for VSTO add-ins, like Load Test Report Addin, there is also another piece that will be added to the user’s hive for Office 2007 (not 2010!). Take a look at these paths for Office 2007:
- for 32 bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn\Create\Software\Microsoft\VSTO\Security\Inclusion\7f16e2a0-bef2-46b6-b4f1-04e413c1e571
- for 64 bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\12.0\User Settings\Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn\Create\Software\Microsoft\VSTO\Security\Inclusion\7f16e2a0-bef2-46b6-b4f1-04e413c1e571
It’s obvious HKEY_CURRENT_USER\Software\Microsoft\VSTO\Security\Inclusion\7f16e2a0-bef2-46b6-b4f1-04e413c1e571 will be created if it doesn’t exist yet and it will be filled up or overwritten with the named values from one of those paths, preserving already existing other named values. Those are the named values typically residing there:
- PublicKey: this REG_SZ is the public key of the public-private key pair used to sign the add-in. The public key may be public, so it’s not a security hole we have just discovered here J
- Url: actually this REG_SZ is the path where the VSTO file can be found
If we want to clean up the add-in configuration at the user level, it’s a good idea to clean this up too. This means we have to control more through group policies than mentioned earlier. This could also be a good reason to just control LoadBehavior and not to delete everything about this add-in.
So, what’s the best solution? Well, there is no 1 ultimate answer. It all depends on what exactly you want. Personally I think disabling Load Test Report Addin is the best thing to do, but that’s not possible in a serious way. So, if we want to keep administration work as low as possible, performance impact again as low as possible, be able to get all the latest updates for the add-in and get all the latest settings at user level for the add-in, but still prevent the add-in from loading, while it’s still possible to load it explicitly, it’s best to do this:
- force LoadBehavior to get the value of 0 in HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\User Settings\Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn through group policy preferences
- force LoadBehavior to get the value of 0 in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\12.0\User Settings\Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn (or HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn) through group policy preferences
If you don’t want to make this add-in visible to your users at all (so it doesn’t appear in any list of Excel 2007) and you want to di it clean, you have to do this:
- delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\User Settings\Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn through group policy preferences
- delete HKEY_CURRENT_USER\Software\Microsoft\VSTO\Security\Inclusion\7f16e2a0-bef2-46b6-b4f1-04e413c1e571 through group policy preferences
- delete HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\12.0\User Settings\Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn (or HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\Microsoft.VisualStudio.QualityTools.LoadTestExcelAddIn) through group policy preferences
If you want some other special solutions, please read the whole article for every possible solution and adapt it a little bit if you want to achieve something similar for another version or add-in. For completeness, HKEY_CURRENT_USER\Software\Microsoft\VSTO\Security\Inclusion represents the so-called Inclusion List of VSTO 3.0 (which is used for Office 2007). Every key in this list has a GUID as the name and represents a VSTO add-in. More information about this concept, which has disappeared in VSTO 4.0 (for Office 2010), can be found dat http://blogs.msdn.com/b/mshneer/archive/2008/04/24/deploying-your-vsto-add-in-to-all-users-part-iii.aspx.
This post was a very long one, despite dealing with only a small problem and solution. But there is a lot of background information, needed to fully understand what you’re doing. I hope it was worth informing you of all this.