将 PIA 部署到混合版本的 Office

发布于 2024-09-18 13:30:15 字数 2049 浏览 3 评论 0原文

您好，我一直在努力解决 MS Office 的主互操作程序集 (PIA) 部署的一些复杂问题。我在 VS 2008 中基于纯 com 技术构建了 Visual Studio Com 插件（不是 VSTO，请参阅底部了解更多信息），它引用 2003 主互操作程序集，但该插件可能在 2003 年、2007 年或现在的 2010 年使用办公机器。因为我永远不知道客户是否会使用 2003、2007 还是 2010，所以我不能简单地部署一个 PIA 版本作为先决条件（除非我制作了 3 个我不想做的安装程序）。现在，我的理解是，当您按照步骤此处将 2003 和 2007 PIA 添加到 Visual Studio 中显示的先决条件列表（2008 ）安装包，先决条件足够智能，可以确定您的目标客户端上正在运行哪个 Office 版本。因此，如果您选择 2003 主 interop 程序集和 2007 主 iterop 程序集作为先决条件，那么当它安装在具有 2003 的计算机上时，它应该足够智能，仅在该计算机上缺少 2003 PIA 时才尝试添加 2003 PIA，并且如果这是 2007 Office 计算机，那么它将仅安装 2007 PIA（而不尝试安装 2003 PIA）。

问题 1 这是一个正确的理解吗（前提包是如此智能，可以根据 Office 版本仅安装所需的内容？）

问题 2 有没有办法让 2010 PIA 像 2003 和 2007 一样显示在 VS 2008 的先决条件列表中吗？我不想将此项目升级到 VS 2010 b/c，它被认为是一个遗留应用程序，现在有来自世界各地的许多客户在使用它。

问题 3 尽管实际程序集引用了 2003 年主要互操作，但我目前并未将这些互操作与加载项一起部署到安装位置。相反，我假设如果我能够安装正确的 PIA，那么我不需要将其存在于安装路径中，因为 PIA 将位于 GAC 中。然而，一种可能的方法可能是仅将引用的 2003 程序集（在我的例子中是 excel 和 word）包含在安装路径中，而不用担心 PIA。我怀疑这适用于 2003 机器，但可能不适用于 2007 和 2010 机器 b/c 后者，即使引用的 2003 互操作在运行时在程序集的安装路径中找到，我认为如果没有如果 GAC 中包含 Policy.11.0.Microsoft.Office.Interop.Excel/Word(etc)，那么 2007 年和 2010 年可能不知道如何处理 11.0 (2003) 互操作（我认为 Policy.11.0.Microsoft.a Office.Interop 文件将 2003 互操作的请求重定向到 2007 或 2010）。对此有什么想法吗？

问题 4：Framework 2.0 应用程序 Office 加载项和 Office 2003 存在一个众所周知的错误，导致加载项无法加载。 KB907417 又名 KB908002 已解决此问题。有谁知道如果您在 3.0 或 3.5 框架上开发（并使 3.0 或 3.5 成为先决条件），这个知识库是否必要，因为这个问题是框架 2.0 特有的？或者是否仍然需要部署 KB，因为这是 Office 2003 的问题，而不是框架的版本？

从我的 3 个问题你可以看出，我试图确定的是我们是否可以通过 VS 安装实用程序构建一个安装程序。如果 PIA 可以通过一个安装程序完成，但上面的 KB 是一个障碍（因为也许答案会回来，即使在 3.0 或 3.5 框架 2003 上，客户也需要该 KB），那么也许一个安装程序的路径就是该知识库是全面的先决条件，并将其安装在 2007 或 2010 机器上，尽管从技术上讲它们并不需要它们。对此选项的任何想法也将不胜感激。最后，我知道现在通常使用 VSTO 而不是纯托管框架代码来为 excel 或 word 编写托管 Com 插件，但这不是目前将遗留应用程序更改为这个方向的选项。另据报道，4.0 框架现在可用于部署加载项，而无需任何 PIA 作为先决条件，但同样，目前这不是一个可行的选择。

原文

Hello I have been fighting some complexities with understanding deployment of Primary Interop Assemblies (PIA) for MS Office. I have Visual Studio Com Add-IN built in VS 2008 on pure com technology (not VSTO see bottom of this for more on that), which references 2003 Primary Interop Assemblies but the add-in may be used on 2003, 2007 or now 2010 Office machines. Because I never know if the customer will be using 2003, 2007, or 2010, I cannot simply deploy one PIA version as a prerequisite (unless I make 3 installers which I do not want to do). Now, my understanding is that when you follow the steps here to add 2003 and 2007 PIA to the prerequisite lists that show up in a Visual Studio (2008) setup package, the prerequisites are smart enough to determine which office version is running on the client you are targeting. So if you were to select 2003 primary interop assemblies and 2007 primary iterop assemblies as both being prerequisites then when this installs on a machine that has 2003 it should be intelligent enough to only try to add the 2003 PIA if those are missing on this machine and if this is a 2007 Office machine then it will only install 2007 PIA (and not try to install 2003 PIA).

Question 1 is this a correct understanding (that the prerequisite packages are this intelligent to only install what it needs based on the version of Office?)

Question 2 is there a way to get the 2010 PIA to show in the list of prerequisites in VS 2008 like 2003 and 2007 do? I do not want to upgrade this project to VS 2010 b/c it is considered a legacy app now with many customers from all around the world using it.

Question 3 Even though the actual assembly references 2003 primary interops, I do not presently deploy those interops with the add-in to the install location. Instead, I am assuming that if I can get the correct PIA installed then I don't need this present in the installation path, since the PIA would be in the GAC. However, one possible approach may be to just include the 2003 assemblies that are referenced (in my case excel and word) in the install path and not worry about the PIA. I suspect this would work on 2003 machines but perhaps not on 2007 and 2010 machines b/c on the latter, even if the 2003 interops that are referenced are found at run time in the install path of the assembly, I think if there is not a Policy.11.0.Microsoft.Office.Interop.Excel/Word(etc) in the GAC, then 2007 and 2010 will likely not know what to do with the 11.0 (2003) interops (as I think the Policy.11.0.Microsoft.Office.Interop files redirect requests for the 2003 interops to 2007 or 2010). Any thoughts on this?

Question 4: There is a well known bug with Framework 2.0 apps Office Add-Ins and Office 2003 where the add-in won't load. This was addressed by KB907417 aka KB908002. Dopes anyone know if this KB necessary if you develop on the 3.0 or 3.5 framework (and make 3.0 or 3.5 a prerequisite) since this problem was specific to framework 2.0? Or does the KB still need to be deployed b/c it's office 2003 that is the problem and not the version of the framework?

As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility. If the PIAs can be done with one installer but the KB above is the obstacle (as perhaps the answer will come back that even on the 3.0 or 3.5 framework 2003 customers will need the KB) then maybe the path to one installer is to just make the KB a prerequisite across the board and install it on 2007 or 2010 machines, though they technically do not need them. Any thoughts on that option would be appreciated as well. Finally, I am aware that writing a manged Com Add-IN for excel or word is now generally done with VSTO instead of pure managed framework code, but this is not an option presently to change the legacy app to this direction. Also it is reported that the 4.0 framework now can be used to deploy add-ins without making any PIA a prerequisite but again, this is not a viable option right now.

分享到QQ

分享到微博