Doctor Deploys Blog

I couldn’t sleep tonight so I thought I’d just poke around online for a while. It turned out to be impossible to miss the fact that the Google App Engine was released tonight. We knew about this a little while ago but now we know it’s name.

The SDK itself is pretty cool. They’ve done a nice job bundling up all their services in nice little downloadable package except they left out the Python runtime (and are afflicted by the Windows Installer’s lack of hyperlink control in their launch condition). In any case, it has been a quite a while since a new technology announcement really got me to kick back and think about how I personally could use it. I was starting to dig into Ruby a bit but maybe I will switch over to Python now. ASP.NET is beginning to drive me bonkers and The Django Book seems like a really nice read.

Anyway, after watching the launch videos I noticed that Bob had sent around an email saying thus, “The Google App Engine SDK for Windows is delivered as an MSI built with WiX (v3.0.3907, even) and Heat.” I hadn’t downloaded the package at that point but bounced on over, downloaded and kicked off the install.

Blam! Right out of the gate I knew I was looking at a package built by WiX.  How?  Look at the red. All the other installation vendors out there like blue. As Bob noted, it looks like Google even used the latest weekly release for WiX v3.

Now, unlike Google’s previous attempt at using the WiX toolset, this looks like a pretty clean package. There is only one ICE message, a warning: C:\Users\robmen\Downloads\GoogleAppEngine.msi : warning SMOK1076 : ICE47: Feature ‘ProductFeature’ has 940 components. This could cause problems on Win9X systems. You should try to have fewer than 817 components per feature.

Win9X probably isn’t something I’d worry about either although it does point to one of the troubles with creating one Component per Resource. There are also only two non-standard CustomActions that open the README.txt and launch the default browser. Both completely reasonable things to do (bonus points for using the default browser).

In the end, as I noted in the beginning, it looks like they’ve done a nice job bundling up all their services. I’ll leave you with one observation that I found kinda’ funny. There are 938 rows in the MsiFileHash table.  There are an equal number of rows in the File table. That means there are no executable files in this package. Obsolete skills indeed.

 

Original post by Rob Mensching

Today, four years ago the WiX toolset was released as the first Open Source project from Microsoft. Each year I like to take a moment and look around to see where we are. Just this week, I’ve found two random blog entries that make me believe we’re being successful.

Over the years I’ve slowly distilled the vision of the WiX toolset into a single sentence.  “The WiX toolset enables all developers to create high quality Windows installation packages by providing tools that integrate seamlessly into the development process.”

I described the philosophy underlying that vision about a month after the WiX toolset’s public release. There are three parts. First, the developer that wrote the feature knows best what needs to be authored into setup. Second, setup authoring is a part of the development process. Third, text files should be the only inputs into the build process.

The first blog entry that I found at the beginning of the week aligns with the third part of the philosophy. The title of the blog entry is The Power of Text Files. Beyond the obvious agreement that “the best medium for code is a text file,” I found the fact that the author had just recently tried the WiX toolset interesting for two reasons. First, it reminds me that there are a great many people that we haven’t yet reached. Second, that the WiX toolset has generated enough interest that it is on developer’s “to try out” list. Both of those observations mean we still have work to do on the WiX toolset.

The second blog entry was a discussion about a talk at VSLive! San Francisco, titled: Multiply your team’s voltage by working in parallel. This blog entry speaks directly to the second part of the philosophy and touches on the first part when mentions: “Code holds code artifacts - C#, VB, SQL, WiX, etc.”. Notice that the WiX code (.wxs files) is called out as a peer of the C# code, the VB code, the SQL code. It is incredibly encouraging to see the setup coding not be relegated to the “etc. bucket” and actually called out as a first class citizen in the development process.

Another exciting development in the WiX toolset is the infusion of a lot of attention by Visual Studio developers. There have been other commercial development on top of the WiX toolset but Visual Studio is the first “company” (for lack of a better term) to actively fund development that improves the core toolset. What I find most impressive is that the Visual Studio team is taking on the “boring” and “dirty” work of integrating 64-bit builds, tackling FxCop issues, building testing infrastructure and just flat out fixing bugs. The WiX toolset (Votive, in particular) is much more solid thanks to their efforts and they aren’t done yet. <smile/>

Finally, I want to recognize Bob Arnson and Peter Marcu for their dedication to the WiX toolset over the last year. Anyone that hangs out on the wix-users mailing lists knows who Bob is, he fields an incredible number of questions. But what you don’t often see is how much I depend on both Bob and Peter as a reliable and educated sounding board for new ideas and large decisions. Peter did an incredible job integrating all of the knowledge about patching spread across Microsoft into the new patching tool in WiX v3 called pyro.

