Precompile application for use with different Office version using early binding

Hi!
I use Word and Excel automation for generating reports.
I don't like the late binding approach(first because I can't find out a way to address Word Document Property Constants like WdLineStyle.wdLineStyleSingle), as I cannot check if everything will work, without running the application myself on PCs with the different Office versions. So I read, that a good idea would be to compile the application with the oldest Interop library necessary, so in my case this would be Office 2003. I downloaded the Interop library for Word, and tried to install it, so I can add the reference to the project. But the installer says, I need to install Word 2003 before I can install this Interop.
So, now I develop the application with Interop for Office 15, and I cannot be sure that I already have not used some properties, that older versions of Word did not include. I would like to use an older Interop, so I am forced to use only features avaliable in the older office versions.

Is there a way, to use early binding by installing the interop on the clients machine during my application installation and then look for the location of it in registry? Or can I assume that the Interop library will be installed to a certain directory.

As I must support three versions of Office, I would make three different installers each for every Office version and then I would send the according version to the client.

Quote:

---

I cannot check if everything will work, without running the application myself on PCs with the different Office versions.

---

Well, duh. That is kinda the responsibility of the developer, don't you think?

The only way to code and test with older Interops is to do so on a machine with the appropriate Office version installed. There really isn't any way round that (or at least if there is you shouldn't take it). Even if you were using late binding, that shouldn't really be an excuse to fail to test the program on the various versions.

Thanks for your comment. However, my idea was to compile the programm using an interop for Word 2003, as this should also work with other office versions. At least that's what I understood, that all basic Word features are backwards compatible in newer office versions. So if I could develop on the Word 2003 interop, then I wouldn't have to test my application as extensively on all office versions, as would be the case if I create multiple different applications for different interops. Of course, if I have to use late binding, as obviously I cannot develop on Interop 2003 with my office installed being 2013, then there is no way around to test the application on all different client system configurations.

If you use early-binding then you can only support the version of Office that you reference. If you want to support multiple versions of Office using early-binding then you have to build against multiple versions. Generally speaking, if you want to support multiple versions then you develop against the oldest version using early-binding and then remove the reference and use late-binding. You should still test against all versions you want to support, although that's not always easy for a lone developer. You can develop against a later version but you must be extra careful not to use features not supported all the way back to the oldest version you want to support.

Dear Jmcilhinney,
thank you very much, now I understand what I misunderstood before -

Quote:

---

you develop against the oldest version using early-binding and then remove the reference and use late-binding

---

I somehow understood that I could use early binding on the oldest version necessary and keep it for all environments. This would have been such a nice thing.

You might consider (if budget permits) Aspose Cells library which does not require Excel to be installed. Aspose also has a Word library too.

Starting with VS2010 you can embed multiple versions of office products. Embedding Type Information from Microsoft Office Assemblies (C# and Visual Basic)

Quote:

---

Originally Posted by kevininstructor

Starting with VS2010 you can embed multiple versions of office products. Embedding Type Information from Microsoft Office Assemblies (C# and Visual Basic)

---

That I didn't know. Sensible step.

@kevininstructor - thank you for this very useful hint regarding embedding the "type information", I read the article and it sounds really good. However, currently I am working on VS2008 Express. I will check if this option is also avaliable in VS 2010 Express, if so then I will switch to it.

Edit: I just checkd my Visual Studio Express 2012 installation, and there I have this Property "Embed Interop Types" for the Interop resource used in the project.
I wonder, if there are some risks to switch from Visual Studio Express 2008 to 2012. I will check if my application compiles and works in VS express 2012 in the coming days. If this solution works, this would probably make my life a lot easier, well I have not yet started to test the application on different office versions, maybe late binding works better than I expect.

Regarding the Aspose Cells Library, it is too expensive for my project. Besides, all client pc's are equipped with Word and Excel, so I will stick to the office automation solution.

Quote:

---

I wonder, if there are some risks to switch from Visual Studio Express 2008 to 2012

---

Keep an eye on what framework is targeted. Otherwise you should be fine.

Well, I don't know which framework I target. This is not a common software development project - it's an upgrade from VB6 to VB.Net carried out by an absolute newbie to VB(I'm talking about me). Considering my knowledge of VB the timeframe was too short. I had no time to study the old app and I had no time to check the current requirements.
The oldest client pc is a XP Pro SP(unknown), so I hope that this app will run in .NET 4. However, I don't think that I use any sophisticated solutions in my app, so even a lower .NET should be fine. I have no idea what performance, functionality or what so ever differences are there in .NET 2 - 4.5.
I just want this application to run, as I already spent too much time on it, and still I am not proud of what I have created. I hope I will get some time to restructure the code and write a short doc, so the next one haveing to change something does not have to face the same problems I had. But in any way, my new chaotic VB.NET code is by far much more readable than the old VB6 code with only Object type used everywhere.