About Windows Installer, the .NET Framework, and Visual Studio.
Notice the differences between the following two dialogs from the same Windows Installer package on the same Windows XP machine.
The first dialog is displayed when launching a sample .msi file using the msiwai.exe program I detailed before. The second dialog is displayed when the sample .msi file is launched from Windows Explorer, thus using the default handler, msiexec.exe. So why the difference?
The difference between the two executable is that msiexec.exe has an embedded manifest to bind to the Common Controls 6 side-by-side native assembly, while my sample application msiwai.exe has no such manifest and, thus, uses the last Common Controls version prior to Windows isolated application and side-by-side (WinSxS) support introduced in Windows XP.
If you open msiexec.exe in Visual Studio, for example, you'll see a resource section called RT_MANIFEST. If you open the item identified as 1 as binary data you'll see what looks like XML. When you extract it as msiexec.exe.manifest (or anything really, but the name is important for external manifests) and open it you'll see the following:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><!-- Copyright © 1981-2001 Microsoft Corporation --><assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1"> <assemblyIdentity type="win32" name="MSIExec" version="126.96.36.199" processorArchitecture="x86" /> <description> Windows installer setup service </description> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="188.8.131.52" publicKeyToken="6595b64144ccf1df" language="*" processorArchitecture="x86"/> </dependentAssembly> </dependency></assembly>
The <dependentAssembly> causes the loader to bind to the Common Controls 6 assembly which includes the rich controls that made their debut in Windows XP. Manifests allow you to isolate applications and use different versions of libraries at the same time for different applications, even redirecting version policies much like you can with .NET Framework side-by-side execution. You can also use manifests for registration-free COM.
Since my sample application wasn't linked with a resource file originally it's not straight-forward to add the manifest. You can, however, use similar content as that above, changing the name attribute from "MSIExec" to something else like "MsiWait", and the <description> to something appropriate like "Bootstrap to wait for a previous installation to finish". Save that to a file named msiwait.exe.manifest and save it in the same location as msiwait.exe. Now run msiwait.exe with a .msi file on Windows XP and newer and you'll see a UI similar to the second dialog above.
Since the setup.exe bootstrap application that Visual Studio creates when building a Windows Installer project (if you've opted to build a bootstrap application) doesn't embed a manifest either you can use that for the next procedure.
Now when you run the bootstrap application on Windows XP or newer Common Control 6 will be loaded instead. If you are using a theme like the default Windows XP theme you'll see a dialog similar to the second one above.
You should not attempt to use control IDs because dialogs are built dynamically and IDs can change. Instead, you can use MsiProcessMessage to disable the Cancel button. At http://msdn.microsoft.com/library/en-us/msi/setup/sending_messages_to_windows_installer_using_msiprocessmessage.asp, read about the INSTALLMESSAGE_COMMONDATA message.
Mike, if you need more advanced UI you should considering writing an external UI handler but this can be a more daunting task than ensuring that your installation works during rollback. That's the most important thing, because one of the great features of Windows Installer is it transactional nature. If a CA does not support rollback when it should, that CA should be rewritten correctly to support rollback, or you're only hurting the end users' machines.
PingBack from http://www.keyongtech.com/2334071-dependency-microsoft-windows-common-controls