none
Outlook Add-in becomes Inactive randomly RRS feed

  • Question

  • Hi

    We have created a VSTO Add-in for Outlook.  The add-in is intended as a plugin so that the other third parties can write their own "providers" that our addin can utilize.  As an example the add-in shows a grid of Items.  Anybody can write a "provider" and display their own items in our grid.

    To do this our add-in in made up of a three projects. core , common and library. The Library contains the public interfaces.

    At run time the add-in uses MEF to load any provider assemblies.

    This has been working quite successfully at numerous client sites with many users for some time.  However last month a client reported that when they start Outlook the Add-in was going inactive.  No attempts to re-active it would work it always went back to inactive.

    We turned on VSTO_SUPRESSDISPLAYALERTS and found that the issue seemed to be because the assemblies were not being loaded when the Add-in initialized.

    Checking the assemblies that were being dynamically loaded we found that two of them were unsigned.  We subsequently signed the assemblies, re-applied and everything worked.

    So far so good.  We patted ourselves on the back and made the assumption that some MS security Patch had been applied that stopped unsigned assemblies from being loaded at run time.

    We could not however replicate the issue in house , not could we find the patch that might have caused the issue.

    The problem however continues....

    Our installations team took a draconian approach to this issue and started installing the signed assemblies on all our customer sites regardless of whether or not they had the original issue.

    For most clients everything was fine.  The add-in worked with or without the signed assemblies.  However at one client site on a number of users pc's the add-in was still inactive.  removing the signed assemblies and putting back the unsigned assemblies resolved the issue.  To say this is weird is an understatement. The complete opposite behavior.

    Now this week they have reported another user has suddenly found the add-in is inactive and using neither the signed nor unsigned assemblies works.

    We are at a complete loss what to look for next.

    To summarize.

    • Our add-in dynamically loads assemblies at run time using MEF
    • It was working fine at all sites until recently.
    • Add-in randomly becomes inactive and cannot be re-activated either manually or through the registry.
    • Signing the Assemblies works at most sites
    • At one site unsigned assemblies work and signed assemblies do not
    • At the same site one user reports neither set of assemblies will activate.
    • We have run Caspol and cannot see anything amiss
    • We have used Caspol to apply Full Trust - no affect
    • We can not replicate in house

    Things we are trying

    • Machine comparisons between working and non working pc's
    • Removal of all other add-ins

      If anyone has any other suggestions what could be causing such behavior it would be much appreciated.

    Nick


    Tuesday, March 31, 2015 8:22 AM

Answers

  • Hello Nick,

    I do not believe the issue depends on the signed/unsigned assemblies. Check out the Trust center settings to make sure that Macro security settings are not applied to add-ins. Also pay special attention to the Trusted Publishers list.

    Anyway, Microsoft Office applications can disable add-ins that behave unexpectedly. If an application does not load your add-in, the application might have hard disabled or soft disabled your add-in.

    Hard disabling can occur when an add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your add-in is executing.

    Soft disabling can occur when an add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable an add-in if it throws an unhandled exception while the Startup event handler is executing.

    When you re-enable a soft-disabled add-in, the application immediately attempts to load the add-in. If the problem that initially caused the application to soft disable the add-in has not been fixed, the application will soft disable the add-in again.

    You can read more about that in the How to: Re-enable an Add-in That Has Been Disabled article in MSDN. Most probably the add-in fires an exception at runtime and Outlook disables the add-in silently.

    Also pay special attention to the Performance criteria for keeping add-ins enabled . Outlook 2013 monitors add-in performance metrics such as add-in startup, shutdown, folder switch, item open, and invoke frequency. Outlook records the elapsed time in milliseconds for each performance monitoring metric.

    For example, the startup metric measures the time required by each connected add-in during Outlook startup. Outlook then computes the median startup time over 5 successive iterations. If the median startup time exceeds 1000 milliseconds (1 second), then Outlook disables the add-in and displays a notification to the user that an add-in has been disabled. The user has the option of always enabling the add-in, in which case Outlook will not disable the add-in even if the add-in exceeds the 1000 millisecond performance threshold

    Tuesday, March 31, 2015 9:20 AM
  • Hi

    I thought it best to put the solution to the problem. Now we have found it.

    The problem was always that we could not replicate the issue and hence as the issue was on the client site we could not use Visual Studio to debug.

    However we managed to convince one of our clients to convert a broken machine into a VM and give it to us.  VM in hand we were able to install Visual Studio and debug the problem.

    It turned out the issue was nothing to do with signed dll's or security policies or updates.

    As part of the add-in were were writing user preferences such as Grid and Column sizes to isolated storage.  The routine that did this was writing it out on an Assembly by assembly basis not a user basis. So the preference XML was being stored in Program Data not AppData.

    It appeared that on some client sites the preference XML files were becoming corrupt or were blank and there was not TRY CATCH around the code that loaded them in. Hence an exception was thrown and the  Add-in was disabled.

    We were fooled by signing the DLL's because this caused it to create a new folder in isolated storage without corrupt file, causing the add-in to load without issue.

    So we spent weeks looking for policies and updates when the actual problem was simply we had no Try Catch around a really simple bit of code.

    Moral of the story...don't jump to conclusions.


    Friday, May 1, 2015 1:51 PM

