Microsoft Office 互操作程序集参考
我有一个在 Visual Studio 2005 中开发的应用程序，我正在使用 ClickOnce 进行部署。 我的解决方案包含两个项目 - 用 VB 编码的用户界面层和用 C# 编码的类库。 我的 C# 类库有一些使用 Outlook 和 Excel 互操作程序集（Microsoft.Office.Interop.Outlook 和 Microsoft.Office.Interop.Excel，均为版本 11）的代码。 这是我的问题。
- 尽管我没有找到绝对的说法，但我的理解是，您必须拥有适当版本的 Office 应用程序 (Outlook/Excel) 才能安装使用 Interop 程序集的应用程序。 它是否正确？
如果 (1. = 是) 那么
如果您的应用程序仅将 Interop 程序集用于少数功能，而这些功能仅由总用户群中的少数人使用，您将如何处理这种情况？ 如果只有部分用户需要使用这些功能，为什么我必须要求应用程序的每个用户安装 Microsoft Office？ 这些 Interop 程序集只是 .dll 文件，因此它们与其他程序集的不同之处在于，无论安装什么软件，您都不能只将文件与项目一起发布并满足引用。客户端？ （显然，我对 GAC 及其对 Visual Studio 行为的影响了解甚少。）我很乐意编写自己的代码来检查是否存在使用 Office 软件的少数功能所需的 Office 软件。 没有 Office，无法访问功能...
否则
如果我对此的理解不正确，那么如何设置我的引用和 ClickOnce 设置，以便用户在尝试安装时不会遇到以下错误？
“无法安装或运行该应用程序。该应用程序要求首先将程序集办公室版本 11.0.0.0 安装在全局程序集缓存 (GAC) 中。
请与您的系统管理员联系。”
- 我尝试将 Interop 引用 CopyLocal 属性设置为 True 和 False。
- 在我的 ClickOnce 应用程序文件列表中，我尝试将这些程序集设置为“包含”、“排除”和“先决条件”。
- 在我的研究中，我发现有些人的这些引用指向 *C:\WINDOWS\ assembly\GAC*，我的则指向 *C:\Program Files\Microsoft Visual Studio 9.0\Visual Studio Tools for Office\PIA\Office11*但我还没有找到改变参考路径的方法。 根据 http://msdn.microsoft.com/en -us/library/ez524kew(VS.80).aspx 您无法添加来自 GAC 的引用，那么其他人是如何管理它的呢？
- 我尝试将引用从 *C:\Program Files\Microsoft Visual Studio 9.0\Visual Studio Tools for Office\PIA\Office11* 复制到我的项目目录并在那里引用它们。
结束如果
我想我需要知道的主要事情是如何/是否可以将这些程序集包含在我的出版物中并满足或绕过 GAC 要求。
如果可能，请尝试尽可能直接回答我的具体问题。 虽然文章很有帮助，但我已经阅读了很多文章并尝试了很多建议的解决方案，但没有成功。 请记住，我对这一切从一开始就如何运作的逻辑缺乏了解。
请原谅我的不理解，并感谢您提供的任何帮助。 非常感谢！
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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可能想查看 NetOffice 项目：http://netoffice.codeplex.com/。
它是一套免费（MIT 许可证）且完整（所有版本 2000-2010 和所有 Office 应用程序）的独立于版本的互操作程序集。 这些程序集是使用工具从实际的 PIA 生成的，因此它们是正确的、完整的和最新的，并且可能会针对未来版本快速更新。
另一个不错的功能是每个成员的 IntelliSense 显示哪些 Office 版本实现了该成员。
对于部署，您可以使用应用程序复制或安装程序集。
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.
根据我的经验，尝试在广泛的部署场景中管理办公室互操作程序集是一场噩梦。 如果您通过 ClickOnce 进行部署，即使您解决了上面提到的 GAC 问题（如果这是企业环境，也许可以让您的 IT 部门推出互操作程序集的 GAC 注册），您也需要处理以下情况：用户拥有与标准版不同的 Office 版本 - 当 Office 13 发布并且用户开始升级并且它破坏了您的应用程序时，天堂会帮助您。
为了避免使用版本相关的互操作程序集，可以直接使用 pinvoke 到 Office COM 包装器来实现办公自动化，这些包装器是版本无关的（它们从注册表中提取客户端上当前的 Office 版本）。 不过，这也有其自身的部署挑战（例如，您可能需要更新注册表以处理安装了 PIA 的计算机，这在使用 ClickOnce 进行部署时可能非常具有挑战性），并且开发起来更加困难。
如果我处于您的立场，我会首先仔细研究您在类库中使用的互操作功能 - 在客户端计算机上的办公室互操作之外，是否有另一种方法可以提供您所需的功能？ 也许是一种面向服务的解决方案，其中客户端向服务器提交请求以生成定制的办公文档并提供下载......
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...
以下是我从经验中了解到的信息（我应该指出，我们没有使用 ClickOnce，但我不确定为什么这很重要）：
如果您写入 Excel 2003 API 并部署到装有 Excel 2007 的计算机，它将起作用，因为Excel 2007 实质上模仿了 Excel 2003。问题是一些 API 已发生更改，其中一些甚至已被删除。 您必须亲自尝试一下，看看您的应用程序是否受到影响。
事实上，情况比这还要糟糕一些。 如果您在安装了 Excel 2003 和 Excel 2007 的计算机上运行应用程序，则使用 Interop 时仍将使用 Excel 2007。
一种可能是使用 SpreadsheetGear for .NET 它为您提供了一个完全在一个 .NET 程序集中实现的 Excel 兼容 Windows 窗体控件，您可以将其与您的应用程序一起部署 - 因此您的应用程序将不依赖于 Office。
如果您想试用，可以在此处下载免费试用版。
免责声明：我拥有 SpreadsheetGear LLC
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
最好的方法是使用后期绑定库
https://sourceforge.net/projects/exceldata/
但是：
The best way is to use late binding library
https://sourceforge.net/projects/exceldata/
However:
使用COM接口和后期绑定。 VB.NET 始终支持后期绑定。 只需使用 Marshal.GetActiveObject() 并将变量的类型设置为 Object。 您可以创建一个 VB.NET 对象来执行此操作并从 C# 中调用它。
在 C# 中，如果使用反射 API，则会出现后期绑定，但使用它编写代码非常痛苦。 在 C# 4 中，您还可以通过动态类型获得后期绑定。
如果执行此操作，则无需分发任何 Office 程序集，并且只要 Office API 中对象的属性不发生更改，您的代码就可以正常工作。
后期绑定代码比早期绑定代码慢，但对于许多用途来说这不是问题。
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.