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.
- 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!
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.
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...
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
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
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.
来源：https://stackoverflow.com/questions/1239673/microsoft-office-interop-assembly-references