If you’ve read my last article What’s new in Outlook 2013 for developers, you would’ve seen I mentioned that Outlook 2013 has become a lot stricter when checking add-in performance for such metrics as add-in start-up, shutdown, item open and folder switching.
If you do have a few misbehaving plug-ins, you might also have seen this new information bar when starting Outlook 2013 “A problem was detected with an add-in and it has been disabled”.
Clicking on the “View Disabled Add-ins…” button shows you a form with all the slow add-ins as well as exactly how slow each add-in was with a Red Bar of Slowness: “These add-ins decreased performance or caused Outlook to start slowly”.
Speaking for myself, I would not like this to happen to my Outlook add-ins. It does not help your users’ confidence in your plug-in if they see this horrible red bar and realise just how much time your add-in took from their lives, by having to wait for it to perform its function.
The new Outlook performance monitoring criteria include:
- Add-in Start-up = 1000 milliseconds
- Add-in Shutdown = 500 milliseconds
- Folder switch = 500 milliseconds
- Item open = 500 milliseconds
Outlook does give each add-in a fair chance, however, by using the average start up time over five consecutive iterations i.e. If your add-in misbehaves and on average takes longer than one second to load, Outlook will disable it and show the user a notification with which they can choose to always enable the add-in or keep it disabled… just imaging those support calls! The same goes for the other criteria, your Outlook plug-in gets five strikes and it’s out.
So let’s have a look at how you can avoid the dreaded Red Bar of Slowness and “A problem was detected with an add-in…” in Outlook 2013:
- This add-in caused Outlook to start slowly
- This add-in caused Outlook to close slowly
- This add-in caused Outlook to switch folders slowly
- This add-in caused Outlook to open items slowly
Slow start-up: This add-in caused Outlook to start slowly
The AddinInitialize is a tempting place to put code that checks for numerous things e.g. licensing, trial expiration etc. It is a good idea to defer long running processes to another part of your add-in to avoid it being disabled by Outlook 2013′s strict policies.
If you are not using any Outlook objects you can always kick off a background thread to do the work for you. This is ideal for situations where you’d want to call a web service to check the users’ license etc. However, be aware that any background thread in your add-in does incur some overhead and it is absolutely NOT a good idea to access the Outlook object model from any thread other than the main thread. Andrei wrote a good article about this – On using threads in managed Office extensions, if you need more information about this challenge.
I do have some good news. From version 7 of the Add-in Express Loader, your add-in is loaded on demand rather than on Outlook start-up, this allows your plugin to bypass the most critical criteria on the add-in’s loading time. The add-in will be loaded by the loader on first call of such methods as GetCustomUI.
This was done as part of our continuation of a trend to optimize the add-in’s performance, and just another reason why I always say that Add-in Express got your back when it comes to Office extensions.
Slow shutdown: This add-in caused Outlook to close slowly
In Outlook 2013, you have 500 milliseconds to completely shut down your add-in. That’s half a second! As with the start-up event, Outlook calculates the average of 5 successive shutdowns of your addin and if it’s not happy, it will disable your plug-in the next time the user starts Outlook.
Folder Switch: This add-in caused Outlook to switch folders slowly
Even though we have your back with Office extensions, we can’t keep you from optimizing your managed code. As with any type of development, you have to keep all scenarios in mind when you decide to take a specific approach.
You need to be careful with the BeforeFolderSwitch and FolderSwitch events, as there are few things as frustrating to a user as having to wait for Outlook to switch to another folder, from the user’s perspective this should occur instantaneously. So, as a general rule if I need to write logic when the user switches between folders, I hold off on making any long network or database calls. MSDN also suggests you rather cache data locally.
ItemOpen: This add-in caused Outlook to open items slowly
Here we’re talking about the Open event on an item, and we also only have half a second before Outlook starts getting angry with us.
Again, use some creative and sensible thinking and try not to incur a lot of overhead when the user opens an Outlook item. Also, be aware that all calls to the Outlook object model happen on the main thread and that in Outlook 2013 any calls made to its object model from any other thread than the main thread, might throw a horrible E_RPC_WRONG_THREAD exception. Again, just imagine those support calls!
Don’t panic – the add-in slow performance issues can be solved!
Ok, so, we’ve seen that Outlook 2013 is even more strict that Outlook 2010 when it comes to add-in performance. Believe it or not, this is a good thing and your users will thank you for it.
As I mentioned earlier, Add-in Express has already coped with the most critical and most frequent one – add-ins’ slow start. The improved Add-in Express Loader will keep your plug-ins save from causing Outlook to start slowly and they will never end up in the “Disabled Items list”. I must say the enhanced loader is pretty spectacular, no matter what I did, I could not get Outlook to show the “Red bar of slowness” with an Add-in Express based add-in, I had to create a VSTO add-in for the screenshots :)
The other challenges (FolderSwitch and ItemOpen) can also be bypassed by keeping a level head and approaching things a bit differently.
No-one said Office development is easy, but with a little bit of common sense and support from your friendly Add-in Express team, you don’t need to worry.
Thank you for reading. Until next time, keep coding!