I use Excel via COM automation (in c#), but it seems that the problem has no control over what version of excel is started on the box - we use both Excel 9 and Excel 11 and one specific set of spreadsheets requires excel 9 else they wont work.
I included the excel 9 com references but on another persons machine excel 11 started. How can I fix this ?
It's nothing to do with CurVer. This is COM. As with all COM applications Windows finds out how to start them by referring to the LocalServer or InprocServer settings in the relevant CLSID key in the registry.
The CLSID for Excel is:
{00024500-0000-0000-C000-000000000046}
If you look at this key under HKCR\CLSID (HKCR\Wow6432Node\CLSID is you are running a 64-bit edition of Windows) you will see these keys. If Excel 2003 and Excel 2007 are installed, all three of these keys:
HKCR\Excel.Appplication
HKCR\Excel.Appplication.11
HKCR\Excel.Appplication.12
Will point to the same same CLSID which is why Windows only knows how to start one version of Excel.
If you find that Excel 2003 is being started its because the sub-keys of the CLSID point to the OFFICE11 installation.
To change this behavior change the path to point to the OFFICE12 (or OFFICE14) path. Windows will use the Unicode variant of the command by preference (which is unintelligible). So unless you know how to update the Unicode just delete the 'command' values.
This article may be of use:
http://forums.devx.com/showthread.php?p=457900#post457900
Like the commenters above, it's unclear to me why Excel 11 would have problems with an Excel 9 spreadsheet
I'm unsure of the ProgId's (friendly names on CLSID Guids) used for Excel, but a quick look leads me to 'Excel.Application', as the type you might activate.
Take a look under HKEY_CLASSES_ROOT, on my machine I see "Excel.Application" and "Excel.Application.12", i suspect that you are activating "Excel.Application", if you look under the "CurVer" key under "Excel.Application" it points back to "Excel.Application.12", inspect this value on your repro machines.
My guess would be that you are starting Excel.Application, you may want to force it to start Excel.Application.9 if the prog id exists on your target machine.
Here is a little code sample:
Type excel9Type = Type.GetTypeFromProgID("Excel.Application.9");
Type excelType = Type.GetTypeFromProgID("Excel.Application");
if (excelType == excel9Type)
{
Console.WriteLine("Default Excel.Application is pointing to 'Verion 9' yay");
}
else
{
Console.WriteLine("Excel is installed, but it's not 'Version 9'");
}
if (excel9Type == null)
{
throw new InvalidOperationException("Excel.Application.9 is not a registered progid");
}
object excelApplication = Activator.CreateInstance(excel9Type);
// Cast excelApplication to whatever you are using as your application type.
Ok so I checked the two machines which give different behaviour, after switiching to Phils suggested Activator solution. Both machines have Excel.Application.9 in the CurVer regkey; but one starts 11 and one starts 9. I'm still at a bit of a loss so far.
I noted in the debugger that the Type object returned from Excel.Application.9 has some evidence of XL11 inside.
Any further suggestions ?
What do the Class ID Guids in the progid's for Excel.Application.9 and .11 say on the two different machines?
To get a specific Excel version you can start the binary executable directly using
System.Diagnostics.Process process = System.Diagnostics.Process.Start(@"C:\Program Files\Microsoft Office\Office11\Excel.exe");
int processId = process.Id;
This will give you the id of the Excel process. You can now connect to this Excel instance and can get hold of the object model by calling AccessibleObjectFromWindow.
This method requires you to use P/Invoke and you also have to get a handle to the Excel window first. Since this is a little more work I will simply reference the following question where everything is described in detail:
