Microsoft’s SDKs (Software Development Kits) are shipped with many tools that target various areas. These tools bring additional value to the developers. Many of these tools are unfortunately not known by developers and it’s more of coincidences that we discover them via forums and blogposts.
I recently spent time to investigate how we can identify the ComponentIDs for prerequisites like the PIAs and VSTO runtime for Excel 2007 VSTO’s solutions.
The reason for it is that Microsoft has not yet updated their article “Deploying Visual Studio 2005 Tools for Office Solutions Using Windows Installer: Walkthroughs (Part 2 of 2)” for Office 2007.
I finally managed to locate the tool Orca, which is defined as:
“… is a database table editor for creating and editing Windows Installer packages and merge modules. The tool provides a graphical interface for validation, highlighting the particular entries where validation errors or warnings occur – Source.”
It’s part of the Windows SDK Components for Windows Installer Developers but since this SDK is rather large to download and install You can download only the Orca Tool from here.
Just to make sure that I was on the right track I viewed the Office 2003 PIA’s MSI file, the VSTO’s MSI file and compared the ComponentIDs with the ones in Microsoft’s article. The output was the following:
The above confirmed that the Orca tool views the correct ComponentIDs in the prerequisites’s MSI files.
In order to retrieve the ComponentID for Excel 2007 PIA I did the following:
- Downloaded Office 2007 redistributable PIA.
- Extracted the MSI file (and also the other files part of the exe file) with Winzip.
- Opened the MSI file in Orca.
- Located the Component Table “Component” and the entry “Global_Pia_Excel”.
- And finally I got hold on the wanted value:
{1ABEAF09-435F-47D6-9FEB-0AD05D4EF3EA}.
The mentioned VSTO ComponentID in the above table is also valid for the latest version included in the VSTO 2005 SE runtime.
Equipped with the Orca Tool we can create correct launch conditions and get a better understanding about how MSI files are created and maintained.
In my next coming blogpost I will continue the series for Creating and Deploying VSTO COM Add-ins.
Update:
The following blogpost gives access to the latest available version of Orca – UACL Compliant.
You can also read Microsoft’s knowledge base : How to use the Orca database editor to edit Windows Installer files.
Kind regards,
Dennis
VSTO & .NET & Excel 
Nice article Dennis… Short, but detailed so I still had to read it a couple of times for it all to sink in. These VSTO deployment issues are really like pealing an onion, eh?
I think I speak for many when I say that I’m glad you keep digging deeper for us. And I’m definately interested in what you’ll have to say about Deploying VSTO COM Addins…
Comment by Mike Rosenblum — February 21, 2007 @ 5:55 am
“These VSTO deployment issues are really like pealing an onion, eh?”
I fully agree Mike! I’ve not really started to look at VSTO yet but I know where I’ll be coming when I do!
I think I follow this Dennis but why do we need to know this info under normal conditions, is it not just a case of “black box”, or does it become important when you are trying to target different version of office?
Cheers
Ross
Comment by Ross — February 21, 2007 @ 11:34 am
Hi guys,
Thanks for Your comments 🙂
If we read the mentioned article it shows a set up where we can create launch conditions (in case the MSI package is executed instead of the Setup exe). In order to get the set up right with Excel 2007 we need to know the right ComponentID for the targeting version of Excel’s PIA.
The ComponentIDs for Office 2007 are required from time to time at the MSDN’s VSTO forum. Since MSFT ignore this kind of question I thought I would make a blogpost about it.
In addition to the above set up configuration we can also implement PIACheck.exe and the AppCheck.exe in a set up (see the first part of the MSFT’s article series) where:
PIACheck requires the ComponentID for Excel’s PIA to check:
– if it exist any version of PIA at all and
– if it’s the right version of the installed PIA on the targeting manchines.
AppCheck requires the ComponentID for Excel to check:
– if it exist any version of Excel at all and
– if it’s the right version of Excel on the targeting manchines.
I’ve not so far been able to track down the right ComponentID for Excel 2007. The main reason is that there exist a major difference between Office 2003 MSI file and Office 2007 MSI file. Except for that I must admit it’s very confusing to take part of this large MSI files…
All in all, I agree that things easily get more and more complicated when we start do dig into the world of VSTO.
Kind regards,
Dennis
Comment by Dennis Wallentin — February 21, 2007 @ 12:40 pm
Arh, thanks Dennis, that makes sense.
Cheers
Ross
Comment by Ross — February 21, 2007 @ 4:00 pm
Ok, Dennis, so what is the limitation then with VSTO and Excel 2007. I don’t doubt that the ComponentID for it is out there *somewhere*, but without it, what is the implication? Can’t deploy? Can deploy, but… but what exactly? What happens?
Comment by Mike Rosenblum — February 22, 2007 @ 11:05 pm
Mike,
Microsoft recommend to use AppCheck.exe and PIACheck.exe in all set ups. If we follow it we, at present, cannot use it because the ComponentID for Excel 2007 is missing. (A workaround is to read the Windows Registry to find out.)
Why is this important? By checking which Excel version is installed (if any!) we can in a smooth way shut down the installation process. For the PIA(s) it’s more of to assure that the right version is available (already installed or to be installed).
From my point of view it simple give us more control. This become important for corporates that have several Excel versions installed and also for third part vendors.
I hope the above make sense in view of Your questions 🙂
Kind regards,
Dennis
Comment by Dennis Wallentin — February 23, 2007 @ 12:00 am
Ah, ok… I knew that AppCheck and PIACheck did not work for Office 2007, but I never knew why. Thanks so much for explaining that. So there’s no GUID/ComponentID for the 2007 PIAs. That’s odd, yeah?
As for the registry, I think we can check for the existance of the Excel.Application by checking the
HKEY_CLASSES_ROOT\Excel.Application\CurVer
looking for a value of Excel.Application.12, or we can even check for multiple versions by looking for the existance of any or all of these locations, which would hold the CLSID, if present:
HKEY_CLASSES_ROOT\Excel.Application.10
HKEY_CLASSES_ROOT\Excel.Application.11
HKEY_CLASSES_ROOT\Excel.Application.12
(These three are the only Excel versions that can have offical PIA’s anyway.)
But these are all equivalent to using AppCheck.exe, I think. I don’t know what registry entries for which to check Excel 12.0 PIAs? Or, is it the case that if Excel/Office 12.0 is installed, the 2007 PIA for it MUST also be installed? (Making it unnecessary to check separately for the PIAs.) This is not the case for Office 2003, but maybe Office 2007 forces PIA intallation?
If Office 2007 does not force PIA installation, then, Dennis, do you know any registry entries that we can check for in order to perform the equivalent of PIACheck.exe?
Comment by Mike Rosenblum — February 24, 2007 @ 10:11 pm
Mike,
>>So there’s no GUID/ComponentID for the 2007 PIAs. That’s odd, yeah?
It exist but MSFT has not yet made them available. That’s why this blogpost exist in the first place…
As for checking if the right Excel version is available I fully agree that it would be sufficient to check in HCR in Windows registry.
The PIAs for Office 2007 is *only* installed if .NET Framework is detected on the targer machine, i e the same scenario as for Office 2003. So when we first install Office 2007, next install .NET Framework 2.0 then we also need to install the KB908003 fix.
As for checking if the PIAs are installed or not I’ve not dived into it since we can use the PiaCheck.exe together with the ComponentIDs for each of the PIA. To answer the question, no I have not checked the entries in the registry as I don’t like workarounds (see below 😉 )
To summarize:
In a way this blogpost is a side track but it’s important as we can create powerfull setup with the tools together with the ComponentIDs.
Per se I don’t like the so called workaround as they defeat the intention of best practice and standards.
All I want is correct information and straightforward updated guidelines from MSFT!
Kind regards,
Dennis
Comment by Dennis Wallentin — February 25, 2007 @ 4:00 pm
“Interesting Article – I’ll be back for more ^^
If you don’t mind me asking, what wordpress template is being used here? Its a great design and I would like to know if it’s a free one.”
Comment by warhammer gold — January 27, 2009 @ 4:30 pm
Hi,
I used one of the templates that are available at WordPress: “Silver is the New Black”
Kind regards,
Dennis
Comment by Dennis Wallentin — January 27, 2009 @ 5:35 pm
This post is great. thank you for sharing these helpful infos. I appreciate your work man
Comment by rapidleech — January 15, 2011 @ 11:24 am