Over the last four years or so, Bob’s and Peter’s role in the WiX toolset has steadily increased and this last year they have really demonstrated solid leadership skills. With my April Fool’s joke this year, some people asked the question about what would happen to the WiX toolset if I stopped working on it. With Bob and Peter available there is no doubt in my mind that everything would continue just fine.

It has been a fantastic year and I look forward to next year where I expect we will all be enjoying an incredibly stable and feature rich WiX v3. And don’t worry, I’ve already started looking out at what’s next. <grin/>

 

Original post by Rob Mensching

A head cold is totally wiping me out right now but I wanted to post a few quick notes about progress on the WiX toolset.

1.  64-bit builds. If you watch the weekly releases then you’ve noticed that there hasn’t been a release in the last few weeks. The primary cause for the disruption is that Mike Carlson (a developer on the Visual Studio team) has been revamping our build system to build x86, x64 and ia64 builds of the WiX toolset. This ended up being a large undertaking because he needed to move the WiX toolset to the Visual Studio 2008 headers and libs.

2. Visual Studio 2008. Since the 64-bit builds will need VS 2008 headers and libs, Peter Marcu is updating the solution files to build with VS 2008. The hope is that this will simplify some of the requirements to build the WiX toolset. Additionally, VS 2008 seems to simply perform better than VS 2005 so maybe we’ll get some development benefit there as well.

3. FxCop compliance. Jason Ginchereau and Muhammad Ghaznawi (two more Visual Studio developers) have been plowing through the backlog of FxCop issues in all of the WiX toolset. Along the way they’ve also been moving a number of strings to resource files so that every part of the WiX toolset (not just the standard UI dialogs) will be able to be localized.

These efforts have resulted in sweeping changes across the whole code base. As a result, we’ve just held off on the builds for a bit while Mike stabilized his build system changes. I expect that when we all get together again next Thursday that the final issues will be worked out and builds will be back on a regular weekly schedule.

Thanks for the patience.

 

Original post by Rob Mensching

What does this blog cover?

With Windows Installer 4.5 support for multi package transaction, the Windows Installer transaction boundary can span more than a single package. Additionally, UAC credential prompts are tied to a package trust boundary. This means, there can be more than one UAC credential prompt per transaction. If you want to use multi-package transactions and don’t want more than one credential prompt, then this blog is for you.

How do I author my packages to not get more than one UAC credential prompt per transaction?

Here’s what you got to do:

1.       Author MsiPackageCertificate table into the package that will be installed first in your multi-package transaction.

2.       Sign all the subsequent packages with one of the certificates listed in the MsiPackageCertificate table.

How does the MsiPackageCertificate table look like?

The MsiPackageCertificate table identifies the possible signer certificates used to digitally sign packages that are part of this product install and do not need separate UAC credential prompt to acquire admin approval. Using this table, setup authors can list the digital certificates that the packages that constitute this product will be signed with.

The table definition is listed below:

Columns

PackageCertificate
The unique identifier for this row in the MsiPackageCertificate Table.

DigitalCertificate_
An external key into the first column of the MsiDigitalCertificate Table. The row indicated in the MsiDigitalCertificate Table contains the binary representation of the signer certificate.

Could you please walk me through on how all of this fits together?

1.       User clicks on a setup.exe.

2.       Setup.exe calls MsiBeginTransaction.

3.       Setup.exe calls MsiInstallProduct to install First.msi that carries an MsiPackageCertificate table that lists the certificates that this package trusts.

4.       Windows Installer puts up a credential prompt for administrator’s consent to install First.msi.

5.       Upon admin consent, Windows Installer goes about installing the product.

6.       Setup.exe calls MsiInstallProduct to install second.msi that is signed by a certificate listed in First.msi package’s MsiPackageCertificate table. Since:

a.       Administrator trusted First.msi and

b.      Second.msi is signed by a certificate trusted by First.msi,

Windows Installer doesn’t put up any credential prompt for second.msi.

7.       Setup.exe finally calls MsiEndTransaction and commits the transaction.

FAQ

Q: Can a package that is not the first one to be installed as part of the transaction, add more trusted digital certificates for this transaction?

A: Yes. As long as the package was consented explicitly (via UAC prompt) or implicitly (trusted because it is signed by one of the trusted certificates)

Q: What will be the content of the Consent UI? Will it display the package information of the transaction information?

A: It will display just the package information. This is analogous to our behavior vis-à-vis MsiPatchCertificate table.

Q: What happens if a certificate listed in the MsiPackageCertificate table is revoked or expired?

