Visual Studio 2008 GenerateBootstrapper task and UAC

I am extremely disappointed in the Visual Studio 2008 bootstrapper to say the least. While the concept of a bootstrapper is great, it is obvious that the designers did not look at real-world deployment scenarios.

Let me give one example scenario: Installing prerequisite packages and interacting with Vista's User Access Control (UAC). Most of the time, the author of the bootstrapper (by the way that packages are authored and selected) is pretty confident as to how things are required (and I use the word required here very specifically) to be installed: per-user or per-machine. In some cases, such as the .NET framework and many third party redistributables, this is a per-machine only situation. Perhaps some components could be installed per-user, but generally if one part is installed per-user, then all parts capable of being installed per-user should be.

The above understanding should certainly be incorporated as part of a bootstrapper from the start. If some components require a per-machine installation, UAC should be prompted for once, start the elevated process, and this elevated process could be 'commanded' by the non-elevated bootstrapper main process. If per-user components exist, the option to install all of them could be given to the user, and appropriate ALLUSERS=x or command line arguments could be passed to the chained installations capable of doing per-user installations, and the elevated or non-elevated boostrapper process is used based on the requirements of the package and user selection.

Instead, the VS 2008 bootstrapper prompts for elevation of each chained installation, even though the entire POINT of a bootstrapper is a single entry point and interaction for the user to get a piece of software installed onto a users machine. We as developers consider setups a massively coordinated symphony of prerequisites and third party components. The user considers software they purchase or wish to install as a single piece and a single process, and it should seem this way to them.

For setups that are rather long and/or chained-installation heavy, prompting after each chained installation is aggravating to the user and is completely unnecessary from their perspective. This design flaw requires the user to babysit the entire process. We as developers hope that the user chooses to elevate each one - if not the entire setup fails with a rather hopeless error message requiring a support call.

Corporate users are the only ones who generally care about per-user installations, and generally can follow a dependency chain of installations to push apps to the users. Most of them will NOT use our generated bootstrapper, anyway.

The point of this post is to tell you how to work around the 'elevate for each' behavior of the generated setup.exe by hacking the setup bootstrapper used by the MSBuild GenerateBootstrapper task so that it prompts for elevation once at startup and installs everything elevated. This is not ideal because sometimes it is not necessary to elevate, but it certainly makes the end-user result better for the 'happy path' for 99% of all users.

Normal caveats apply - if you break something, its not my fault. Keep a backup of all modified files. The solution presented here will change the behavior for ALL GenerateBootstrapper build tasks unless as part of your msbuild script you replace the appropriate file with the version that gives you the appropriate results.

The Windows SDK actually contains this bootstrapper, and it can be located here on a default installation on a 'normal' PC: C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Engine\setup.bin. Copy this somewhere and rename it to setup.exe. In Visual Studio 2008, do a File->Open->File and find your setup.exe. This will open up a resource viewer/editor. The RT_MANIFEST 'folder' is what you want to expand. Right-click on "1" and export it, saving it as a text file. Open the text file and find the requestedExecutionLevel node - change the level attribute's value to 'requireAdministrator'. Use CTRL-A and CTRL-C to copy the contents of this file to the clipboard. Back at the resource editor, double-click the '1' entry to get it in the hex editor. Select all but the first three bytes and paste your clipboard contents in there. Save and exit. Now rename the setup.exe back to setup.bin and replace the original file, saving a backup, of course. The next time your build happens, the setup.exe will now use the new manifest, giving you one prompt and doing EVERYTHING elevated.

I won't get into the other issues with this bootstrapper - no autogeneration of MSI logs, no timestamps in its own log, immediate run and exit that hinders seld-extracting archive packages for single-file download, no MSI caching for patch scenarios like the Office team uses, spanning over multiple CDs/DVDs etc. I will wait for Wix 3.5's Burn to hopefully resolve these issues and the ones not mentioned. Rob Mensching, are you listening? I'll even volunteer to help write it.

Turning off Data Execution Prevention (DEP) for IE7 on Vista x64

Time flies so fast that you dont even realize you have not written a new blog entry in a very long time...  

