Microsoft Office Interop Assembly references

Question

I have an application developed in Visual Studio 2005 which I am deploying using ClickOnce. My solution contains two projects - a user interface layer coded in VB, and a class library coded in C#. My C# class library has some code that uses the Outlook and Excel Interop Assemblies (Microsoft.Office.Interop.Outlook and Microsoft.Office.Interop.Excel, both version 11). Here are my questions.

1. Although I haven't found where this is stated as an absolute, my understanding is that you MUST have the appropriate versions of the Office applications (Outlook/Excel) in order to install an application that uses the Interop assemblies. Is this correct?

If (1. = Yes) Then

How would you handle the situation in which your application uses the Interop assemblies for only a couple of features that will be utilized by only a select few of the total user base? Why must I require every user of my application to install Microsoft Office if only some users will need to use those features? These Interop assemblies are just .dll files, so what makes them so different from others in that you can't just publish the file with your project and have that satisfy the reference regardless of what software is installed at the client? (Clearly I have a poor understanding of the GAC and it's effect on Visual Studio's behavior.) I would be happy to write my own code to check for the existence of the required Office software for the few features that use them. No Office, no access to feature...

Else

If my understanding on this is incorrect, then HOW do I setup my references and ClickOnce settings so that users don't encounter the following error upon installation attempt?

"Unable to install or run the application. The application requires that assembly office Version 11.0.0.0 be installed in the Global Assembly Cache (GAC) first.

Please Contact your system administrator."

• I have tried setting my Interop references CopyLocal property to both True and False.
• In my ClickOnce Application Files list, I have tried setting these assemblies to Include, Exclude and Prerequisite.
• In my research I have seen where some people have these references pointing to *C:\WINDOWS\assembly\GAC*, mine points to *C:\Program Files\Microsoft Visual Studio 9.0\Visual Studio Tools for Office\PIA\Office11* but I haven't found a way to change the reference path. According to http://msdn.microsoft.com/en-us/library/ez524kew(VS.80).aspx you CAN'T add references from the GAC, so how did other people manage it?
• I have tried copying the references from *C:\Program Files\Microsoft Visual Studio 9.0\Visual Studio Tools for Office\PIA\Office11* to my project directory and referencing them there.

End If

I suppose the main thing I need to know is how/if I can include these assemblies in my publication and satisfy or bypass the GAC requirement.

Where possible, please try to answer my specific questions as directly as possible. While articles are helpful, I have already read A LOT of articles and tried A LOT of suggested solutions and have found no success. Keep in mind my lack of understanding of the logistics of how this all works to begin with.

Forgive me for my lack of understanding, and thank you for any help you can offer. It is much appreciated!

Mojave

Answer 1

You might like to have a look at the NetOffice project: http://netoffice.codeplex.com/.

It is a free (MIT License) and complete (all the versions 2000-2010 and all the Office apps) set of version-independent interop assemblies. The assemblies are generated from the actual PIAs with a tool, so they are correct, complete and up-to-date, and likely to be be updated quickly for future versions.

Another nice feature is that the IntelliSense for each member displays which Office versions implement that member.

For deployment, you can copy or install the assemblies with your app.

Pungy

Answer 2

In my experience, trying to manage office interop assemblies in a broad deployment scenario is a nightmare. If you are deploying via ClickOnce, even if you get around the GAC issue you note above (perhaps by having your IT department push out a GAC registration of the interop assemblies, if this is a corporate environment), you will need to handle situations where users have a different version of Office than the standard -- and heaven help you when Office 13 comes out and users start to upgrade and it breaks your application.

In order to get around using the version-tied interop assemblies, it is possible to do office automation using pinvoke directly to the Office COM wrappers, which are version-independent (they pull the current office version on the client out of the registry). This will have its own deployment challenges, though (you may need to update the registry to handle machines that have the PIAs installed, for example, which could be very challenging when using ClickOnce for deployment), and is a lot harder to develop against.

If I were in your shoes, I would start out by taking a long hard look at the interop functionality you are using in your class library -- is there another way to provide the functionality you need, outside of office interop on the client machine? Perhaps a service-oriented solution where clients submit a request a server to generate a customized office doc and provide it for download...

Ailsa

Thank you for your response. So far I haven't had version conflict issues - users with both 2003 and 2007 have been able to use these features just fine. I guess a more simple question to really target what I'm wondering is this, can I make my application installable for users that DO NOT have ANY version of Office, allowing them to use the non-Interop features of my application? I understand that they must have Outlook/Excel to use my Interop-based features, but most of my application has nothing to to with Office. – Mojave

I would like to think that one instance of Interop code wouldn't entirely limit your application to those who have Office installed. – Mojave

One thing to try would be to use Download On Demand (msdn.microsoft.com/en-us/library/ak58kz04(VS.80).aspx) -- you should be able to code so that prior to invoking/downloading the assembly containing your Office interop classes, there is a check to see if Office is installed. What I do not know is whether ClickOnce delays checking for dependencies until the Download On Demand assembly is actually requested for download, or if it checks for all possible dependencies out of the gate. – Ailsa

This looks very interesting. It's the first I heard of it; I'll have to give it a try and see if I have any better luck. Thanks, and I'll post back if this helps solve my problem. – Mojave

Guy- Making the assemblies "optional" using the technique outlined on MSDN didn't solve my problem. I still get the error that says I need the assembly in the GAC and doesn't allow me to install the application. Any other ideas? It is very frustrating and confusing to me that one or two uses of an Office Interop in an application makes the application totally uninstallable by anyone without Microsoft Office installed. – Mojave

Well, I am not surprised either way -- deploying office interop via ClickOnce is probably not in the core use-cases for ClickOnce when MS designed it. I guess if you are certain it won't work, another option is to look into what I originally suggested, having a service that generates your office documents on a dedicated server. This of course might not meet your requirements, and it may also be out of scope/budget to rearchitect at this level. Good luck. – Ailsa

Answer 3

Here is what I know from experience (I should point out that we did not use ClickOnce but I'm not sure why that would matter):

If you write to the Excel 2003 APIs and deploy to a machine with Excel 2007 it will work because Excel 2007 essentially impersonates Excel 2003. The problem is that some APIs have changed and their are a few which have even been removed. You'll have to try it yourself to see if your application is affected.

In fact, it's slightly worse than that. If you run your application on a machine with Excel 2003 and Excel 2007 installed, your use of Interop will still use Excel 2007.

One possibility is to use SpreadsheetGear for .NET which gives you an Excel compatible Windows Forms control implemented entirely in one .NET assembly which you can deploy with your application - so your application will not depend on Office.

You can download a free trial here if you want to try it out.

Disclaimer: I own SpreadsheetGear LLC

Brookins

Answer 4

The best way is to use late binding library

https://sourceforge.net/projects/exceldata/

• no nigthmare with iterops and tlbs with different office versions
• support of various offices
• easy to make modificate

However:

• its hard to support this library

Bludgeon

Answer 5

Use the COM interface and late-binding. VB.NET has always supported late-binding. Just use Marshal.GetActiveObject() and set the type of your variable to Object. You can make a VB.NET object that does this and call it from C#.

With C# you get late-binding if you use the reflection API but it's pretty painful to write code using this. In C# 4 you can also get late binding via the dynamic type.

If you do this you don't need to distribute any Office assemblies and your code will work as long as the attributes on the objects in the Office API don't change.

Late binding code is slower than early binding code but for many purposes this is not a problem.

Hesler