Best practice distributing app using Microsoft.Office.Interop

Question

I have an application that's creating and manipulating Excel files. It's written in vb.net, one can imagine something along the lines of open Excel, create file, fill it, show this file in Excel ( somewhat similar examples ).

I want to distribute this app but I don't know which exact office versions are installed on users' machines. How do I achieve the most compatibility?

Should I use the oldest interop dlls I can get my hands on (Office 2010 seems reasonably old) and embed interop types as recommended ? In this scenario, there are no extra dlls in the app folder, am I safe to assume it will work everywhere Office >=2010 is installed?

Setting CopyLocal=True on Microsoft.Office.Interop.Excel results in 4 dlls being copied into app folder: Microsoft.Office.Interop.Excel.dll , Microsoft.Vbe.Interop.dll , office.dll and stdole.dll . Should I pack them together with my app?

Is it maybe a combination of the above?

Sorry for so many questions, but I'm really lost.

Is there a way to test the app with different versions of Office without buying and installing them all somewhere?

Answer 1

Is there a way to test the app with different versions of Office without buying and installing them all somewhere?

You may use Azure VMs with pre-installed Office applications if you don't want to maintain a test labs on your own.

4 dlls being copied into app folder: Microsoft.Office.Interop.Excel.dll, Microsoft.Vbe.Interop.dll, office.dll and stdole.dll. Should I pack them together with my app?

The number of libs depends on the code - what features are used (classes etc.). Here is the brief explanation of the interop assemblies:

• Microsoft.Vbe.Interop.dll -> Microsoft Visual Basic for Applications Extensibility
• Microsoft.Office.Interop.Excel.dll -> Microsoft Excel Object Library
• office.dll -> Microsoft Office Object Library (Office shared functionality)
• stdole.dll -> It may use a "standard" COM interface like IFont or IDispatch. Seems support for these interfaces in .NET need to ref stdole.dll.

Instead of deploying separate interop assemblies you may consider setting the Embed Interop Types property on the COM reference. Read more about that on the What's the difference setting Embed Interop Types true and false in Visual Studio? thread. It is up to you whether to deploy separate assemblies or use this option. Both ways are acceptable.

Should I use the oldest interop dlls I can get my hands on

Yes, the oldest interop version is the minimum supported Office version. In that case you can be sure your application will be using APIs available in the oldest version and don't call the newest ones.