In January of 2007, I posted a comment to a security blog relating to the difficulty in turning off DEP in the 32-bit version of Internet Explorer 7 on a Vista x64 OS.  As to why you would want to do this, I will offer no opinion and would not recommend it in general for long term use.  However, lets say that your 32 bit IE (on Vista x64) opens and immediately crashes for some reason.  This means you need to tweak settings (like removing an add-in) for the 32-bit IE, yet the control panel only offers the 64-bit IE settings. Normally, you can get to the 32-bit settings from inside a 32-bit browser instance but due to the immediate crash this is not possible.

A very astute individual came across my comment and since comments were closed on the initial post, sent me a how-to guide for accessing the 32-bit IE settings in Vista x64.  I offered to re-post the details here with attribution.  Kudos to Razvan Socol, a SQL Server MVP, for providing this solution after encountering the same problem (after "blindingly following the advice in the Security Advisory 961051"), which makes this post fairly timely in case someone else falls into this trap:

To access the options for the 32-bit Internet Explorer, I started an elevated command prompt and executed C:\WINDOWS\SYSWOW64\EXPLORER.EXE /SEPARATE to execute Windows Explorer in 32-bit mode. In this window, I navigated to the Internet Explorer icon on the desktop and by right-clicking it, I accessed the Internet Options for the Internet Explorer 32-bit, where I could finally uncheck that box.

 

I'd like to post a comment on Michael's blog to share this info with the world, but the comments are closed for that post. Anyway, I thought at least I should let you know on how to solve that problem, although I'm sure you have solved it in another way by now... [ed: I actually did not find an easy way to do it previously outside of several registry tweaks]

Software Product Lines

This is the first of a series of articles on an approach to systems architecture called “Software Product Lines.” To introduce the concept, let’s ignore the word “software” for now and focus on what a product line is in a more general and tangible fashion.

If you are in the market for a laptop and go to Dell’s website, you have a choice of several different base models that can be configured to your specification. Once you select the base model, you can configure things such as the size of RAM, size of the hard drive, type of display, etc. What makes this possible is a hardware architecture of various components that can fit into the same slot – compatible electrically as well as physically. This allows Dell to create and mass produce (or purchase) several standardized components and simply plug them together to create a customized product at a reasonable cost in a short timeframe. When new technologies come out that require changes to the base product, like ATA laptop hard drives, Dell spins up a new product line with that one modification reusing the old technology and components that is still valid, tried, and true. This sounds like a great idea and solid common sense, doesn’t it?

As with anything, there are challenges to this approach. Take for instance a design flaw in one of the more heavily shared components, such as the motherboard, where the power connector solder joints go bad due to heat and constant plugging/unplugging. This one design flaw could end up costing dearly in repair and possibly recall expenses, as a significantly higher number of devices are impacted then if the system was not as modular. It is also significantly more difficult and time consuming up-front to design, build, and test a system that shares components. In a product line, tight adherence to specifications needs to be considered for future compatibility. Take for example the wireless network/Bluetooth riser cards found in many laptops. Let’s assume the bus timings are just a hair off spec, but the current crop of hardware is tolerant of it. Newer technologies coming out six months later may not be tolerant. A non-product line approach would be to make a revision of the entire system – which is required anyway; however, the product line approach requires significant expense to revise and test one or both of the components to assure compatibility.

Software is not very different than hardware when it comes to product lines. Most high-end software packages are heavily customizable so it can integrate into a variety of environments. Microsoft’s SharePoint product is one example, SAP is another. These two products are off-the-shelf packages intended to appeal to a very large market. There was heavy up-front investment by the vendor in design, documentation, interfaces, components, external training and certification programs, and more. But what if your product is very specialized with a small market? Even worse, what if your product is designed for small to medium sized businesses that typically can’t afford or will not have the resources to self-customize such a vast system? To top it all off, certainly, you cannot afford to invest in the amount of up-front work required to build, test, and debug a heavily customizable system given the small size of your target market.

Enter the concept of Software Product Lines. It is important to note that this is an engineering approach to solve a specific business problem. Using the Software Product Line methodology in a business environment that is not controlled or the problem domain of the customer is not well understood will cause you to paint yourself into a corner with no easy or cheap way out. Another salient comment is choosing this approach should not significantly change your development methodology (assuming, of course, that you have adopted a legitimate methodology in the first place). Finally, this approach is NOT a method of implementation, merely a way of thinking from a design perspective of what needs componentized. The decision to use a Service Oriented Architecture to implement a Software Product Line is off-topic – these are two different animals entirely.

Part II of this series will delve into some of these concepts deeper.

Go Steelers Redux

