Windows Installer (MSI) 4.5 (April 3, 2008)

Chat Topic: Windows Installer (MSI) 4.5
Date: Thursday, April 03, 2008

Daniel (Moderator):
Let's get started with our chat. Before we begin, though, I'd like to have our Experts introduce themselves and then they'll get started answering your questions.

Introductions:

Hem (Expert):
I am Hem (rhymes with name, fame, game). I have been a developer on the Windows Installer team for over five years now. Its a pleasure chatting today and answer any questions you might have.

WCheng (Expert):
Hi, I'm William, and I'm a developer on the windows installer team.

Start of chat:

Hem (Expert):
Q: When building a patch, msimsp generates the following log line: ERROR: Cannot generate a pound transform.
What does this line mean?
A: It most likely means that an attempt by patchwiz to generate a transform using the MsiDatabaseGenerateTransform API failed. It could possibly be because the target and upgrade MSI referenced by the PCP file are the same. Check to make sure that is not the case. The transform name itself should indicate which target/upgrade images are being looked at.

Hem (Expert):
Q: Could you please explain the new Transaction functionality that has been added to WI 4.5. When do you anticipate its use? Are there any rules or suggestions about using transactions?
A: Most major application vendors compose their applications from multiple packages. Currently MSI does not provide a mechanism for rolling back multiple packages as a single transaction and hence the robustness of the multi-package installation is poorer than the robustness of a single package installation. Application vendors are asking for an ability to create a transaction across multiple packages and patch installation.

The goal of the new transaction functionality is therefore to:
§ Enable transaction across packages and patches.
§ Enable chainer to delegate control of multi-package transaction to another chainer.
§ UAC credentials will be prompted only once for the entire transaction on an as needed basis.

Hem (Expert):
Q: When 4.5 RTM will be release? Does this means ALL OSs at the same time release?
A: Yes. The current plan is to make MSI 4.5 RTM available for XPSP2/SP3, Win 2003 SP1/SP2, Vista RTM and SP1, Win Server 08.

Hem (Expert):
Q: Could you please explain the new Transaction functionality that has been added to WI 4.5. When do you anticipate its use? Are there any rules or suggestions about using transactions?
A: If you are subscribed to our Beta program you should have gotten access to a agility white paper that explains on how we expect people to use this new functionality. Please stay tuned to our blog https://blogs.msdn.com/windows_installer_team/ for more informal discussions and clarity on this.

WCheng (Expert):
Q: Will windows installer 4.5 provide support for the Vista Restart Manager on WinXP?
A: No, Restart Manager is a Vista feature. MSI4.5 released on XP will not be able to call into the Restart Manager feature, and will continue to use the existing filesinuse support instead.

Hem (Expert):
Q: What is the planned rtm date for MSI 4.5?
A: We are targeting for Q3 of this year.

Hem (Expert):
Q: The new MSI 4.5 supports an embedded external UI. The built-in dialog controls did not get updated. Does this mean that the built-in dialog support is being considered obsolete in the future? What is planned in the next versions?
A: Embedded UI does not obsolete external UI or Windows Installer's authored internal UI. It is another option for package authors trying to address some of Windows Installer's UI limitations. Please read the blog posting @ https://blogs.msdn.com/windows_installer_team/archive/2008/04/01/windows-installer-4-5-ui-enhancements-embedded-ui.aspx to get an idea of why you need embedded UI.

For those of you who don't need the advanced UI functionality, can still continue to use Windows Installer's authored internal UI.

Hem (Expert):
Q: Any chance of MSI 4.5 expanding the MsiNTProductType to cover all the new product types returned by the GetProductInfo Function so we can detect things like Server Core?
A: Thank you for the feedback on this property. We will consider adding better support to the property in this or other future release of Windows Installer.

Hem (Expert):
Q: Is there a way to properly parent an embedded UI to the internal MSI UI similar to how a parent window handle can be provided to MsiSetInternalUI?
A: There is no support for that behavior for this release. Do you have a scenario in mind that requires this support?

