Manage Muliple Office Versions on one Dev. Machine

StLi

Hi,

I'm working for a Solution center that supports multiple Companies with different Versions of NAV and different Version of MS Office on their Terminals.

We already have a custom-made solution to manage all the different Builts of NAV on each Developers machine, which is also tricky, but solved - so don't worry about that.

My current issue is at the MS Office Level: I recently got my old dev manchine replaced with the newest version Office pre installed (2013)
Now i have to realize a change request on a Customers Database that still uses Office 2010. With that CR, i have to change some functions that use Outlook to send a Mail.

The Problem is: The Automation variable on the Customers Database Refers to 'Microsoft Outlook 12.0 Object Library'.Application
On my new Dev. Machine there is only 'Microsoft Outlook 15.0 Object Library'.Application available

So when i want to compile, the Development Client start complaining.

I'm aware that there are "easy-to-do-once" workarounds available for me.
- I could just replace the Automation, Deploy the Codeunit and change the automation back to the Clients version on their system
- I could not compile and deploy the Object as a txt-Export
- etc.

But what i'd actually really want would be a way to have all the different Versions of the differente MSO Librarys registered paralelly on my dev machine. Is there some kind of software availble to do this or manage the different versions by registering/unregistering them?

I do have all the Interop DLLs MS shipped with the different versions of NAV in the installation folder. But the classic client can't use them automaticly like the RTC does. I'm not sure if i can register them manually to have them all registered at once. (can i? does that take some special parameters?)

I know it would be best practise to capsule the Libraries in a seperate codeunit but there are technical difficulties which make this task really hard. Just think about the available Datatypes for parameters on NAV 2009 SP1 :-/ Also: sometimes we just have to deal with "old sins" in the code and don't have the time or budget to retroactively overhaul the whole module just because the Client needs 2 or 3 more data-fields in some Form.

It's hard for me to imagine I'm the first guy with the problem.

Thanks for all the help (and the patience to read all this^^)

mdPartnerNL

if you compile an object with the lowest version of the office library then your code will work in newer versions too (as long as you use the same office statements).

StLi

I hope you're right... however this leads me to my followup question, how do i switch the library versions on my Client without messing up my current office version.