All replies

  • Hello Nick,

    I do not believe the issue depends on the signed/unsigned assemblies. Check out the Trust center settings to make sure that Macro security settings are not applied to add-ins. Also pay special attention to the Trusted Publishers list.

    Anyway, Microsoft Office applications can disable add-ins that behave unexpectedly. If an application does not load your add-in, the application might have hard disabled or soft disabled your add-in.

    Hard disabling can occur when an add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your add-in is executing.

    Soft disabling can occur when an add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable an add-in if it throws an unhandled exception while the Startup event handler is executing.

    When you re-enable a soft-disabled add-in, the application immediately attempts to load the add-in. If the problem that initially caused the application to soft disable the add-in has not been fixed, the application will soft disable the add-in again.

    You can read more about that in the How to: Re-enable an Add-in That Has Been Disabled article in MSDN. Most probably the add-in fires an exception at runtime and Outlook disables the add-in silently.

    Also pay special attention to the Performance criteria for keeping add-ins enabled . Outlook 2013 monitors add-in performance metrics such as add-in startup, shutdown, folder switch, item open, and invoke frequency. Outlook records the elapsed time in milliseconds for each performance monitoring metric.

    For example, the startup metric measures the time required by each connected add-in during Outlook startup. Outlook then computes the median startup time over 5 successive iterations. If the median startup time exceeds 1000 milliseconds (1 second), then Outlook disables the add-in and displays a notification to the user that an add-in has been disabled. The user has the option of always enabling the add-in, in which case Outlook will not disable the add-in even if the add-in exceeds the 1000 millisecond performance threshold

    Tuesday, March 31, 2015 9:20 AM
  • Hi

    Thanks for the reply.

    The Trust settings in Outlook all appear to be ok. It is not an issue to do with it being slow to load as we have debugged the add-in to the composition factory where it is dynamically loading the assemblies.

    It is an unhandled exception causing it to become inactive but the exception is caused because it cannot load the assembly.

    We are going to do some more debug today so I will post the code where we are getting the problem but it does feel like either some kind of security patch , group policy or other outside factor.

    I did read somewhere that other add-ins in written in .net 1.1 or vb6 with .net components can cause VSTo add-ins not to load???

    Nick

    Tuesday, March 31, 2015 8:06 PM
  • Nick,

    You are right, see COM Addins / VSTO Addins Do not load no matter what I do... pls help for more information. But I don't think that is the case. Try to disable all other add-ins and check out the Outlook.exe.config file for statements described in the How to: Use an Application Configuration File to Target a .NET Framework Version  article in MSDN.

    If you have got any antivirus software installed on the problematic PC, make sure that latest updates are installed. It may block the add-in from loading.

    In general, I'd suggest going through the steps described in the Troubleshooting COM Add-In load failures article. 

    Tuesday, March 31, 2015 9:28 PM
  • Hi

    I thought it best to put the solution to the problem. Now we have found it.

    The problem was always that we could not replicate the issue and hence as the issue was on the client site we could not use Visual Studio to debug.

    However we managed to convince one of our clients to convert a broken machine into a VM and give it to us.  VM in hand we were able to install Visual Studio and debug the problem.

    It turned out the issue was nothing to do with signed dll's or security policies or updates.

    As part of the add-in were were writing user preferences such as Grid and Column sizes to isolated storage.  The routine that did this was writing it out on an Assembly by assembly basis not a user basis. So the preference XML was being stored in Program Data not AppData.

    It appeared that on some client sites the preference XML files were becoming corrupt or were blank and there was not TRY CATCH around the code that loaded them in. Hence an exception was thrown and the  Add-in was disabled.

    We were fooled by signing the DLL's because this caused it to create a new folder in isolated storage without corrupt file, causing the add-in to load without issue.

    So we spent weeks looking for policies and updates when the actual problem was simply we had no Try Catch around a really simple bit of code.

    Moral of the story...don't jump to conclusions.


    Friday, May 1, 2015 1:51 PM