lessons we have learnt about office integration

Lesson 1: trust it

Everything could cause problem. There is no API could be really stable. Even it is stable itself, the interop and version difference or mis-use could cause problems as well.

Lesson 2: rely on 3rd party vendor

Add-in express is causing lots of troubles. Should be no feature rely on some solo 3rd party vendor, at least we need some backup plan.

Lesson 3: not taking resource management into consideration at the very beginning

COM requires you to manage the resource. It can cause the outlook won't quit, or powerpoint crash sometime if you leave it uncared. Actually, pool might be a good option.

Lesson 4: not wrapping the api

Using the raw api directly is dangerous. Not only because it could be too low-level, and also you lose the chance to change the api you use, because there is no way to change the api, becaue they are COM and closed sourced. Also, not wrapping it means you need to startup the real office application to test your addin.

Lesson 5: using office api in multi threading code

massing with multi threading and office api could cause problem as well. As it is not designed to be called from thread other than the primary gui thread.

Lesson 6: going into in-process addin model too early

being a addin means you can have consistent life cycle with the office application you are integrating with. But if we only want to use office in some part not the whole application, we probably should not adopt the addin model too early.

Lesson 7: integrate too much

sometimes, we are integrating too much. When user talk about using excel user defined function, it could be just use that to input a formula, but not necessarily pulling the data or doing the calculation. And popping up a separate window or putting the window beside outlook window could be a lot easier than using form region or outlook customized form.

Lesson 8: not taking deployment and version difference into consideration

deployment of addin could be very hard, and addin written in VSTO is even harder. Think about it, all the time. The version of office could be problem as well. Such as outlook 2007 can not use WCF to seralize the IList but 2003 can.

Lesson 9: annoying the end-user

slowing down the outlook startup. flash a window when excel launches. popping up error message box when editing tables in powerpoint. or flash and slows opening up the email composer in outlook for one second. All those kinds of things are not acceptable. Whatever our application is doing, should not annoy the end-user.

Lesson 10: mixing hacking code with rest of production code

It is the reality of life, we have to hack using COM, C++, win32 api or anything that works to get things done when working with office. But mixing the hacking code with other production code is really a bad idea. We need to build a layer to wrap the office api, and locking all the monsters there.

Lesson 11: expose .NET win form control as ActiveX and embed in outlook form or form region

It is just unstable, and with limited security permission.

----

The projects I have worked on with office product include:

a excel addin along with udf for pulling series data from energy server

a powerpoint addin for analyst doing prototype & storyboarding better (www.viprototype.com)

a outlook 2007 PoC project to demonstrate its extending potentials

a crm project with tight outlook integration also can export meeting details to word to print.