尝试使用Excel 2007执行Office Automation，但是继续使用Excel 2003 [英] Trying to do Office Automation with Excel 2007, but keeps using Excel 2003

问题描述

环境：

Windows XP机器

安装了Excel 2007和Excel 2003（按顺序，不是按时间顺序）。

C＃3.5

问题：

当我使用PIA做一些Office自动化时，我使用以下代码行：

  var excel = new ApplicationClass ）; 
  

PIA的版本具体指的是Excel 12.

C：\\ \\WINDOWS\assembly\GAC\Microsoft.Office.Interop.Excel\12.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll

但是：

  excel.Version; //这是11.0而不是12.0 
  

因此，当我尝试使用扩展名.xlsx打开文件时，会警告我关于文件转换中的功能丢失，并使用excel 2003打开它。我很确定它与安装顺序是2007年 - > 2003年，但是我无法在我的机器上卸载2003 b / c我们在我们的Web服务器上有一些办公自动化，用于使用excel 2003的无关项目。

我看过Policy.11.0.Microsoft.Office.Interop.Excel.config的东西，但是它说

 < bindingRedirect oldVersion =11.0.0.0newVersion =12.0.0.0>< / bindingRedirect> 
  

所以，我很失落。为什么我不能告诉COM Interop哪个版本的Excel要使用？

解决方案

您无法以编程方式命令要使用哪个版本的Excel。 PIAs只规定您正在开发的接口或对象模型。但是哪个版本的Excel实际运行是由注册表控制的。

然而，在运行PIAs时，您将实际运行在系统上安装的最高级别的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将运行。 / p>

好的，所以你没有很多控制PIA，因为您开发的PIA实际上不会控制客户端机器上实际运行的PIA。

您没有很多控制权在哪个版本的Excel也被启动。例如，当您通过以下方式创建新的Excel实例时：

  Excel.Application excelApp = new Application（）; 
  

根据注册表中设置的当前版本设置加载的Excel应用程序。当前版本保存在：

  HKEY_CLASSES_ROOT\Excel.Application\CurVer 
  

您的案例中的CurVer键的默认值为Excel.Application.11，而不是Excel.Application 0.12' 。改变这个可能会做的伎俩，但我宁愿做一个修复，以确保所有的注册表设置被正确的修正。 （我不可能知道所有的设置应该是什么）好的，我刚刚发现另一个：你也需要改变：

  [HKEY_CLASSES_ROOT\CLSID\ {00024500-0000-0000-C000-000000000046} \ProgID] 
  

保存Excel.Application.12值。但是我强烈建议您运行修复。我不知道还有哪些其他设置可能需要更改，所以手动更改它们有点冒险。

此外，您还应该找到以下密钥：

  HKEY_CLASSES_ROOT\Excel.Application.11 
 HKEY_CLASSES_ROOT\Excel.Application.12 
  

因为这些是您安装的Excel版本。

（请参阅 here 进一步讨论。）

我很确定它与
安装顺序是2007年 - > 2003年

是的，这是100％正确。您可以尝试在Excel 2007上运行修复，这将是最简单的事情。如果这不起作用，那么我将卸载它们，然后重新安装它们。我将卸载Excel 2003，然后卸载2007（反转安装它们的顺序），然​​后安装Excel 2003，然后安装Excel 2007，以便正确的顺序安装这两个版本。

但是请记住，通过这样做，当您调用 Excel.Application excelApp = new Application（）时，Excel 2007将默认运行。 p>

实际推荐的做法是不是，以便在开发人员的机器上运行两个版本的Excel。有关更多信息，请参阅：

• 为什么多个版本的Office不支持VS开发？


• 您可以为多个版本的Office构建一个加载项吗？


• 为多个Office版本编写自动化客户端

我曾经在同一个开发机器上有多个Excel版本，我个人觉得这些缺点并不像这些文章那么复杂。一般来说，Excel 2007 PIA向后兼容Excel 2003 PIA，一切正常。但是，我曾经进入一个类似于你的注册表混乱，并决定做正确的事情。我卸载了两者，然后只重新安装了Excel 2007。

从那里我安装了虚拟PC，这是免费的（VMware实际上是一个更好的一点，但它不是免费的），然后在不同的虚拟机上安装我的2003,2002,2000和'97的较低版本的Excel。这绝对是一些工作要做，但一旦你这样做，一切都是100％干净。

那么说，我可能不想实际开发对于VM上的较低版本的Excel，使用虚拟机中托管的Visual Studio将太难了。因此，这些虚拟机只适用于测试部署，以确保您的系统可以对付各种客户端配置。有意义吗？

希望这有帮助！

Mike

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?

解决方案

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:

Excel.Application excelApp = new Application();

The Excel application loaded is set according to the current version set in the registry. The current version is saved at:

HKEY_CLASSES_ROOT\Excel.Application\CurVer

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:

[HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\ProgID]

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:

HKEY_CLASSES_ROOT\Excel.Application.11
HKEY_CLASSES_ROOT\Excel.Application.12

Because these are the versions of Excel that you have installed.

(See here for a further discussion.)

I am pretty sure it has to do with the install order being 2007 -> 2003

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:

• Why is VS development not supported with multiple versions of Office?
• Can you build one add-in for multiple versions of Office?
• Writing Automation clients for multiple Office versions

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

这篇关于尝试使用Excel 2007执行Office Automation，但是继续使用Excel 2003的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！