Support for Outlook 2003 and Outlook2007 in same assembly   

Hi there,

I have written an AddIn for Outlook 2003 and upgraded it to Outlook 2007.
As I am working with different versions of Office assemblies I need to 
compile with references to one or the other set.

However, the code I wrote actually does not need to change (in this case, of 
course, if I were accessing version dependent features, like ribbons, this 
would not hold).

This leads me to the following interesting question.
Can I template away my business logic into a library that does not depend on 
the version of the Office assemblies, (maybe does not depend on those 
assemblies at all) and place the dependent code into two separate projects, 
one created with the Outlook 2003 Add-In project template, and the other 
with the Outlook 2007 Add-In project?
I would like to have this benefit so that I can maintain all my business 
logic in one place.

My natural candidate was generics.
I defined my Application, Explorer, CommandBar, CommandBarButton etc types - 
which exist in both Office assemblie sets, but the list went on and there 
are of course classes that need to be defined with constraints - as they are 
required to have methods such as "ActiveExplorer" for Application, etc.
So, this was dragging me in the direction, of demanding that each AddIn 
define a hierarchy of interfaces, mimicking those in Office and implementing 
them with the appropriate version of Office assemblies.
Yach!

Can anyone think of a better solution, or do I am I doomed to maintaining 
two separate AddIns duplicating most of the code.

Is there no Design Pattern for this - something like Dependency Injection ?

Thanks !

David

date: Sat, 9 Aug 2008 03:13:57 +0300   author:   David Sackstein

Re: Support for Outlook 2003 and Outlook2007 in same assembly   

The rule of thumb is to develop using references to the oldest version of 
Outlook you plan to support and to use late binding (reflection) to use 
properties or methods exposed in later versions if you detect the later 
version at runtime.

I sometimes use a subsidiary dll compiled under Outlook 2007 for certain 
things or events for Outlook 2007 that I load using LoadLibrary and then 
work with the exposed interface of the subsidiary dll for those things.

Reflection is expensive in CPU cycles, so use it only when necessary.

-- 
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"David Sackstein"  wrote in message 
news:OF9SUTb%23IHA.4156@TK2MSFTNGP02.phx.gbl...
> Hi there,
>
> I have written an AddIn for Outlook 2003 and upgraded it to Outlook 2007.
> As I am working with different versions of Office assemblies I need to 
> compile with references to one or the other set.
>
> However, the code I wrote actually does not need to change (in this case, 
> of course, if I were accessing version dependent features, like ribbons, 
> this would not hold).
>
> This leads me to the following interesting question.
> Can I template away my business logic into a library that does not depend 
> on the version of the Office assemblies, (maybe does not depend on those 
> assemblies at all) and place the dependent code into two separate 
> projects, one created with the Outlook 2003 Add-In project template, and 
> the other with the Outlook 2007 Add-In project?
> I would like to have this benefit so that I can maintain all my business 
> logic in one place.
>
> My natural candidate was generics.
> I defined my Application, Explorer, CommandBar, CommandBarButton etc 
> types - which exist in both Office assemblie sets, but the list went on 
> and there are of course classes that need to be defined with constraints - 
> as they are required to have methods such as "ActiveExplorer" for 
> Application, etc.
> So, this was dragging me in the direction, of demanding that each AddIn 
> define a hierarchy of interfaces, mimicking those in Office and 
> implementing them with the appropriate version of Office assemblies.
> Yach!
>
> Can anyone think of a better solution, or do I am I doomed to maintaining 
> two separate AddIns duplicating most of the code.
>
> Is there no Design Pattern for this - something like Dependency Injection 
> ?
>
> Thanks !
>
> David
>
>

date: Thu, 14 Aug 2008 16:17:23 -0400   author:   Ken Slovak - [MVP - Outlook]

Re: Support for Outlook 2003 and Outlook2007 in same assembly   

Hi Ken,
Thanks for the tip - the one I feared most.
I still wonder, why somewhere between strong-named assemblies, unique 
namespace qualification and generics, .Net would not somehow allow me to 
write at least common parts of the code once without resorting to late 
binding.
Thinking about features that might be considered for future development, I 
am also wondering how I could define what I am looking for so that it would 
require some small extension to the framework and not violate any existing 
design principles.
Do you have any pointers to thoughts on that?
But, I understand this isnt appropriate for this forum...
Thanks anyway
David