Hem (Expert):
Q: Were can I get the cab files for windows xp sp2
A: This chat is about Windows Installer as in MSI technology to install apps on Windows. I assume your question is related to install of the Windows OS itself. So, this question is off topic with the current chat.

Hem (Expert):
Q: For example, I may want to have some common UI up behind an MSI installation that is using the internal UI, possibly a CD browser that launches common UI for a multi-package transaction.
A: We have support for embedded UI to span across multiple packages in a multi-package transaction. So, that should possibly address your need for common UI for a multi-package transaction...

Hem (Expert):
Q: Can you say something about the roadmap for the next MSI versions?
A: The next version of Windows Installer (post MSI 4.5) is still in the works and we are not in a position to share it publicly. However, if you have any pet features/functionality or trends, please feel free to ask us.

Hem (Expert):
Q: Is COM initialized across all the embedded UI entry points?
A: Nope.

WCheng (Expert):
Q: What's the mechanism for passing back installation progress from a multi-package transaction to the embedded UI?
A: For a multi package transaction, you can begin the transaction with the msiTransactionAttributeChainEmbeddedUI attribute set (1). This allows every package in the transaction to use the embedded UI from the first package in the transaction. We also added new messages to denote the start of a product install and end of a product install. If you filter for INSTALLLOGMODE_INSTALLSTART and INSTALLLOGMODE_INSTALLEND, you should receive the INSTALLMESSAGE_INSTALLSTART and INSTALLMESSAGE_INSTALLEND messages, respectively, and from there, your embedded UI can display the progress for that package.

Hem (Expert):
Q: Will commits to the GAC from one package be available to subsequent packages? I'm thinking about CAs that rely on VC8.0 runtime, .NET CAs (even though they're unsupported), etc.
A: In a multi package transaction initiated by MsiBeginTransaction, commit phase is deferred to the end of the transaction. Only when you call MsiEndTransaction will your assemblies installed by the multiple MSI packages be committed to GAC and commit custom actions run. So such packages should be outside the transaction.

Hem (Expert):
Q: Can you uninstall multiple package transactions with one UAC prompt?
A: Yes. If you use the new MsiPackageCertificate table to chain trust across packages.

However, there is a caveat to that. If the package has an embedded CAB then that will be stripped when it is cached on to the user's machine. As a result, the certificate that was used to sign that package is no more valid. So, the certificates from MsiPackageCertificate table are not valid anymore and the chain of trust is broken. This causes us to put up credential prompt for all the packages that carried embedded CABs. We do understand this limitation.

WCheng (Expert):
Q: Can we get progress messages from chained packages to inital internal MSI UI?
A: Is this what you're asking: "if in a multiple package transaction, the first package's internal UI will be able to handle progress messages from another package in the transaction"? The answer to that question is that no, internal UI can only be used for the install of the package in which the internal UI was authored. The suggested methods of handling UI across multiple packages is to use external UI or embedded UI.

Hem (Expert):
Q: Hem: MsiPackageCertificate? Did you mean MsiPatchCertificateMsiPatchCertificate?
A: No. We added a new table called MsiPackageCertificate table to support UAC credential caching for a multi-package transaction. Please check out our blog (https://blogs.msdn.com/windows\_installer\_team/) later today and feel free to send in your comments.

WCheng (Expert):
Q: Any suggestions for debugging user32 API call hangs (for example, calling SetWindowPos hangs somewhere in win32k.sys) from the embedded UI (the same code doesn't hang from an external UI)?
A: You can set MsiBreak to MsiEmbeddedUI (similar to debugging custom actions) to debug into your embedded UI. The embedded UI process should be similar to a custom action process.

Hem (Expert):
Q: I must be blind. I'm not seing MsiPackageCertificate in the beta 2 msi.chm nor in the blog.
A: Thank you for pointing it out. I will make sure that it will get into our RTM docs. In the meantime, we should be able to communicate the intent of this new table on the team blog.

Daniel (Moderator):
Well we're out of time for today's chat.

Thank you very much to all of our guests who joined us today as well as to our Experts for answering so many great questions. Have a great day everyone!

Top of page