AddInSpy - Diagnosing/Troubleshooting Office Add-ins
AddInSpy is a new diagnostic tool for reporting the maximum possible information about all Office add-ins registered on a machine. This is a free (unsupported) download, available on MSDN Code Gallery here. Covering article on MSDN here.
In fact, there are 2 tools: AddInSpy, which is a WPF GUI application, and AS, which is a scriptable console application. They both use the same scanning engine, so results are identical. Both tools allow you to produce an XML report of add-ins, and AddInSpy additionally displays the scan results in a convenient grid.
The tool discovers and reports a lot more information than is available through the Office UI natively, and will report on all registered add-ins, for all Office client applications that support COM add-ins, that is: Access, Excel, FrontPage, InfoPath, Outlook, PowerPoint, Project, Publisher, SharePoint Designer, Visio and Word. The tool covers native add-ins, managed shared add-ins and VSTO add-ins. It does not report on other extensions (Smart Tags, automation add-ins, and the like). The reported information includes the following:
ú The type of each add-in: VSTO, managed non-VSTO, native.
ú FriendlyName, ProgID, CLSID and LoadBehavior of the add-in.
ú For managed add-ins, the manifest path, assembly path, and assembly strongname, and the CLR version the add-in was built against.
ú The registry hive (HKCU or HKLM) where the add-in is registered.
ú For VSTO add-ins, the VSTO runtime version used by the add-in.
ú Installed date, and publish version, where applicable.
ú Which extensibility interfaces the add-in implements (IRibbonExtensibility, ICustomTaskPaneConsumer, FormRegionStartup, IBlogExtensibility, IBlogPictureExtensibility, EncryptionProvider, SignatureProvider or IDocumentInspector).
ú Whether the add-in uses any of the VSTO wrappers for Ribbon, custom taskpane, or custom form region.
ú Whether the add-in exposes itself for automation through the COMAddIns collection of the host application.
ú Whether the host application is running, and whether the add-in is loaded.
ú Whether the add-in is in the disabled items list (aka “blacklist”) for the current user, for each selected Office host application.
ú Context information: machine name, user/domain name, OS details, VSTO environment variables.
Both AddInSpy and AS support comprehensive configuration, allowing you to specify what type of scan to perform, and what types of data to include in the report. AddInSpy reports are configurable via the UI, whereas AS reports are configurable via command-line switches. Here’s a screenshot of the main AddInSpy window (made small so it fits on this blog):
You can also drill down on individual add-ins if you want, and get a dialog with the data for just one add-in of interest:
Note: this tool is a work in progress. Please download it, use it, and send me feedback. You can provide feedback (and report any bugs) on the Code Gallery site for the tool, or by posting comments to this blog post. Give it a work-out, and let me know what you think.
Comments
- Anonymous
October 01, 2008
PingBack from http://xldennis.wordpress.com/2008/10/01/addinspy-the-missing-diagnostic-tool/ - Anonymous
October 01, 2008
Hi Andrew,The tool looks very promising and so far I like what I see. Kudos to You and other who areinvolved in the project!The only objection I have, at this stage, is the word "spy" in the name.Kind regards,Dennis - Anonymous
October 02, 2008
If you missed the announcement on the VSTO Developer Portal , the team released a tool called AddInSpy - Anonymous
October 03, 2008
The comment has been removed - Anonymous
October 03, 2008
Nicholas - unfortunately, the source-code is not available at this time. However, the downloadable zip of the binaries includes just 4 files - if you only want the AS tool, then you only need 2 files: AS.exe and AddInScanEngine.dll. There's no setup required, so you can simply copy these files to wherever you need them. - Anonymous
October 08, 2008
I tried to run AddIn Spy on a machine with german XP/SP2, VS 2008 and VSTO-Runtimes - when double clicking the exe there's a hourglass for a second, it pops up in the process list in task manager, but then disapears without showing a window or any error messages. Any idea? - Anonymous
October 09, 2008
HJB - thanks for your feedback. Unfortunately, while this first release of AddInSpy is technically localizable, it is not localized. I only built an ENU version, and only tested ENU.Supporting other locales is on my todo-list, but I don't know when I'll get the time to add that support. - Anonymous
March 02, 2009
Thank you for producing this useful program.How is the value of the 'Exposed' tag derived?How can it be false if Loaded and Running are true?Your answer would help me resolve an issue where my Add-in works on one PC but not another. The only significant difference in the output produced by your valuable program is the value of the Exposed tag - it's true on the working PC and false on the other.Thanks again. - Anonymous
March 03, 2009
Martin - the 'Exposed' field indicates whether or not the add-in exposes itself for automation through the COMAddIns collection of the Office host application. Most add-ins do not do this. If this is True on one machine, it should be True on all machines - it is unlikely that the add-in exposes itself conditionally. So, if AddInSpy thinks it does NOT expose itself on some machines and not others, then there's a bug somewhere (possibly in the add-in) - most likely it is throwing an exception which the host is silently swallowing. You should debug this: set breakpoints on the Startup (or OnConnection) code in the add-in, and then load/unload it via the Office UI to see where it is failing. - Anonymous
March 13, 2009
Thank you, Andrew, for replying to my question.I realise that I'm taking a bit of a liberty using your blog for this type of query but, if you can help, I'd be very grateful.To try and identify whether an exception is being thrown, I added diagnostic messages to the initialization and startup functions in both ThisAddIn.cs and ThisAddIn.Designer.cs - including the constructor.I also added try/catch to my ThisAddIn_Startup and RequestComAddInAutomationService functions.On the good PC's, the diagnostics are shown as expected.On the 'bad' PC (where Exposed is false), no diagnostic messages are shown at all. In other words, the body of the ThisAddin constructor is not entered. So either the object is not constructed at all or the exception occurs in the construction of the base class - Microsoft.Office.Tools.AddIn.Another observation about the 'bad' PC - Using VBA, I can see the add-in in the COMAddIns collection, the GUID is filled in but the Object property is null.Other relevant facts - all PC's are XP Pro SP2 using Excel 2003 SP3. Addin has been built using VS2008 and VSTO 2005 SE. LoadBehavior is 3. - Anonymous
March 13, 2009
Martin - this is mysterious. If the add-in is getting loaded (which it is, if you can see it in the COMAddIns collection from VBA, and the LoadBehavior value remains at 3), then the ThisAddIn ctor and ThisAddIn_Startup should get called. Apart from the non-exposure of the automation object, is the rest of the add-in functional?Also, can you run the VSTO Troubleshooter over both good and bad machines to see if you can identify any differences, or any issues with the bad machine? You can get this from the VSTO Power Tools here: http://www.microsoft.com/downloads/details.aspx?FamilyId=46B6BF86-E35D-4870-B214-4D7B72B02BF9&displaylang=en - Anonymous
May 10, 2009
Hi Andrew,Martin Wills seems to have the same problem we are experiencing (Addin loaded and running but not exposed and only on some machines) did you get any feedback as to whether he solved this problem or not ?regardsPaul - Anonymous
May 11, 2009
Paul - no, I didn't hear anything more from Martin. - Anonymous
May 16, 2009
It's taken some time and much agony but, 2 months later, I think I've now made some progress.Office, VSTO, Visual Studio, Installer and Security weave a tangled web. Every now and then you think you see a way through but then another strand trips you up.Basically it boils down to Security and the need for the Add-In to have Full Trust.I had already incorporated the SetSecurity Custom Action (see http://msdn.microsoft.com/en-us/library/bb332051.aspx etc).I put in diagnostics to log the Caspol commands and their results and all seemed well. Still the AddIn was not exposed.Eventually, it transpired that the Installer was running the Custom Actions under the System account. So SetSecurity was setting user-level policies but for the wrong user!!!I don't understand why it happens on some PC's and not others. I also believe that it's connected to a change in installs generated by VS2008 (not 2005) that causes this.Anyway, I considered making it a requirement that the AddIn was installed by an administrator for all users since that would set a machine-level security policy. But since the AddIn is registered for Excel under HKCU that doesn't work.So my solution was to enhance the SetSecurity and CaspolSecurityPolicyCreator code to generate a .CMD file containing the Caspol commands which were executed and leave that in the user's folder.So, if the addin doesn't work, (s)he just runs the command file under his/her user name.But the message, Andrew, for your AddInSpy program is to check explicitly for the lack of Full Trust so that you can point the user in the right direction.Other gotcha's encountered(1) VS-generated installs won't install in the user's chosen directory if they are not an admin. You need to modify the .msi file and add some values to SecureCustomProperties.(2) The supplied SetSecurity code doesn't work if you have a dependent assembly which must also be fully trusted. You can put in 2 calls of SetSecurity in your Custom Actions but then st it doesn't uninstall or rollback properly. I can explain more if needed. But I enhanced the SetSecurity code so that it could handle more than one DLL to be put in the same security group.(3) The fact that the installer runs the custom actions under the sytem account seems to be related to the setting of the NoImpersonate flag in the CustomAction record in the msi file. VS2008 always sets this flag in order that the install works under Vista. I did try clearing this flag in the msi file. When I ran the install on an XP achine for a non-admin I got a message about the install not being allowed dur to the system administrator's policy.Overall, I have learned a lot more than I think I should have to know.I do still have a lot of respect for Microsoft Developer products but a little less admiration for their seamless integration.And in case, the message has been lost ...Do check that the security policy for the AddIn has been registered under the correct user.Martin - Anonymous
May 21, 2009
Martin - thanks very much for your comments, and for taking the time to bottom out the issues and report feedback.Just to clarify, the technique you mention (and the MSDN article you reference) relate to VSTO v2, which was the last version of VSTO to use persisted CAS policy. VSTO v3 onwards uses a different security mechanism that is more closely aligned with standard Office security, and does not use the CAS repository.The article was always intended only as a starting point, to show how developers could customize their VSTO v2 deployments. We recognize that, as a starting point, it has obvious limitations - some of which you have identified. It would be very useful if you could post your feedback as a comment to the article itself - that way, your findings will be available to anyone else who needs to use this approach.Note that even with VSTO v3, it is still possible for developers to customize the deployment experience (using MSI instead of ClickOnce), and an article that describes how to get started with this for v3 is here: http://code.msdn.microsoft.com/VSTO3MSI.Re AddInSpy - I'll certainly add your suggestion to the list of features that folks have requested for future versions.Thanks againAndrew