尝试使用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.071e9bce111e9429c\Microsoft.Office.Interop.Excel.dll

但是：

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

因此，当我尝试打开一个扩展名为.xlsx的文件时，它警告我关于文件转换中的功能损失，并用excel 2003打开它。我很确定它与安装顺序是2007 - > 2003，但我不能卸载2003在我的机器b / c我们有一些办公自动化在我们的webserver一个无关的项目，使用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。 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。 / p>

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

您没有很多控制也将启动其版本的Excel。例如，通过以下方式创建新的Excel实例时：

  Excel.Application excelApp = new Application（）; 
  

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

  HKEY_CLASSES_ROOT\Excel.Application\CurVer 
  

看起来您的案例中的CurVer键的默认值为Excel.Application.11，而不是Excel.Application .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版本。

（请参阅此处以进一步讨论。）

我很确定它与
安装顺序是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实际上是一个更好一点，但它不是免费的），然后在单独的VM上安装了我的较低版本的Excel 2003,2002，2000和'97。这肯定是一些工作要设置，但一旦你这样做，一切都是100％干净。

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

希望这会有帮助！

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屋！