Tratar de hacer Ofimática con Excel 2007, pero sigue usando Excel 2003

Question

Medio Ambiente:

máquina Windows XP
Tanto Excel 2007 y Excel 2003 instalado (en ese orden, no por orden cronológico).
C# 3.5

Problema:

Cuando uso los PIA para hacer algo de automatización de oficina, utilizo la siguiente línea de código:

var excel = new ApplicationClass(); 

La versión del PIA se refiere específicamente a ella como Excel 12.
C: \ WINDOWS \ assembly \ GAC \ Microsoft.Office.Interop.Excel \ 12.0.0.0__71e9bce111e9429c \ Microsoft.Office.Interop.Excel.dll
Pero:

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

Por lo tanto, cuando intento abrir un archivo con extensión .xlsx, me advierte acerca de la funcionalidad perdida en la conversión de archivos, y lo abre con Excel 2003. Estoy bastante seguro de que tiene que ver con la instalación orden siendo 2007 -> 2003, pero no puedo desinstalar 2003 en mi máquina b/c tenemos un poco de automatización de oficina en nuestro servidor web para un proyecto no relacionado que utiliza Excel 2003.

He visto la Política.11.0 .Microsoft.Office.Interop.Excel.config cosas, pero no dice

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

lo tanto, yo estoy en una pérdida. ¿Por qué no puedo decirle a COM Interop qué versión de Excel usar?

Answer 1

No se puede controlar programáticamente qué versión de Excel usar. Los PIA solo dictan qué interfaz o modelo de objeto está desarrollando. Pero la versión de Excel que se está ejecutando realmente está controlada por el registro.

Sin embargo, cuando se trata de ejecutar los PIA, en realidad se ejecutará contra el PIA de nivel más alto instalado en el sistema. Entonces, si desarrolla contra el PIA de Excel 2003, pero el cliente tiene Excel 2007 con el PIA de Excel 2007, su código se ejecutará contra el PIA de Excel 2007, y debería funcionar bien, porque el PIA de Excel 2007 es compatible con versiones anteriores. Es decir, cada versión de PIA de mayor numeración (y modelo de objetos de Excel) es compatible con versiones anteriores de comandos compilados contra un PIA antiguo y un modelo de objetos de Excel anterior. Tenga en cuenta que si el cliente tuviera los PIA de Excel 2007 y Excel 2003 en el equipo, se cargaría el PIA de versión superior, independientemente de la versión de Excel que esté ejecutándose, de modo que el PIA de Excel 2007 se ejecutaría si ambos PIA estuvieran disponibles.

[Editar: Una advertencia es que los PIA de Excel 2007 deben ser 100% compatibles con versiones anteriores cuando se utiliza VB.NET o C# 4.0. Si se utiliza C# 3.0 o menos, el hecho de que se necesiten parámetros opcionales cuando se los llama desde C# 3.0 o inferior creará un corte en algún código cuando se ejecute contra el PIA de mayor versión o el modelo de objetos. Sin embargo, es relativamente raro, y con C# 4.0, este problema debería desaparecer, en teoría.]

Ok, entonces no tienes mucho control sobre los PIA porque la PIA contra la que desarrollaste en realidad no controlar qué PIA realmente se ejecutará en la máquina del cliente.

Tampoco tiene mucho control sobre la versión de Excel que se inicia.Por ejemplo, cuando crea una nueva instancia de Excel a través de:

Excel.Application excelApp = new Application(); 

La aplicación de Excel cargada se establece según la versión actual establecida en el registro. La versión actual se guarda en:

HKEY_CLASSES_ROOT\Excel.Application\CurVer 

Parece que la clave 'CurVer' en su caso tendrá un valor por defecto de 'Excel.Application.11', en lugar de 'Excel.Application.12'. Cambiar esto solo podría ser el truco, pero preferiría hacer una reparación para asegurarme de que todas las configuraciones de registro se corrijan correctamente. (Y yo no podría saber qué deben ser todos los ajustes.) Ok, acabo de encontrar otra: también tendría que cambiar:

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

para mantener un valor de "Excel.Application.12" . Pero recomendaría ejecutar una reparación en su lugar. No sé qué otras configuraciones podrían necesitar ser cambiadas, así que cambiarlas a mano es un poco arriesgado.

Además, debe encontrar las claves siguientes, así:

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

porque estas son las versiones de Excel que haya instalado.

(Ver here para una discusión adicional.)

Estoy bastante seguro de que tiene que ver con el instalar siendo para 2007 -> 2003

Sí, esto es 100% correcto . Podría intentar ejecutar una reparación en Excel 2007, esto sería lo más fácil de hacer. Si esto no funciona, entonces desinstalaría ambos y luego los volvería a instalar. Desinstalaría Excel 2003 y luego desinstalaría 2007 (invirtiendo el orden en que los instaló) y luego instalaría Excel 2003 y luego instalaría Excel 2007 para que esté instalando ambas versiones en el orden correcto.

Pero tenga en cuenta que al hacer esto, Excel 2007 se ejecutará de manera predeterminada cuando llame al Excel.Application excelApp = new Application().

La práctica recomendada es real no tener ambas versiones de Excel que se ejecutan en la máquina del desarrollador. Para más información sobre este tema, consulte:

• 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

que solía tener varias versiones de Excel en mi misma máquina de desarrollo, y personalmente me pareció que los inconvenientes eran no tan complicado como estos artículos lo hacen sonar. En general, el Excel 2007 PIA es compatible con versiones anteriores de Excel 2003 PIA y todo funciona bien. Pero una vez me metí en un lío de registro similar al tuyo y decidí "hacer lo correcto". Desinstalé ambos y luego solo volví a instalar Excel 2007.

A partir de allí instalé Virtual PC, que es gratis (VM ware es en realidad un poco mejor, pero no es gratis) y luego instalé mis versiones inferiores de Excel para 2003 , 2002, 2000 y '97 en máquinas virtuales separadas. Definitivamente es algo trabajo de configurar, pero una vez que haces esto, todo está 100% limpio.

Dicho esto, probablemente no me quiero realmente desarrollan contra-bajos versiones de Excel en una máquina virtual, sería demasiado difícil de usar alojada dentro de una máquina virtual de Visual Studio. Por lo tanto, estas máquinas virtuales solo sirven para probar la implementación y asegurarse de que su sistema pueda funcionar contra varias configuraciones de clientes. ¿Tener sentido?

Espero que esto ayude!

Mike