Not only has it been a long time since my last post, but it has been exactly a year since my last post on my hometown NFL football team, the Pittsburgh Steelers. Sadly, last year we lost the AFC championship. This year we won it against the Denver Bronco's. This means we are off to the Super Bowl against the Seattle Seahawks. Superbowl XL is on February 5th, 2006. In preparation, my blog banner has been updated to "All Steelers, all the time" from the revolving banner of the past.

One of the great things about living in (or coming from) the Pittsburgh area is the friendliness of the people in and around the city. Last year, I blogged a bit about Myron Cope and the "Terrible Towel." One thing I neglected to mention is that all proceeds on the sale of the towel go to the Allegheny Valley School that provides care for children, adults, and seniors with mental retardation and physical disabilities. If you would like to support the Steelers, and the school, please use the above link (instead of the Google AdSense ones) so that the school gets additional credit.

I believe the Steelers have been playing for the 'Bus' - a.k.a. running back Jerome Bettis. The Bus has been a Pittsburgh fixture for years, not only as a dependable player, but as an excellent example of what a celebrity should be like. To illustrate my point, Hines Ward (a teammate and Steelers Wide Receiver) was in tears last year after the AFC Championship loss because he believed the team let Jerome down in his potentially last season. This year is different. Jerome will have the opportunity to play, and in his home city, Detroit. Jerome is active in the community, and is currently raising awareness about Asthma, a disease he is afflicted with, in addition to a program called "The Bus Stops Here," benefiting children from both Pittsburgh and Detroit. Jerome's parents, Gladys and John, have every reason to proud of their son, and the values they instilled in him.

Other team members have had tremendous impact on the Pittsburgh region. I don't want to leave out any players, but Charlie Batch, a backup quarterback, is also famous for not only coming from the Pittsburgh area, but for his contributions to it. There are several other examples of how the team and its players gives back to the community.

I believe much of the reason for the positive impact of the players of the Steelers goes back to the team's ownership and philosophy. The most famous owner is Art Rooney, a.k.a. "The Chief", who bought the franchise in 1933. If any Pittsburgher's have not yet seen the play "The Chief" at the Pittsburgh Public Theatre, you don't know what you missed! This play ran in 2003, 2004, and earlier this month - keep checking for it to return (possibly) next fall at the PPT website. Franco Harris (star player in the 70's) was talking about Art Rooney when he said, "He was always there to help and to give. And this feeling filtered down to the players. I think the Steelers' players give more to their community than any other team in professional sport."

I'm hoping that the Super Bowl in a few weeks does not bring on any additional heart attacks among the fans, but that you watch it with the understanding that many of the athletes on both sides of the ball are using their celebrity status and monies to better their communities. I think we can all learn from this.

To my readers in the Seattle/Redmond area - I didn't mean to leave out the players of your team, I merely am not familiar with their good works. I am, however, familiar with Victor's Celtic Coffee Company, and am currently out of the "Redmond Slough" blend as of this morning. I'd be willing to trade for some of that in exchange for posting Seattle Seahawks charity links and an equivalent amount of coffee from one of our local coffee houses (Coffee Tree Roasters)...

Go Steelers!

Silence is a virtue...

I was looking for some way of explaining my recent blog silence. As one who likes to use the words of others to explain things that are difficult to explain in my own words, I hit the quote book and encountered this gem by Sally Berger: "You never saw a fish on the wall with its mouth shut." That doesn't really fit, but I found it kinda funny and that will have to do.

In addition to the typical excuse of the holidays, I also recently changed employers. This has the side effect of changing the type of development I do. Keeping with my philosophy that I speak only for myself and not my employer, I will not divulge the name of my current employer. I will also not divulge anything that could be considered something other than generally available developer knowledge. So in reality, the only thing that could possibly change is the type of content.

Most likely I will be delving into topics such as .NET Development, the Compact Framework, and native Windows Mobile (Windows CE) development/debugging. Some of these postings may be about deployment concerns in the Windows Mobile environment. Content suggestions related to this area of development are welcome. I also plan on finishing up a few posts on MSI related subjects I started a while back after some editing and reviewing.

If you have questions regarding MSI of other installer technologies, please keep them coming - many of the privately asked (and answered) questions I have saved as blog post drafts to be completed later, and I will continue to attempt to answer them time permitting.

In the meantime, constant reader, please bear with me while I adapt to my new environment and gather together some new (and old) content.