Automation against multiple MS Word versions

[Evan Stone]

If one is developing a .NET application, how can I develop an application
that uses COM automation that targets multiple versions of Word? For
example, the signature for the Document.Open method is different from
version 9 to version 11 (and I'm sure there are other variations as well),
and I'm wondering if there's some easy way to deal with it.

At present I'm only concerned with supporting 9-11 (i.e. Word 2000, XP, and
2003), though I'd like to be flexible enough to deal with future versions as
well. How are developers dealing with this sticky situation now?

evan stone | software engineer

 

[Nicholas Paldino [.NET/C# MVP]]

Evan,

Unfortunately, there is no good solution for this. For something like
this, you will have to determine the version of Word you are using, and make
the appropriate call. This will also mean having references to the interop
assemblies for all three versions.

Given that the newer versions should support the older interfaces, you
might have some luck for most of the properties/methods, since you can
always downcast to the lowest version of the interface you will support.

However, if you need to do something different based on the version that
you have, you should probably write a utility class which will expose
methods which take the interface pointer, a version, and the parameters for
the operation, which will contain the separate logic.

Hope this helps.

 

[carion1]

Office automation is pure evil.

 

[Evan Stone]

Unfortunately, there is no good solution for this.

It figures.

For something like
this, you will have to determine the version of Word you are using, and make
the appropriate call. This will also mean having references to the interop
assemblies for all three versions.

Is it possible to set references to multiple type libraries within one
assembly? How does that work - is VS.NET smart enough to create separate
namespaces for the different versions of the assemblies so we can
differentiate at runtime?

Or, would it make sense to create 3 (for now) assemblies that each have one
reference to each Word Interop assembly, and then use a Factory pattern to
instantiate the appropriate version of a wrapper object designed to handle
its corresponding version?

Then there's the matter of determining the version of Word that they have
installed, which is another problem to deal with as well (but probably less
tricky)....

evan stone | software engineer

 

[Nicholas Paldino [.NET/C# MVP]]

Evan,

See inline:

Is it possible to set references to multiple type libraries within one
assembly? How does that work - is VS.NET smart enough to create separate
namespaces for the different versions of the assemblies so we can
differentiate at runtime?

No, it is not.

Or, would it make sense to create 3 (for now) assemblies that each have
one
reference to each Word Interop assembly, and then use a Factory pattern to
instantiate the appropriate version of a wrapper object designed to handle
its corresponding version?

Yes, it would. However, you would have to take care of the situations
where the interface differs. This would involve you having to create your
own interface, which in turn would check the version on those "tricky"
calls, and make the call to the appropriate interface.

Then there's the matter of determining the version of Word that they have
installed, which is another problem to deal with as well (but probably
less
tricky)....

I believe there is a registry setting which will tell you this.

 

[Evan Stone]

Office automation is pure evil.

Agreed. But sometimes a necessary evil, unfortunately...

evan stone | software engineer

 

[Evan Stone]

Inline.

No, it is not.

Neato!

....but it's also as I figured, so whatever.

Yes, it would. However, you would have to take care of the situations
where the interface differs. This would involve you having to create your
own interface, which in turn would check the version on those "tricky"
calls, and make the call to the appropriate interface.

This is the scenario that I was originally planning for. I was planning on
writing an Adapter that would provide a *consistent* interface that the rest
of my application would interact with, and then pass the calls to the
appropriate underlying component.

I believe there is a registry setting which will tell you this.

OK. I'll check this out... I'm sure it's fairly easy to do, and is not one
of my major concerns at this point.

Thanks for the information, Nicholas. You've been most helpful.



evan stone | software engineer

 

[Evan Stone]

Nicholas,

One more thing....

Do you have any idea as to how to get hold of the various .OLB type library
files one would need to accomplish what I'm hoping to do? Actually I *think*
I can get my hands on the v10 and v11 typelibs, but I'm not sure if I have
v9 around anywhere...

Thanks!

evan stone | software engineer

 

[Nicholas Paldino [.NET/C# MVP]]

Evan,

If you have the original installs of those products, then you should be
able to get the type libraries.

Also, I forgot one thing. The recommendation that you use different
namespaces for the different versions can actually be done. Instead of
setting a reference in VS.NET to the COM object, use the TLBIMP utility to
generate the type libraries. That utility will allow you to specify the
namespace that the types in the assembly are in.

Hope this helps.

 

[Willy Denoyette [MVP]]

Not if you choose the right tools, and C# is not such tool, programming
against Office is where VB.NET has got it over C# hands-down. For example
VB.NET supports late binding at the language level, no need to resort to
reflection, VB.NET supports optional parameters, named parameters and
passing expressions to ref. parameters, whereas C# does not.

Willy.

Office automation is pure evil.

 

[Evan Stone]

If you have the original installs of those products, then you should
be

able to get the type libraries.

I'm sure we've got Office 2000 around here somewhere. It's just a matter of
getting the OLB file and then using the TLBIMP utility to generate the type
libraries, correct? I just found out about the TLBIMP utility this morning,
so it's interesting that you mentioned it as well.

I'll take a look at it, but for now I seem to have a handle on things. I
still need to generate libraries for Office 2000 (v9), however, but it's not
urgent at the moment. I'm hoping that I can develop to the version 9
interface and all will be well, per the info in the MS KB.

Thanks!

evan stone | software engineer

 

[Evan Stone]

Not if you choose the right tools, and C# is not such tool, programming

against Office is where VB.NET has got it over C# hands-down. For example
VB.NET supports late binding at the language level, no need to resort to
reflection, VB.NET supports optional parameters, named parameters and
passing expressions to ref. parameters, whereas C# does not.

Very interesting. Actually I'm finding the automation with C# to be not as
bad as I had originally thought it would be. However, if using VB.NET would
make it much easier, then perhaps writing an Adapter/Wrapper in VB.NET that
could be consumed by the rest of my C# application might make a lot of
sense. For the time being, C# has been working fine, but if I really have to
do some hardcore automation then perhaps I might do exactly that.

Thanks for the suggestion!

evan stone | software engineer

 

[Evan Stone]

Instead of setting a reference in VS.NET to the COM object,

use the TLBIMP utility to generate the type libraries.
That utility will allow you to specify the
namespace that the types in the assembly are in.

Will TLBIMP create the four DLLs I need:

- Interop.Office.dll
- Interop.VBIDE.dll
- Interop.Word.dll
- office.dll

Thanks!

evan stone | software engineer