A: Packages signed with revoked certificates will result in separate UAC prompts and cached credentials will not be used for those package installs. This is analogous to our behavior vis-à-vis MsiPatchCertificate table.

Q: Does the same behavior exist during uninstalls and re-cache reinstalls?

A: Yes. If a package carrying MsiPackageCertificate table is accepted as trusted by a UAC credential prompt then any subsequent packages (launched by embedded chainer or otherwise) signed by one of those certificates will also be considered as trusted.

Q: Can a patch add/delete certificates listed in the MsiPackageCertificate table?

A: Yes.

Q: Can a UAC compliant package add certificates?

A: No. UAC compliant packages are considered to be per-user packages; hence do not require admin credentials. So, they do not have the ability to add certificates.

Q: Can you uninstall multiple packages in a transaction with just 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.

[Author: Hemchander  Sannidhanam]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

Why Multi Package Transaction?

Application vendors who compose their applications from multiple MSI packages should find this blog interesting. Currently Windows Installer does not provide a mechanism for installing multiple packages in a single transaction. This blog will talk about how Windows Installer has exposed the ability for multiple packages and patches to be part of a single transaction. Please go through the attached slide deck to get a high level overview of what problem space this new functionality addresses.

Overview of Windows Installer Transaction Terminology

Acquisition Phase

During this phase, Windows Installer analyzes the MSI package and the machine state and composes the list of operations that need to be performed to the system to install the package. Costing is an example of an activity that is run during this phase.

Execution Phase

During this phase, Windows Installer uses the list of operations created in the acquisition phase to change the system. As it is making those changes, it also creates a list of undo operations that it can use if the install fails. Copying the files, updating the registry keys and such are the activities performed in execution phase.

Commit Phase

This is the time when the transaction is committed to the system. For example, committing the assemblies to the GAC, or running the commit custom actions constitute this phase. Note that this is a point of no return. Any failures here are not guaranteed to be undone.

Rollback

Windows Installer supports transactional installs because it can rollback a transaction upon failure. That’s primarily because, it stores off undo operations for any changes that it makes to the system.

How can I use it?

In this section I will use several walkthroughs to bring forth how the new MsiBeginTransaction and MsiEndTransaction API work.

A simple walkthrough

1.       A setup author who wants to install multiple MSI packages as part of installing a single logical product, would request the Windows Installer service to start a transaction by calling the new MsiBeginTransaction API. By calling this API, the setup author requests Windows Installer to install subsequent packages as part of the transaction that was started by the call to MsiBeginTransaction.

2.       The setup.exe that started the transaction now calls MsiInstallProduct.

3.       Windows Installer runs the acquisition and execution phases to the MSI package that was requested to be installed. The net effect of this is:

a.       Costing actions like CostInitialize, FileCost, CostFinalize, InstallValidate are run on a per-package basis.

b.      When script execution actions like InstallExecute, InstallExecuteAgain, or InstallFinalize are run, the machine state is altered, files are copied/patched/upgraded, registry keys installed/modified and the product is published.

4.       Windows Installer defers the commit phase for the package until a later point of time. What this means is that if there are any assemblies or commit custom actions in this package, they will not be run now.

5.       The setup.exe can queue up more packages/patches to this transaction by calling API like MsiInstallProduct, MsiApplyMultiplePatches, etc.

6.       If the setup.exe is done with installing the product, it then calls MsiEndTransaction to commit and complete the transaction. At this point the commit phases of each of the packages is run in the order in which their install requests were made in steps 2 and 5 above.

This walkthrough summarizes the following aspects a multi-package transaction:

1.       Acquisition and execution phases are run on a per-package basis.

2.       Acquisition and execution happens right away. I.e., when a call to MsiInstallProduct returns successfully while running a multi-package transaction, you know that acquisition and execution phases were complete for that package.

3.       Commit level dependencies cannot exist between packages that are part of a multi-package transaction.

4.       Commit phases of all the packages that are part of a transaction are run in FIFO order. i.e., commit phase of the first package on which MsiInstallProduct was called will be run first before moving onto the commit phase of the second package.

A rollback walkthrough

1.       A setup.exe calls MsiBeginTransaction API.

2.       The setup.exe that started the transaction now calls MsiInstallProduct to install Required.msi. Let us assume this call succeeded.

3.       Setup.exe now calls MsiInstallProduct to install AnotherRequired.msi. Let us assume this call also succeeds.

4.       Now while doing some other work on its own, let us assume that the setup.exe determines that it should rollback the transaction. At this point, Setup.exe calls MsiEndTransaction to rollback and end the transaction.

