Tentando fazer Office Automation com o Excel 2007, mas continua usando Excel 2003

Question

Ambiente:

Windows XP máquina
Ambos Excel 2007 e Excel 2003 instalado (nessa ordem, não cronologicamente).
C # 3.5

Problema:

Quando eu uso os PIAs para fazer alguma automação de escritório, eu uso a seguinte linha de código:

var excel = new ApplicationClass();

A versão do PIA refere-se especificamente a ele como Excel 12.
C: \ WINDOWS \ assembly \ GAC \ Microsoft.Office.Interop.Excel \ 12.0.0.0__71e9bce111e9429c \ Microsoft.Office.Interop.Excel.dll
Mas:

 excel.Version;//this is 11.0 instead of 12.0

Assim, quando tento abrir um arquivo com extensão .xlsx, ele me avisa sobre a funcionalidade perdida na conversão de arquivos, e abre-o com o Excel 2003. Tenho a certeza que tem a ver com a ordem instalar sendo 2007 - > 2003, mas não posso desinstalação de 2003, sobre a minha máquina b / c temos alguma automação de escritório em nosso servidor web para um projeto relacionado que usa o excel 2003.

Eu olhei o material Policy.11.0.Microsoft.Office.Interop.Excel.config, mas ele diz que

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

Então, eu estou em uma perda. Por que eu não posso dizer a interoperabilidade qual versão do Excel para usar?

Answer 1

Você não pode comandar programaticamente qual versão do Excel para uso. Os PIAs única ditar a interface, ou modelo de objeto, você está desenvolvendo contra. Mas qual versão do Excel está atualmente em execução é controlada pelo Registro.

Quando se trata de gerir os PIAs, no entanto, você vai realmente executar contra o mais alto nível PIA instalado no sistema. Então, se você desenvolver contra 2003 PIA Excel, mas o cliente tenha o Excel 2007 com o Excel 2007 PIA, o seu código será executado contra o Excel 2007 PIA - e deve correr bem, porque 2007 PIA Excel é compatível. Ou seja, cada versão PIA de número maior (e modelo de objeto Excel) é compatível aos comandos compilados contra um PIA mais e mais velho modelo de objeto Excel. Note-se que se o cliente tinha ambos os PIAs Excel 2007 e Excel 2003 na máquina, em seguida, a PIA de versão mais elevada seria de carga, independentemente de qual versão do Excel está em execução -. Modo que o Excel 2007 PIA seria executado, se ambos os PIAs estavam disponíveis

[Edit: Uma ressalva é que os PIAs Excel 2007 deve ser 100% compatível ao usar VB.NET ou C # 4.0. Se estiver usando C # 3.0 ou abaixo, o fato de que os parâmetros opcionais são realmente necessários quando chamado de C # 3.0 ou abaixo criará uma pausa em algum código durante a execução contra a maior versão PIA ou modelo objeto. É embora relativamente raros, e com C # 4.0, esta questão deve ir embora, em teoria.]

Ok, então você não tem um monte de controle sobre os PIAs porque o PIA que você desenvolveu contra a verdade não controlar quais PIA será realmente sendo executado na máquina cliente.

Você não tem um monte de controle sobre qual versão do Excel é iniciado qualquer um. Por exemplo, quando você cria uma nova instância do Excel via:

Excel.Application excelApp = new Application();

O aplicativo Excel carregado é definido de acordo com o conjunto versão atual no registro. A versão atual é salvo em:

HKEY_CLASSES_ROOT\Excel.Application\CurVer

Parece que a tecla 'CurVer' no seu caso terá um valor padrão de 'Excel.Application.11', em vez de 'Excel.Application.12'. Alterar este sozinho pode fazer o truque, mas eu preferiria fazer um reparo em vez para se certificar de que todas as configurações de registro são corrigidas corretamente. (E eu não poderia saber o que todas as configurações devem ser.) Ok, eu só encontrei um outro: você também precisa mudar:

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

para manter um valor de "Excel.Application.12". Mas eu recomendo fortemente a execução de um reparo em seu lugar. Eu não sei o que as outras configurações podem precisar de ser mudado, então alterá-los com a mão é um pouco arriscado.

Além disso, você deve encontrar as seguintes chaves, assim:

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

Porque estas são as versões do Excel que você instalou.

(Veja aqui para uma discussão mais aprofundada.)

Tenho a certeza que tem a ver com o instalar fim sendo 2007 -> 2003

Sim, esta é 100% correto. Você poderia tentar executar um reparo em Excel 2007, esta seria a coisa mais fácil de fazer. Se isso não funcionar, então eu iria desinstalar ambos e, em seguida, reinstalá-los ambos. Gostaria de desinstalar o Excel 2003 e, em seguida, desinstalar 2007 (invertendo a ordem em que você instalou-los) e, em seguida, instalar o Excel 2003 e, em seguida, instalar o Excel 2007 para que você está instalando ambas as versões na ordem correta.

Mas tenha em mente que, fazendo isso, Excel 2007 será executado por padrão quando você chamar Excel.Application excelApp = new Application().

A prática recomendada é não ter ambas as versões do Excel em execução na máquina do desenvolvedor. Para saber mais sobre isso, consulte:

• por que o desenvolvimento VS não suportado com várias versões do Office?
• você pode construir um add-in para várias versões do Office?
• Escrita de automação para várias versões do Office

Eu costumava ter várias versões do Excel no meu mesma máquina de desenvolvimento, e eu, pessoalmente, senti que as desvantagens não foram tão complicado como estes artigos tornam som. Em geral, 2007 PIA Excel é compatível com versões anteriores à 2003 PIA Excel e tudo funciona bem. Mas uma vez eu entrei em uma confusão de registo semelhante ao seu e decidiu "fazer a coisa certa". Eu desinstalei tanto e só então re-instalado Excel 2007.

A partir daí eu instalado Virtual PC, que é gratuito (VM Ware é na verdade um pouco melhor, mas não é livre) e depois instalado minhas versões inferiores do Excel para 2003, 2002, 2000 e '97 em VMs separado. É definitivamente um trabalho de configurar, mas uma vez que você fizer isso, tudo é 100% limpo.

Dito isso, eu provavelmente não iria querer realmente desenvolver contra inferior versões do Excel em um VM, seria muito difícil de usar Visual Studio hospedado dentro de uma VM. Portanto, estas VMs são boas apenas para testar a implementação para se certificar de que seu sistema pode funcionar contra várias configurações do cliente. Faz sentido?

Espero que isso ajude!

Mike