Microsoft Office互操作程序集引用
我有一个在Visual Studio 2005中开发的应用程序，我使用ClickOnce进行部署。 我的解决scheme包含两个项目 – 用VB编写的用户界面层和用C＃编码的类库。 我的C＃类库有一些代码使用Outlook和Excel互操作程序集（Microsoft.Office.Interop.Outlook和Microsoft.Office.Interop.Excel，都是版本11）。 这是我的问题。
- 虽然我没有find这是绝对的，我的理解是，你必须有相应版本的Office应用程序（Outlook / Excel）才能安装使用Interop程序集的应用程序。 它是否正确？
如果（1. =是）那么
你将如何处理你的应用程序使用Interop汇编程序的情况，只有几个function，只有less数总用户群才能使用？ 为什么我必须要求我的应用程序的每个用户安装Microsoft Office，如果只有一些用户需要使用这些function？ 这些互操作程序集只是.dll文件，所以它们与其他软件不同之处在于，无论客户端安装了什么软件，您都不能只将该文件发布到项目中并满足参考要求。 （很明显，我对GAC的理解很差，对Visual Studio的行为有影响）。我很乐意编写自己的代码来检查所需的Office软件是否存在less数使用它们的function。 没有办公室，没有访问function…
其他
如果我对此的理解不正确，那么如何设置我的引用和ClickOnce设置，以便用户在安装尝试时不会遇到以下错误？
“无法安装或运行应用程序，应用程序需要首先在全局程序集caching（GAC）中安装程序集版本11.0.0.0。
请联系您的系统pipe理员。“
- 我已经尝试将我的Interop引用CopyLocal属性设置为True和False。
- 在我的ClickOnce应用程序文件列表中，我已经尝试将这些程序集设置为包含，排除和先决条件。
- 在我的研究中，我已经看到有些人将这些引用指向* C：\ WINDOWS \ assembly \ GAC *，指向* C：\ Program Files \ Microsoft Visual Studio 9.0 \ Office \ PIA \ Office11的Visual Studio工具*但我还没有find改变参考path的方法。 根据http://msdn.microsoft.com/en-us/library/ez524kew(VS.80).aspx你不能添加来自GAC的引用，所以其他人如何pipe理它？
- 我已经尝试从* C：\ Program Files \ Microsoft Visual Studio 9.0 \ Visual Studio Tools for Office \ PIA \ Office11 *复制引用到我的项目目录并在那里引用它们。
万一
我想我需要知道的主要是如何/如果我可以在我的出版物中包括这些程序集，并满足或绕过GAC的要求。
如有可能，请尽可能直接回答我的具体问题。 虽然文章是有帮助的，但我已经阅读了大量的文章，并尝试了很多build议的解决scheme，并没有find成功。 请记住，我对于所有这些工作的后勤缺乏了解。
原谅我的缺乏理解，并感谢您提供的任何帮助。 非常感谢！
您可能想了解一下NetOffice项目： http ： //netoffice.codeplex.com/ 。
这是一个免费的（麻省理工学院许可证）和完整的（所有版本2000-2010和所有的Office应用程序）一套独立于版本的互操作程序集。 这些程序集是通过一个工具从实际的PIA生成的，所以它们是正确的，完整的和最新的，并且很可能在将来的版本中被快速更新。
另一个不错的function是每个成员的智能感知显示哪个Office版本实现该成员。
对于部署，您可以使用您的应用程序复制或安装程序集。
根据我的经验，试图在广泛的部署场景中pipe理办公互操作程序集是一场噩梦。 如果通过ClickOnce进行部署，即使您解决了上述的GAC问题（也许通过让IT部门推出互操作程序集的GAC注册，如果这是一个公司环境），您将需要处理用户拥有与标准不同的Office版本 – 当Office 13出现，用户开始升级并破坏应用程序时，Heaven将为您提供帮助。
为了避免使用版本绑定的互操作程序集，可以直接使用与COM版本无关的Office COM包装（它们将客户端上的当前办公室版本从registry中提取）直接进行Office自动处理。 但是，这将会面临其自身的部署挑战（例如，您可能需要更新registry来处理安装了PIA的计算机，而使用ClickOnce进行部署时，这可能会非常具有挑战性），而且难以发展。
如果我处在你的位置上，我将首先仔细研究你在类库中使用的互操作性function – 还有另外一种方法可以在客户端机器上的办公互操作之外提供所需的function吗？ 也许面向服务的解决scheme，客户提交一个请求服务器来生成一个自定义的办公文档，并提供下载…
这里是我从经验中知道的（我应该指出，我们并没有使用ClickOnce，但我不确定为什么会这么重要）：
如果您写入Excel 2003 API并将其部署到使用Excel 2007的计算机上，则可以工作，因为Excel 2007本质上模拟了Excel 2003.问题在于某些API已更改，而且这些API甚至已被删除。 你必须自己尝试一下，看看你的应用程序是否受到影响。
事实上，这比这还差一些。 如果您在安装了Excel 2003和Excel 2007的计算机上运行应用程序，则使用Interop仍将使用Excel 2007。
一种可能性是使用SpreadsheetGear for .NET ，它为您提供了一个完全在一个.NET程序集中实现的兼容Excel的Windows窗体控件，您可以将其与应用程序一起部署，因此您的应用程序将不依赖于Office。
如果您想试用，可以在这里下载免费试用版。
免责声明：我自己的SpreadsheetGear LLC
最好的方法是使用后期绑定库
https://sourceforge.net/projects/exceldata/
- 没有与iterops和tlbs不同办公室版本的nigthmare
- 支持各个办事处
- 容易做modificate
然而：
- 它很难支持这个图书馆
使用COM接口和后期绑定。 VB.NET一直支持后期绑定。 只需使用Marshal.GetActiveObject（）并将variables的types设置为Object。 你可以创build一个VB.NET对象，并从C＃调用它。
用C＃，如果你使用reflectionAPI，你会得到迟绑定，但是用这个编写代码是非常痛苦的。 在C＃4中，您还可以通过dynamictypes获得更晚的绑定。
如果您这样做，则不需要分发任何Office程序集，只要Office API中对象的属性不会更改，代码就会工作。
后期绑定代码比早期绑定代码慢，但是对于许多目的来说，这不是问题。