5.       At this point, Windows Installer will run the rollback operations of both AnotherRequired.msi and Required.msi in that order.

This walkthrough summarizes that:

1.       Rollback can be deferred.

2.       Rollback operations are executed in LIFO order.

 Optional Package Failures

1.       A setup.exe calls MsiBeginTransaction API.

2.       The setup.exe that started the transaction now calls MsiInstallProduct to install Required.msi. Let us assume this call succeeded.

3.       The same setup.exe now calls MsiInstallProduct to install optional.msi.

4.       While installing optional.msi, let us assume Windows Installer encounters an error. This error could be either because, user canceled the install or because of some other reason altogether. In any case, Windows Installer rolls back the install of optional.msi.

5.       Based on the return code from MsiInstallProduct, Setup.exe learns that there was a failure while installing optional.msi. However, it chooses to continue the product install and disregard the failure due to the optional package.

6.       Setup.exe now calls MsiInstallProduct to install AnotherRequired.msi. Let us assume this call succeeds.

7.       When Setup.exe is done with installing the product, it calls MsiEndTransaction to commit the transaction. At this point, Windows Installer will run the commit phases of both Required.msi and AnotherRequired.msi.

This walkthrough summarizes that every package/patch install run during a multi-package transaction is optional. Failures in those API will not rollback the entire transaction.

Subsequent blogs will attempt to capture other areas of the multi-package transaction.

[Author: Hemchander  Sannidhanam]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

Yesterday was April Fool’s Day. Jenny’s family has a long history of playing jokes on that day. My family does not. As a result, I’m not particularly good at pulling off an elaborate (or even simple) practical joke and Jenny has her guard up all day. This year was different.

When I came home from work, Jenny was on the phone with her mother discussing the practical joke that her mom’s co-workers had pulled off. Apparently, when she got into work Jenny’s mom was told there was a great sales lead for a guy named “Harry Lyon”. Jenny’s mom immediately made the call and reached a woman. Jenny’s mom asked for “Mr. Lyon” and listened to the woman on the other side sigh. “Do you know where you’ve called?” the woman asked.  “No, I’m just trying to reach Harry Lyon.” The woman sighed again and responded, “This is the zoo. We get a few of these calls every year on April first.”

Apparently, “Sally Mander” is another common name for a sales lead at the zoo.

I was through the whole first paragraph of my blog post yesterday before Jenny finished talking on the phone. She came over and asked how my day went. This is the point where all my practical jokes fall down. I can’t help grinning. So I did my best to keep a straight face and simply turned the laptop so that she could read it.

A couple seconds later Jenny looks at me and says that she fully supports my decision to quit and asks what happened that I chose to make this decision so suddenly without time to discuss it with her. In case you’ve missed this comment on this blog before let me reiterate, I have an incredibly wonderful wife. There is no better response a man could ask for from his wife.

Of course, I quickly broke out in a grin and Jenny immediately knew she’d be had. She couldn’t believe it since she had just finished talking to her mom about April Fool’s jokes. Jenny immediately jumped up and called her mom to happily commiserate.

The hardest part about actually finishing the blog entry was coming up with a way to have people know it was a joke without immediately giving it away. The idea of using Twitter jumped out at me since I just joined and started posting to it last Friday. Why not introduce everyone to my new Twitter feed at the same time telling them:

today do not believe everything you read online.

That was fun. I apologize for any trouble my little fun might have caused you. I found many of the comments you all sent me interesting and will revisit some of in future blog entries. In the meantime, keep coding.  You know I am (at Microsoft).

 

Original post by Rob Mensching

So after 9 years of challenges and triumphs I have finally decided it is time to step away from Microsoft. I had a blast at Microsoft’s Open Source Day 2008 (also told by John Lam) and after it all I felt like I had accomplished a lifetime’s worth of achievements. It is now time to seek out new challenges.

I do plan to stay active in the WiX toolset while I search out that next opportunity. Maybe I’ll finally make time to work on that book about the WiX toolset that I always wanted to write. Yeah, maybe…

Anyway, to all those people that I worked with but didn’t get a chance to say goodbye, don’t be strangers. I’ll still be in the area and would love to see you. Wish me luck!

In the meantime, keep on coding, you know I am.

 

PS: You can now follow me more on Twitter.

 

Original post by Rob Mensching

Windows Installer 4.5 chat is due in another two days. The MSDN Technical Chat is scheduled on April 3, 2008 at 10:00 AM (Pacific). Click here to add the chat to your calendar so you don’t miss it!

[Author: Hemchander Sannidhanam]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team