尝试使用 Excel 2007 进行办公自动化，但继续使用 Excel 2003
环境：
Windows XP 计算机
Excel 2007 和 Excel 2003 均已安装（按此顺序，而不是按时间顺序）。
C# 3.5
问题：
当我使用 PIA 执行一些 Office 自动化时，我使用以下代码行：
var excel = new ApplicationClass();
PIA 的版本专门将其称为 Excel 12。
C：\ WINDOWS \程序集\ GAC \ Microsoft.Office.Interop.Excel \ 12.0.0.0__71e9bce111e9429c \ Microsoft.Office.Interop.Excel.dll
但是：
excel.Version;//this is 11.0 instead of 12.0
因此，当我尝试打开扩展名为 .xlsx 的文件时，它会警告我文件转换中丢失的功能，并使用 excel 2003 打开它。我很确定这与 2007 年的安装顺序有关 -> ; 2003，但我无法在我的计算机上卸载 2003，因为我们的网络服务器上有一些办公自动化，用于使用 excel 2003 的不相关项目。
我查看了 Policy.11.0.Microsoft.Office.Interop.Excel。配置的东西，但它说
<bindingRedirect oldVersion="11.0.0.0" newVersion="12.0.0.0"></bindingRedirect>
所以，我不知所措。为什么我无法告诉 COM Interop 使用哪个版本的 Excel？
Environment:
Windows XP machine
Both Excel 2007 and Excel 2003 installed (in that order, not chronologically).
C# 3.5
Problem:
When I use the PIAs to do some Office automation, I use the following line of code:
var excel = new ApplicationClass();
The PIA's version specifically refers to it as Excel 12.
C:\WINDOWS\assembly\GAC\Microsoft.Office.Interop.Excel\12.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll
But:
excel.Version;//this is 11.0 instead of 12.0
Thus, when I try to open a file with extention .xlsx, it warns me about lost functionality in the file conversion, and opens it with excel 2003. I am pretty sure it has to do with the install order being 2007 -> 2003, but I can't uninstall 2003 on my machine b/c we have some office automation on our webserver for an unrelated project that uses excel 2003.
I've looked at the Policy.11.0.Microsoft.Office.Interop.Excel.config stuff, but it says
<bindingRedirect oldVersion="11.0.0.0" newVersion="12.0.0.0"></bindingRedirect>
So, I am at a loss. Why can't I tell the COM Interop which version of Excel to use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您无法以编程方式命令使用哪个版本的 Excel。 PIA 仅规定您要针对哪个接口或对象模型进行开发。但实际运行的 Excel 版本是由注册表控制的。
然而，在运行 PIA 时，您实际上将针对系统上安装的最高级别的 PIA 运行。因此，如果您针对 Excel 2003 PIA 进行开发，但客户端具有带有 Excel 2007 PIA 的 Excel 2007，则您的代码将针对 Excel 2007 PIA 运行 — 并且它应该运行良好，因为 Excel 2007 PIA 向后兼容。也就是说，每个编号较高的 PIA 版本（和 Excel 对象模型）向后兼容针对旧版 PIA 和旧版 Excel 对象模型编译的命令。请注意，如果客户端计算机上同时具有 Excel 2007 和 Excel 2003 PIA，则无论运行哪个版本的 Excel，都将加载更高版本的 PIA - 因此，如果两个 PIA 都可用，则 Excel 2007 PIA 将运行。
[编辑：需要注意的是，使用 VB.NET 或 C# 4.0 时，Excel 2007 PIA 应该 100% 向后兼容。如果使用 C# 3.0 或更低版本，则从 C# 3.0 或更低版本调用时实际上需要可选参数，这一事实将在针对更高版本的 PIA 或对象模型运行时在某些代码中造成中断。不过这种情况相对较少，理论上来说，使用 C# 4.0，这个问题应该会消失。]
好的，所以您对 PIA 没有太多控制权，因为您开发的 PIA 实际上并不控制 PIA哪个 PIA 实际上将在客户端计算机上运行。
您也无法很好地控制启动哪个版本的 Excel。例如，当您通过以下方式创建新的 Excel 实例时：
加载的 Excel 应用程序根据注册表中设置的当前版本进行设置。当前版本保存在：
看起来您的情况下的“CurVer”键的默认值为“Excel.Application.11”，而不是“Excel.Application.12”。单独更改此功能可能会解决问题，但我更愿意进行修复，以确保所有注册表设置均已正确更正。 （而且我不可能知道所有设置应该是什么。）好吧，我刚刚找到了另一个：您还需要更改：
以保存“Excel.Application.12”的值。但我强烈建议进行修复。我不知道还需要更改哪些其他设置，因此手动更改它们有点冒险。
此外，您还应该找到以下项：
因为这些是您已安装的 Excel 版本。
（有关进一步讨论，请参阅此处。）
是的，这是 100% 正确的。您可以尝试在 Excel 2007 上运行修复，这将是最简单的事情。如果这不起作用，那么我将卸载它们，然后重新安装它们。我将卸载 Excel 2003，然后卸载 2007（与安装顺序相反），然后安装 Excel 2003，然后安装 Excel 2007，以便按照正确的顺序安装这两个版本。
但请记住，通过执行此操作，当您调用
Excel.Application excelApp = new Application()时，Excel 2007 将默认运行。实际建议的做法是不要在开发人员的计算机上运行两个版本的 Excel。有关详细信息，请参阅：
我曾经在同一台开发计算机上拥有多个版本的 Excel，我个人认为其缺点并不像这些文章听起来那么复杂。一般来说，Excel 2007 PIA 向后兼容 Excel 2003 PIA，并且一切正常。但我曾经遇到过与你类似的注册表混乱，并决定“做正确的事”。我卸载了两者，然后只重新安装了 Excel 2007。
从那里我安装了免费的 Virtual PC（VM ware 实际上更好一点，但它不是免费的），然后安装了 2003、2002、2000 的较低版本的 Excel和 '97 在不同的虚拟机上。设置起来确实需要一些工作，但一旦完成，一切就 100% 干净了。
也就是说，我可能不想在虚拟机上针对较低版本的 Excel 进行实际开发，因为使用虚拟机中托管的 Visual Studio 太难了。因此，这些虚拟机仅适用于测试部署，以确保您的系统可以针对各种客户端配置运行。有道理吗？
希望这有帮助！
麦克风
You cannot programmatically command which version of Excel to use. The PIAs only dictate which interface, or object model, you are developing against. But which version of Excel is actually running is controlled by the registry.
When it comes to running the PIAs, however, you will actually run against the highest-level PIA installed on the system. So if you develop against the Excel 2003 PIA, but the client has Excel 2007 with the Excel 2007 PIA, your code will run against the Excel 2007 PIA -- and it should run fine, because the Excel 2007 PIA is backward compatible. That is, each higher-numbered PIA version (and Excel object model) is backward compatible to commands compiled against an older PIA and older Excel object model. Note that if the client had both the Excel 2007 and Excel 2003 PIAs on the machine, then the higher versioned PIA would load, regardless of which version of Excel is running - so the Excel 2007 PIA would run, if both PIAs were available.
[Edit: One caveat is that the Excel 2007 PIAs should be 100% backward compatible when using VB.NET or C# 4.0. If using C# 3.0 or below, the fact that optional parameters are actually required when called from C# 3.0 or below will create a break in some code when running against the higher-version PIA or object model. It's relatively rare though, and with C# 4.0, this issue should go away, in theory.]
Ok, so you don't have a lot of control over the PIAs because the PIA that you developed against does not actually control which PIA will actually be running on the client machine.
You don't have a lot of control over which version of Excel is launched either. For example, when you create a new Excel instance via:
The Excel application loaded is set according to the current version set in the registry. The current version is saved at:
It looks like the 'CurVer' key in your case will have a default value of 'Excel.Application.11', instead of 'Excel.Application.12'. Changing this alone might do the trick, but I would prefer to do a repair instead to make sure that all the registry settings are corrected properly. (And I couldn't possibly know what all the settings should be.) Ok, I just found another one: you would also need to change:
to hold a value of "Excel.Application.12". But I would strongly recommend running a repair instead. I don't know what other settings might need to be changed, so changing them by hand is a bit risky.
In addition, you should find the following keys as well:
Because these are the versions of Excel that you have installed.
(See here for a further discussion.)
Yes, this is 100% correct. You could try running a repair on Excel 2007, this would be the easiest thing to do. If this does not work, then I would uninstall both and then re-install them both. I would uninstall Excel 2003 and then uninstall 2007 (reversing the order in which you installed them) and then install Excel 2003 and then install Excel 2007 so that you are installing both versions in the correct order.
But keep in mind that by doing this, Excel 2007 will be run by default when you call
Excel.Application excelApp = new Application().The actual recommended practice is not to have both versions of Excel running on the developer's machine. For more on this, see:
I used to have multiple versions of Excel on my same development machine, and I personally felt that the downsides were not as complicated as these articles make it sound. In general, the Excel 2007 PIA is backward-compatible to the Excel 2003 PIA and everything works fine. But I once got into a registry mess similar to yours and decided to "do the right thing". I uninstalled both and then only re-installed Excel 2007.
From there I installed Virtual PC, which is free (VM ware is actually a little better, but it's not free) and then installed my lower versions of Excel for 2003, 2002, 2000, and '97 on separate VMs. It is definitely some work to set up, but once you do this, everything is 100% clean.
That said, I probably would not want to actually develop against lower-versions of Excel on a VM, it would be too hard to use Visual Studio hosted within a VM. So these VMs are only good for testing deployment to make sure that your system can work against various client configurations. Make sense?
Hope this helps!
Mike