"Ken Slovak - [MVP - Outlook]"  wrote in message 
news:unKLHrk$IHA.4740@TK2MSFTNGP03.phx.gbl...
> The rule of thumb is to develop using references to the oldest version of 
> Outlook you plan to support and to use late binding (reflection) to use 
> properties or methods exposed in later versions if you detect the later 
> version at runtime.
>
> I sometimes use a subsidiary dll compiled under Outlook 2007 for certain 
> things or events for Outlook 2007 that I load using LoadLibrary and then 
> work with the exposed interface of the subsidiary dll for those things.
>
> Reflection is expensive in CPU cycles, so use it only when necessary.
>
> -- 
> Ken Slovak
> [MVP - Outlook]
> http://www.slovaktech.com
> Author: Professional Programming Outlook 2007.
> Reminder Manager, Extended Reminders, Attachment Options.
> http://www.slovaktech.com/products.htm
>
>
> "David Sackstein"  wrote in message 
> news:OF9SUTb%23IHA.4156@TK2MSFTNGP02.phx.gbl...
>> Hi there,
>>
>> I have written an AddIn for Outlook 2003 and upgraded it to Outlook 2007.
>> As I am working with different versions of Office assemblies I need to 
>> compile with references to one or the other set.
>>
>> However, the code I wrote actually does not need to change (in this case, 
>> of course, if I were accessing version dependent features, like ribbons, 
>> this would not hold).
>>
>> This leads me to the following interesting question.
>> Can I template away my business logic into a library that does not depend 
>> on the version of the Office assemblies, (maybe does not depend on those 
>> assemblies at all) and place the dependent code into two separate 
>> projects, one created with the Outlook 2003 Add-In project template, and 
>> the other with the Outlook 2007 Add-In project?
>> I would like to have this benefit so that I can maintain all my business 
>> logic in one place.
>>
>> My natural candidate was generics.
>> I defined my Application, Explorer, CommandBar, CommandBarButton etc 
>> types - which exist in both Office assemblie sets, but the list went on 
>> and there are of course classes that need to be defined with 
>> constraints - as they are required to have methods such as 
>> "ActiveExplorer" for Application, etc.
>> So, this was dragging me in the direction, of demanding that each AddIn 
>> define a hierarchy of interfaces, mimicking those in Office and 
>> implementing them with the appropriate version of Office assemblies.
>> Yach!
>>
>> Can anyone think of a better solution, or do I am I doomed to maintaining 
>> two separate AddIns duplicating most of the code.
>>
>> Is there no Design Pattern for this - something like Dependency Injection 
>> ?
>>
>> Thanks !
>>
>> David
>>
>>
>

date: Thu, 14 Aug 2008 23:55:01 +0300   author:   David Sackstein

Re: Support for Outlook 2003 and Outlook2007 in same assembly   

My working model, in both managed and unmanaged code is to only use those 
properties, methods and events available in the oldest version of Outlook 
I'm targeting.

I almost always use the Redemption library in my code and that gives me 
access to just about everything that's exposed in later versions anyway. I 
rarely use a subsidiary DLL.

For things like ribbon support if I'm developing using older Outlook/Office 
references I use the XLIRibbonExtensibility.tlb from XL-Dennis (Dennis 
Wallentin) to provide ribbon support.

I write using the Outlook 2000 reference and can still do everything or more 
that I could do using the Outlook 2007 reference other than form regions or 
custom task panes.

That works for me, but it's not VSTO. For VSTO projects I limit them to 
supporting only what's available.

-- 
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"David Sackstein"  wrote in message 
news:euqzJAl$IHA.5192@TK2MSFTNGP04.phx.gbl...
> Hi Ken,
> Thanks for the tip - the one I feared most.
> I still wonder, why somewhere between strong-named assemblies, unique 
> namespace qualification and generics, .Net would not somehow allow me to 
> write at least common parts of the code once without resorting to late 
> binding.
> Thinking about features that might be considered for future development, I 
> am also wondering how I could define what I am looking for so that it 
> would require some small extension to the framework and not violate any 
> existing design principles.
> Do you have any pointers to thoughts on that?
> But, I understand this isnt appropriate for this forum...
> Thanks anyway
> David

date: Fri, 15 Aug 2008 10:56:06 -0400   author:   Ken Slovak - [MVP - Outlook]