Setup Related Blogs

Today Acresso extended the upgrade discount offer (10% off the upgrade price) that is available through the end of September (for AdminStudio: end of October) to the following product versions:

• InstallShield Express: versions 11, 11.5, 12, 2008
• InstallShield Professional and Premier: versions 11, 11.5
• InstallAnywhere Standard and Enterprise: version 7.0
• AdminStudio Standard, Professional and Enterprise: versions 7.x, 8.x

In addition, owners of old InstallShield, InstallAnywhere and AdminStudio versions that are past end-of-life and no longer qualify for upgrade pricing can get 30% off the price of the full product during the same time period.

Please contact your preferred reseller for the appropriate discount codes.

You can buy InstallShield, InstallAnywhere and AdminStudio in the InstallSite Shop

On August 29, 2008 Acresso released version 9.0 of AdminStudio Enterprise, Professional and Standard editions.

• AdminStudio 9 Release Notes (PDF)
• Webinar: What's New in AdminStudio 9.0 and Workflow Manager 5.0
  Registration required. WARNING: Anyone who knows your e-mail address can retrieve the information you entered during registration, so be careful what you enter as address, phone number, company revenue, etc.

At the same time, Acresso announced the end of life of AdminStudio 7.0 and 7.5. This includes Enterprise, Professional and Standard Editions. To stay current with the latest Acresso release, AdminStudio 7.x users can purchase the latest version of AdminStudio at the upgrade price through December 31, 2008. After December 31, 2008, they will need to purchase a new license of the latest version of AdminStudio at the regular full license price in order to stay current.

• AdminStudio End-of-Life Notice
  

You can buy AdminStudio in the InstallSite Shop

On August 27, 2008, Acresso announced the end of life of InstallShield 11 and 11.5. This includes Premier, Professional and Express Editions and all languages of these Editions. Acresso also announced the end of life of InstallAnywhere 7.x.

To stay current with the latest Acresso release, InstallShield 11.x and InstallAnywhere 7.x users can purchase the latest version of InstallShield (for Windows support) or InstallAnywhere (for multiplatform support) - depending on their existing version and edition - at the upgrade price through December 31, 2008. After December 31, 2008, they will need to purchase a new license of the latest version of InstallShield or InstallAnywhere at the regular full license price in order to stay current.

• InstallShield End-of-Life Notice
• InstallAnywhere End-of-Life Notice

Special upgrade discount through September 30, 2008

Customers who want to upgrade from InstallShield 11.x or InstallAnywhere 7.x to the latest version can get an extra 10% discount off of the upgrade price when ordering before September 30, 2008 (please contact your preferred reseller for discount code).

You can buy InstallShield and InstallAnywhere in the InstallSite Shop

On August 27, 2008 Acresso released version 2009 of InstallShield Express, completing the InstallShield 2009 product family: Premier, Professional and Express.

New features in this version include:

• Setup Prerequisites based on feature selection
• Visual Studio 2008 support
• MSI 4.5 Support
• Adobe Flash support on billboards
• Windows Mobile 6.x support and other improvements for Windows Mobile
• Value Added Service - you can (optionally) install the Yahoo! Toolbar with your setup, which might be useful if your product is ad-funded.

Support for Adobe Flash animations on the billboards that are displayed during file copy is currently only available in the Express edition.

Webinar: What's New in InstallShield 2009 Express Edition 
Registration required. WARNING: Anyone who knows your e-mail address can retrieve the information you entered during registration, so be careful what you enter as address, phone number, company revenue, etc.

You can buy InstallShield in the InstallSite Shop

On August 19th, 2008 Caphyon Ltd. announced the latest edition of its Windows Installer authoring tool. The new Advanced Installer enables developers and system administrators to easily build and repackage complex applications into reliable, ready to deploy MSI and EXE installers, patches and on-line updates.

The 6.5 version completes the full implementation of Windows Installer
4.5 features. Embed multiple MSIs in a unified setup package and install them chained in a single, atomic transaction.

A new WiX import feature helps you leverage existing installer projects while at the same time giving you access to the numerous Advanced Installer features and capabilities.

Collect user information during install and POST it to your server with the included predefined Custom Action. With just one click specify your software dependencies using one of the newly added prerequisites and launch conditions.

Other improvements in this version:

• Complete Windows Installer 4.5 feature support
• WiX projects import
• .NET Native Image Generation 2.0 support
• .NET Native Image Generation support for assemblies installed in GAC
• User info collection and retrieval custom action
• Support for discrete "INI entry removal" operation
• Windows Installer 4.5 predefined Prerequisites
• SQL Server compact edition predefined prerequisite
• Visual C++ 2005 SP1 redistributable predefined prerequisite
• Visual C++ 2008 redistributable predefined prerequisite
• MS XML Parser predefined prerequisite
• Acrobat Reader 9.0 predefined prerequisite
• Acrobat Reader 9.0 predefined launch condition
• DirectX predefined launch condition

Advanced Installer is available in four editions, starting with the Freeware community edition and offering a 30-day trial period for the other editions.

For more information about Advanced Installer please see:
www.installsite.biz/advancedinstaller.htm

 

(Text based on a press release from Caphyon Ltd.)

Error code 1335 means: "The cabinet file '[2]' required for this installation is corrupt and cannot be used. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package."

Software maker Encore, Inc. recommends a "clean install" to fix this problem:

When attempting to install The Print Shop® 22, an error that includes the message "Error 1335..." appears. A conflict during the installation may cause this issue. Completing a clean installation of the program will help to prevent conflicts that can occur. The remainder of this note describes the procedure.

Complete the steps below to reduce conflicts during the installation.

Clean the CD or DVD

1. Place a small amount of nonabrasive, liquid soap on the shiny side of the CD or DVD.
2. Using your fingertips and warm water, gently rub the soap on the disc in a circular motion.
3. Rinse the disc thoroughly and dry it using a clean, soft T-shirt or lint-free towel. Do not use paper towels or tissue paper.
4. Install the program.

I couldn't help but laugh when I read these instructions for a "clean install". But seriously: Cleaning the CD might actually help if the error is caused by stains on the CD.

As you all may already know the final release of the Windows Installer 4.5 Redistributable and SDK are now available.

The current version of Windows Installer is in the form; major.minor.build.update. We have received a few questions regarding the differences in the "build" and "update" fields of the version of Windows Installer 4.5 installed across different supported Windows Operating Systems . I will try to explain what these differences are and why they are expected.

The Windows Installer 4.5 redistributable can install on the following Windows Operating Systems:

Target Operating System	Windows Installer 4.5 version
Windows Vista RTM	4.5.6000.20817
Windows Vista SP1, Windows Server 2008	4.5.6001.22162
Windows XP SP2, Windows XP SP3, Windows Server 2003 SP1, Windows Server 2003 SP2	4.5.6001.22159

Windows Vista RTM build number is 6000, while Windows Vista SP1 and Windows Server 2008 RTM are build number 6001. Hence, to comply with the different OS build numbers and applicability logic on Vista RTM and Vista SP1/Server 2008 operating systems, the Windows Installer binaries are built from the Vista RTM and Vista SP1 servicing branches respectively.

The "update" field is based on the OS revision number.  Since the redistributable packages to install Window Installer 4.5 on the different target operating systems are built from different Windows servicing branches, the revision number is different for each.

However, the different versions have no effect on the functionality provided by Windows Installer 4.5.

[Author: Zainab Hakim]
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.

Hi, I'm Zainab (pronounced Zay'nab) and I am the test engineer for the Windows Installer (MSI) team. I have been a part of the MSI team for just a little under 3 years now. I love coming in every day to my job and working on the technology that significantly affects a variety of customers worldwide and enables them to provide a great installation and configuration experience of their applications.

I served as the test lead for Windows Installer 4.5 out-of-band release, which is the latest release of Windows Installer. This article describes all the new and improved features of Windows Installer 4.5. 

In addition to contributing to the Windows Installer Team blog <grin>, I also look forward to the future challenges in the application deployment space and working on the next generation application model.

If you need to repair Visual Studio 2008 once SP1 has been applied or wish to change which features are installed, you cannot run setup.exe from the original installation media.

When you run repair from media you may see an error like, "A problem has been encountered while loading the setup components. Canceling setup."

Workaround

Open the Control Panel and go to Add/Remove Programs, or on Vista click on the "Uninstall a program" link under Programs. Find Microsoft Visual Studio 2008 (the exact product name will vary based on edition and language installed) and click on the Uninstall/Change button. When setup launches and components are loaded, you will be asked to repair, change features, or uninstall. Choose the option you which to perform and continue as directed.

Details

Visual Studio is actually a collection of different installation packages, just as VS2008 SP1 is a collection of different installation packages. VS2008 SP1 replaces some of the original packages using minor or major upgrades and patches other products. This changes information about the products originally installed like the ProductCode and/or ProductVersion. This affects the detection logic that setup.exe uses to determine what to do when installing, repairing, or uninstalling the product.

This information is stored both on the installation media as well as on your hard disk under the target installation directory. For various reasons including that media is often write-protected, we can only update this information stored on your hard disk. So once SP1 is installed, the detection and package information on the installation media and on your hard disk are out of sync and only the copy on your hard disk contains the correct information.

Some customers are reporting that Microsoft Visual Studio 2008 SP1 is failing to install with the following error in the HTML log you can view from the error dialog.

Patch (C:\Users\heaths\AppData\Local\TEMP\WebDesignerCore_KB950278.msp) install failed on product (Microsoft Office Enterprise 2007). Msi Log: Microsoft Visual Studio 2008 SP1_20080816_141317516-Microsoft Office Enterprise 2007-MSP0.txt

Final Result: Installation failed with error code: (0x80070663), This update package could not be opened. Verify that the update package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer update package.

Workaround

Most often this happens because a patch package is missing from the Windows Installer cache and is required to install a new patch. In this case, the Windows Installer cache must be rebuilt.

While the method to determine which packages have to be restored is fairly generic, these following instructions are specific to Office to serve as an example and because this seems to be the most common case given the likely cause described in the next section, Prevention, and the size of Office 2007 SP1 patch packages.

1. Click on the link to the log file right above the line beginning with "Final Result". A file should open where the majority of lines begin with "MSI".
2. Search for "SOURCEMGMT" (without quotes). A few lines above it should note the missing package. For example (highlight added for emphasis):
   Couldn't find local patch 'C:\WINDOWS\Installer\3bb98.msp'. Looking for it at its source.
3. Search ahead from that point for "2203" or "1706" (without quotes). Note the file name within that line. For example (highlight added for emphasis):
   Note: 1: 2203 2: C:\Temp\OWP15A.tmp\MAINWWsp1.msp 3: -2147287037
4. In this example, MAINWWsp1.msp is part of Office 2007 SP1. If you find a different file name, search the web for any references to that file to determine what to download. Be sure you only download packages from their original manufacturers' web sites. In this example, download http://www.microsoft.com/downloads/details.aspx?FamilyID=9EC51594-992C-4165-A997-25DA01F388F5 to %TEMP%.
5. Open an elevated command prompt a change directories to %TEMP%:
   cd %TEMP%
6. Extract the contents of the executable package; note that the file name will differ based on the language you downloaded:
   office2007sp1-kb936982-fullfile-en-us.exe /extract:"%TEMP%\office_2007_sp1"
7. Copy MAINWWsp1.msp to the location where Windows Installer was originally looking. In this example above, that location is C:\WINDOWS\Installer\3bb98.msp. Remember that this location will vary so you need to check your log file as described above.
   copy "%TEMP%\office_2007_sp1\MAINWWsp1.msp C:\WINDOWS\Installer\3bb98.msp

Now try installing VS2008 SP1 again.

Prevention

While there are potentially other reasons packages might be missing from the Windows Installer cache in %WINDIR%\Installer, the most common cause is when those files are deleted to free up disk space. Those files directly under %WINDIR%\Installer are required for Windows Installer to function properly for all maintenance installations, which is everything after initial install including patch install, patch uninstall, repairs, changes to feature selection, and even product uninstalls. These files must not be removed.

If you need to free disk space, be sure to run the Disk Cleanup utility in your your Accessories / System Tools programs folder first. You can also uninstall old and unneeded applications.

Because Windows Installer may require a lot of space on your system drive, be sure to partition your hard disk with plenty of space not just for Windows or Windows Installer, but also because a lot of applications may install to Program Files or Common Files which are, by default, on your system drive.

Details

Windows Installer will always open every patch registered to a product whether or not it has already been obsolesced or superseded when opening a product or package handle (as long as machine state is not ignored). When performing a maintenance installation, a product is opened and all patches registered to that product are opened. If one or more of those patch packages is missing from the Windows Installer cache, Windows Installer attempts to resolve the location as you can see from the log below.

MSI (s) (D4:98) [14:17:19:688]: Opening existing patch 'C:\WINDOWS\Installer\3bb98.msp'.
MSI (s) (D4:98) [14:17:19:688]: Note: 1: 2203 2: C:\WINDOWS\Installer\3bb98.msp 3: -2147287038
MSI (s) (D4:98) [14:17:19:688]: Couldn't find local patch 'C:\WINDOWS\Installer\3bb98.msp'. Looking for it at its source.
MSI (s) (D4:98) [14:17:19:688]: Resolving Patch source.
MSI (s) (D4:98) [14:17:19:688]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (D4:98) [14:17:19:688]: User policy value 'DisableMedia' is 0
MSI (s) (D4:98) [14:17:19:688]: Machine policy value 'AllowLockdownMedia' is 0
MSI (s) (D4:98) [14:17:19:688]: SOURCEMGMT: Media enabled only if package is safe.
MSI (s) (D4:98) [14:17:19:688]: SOURCEMGMT: Looking for sourcelist for product {BEE75E01-DD3F-4D5F-B96C-609E6538D419}
MSI (s) (D4:98) [14:17:19:688]: SOURCEMGMT: Adding {BEE75E01-DD3F-4D5F-B96C-609E6538D419}; to potential sourcelist list (pcode;disk;relpath).
MSI (s) (D4:98) [14:17:19:688]: SOURCEMGMT: Now checking product {BEE75E01-DD3F-4D5F-B96C-609E6538D419}
MSI (s) (D4:98) [14:17:19:704]: SOURCEMGMT: Media is enabled for product.
MSI (s) (D4:98) [14:17:19:720]: SOURCEMGMT: Attempting to use LastUsedSource from source list.
MSI (s) (D4:98) [14:17:19:720]: SOURCEMGMT: Trying source C:\Temp\OWP15A.tmp\.
MSI (s) (D4:98) [14:17:19:720]: Note: 1: 2203 2: C:\Temp\OWP15A.tmp\MAINWWsp1.msp 3: -2147287037
MSI (s) (D4:98) [14:17:19:720]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
MSI (s) (D4:98) [14:17:19:720]: Note: 1: 1706 2: -2147483647 3: MAINWWsp1.msp
MSI (s) (D4:98) [14:17:19:720]: SOURCEMGMT: Processing net source list.
MSI (s) (D4:98) [14:17:19:720]: Note: 1: 1706 2: -2147483647 3: MAINWWsp1.msp
MSI (s) (D4:98) [14:17:19:720]: SOURCEMGMT: Processing media source list.
MSI (s) (D4:98) [14:17:25:470]: SOURCEMGMT: Resolved source to: 'MAINWWsp1.msp'
MSI (s) (D4:98) [14:18:57:126]: Note: 1: 1314 2: MAINWWsp1.msp
MSI (s) (D4:98) [14:18:57:126]: Unable to create a temp copy of patch 'MAINWWsp1.msp'.
MSI (s) (D4:98) [14:18:57:141]: Note: 1: 1708
MSI (s) (D4:98) [14:18:57:141]: Note: 1: 2729

Failing to resolve the source location for the patch, Windows Installer returns error code 1635 (ERROR_PATCH_PACKAGE_OPEN_FAILED).

Often the simple solution is to find and restore the package to where Windows Installer expected to find it in the first place: back in the Windows Installer cache under %WINDIR%\Installer. You could also put it in the other locations where you see "SOURCEMGMT: Trying source".

All files directly under %WINDIR%\Installer are required. To free up additional space as mentioned in why Windows Installer may require so much space, you can delete subdirectories under or even all of %WINDIR%\Installer\$PatchCache$, or even disable it for future patch installations but at the cost of prompts for original source in many scenarios. The baseline cache files are intended to provide a backup of baseline (ex: RTM) files so that when they are needed they are available. They are needed when applying patches containing binary delta patches to individual files (as opposed to whole-file updates, which are more common) or when uninstalling patches.

You can also try finding and uninstalling superseded patches. Superseded patches are not actually uninstalled when superseded - they just become inactive. This way when all superseding patches are removed with respect to these superseded patches, those superseded patches become active again. You can even install patches in an initially superseded state for this very purpose. I do have an example of detecting superseded patches using PowerShell with the Windows Installer PowerShell Extensions installed but there are other ways by calling the MsiEnumPatchesEx() function or the PatchesEx method for script automation in your own applications or scripts.

Some virus scanning application have been reporting that setup.bin is a Trojan horse containing one of the following viruses:

• Win32:Trojan-gen
• Win32:Trojan-gen {Other}
• Backdoor.Win32.VB.ffx

This file is typically installed to C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Engine\setup.bin by the Windows SDK and is actually setup.exe that has been renamed to setup.bin. This file is used when you build your own installation package that can chain install packages like .NET, Report Viewer, SQL, the VC runtime, Visual Tools for Office runtime, and Windows Installer.

Jeremy Kelley, a program manager in our Community Connections team, posted the following to an MSDN forums thread where this was reported.

Hi everyone, I know you've all been waiting anxiously for a response from us on this issue, and we appreciate your patience. Since the issue was first reported, we've been working with the AV companies to confirm the virus alert on setup.bin as a false positive.

The AV companies have all been great helping us get this resolved; with them, we are ensuring that this is properly addressed in updated virus definition files from each of the companies. While there are some scanners that are still flagging this as a virus, the majority of our partners have already updated their signatures.

For more information on which scanners have updated signatures for this, please see this site: http://www.virustotal.com/analisis/a3afa20071b67a8fa794173be1ec60d5 If you are running a scanner that is still detecting a virus in setup.bin, please watch for updated signatures from your AV vendor to resolve the issue.

Thanks to everyone who reported the issue, we appreciate the early heads up each of you have given us. I'll be around here on the thread if anyone has any other questions with this issue.

-Jeremy Kelley
Program Manager
Developer Division Community Connection Team
Microsoft

If this file was already quarantined I recommend you update your virus definitions and re-scan it. If no problems are found please restore it to its original location.

If you're on a network that uses Microsoft ISA Server or another proxy server, you may have problems downloading Visual Studio 2008 Service Pack 1. The error dialog displays the following.

The installation failed with the follow message:

Fatal error during installation.

Click the Finish button to exit.

Solution

Download and install the Microsoft ISA Proxy Client. The default settings should be sufficient, but if you have doubts or questions please contact your network administrator.

Details

The VS2008 SP1 bootstrap application relies on the Background Intelligent Transfer Service (BITS), falling back to WinHTTP then URLMon to download packages. BITS and Windows HTTP Services (WinHTTP) do not, by default, use Internet Explorer proxy settings. So even if you have Internet Explorer set to automatically detect a proxy server or have manually specified a proxy server, these protocol handlers will fail if the network administrator has enforced the proxy server; i.e., it cannot be bypassed.

These protocol handlers will attempt to automatically detect a proxy server, but if that information is not available or the system accounts were not manually configured with proxy server settings they will fail.

You can use the BITSAdmin tool to configure BITS to use automatic proxy detection or manual proxy settings like shown in the following examples.

bitsadmin.exe /util /setieproxy localsystem AUTODETECT
bitsadmin.exe /util /setieproxy localsystem MANUAL_PROXY proxy1:80 "<local>"

If BITS is not properly configured for your network proxy, you might also be getting error 0x8024402C from Windows Update.

Because BITS is robust, it is preferred to download packages for VS 2008 SP1; but if you'd like to configure WinHTTP to use the current IE proxy settings, you can use the Proxy Configuration Tool like shown in the following example.

proxycfg.exe -u

Another solution if you're on a network that uses ISA Server is to install the Microsoft ISA Proxy Client which should properly detect the proper proxy server settings and configure both the current user and machine accounts to use the correct proxy servers. If it does not, please contact your network administrator.

---

Updated: first reconfiguring BITS or WinHTTP to use the correct proxy is the recommended approach before installing the ISA Proxy Client. The ISA Proxy Client is only supported for ISA-protected networks. Since this problem is not limited to ISA proxies installing the ISA Proxy Client may not work on your network.

When I announced that Visual Studio 2008 SP1 RTM will install over SP1 beta, we were on track to make that reality. However, when SP1 beta shipped we found that adding new components into existing features was causing a prompt for source for non-default installations of Visual Studio 2008. To fix this, we would have to remove those components and put them into a new feature. This, in turn, causes the installation to not actually update most files if the beta was installed because it advertises the features.

After a lot of discussion, we decided that because a prompt for source is a blocking issue for more customers that installed the beta we would block SP1 RTM from upgrading SP1 beta. To make this easier, we have provided a tool that uninstalls only certain beta patches. Not all patches need to be removed so this exercise is made simple and relatively faster than uninstalling all of the beta.

Note: you do not have to uninstall Visual Studio 2008 Express Editions with SP1 Beta prior to installing Express SP1 RTM. The tool described below for VS box SKUs does not apply to Express SKUs.

Workaround

If you installed VS2008 SP1 Beta, you will see a dialog similar to the following.

The dialog above lists all the pre-release updates that must first be removed, depending on which you have installed. It reads,

You must first use Microsoft Visual Studio Patch removal tool before installing Visual Studio 2008 SP1. The tool will verify Visual Studio integrity and remove previous Visual Studio 2008 updates or pre-release software

• Microsoft Visual Studio 2008 - KB945140 (Beta)
• Microsoft Visual Studio 2008 - KB944899
• Microsoft Silverlight Tools Beta 1
• Microsoft Visual Studio 2008 - KB949325

The tool is straight forward to use and should allow you to install VS 2008 SP1 - assuming you are running as an administrator and have applicable products installed.

Details

When VS 2008 SP1 Beta is installed it adds new components to existing features. This causes Windows Installer to install that feature, its parent features, and all those features' child features which follow their parent install state. If one of those features was not already installed, the files authored into that feature likely do not already exist on your machine. Windows Installer then prompts for source to find and install those files.

To fix this, we have to move those new components to new top-level features which always get installed.

Because a patch alters the view of the product - the installer package (.msi file) and all patch packages (.msp files) combined - those new components are now part of the product. When SP1 Beta is already installed and SP1 RTM is being installed, those new components in Beta get removed from their parent features and put into new features. Because a there is no "move" operation, it's actually a "delete" and an "add". Deleting a component, however, advertises the parent feature. The result is that any files within affected features are not updated because they are not registered as being installed locally. In fact, none of those files will ever be upgraded again until the product is reinstalled with a specially crafted command line specific to your machine, or uninstalled and then re-installed. That means no updates and no new features for a lot of the product.

Based on the estimated number of people that installed the beta and the number of people that customized their installations of Visual Studio 2008, we felt it was better to block installation of VS2008 SP1 RTM if VS2008 SP1 Beta was installed. We also block if features installed with applicable products are also already advertised since this could happen in a couple of other scenarios - like if KB944899 was installed and you then installed SP1 Beta.

The tool we have provided performs these same checks on product that SP1 updates and attempts to fix them. When uninstalling patches, however, you might be prompted for source to restore files in shared components. This happens when share components in another product were already updated. When any other products' shared components are then updated, those products' baseline caches are not updated with a backup copy of those shared files already updated. To streamline the operation, for one product where this happened 100% of the time we shipped the source but it was small - only a few megabytes. But for Visual Studio and other products which are much larger overall, note the title of the source prompt dialog, insert your installation media (network installs likely won't cause prompts), and browse to the path of that product. Typically this will be vs_setup.msi in the root directory for the drive containing the installation media.

---

Updated: added that users do not have to remove Express SP1 Beta prior to installing Express SP1 RTM.

I thought the next installation package I would evaluate from the inside out would be the Windows Live Writer Tech Preview. However, before I got around to that, lots of noise was made about Google Chrome's release so I thought I'd pile on and dig in. As usual, I found a few interesting things.

Initiating the download.

First, the installation experience starts by downloading a pretty small bootstrap (474 KB) executable. A bootstrap executable like this is basically required for any distribution over the Internet so the only thing interesting here is that they did not to ship the product embedded in the initial bootstrap executable. Instead, the bootstrap executable contains the Google Updater and the applications to have the Google Updater download then install. Don't forget about the Updater, we'll come back to it at the end.

One important thing to note here is that the bootstrapper is specifically marked for no elevation (<requestedExecutionLevel level="asInvoker" />). That's good because it'd be less than ideal to be downloading from the Internet from an elevated process. What's more interesting though is that there is never an elevation prompt. This means that the Google Updater, Google Chrome and Google Gears are per-user installations. I am always interested in applications that choose to go per-user since there is always a reason behind the choice (usually to avoid a UAC prompt on Vista).  ClickThrough installations are per-user and more spectacularly Live Mesh is per-user. I'll cover the details of per-user installations, why they are interesting and how they differ from per-machine installs in a future blog post.

Before going forward, going back to the very beginning, the EULA dialog is very tricky. I don't know if Google did this on purpose but notice the checkbox in the location where most installs say you must check to "Accept". It actually is the option to opt-in to sending all your usage data to Google. If a user wasn't paying close attention and was just clicking to get to the download they might opt-in to accidentally. Sneaky, if intentional.

Also, I kept looking for some place that explained that we were going to be getting the Google Updater and Google Gears with Google Chrome. Haven't found it.

Actually downloading and installing Google Chrome.

Next, the Google Updater installs itself and starts downloading Google Chrome and Google Gears. After downloading, Google Updater launches the installs for Google Chrome and Google Gears. The progress bar behavior is interesting to watch during this process. During the first initialization the progress bar enters "endless loop" mode (or "confused Cylon mode" for you BSG fans). When the download starts the progress bar fills the bar normally. Then the progress bar goes back to "endless loop" mode during the installation. That means there is no real progress during install itself.

At this point, Google Updater will have installed itself in the LocalAppDataFolder under Google\Update and pointed a HKCU\Software\Microsoft\Windows\CurrentVersion\Run key to start it on every boot. Google Chrome was installed by some opaque (presumably custom) engine using a 7-Zip package as for its data. Google Gears, however, was installed by an MSI. The MSI was created with the WiX toolset (older build) and tailored for the Chrome install location and marked to not show up in Add/Remove Programs itself. That means the Chrome uninstall is responsible for kicking off the package uninstall.  The only real problem here is that the original source MSI is deleted after the installation is complete. That means should the Windows Installer require the original source for any reason, it'll be impossible for typical users to satisfy the source prompt. I am curious why Google chose to use MSI for installing Google Gears but used some other installation mechanism to setup the rest of Google Chrome.

While all of this custom stuff provides a very hands off installation experience for consumers, it doesn't play well with serious enterprise deployments. However, the fact that this is a per-user install means that individuals can probably get Google Chrome installed on their desktops without the Google Gears MSI install since even administrators may block it (the Windows Installer respects global Group Policy settings that can prevent all installations). Of course, it's possible (I'd dare say likely) that Google wouldn't rate enterprise deployment high on their list of priorities for Google Chrome.

First boot experience.

When the install is complete, Google Chrome launches and goes into a "first boot" experience to do let the user configure their settings and migrate any existing bookmarks. This is exactly the right thing to do. I see so many applications make the mistake of trying to do this type of work in setup its refreshing to see someone get it right. I'll go into more details about settings management in the future.

Google Chrome Uninstall FAIL.

To dissect the Google Chrome setup, I had to uninstall several times. On the first uninstall, I saw that Google Chrome's "User Data" directory was left behind. This is fine and, in many cases, desirable. If there is data in there that the user may want later, leaving the data around is the best choice. An option to clean up all the data during uninstall is also a good idea especially since this is a per-user app and it can correctly clean up the appropriate user data. No big deal but that did lead me to the beginning of the badness for Google Chrome's uninstall.

First, the prompt to uninstall is a bit goofy when it asks, "Are you sure you want to uninstall Google Chrome? (Was it something we said?)". Maybe the rhetorical question fits in with the comic book introduction and the cutesy Mac-like fail screens but it certainly doesn't feel very professional. Clicking OK causes the prompt to disappear but there is no indication that Google Chrome is being uninstalled until a short bit later a web browser window pops up navigated to a Google page asking why I uninstalled. The experience is disconnected even though the uninstall is pretty quick. The extra browser launch is also a bit annoying. I wonder what type of feedback they'll get there.

However, this next issue is huge. Uninstalling Google Chrome does not uninstall the Google Updater. That means that Google Updater will start up on every login (because it's still in the Run key) even though you don't have any Google stuff to update. Unless you manually run "%LOCALAPPDATA%\Google\Update\GoogleUpdate.exe --uninstall" before deleting everything in the Google directory, you'll be left with COM goo on the machine.  The real problem is that there is no visible indication that the Google Updater is still on you machine.

Maybe this uninstall problem is just an oversight on Google's part but there is so much registration around the Google Updater that it is surprising it could be forgotten. It is especially important to clean it up because it wasn't really clear that you were getting the Google Updater when you just wanted the Google Chrome.

Conclusion

The initial installation experience didn't really impress me with its vague progress bars but overlooking the uninstall of the Google Updater really ruined my opinion of the overall Google Chrome setup experience. The clean per-user installation and appropriately timed migration experience doesn't outweigh the uninstall problem. If the uninstall just left some dormant files in a directory that'd be one thing but the Google Updater is left active on my machine after I uninstalled everything.

 

Recently Robert Scoble posted a blog entry about how Windows engineers feel Win7 is being managed differently than previous Windows releases. As I read through the list, I immediately thought, "Hey, that's just like Office." It also reminded me of an analogy I came up with when I first joined Microsoft.

Before I continue, I should note that I consider myself to heavily influenced by the "Office-way of software engineering". When discussing software development philosophies with other Microsoft employees I often say that "I grew up in Office". I believe that foundation in large scale software engineering tempered by my exposure to the "Open Source-way of software development" has been invaluable to my development as a software engineer. There was many a day when I was in Windows where I longed for the "Office-way". However, as a disclaimer, do know that I was young when I was in Office and it was a long time ago so nostalgia may have seeped into some of my memories. Also, as always, these are my feelings and views alone... others may see things very differently.

Now, back to my story.

When first at Microsoft I was trying to describe to my Mom the differences between Office and Windows. Not that one was suite of productivity applications and the other was an operating system. Instead, I was trying to explain the cultural differences across the two organizations. It amazed me how incredibly different the culture of two parts of the same company could be. I described it to my Mom back then as the "Office family" and the "Windows division".

In Office, everyone felt like a part of the extended family. I always worked on a "Core" team so the build team and UI team felt like siblings while the "Word" and "Excel" teams felt like cousins and the "Powerpoint" team felt like distant cousins (since they were down in Silicon Valley). Development managers and directors felt like "heads of the household" and the "head of the family" (Steven Sinofsky, during my tenure) all provided direction, discipline and support at their various levels. You were expected to work out issues at your level and not "go crying to daddy". In fact, escalating usually had negative consequences for all of the people involved. Overall, it felt like everyone was working together to ship a very complex and large product on time.

In Windows, it felt like there were all of these small kingdoms vying for attention and resources. Everyone felt very compartmentalized on their particular feature. The development manager and directors were necessary to exert your requirements on other team. Escalation was the norm and sometimes you'd have to go through 6 layers to get the leverage desired. Also, rigorous process seemed to be valued over developer productivity. I think the term "death march" was invented in Windows. Overall, it felt like constant battle to test the mettle of teams and the features to be delivered into the operating system.

Now, to be fair to the culture that developed in Windows, there is a serious amount of pressure to be all things to all people. Not only do you have to build features that capture the imagination of the future but you have to make sure everything that worked in the past continues to work today.  And the OS is always on. If you want to see someone take the responsibility seriously check out Raymond Chen's blog. He's one of the true Microsoft heroes.

Anyway, after I heard Sinofsky would be moving from Office to Windows I hoped that many of the changes Scoble described would occur. When I later heard that Jon Devaan was moving in to lead another part of Windows, I expected a culture change was inevitable. Why? Because the guy that led Office before Sinofsky was Devaan. I believe culture comes from the top and the Windows division got a huge injection of "family values" when Devaan and Sinofsky moved in.

Now I just hope the (IMHO) improved culture creates an incredible product.

 

PS: The Live Mesh team has a different feel than any other team I've been on. I expect that is due to Ray Ozzie's influence (remember, culture from the top). Maybe I'll write more about my feelings on the Live Mesh culture when I understand it better.

 

Almost two years ago, I took note that major life changes seemed to "get all bunched up together". I still don't understand the phenomenon but for the last couple months I've been living it again. Like last time I'm facing major updates to my life and my work.

To the left is a picture of my house. I bought this house over five years ago and it's been a great place to live for me. However, the time has come to sell and move to a new neighborhood.

It isn't that I like the house any less. Quite the contrary.  I love the location and its convenience to everything in my life.  I love the quiet street and private backyard backed up against the greenbelt. I especially love the layout and space inside the house and will miss it all.

But this has always been kinda' my house. I bought the house before meeting Jenny and had two roommates the whole time we were dating. They moved out shortly before we got married but we still unconsciously call bedrooms in the house "Peter's room" or "Reid's room". Jenny still feels like she "moved in".

So we felt like it was time to go find a house together. Of course, there were a great many projects to do to update our house and make it attractive in the competitive housing market. The interior and exterior were painted, the kitchen and bathrooms updated, the yard dressed up with plants and flowers and much much more. Our friends have been amazed with the changes and many people have said we packed 3 months of work into 1.5. It certainly felt like it. But now we're done and the house is on the market. Which brings me to the second change that struck me at the same time.

Over the last six months my team has been undergoing a change in focus. Throughout the time I wasn't sure if the new direction interested me. For the last few months I started thinking that maybe it was time to get out of setup and try something completely new. I looked around inside the company and even thought about going out on my own. That made my April Fool's Joke this year particularly effective for the people that knew me well.

At the same time we were starting up a million house projects, I decided to get serious about finding a "new home" at work as well. Now feeling completely unsettled in all aspects of life, I started reaching out to friends across the company. Fortunately, a couple of those friends insisted I sit down and talk to their management to learn more about their project. After talking to a couple senior people on one of those teams, I became convinced I had found an opportunity that I just couldn't pass up.

A couple people recently asked me what "9/2" meant. Its simple. On September 2nd, I join the Live Mesh team. I am seriously stoked.

 

Recently, I heard from a customer who was attempting to create an MSI-based installer using WiX v3.0.  They needed to install an assembly to the global assembly cache (GAC) in their installer, but when they attempted to run their MSI, the installation failed.  The verbose MSI log file contained an error message like the following:

Error 1935. An error occurred during the installation of assembly 'MyAssembly,version="1.0.0.0",culture="neutral",publicKeyToken="################",processorArchitecture="MSIL"'. Please refer to Help and Support for more information. HRESULT: 0x80131047. assembly interface: IAssemblyCacheItem, function: Commit, component: {########-####-####-####-############}

From the information in corerror.h in the Windows SDK and in the blog post I wrote a while back about error code 1935, the HRESULT value 0x80131047 means "The given assembly name or code-base is invalid."

The customer tried installing the same assembly manually using gacutil.exe and it worked fine, so this error didn't make much sense initially.

After examining their WiX authoring and trying some scenarios, I discovered a tricky authoring error that ended up being the cause of this error.  The WiX authoring that led to the error looked like this:

<Component Id='MyComponent' Guid='PUT-GUID-HERE'>
    <File Id='MyFile'
            Name='MyName'
            DiskId='1'
            Source='MyAssembly.dll'
            Assembly='.net'
            KeyPath='yes' />
</Component>

The underlying issue turned out to be that the destination name of the file did not match the assembly identity for this assembly.  Behind the scenes, Windows Installer uses fusion APIs to install assemblies to the GAC, and fusion requires that the file name be the same as the assembly identity.  When the customer was attempting to manually run gacutil.exe on this assembly, they used the source file name (MyAssembly.dll in this case), which did match.  However, the WiX authoring caused the file to be installed with the name MyName, and then when Windows Installer attempted to call fusion APIs to install the assembly from the location the file was installed to, that copy of the file did not have a name that matched the assembly identity, and it resulted in a 1935 error with HRESULT 0x80131047.

Changing this setup authoring to the following and rebuilding the MSI allowed the installation to succeed:

<Component Id='MyComponent' Guid='PUT-GUID-HERE'>
    <File Id='MyFile'
            Name='MyAssembly.dll'
            DiskId='1'
            Source='MyAssembly.dll'
            Assembly='.net'
            KeyPath='yes' />
</Component>

Since this type of scenario is tricky to debug and it is also possible to catch it up-front when creating the MSI in the first place, I logged this bug on the WiX SourceForge site so that hopefully this will be caught in the WiX build process in the future.  In the meantime, if you are authoring assemblies to be installed to the GAC in WiX, make sure that the destination name being used for each of your assemblies matches the actual assembly identity.

The audio files for talks given by members of the XNA Community Gaming Platform team at Gamefest 2008 have been posted for download on the Microsoft download center.  If you weren't able to attend Gamefest 2008 or if you'd like to listen to the talks again, I encourage you to download them and check them out.  Here is a complete list of the available talks:

• What's New in XNA Game Studio 3.0 (by Mitch Walker)
• XNA Game Studio Performance 2008: Multithreading and GPU (by Frank Savage)
• Real World Content Pipeline Examples (by Eli Tayrien)
• Building Worlds with the Content Pipeline (by Shawn Hargreaves)
• Creating Great Community Games (by Mitch Walker)
• Networking, Traffic Jams, and Schrödinger's Cat (by Shawn Hargreaves)

I have posted several items on my blog in the past about the .NET Framework cleanup tool.  The information has ended up becoming more scattered and difficult to find over time, so I decided to create a centralized introductory topic.

You can find the .NET Framework cleanup tool user's guide at http://blogs.msdn.com/astebner/pages/8904493.aspx or http://go.microsoft.com/fwlink/?LinkID=121918.

The user's guide includes the following information:

• Caveats to review before using the .NET Framework cleanup tool
• Where to download the tool
• Versions of the .NET Framework that can be removed with the tool
• How to run in silent mode
• How to run in unattended mode
• Exit codes returned by the tool
• Log files created by the tool

As changes are made to the .NET Framework cleanup tool in the future, I will keep the user's guide up-to-date at the location at the link above so information about this tool can be found at a consistent place from now on.

I have heard from a couple of customers who ran into issues installing the .NET Framework 3.5 and/or the .NET Framework 3.5 SP1 on one of the following OS types:

• Checked (also known as debug) builds of Windows Vista and/or Windows Server 2008
• Pre-release builds of Windows Vista and/or Windows Server 2008

One of these customer reports can be found in this forum post.  I wanted to describe this scenario in more detail in case anyone else runs into a similar issue in the future.

Description of the issue

The .NET Framework 3.5 and 3.5 SP1 install service packs for the .NET Framework 2.0 and the .NET Framework 3.0 behind the scenes.  On Windows Vista and Windows Server 2008, the .NET Framework 2.0 and 3.0 service packs are installed as OS updates.  These OS updates are marked to only install on the final release versions of Windows Vista and Windows Server 2008.  That means that they will not allow you to install them on checked builds of these OS's, and they will also not allow you to install them on pre-release versions of these OS's.

Here is the exact list of .NET Framework 3.5 installation scenarios that will fail on checked builds of the OS or pre-release builds of the OS:

• Installing the .NET Framework 3.5 on the original release of Windows Vista (but not Windows Vista SP1 or later)
• Installing the .NET Framework 3.5 SP1 on the original release of Windows Vista or Windows Vista SP1
• Installing the .NET Framework 3.5 SP1 on Windows Server 2008

However, installing the original release of the .NET Framework 3.5 on Windows Vista SP1 or Windows Server 2008 will not fail due to this issue.  This is because Windows Vista SP1 and Windows Server 2008 already include the .NET Framework 2.0 SP1 and 3.0 SP1 as OS components, so .NET Framework 3.5 setup does not need to install any OS updates on those systems.

How to work around the issue

Unfortunately, there is not a workaround that will allow you to install on a checked build or a pre-release build of Windows Vista or Windows Server 2008.  Instead, you will need to install a final release build of Windows Vista or Windows Server 2008, then re-run .NET Framework 3.5 or 3.5 SP1 setup.

How to diagnose the issue

If you try to install in one of the above configurations, you will see the following error in the .NET Framework 3.5 or 3.5 SP1 log file named %temp%\dd_dotnetfx35install.txt:

[08/08/08,11:11:11] Microsoft .NET Framework 2.0SP1 (CBS): ***ERRORLOG EVENT*** : Error: Installation failed for component Microsoft .NET Framework 2.0SP1 (CBS). MSI returned error code 1.

Error code 1 for Windows Vista or Windows Server 2008 OS update packages means that the package is not applicable on the current OS.

Important note about error code 1 during .NET Framework 3.5 or 3.5 SP1 setup

Please note that this blog post only describes one possible cause of error code 1 during .NET Framework 3.5 or 3.5 SP1 installation.  If you are not running a checked build of Windows or a pre-release version of Windows, then the issue described here is not the cause of the installation failure on your system.

If you are running into error code 1 but are not running a checked or pre-release build of Windows, then it typically helps to review the .NET Framework 3.5 log files to try to learn more about the root cause of the issue.  You can find more information about what log files are produced by .NET Framework 3.5 setup in this blog post, and there is information in this blog post that describes options for reporting installation failures back to Microsoft for additional investigation.

The logs that are typically the most useful in diagnosing error code 1 are the following:

• %temp%\dd_dotnetfx35install.txt
• %windir%\logs\cbs\cbs.log
• %windir%\WindowsUpdate.log

I haven't had time to look more closely at this, but I noticed that Microsoft's Application Virtualization 4.5 product ( formerly SoftGrid ) has RTM'd. Until I have a chance to learn more, here's a link to follow.
Pulling this down and playing with it has to be more productive and interesting then playing Setup Police and berating Google for their setup violations.

I was reading an interesting article from Ed Burnette at ZDNet:

Google announced a new web browser today called Chrome. Analysts who wonder if this spells “doom� for Firefox, or if it’s an “IE killer� are missing the point. Like Gears, Chrome is Google’s latest attempt to lead by example, and push the envelope of the web experience.

The article includes this comic strip panel from Google:



Now I have such a one track mind sometimes that I couldn't help think about WiX and other setup tools vendors. My observations are that while WiX is open sourced, Rob Mensching tends to get very irritated companies other then Microsoft take his code and turn it into a revenue generating product. Case in point being is his comments aimed at InstallAware when WiXAware was first released. I also happen to know another well known tools vendor is very hesitant to include WiX technology in their product. I also believe that this is not an engineering reason rather a fear of opening a can of worms.

The truth is there are some things in WiX that are very good and it would be really interesting if the Google model could be followed. We'd probably all end up with better tools.

Over the years I've noticed that it seems I'm always extremely busy before and after taking time off from work. It's almost pointless to have time off from work since I always end up getting worked so hard that I end up needing the time off instead of just enjoying the time off.

At the beginning of August I found out about a new project at my day job that kicked off an intense week of planning before taking a week off in South Padre. It was suddenly a really bad time to take a vacation but it had been planned for months.

When I returned, I decided to pack up my office and move closer to the developers I'd be supporting. I spent the next two weeks `embedded` with this development team attempting to gain their trust, understand their problem domain, influence their software design choices and ultimately deliver the best build and installer experience possible. When I first started interacting with this team I wasn't sure it was going to go well but it actually turned out really nice. We completed our first sprint and delivered the first 10 of about 40 installs to QA. The ground work has been laid and the remaining 30 installs will just be details over the coming months.

Since then, I've spent the last two days enjoying labor day weekend with my family. It's been so relaxing. I've missed them so much and it's so nice to hear my family say "Daddy, where have you been? We miss you." It feels like I'm back in South Padre spending all day and all night with them once again.

I previously blogged early this year that it was going to be An Interesting Year Of Change To Come. At the time I wrote:

I can't help but notice the pendulum swing that's happening and I advise everyone to seek knowledge and apply it to your own personal situation. It seems that change is in the air again ( as it always is ) and it smells like recession driven merger and consolidation. Just about every industry that I've been in is seeing a lot of activity in this area and a few minutes ago I found out that I've been `sold` once again.

At the time, I had worked for a private company (Hart InterCivic) which was sold to a public company (Manatron) which was then sold back to another private company (TCB) who just happened to have also bought a software division (InstallShield) from another public company ( Macrovision ) to form a new company (Acresso). Then there was another private company I worked for ( Austin Information Systems ) which aquired private equity to become another company ( Overwatch Systems ) and finally sold to a public company ( Textron ). I didn't stick around for that deal to finish though.


Add in some contracting agencies, dot bombs and airlines ( which almost merged ) and my work history becomes somewhat confusing. Ohwell, at least there will always be a United States Marine Corps! Red and Gold baby, forget purple.

Anyways back to my original reason for posting. Today HP closes on the EDS deal for some $13.9 billion USD.

Wow. There were always rumors of a sale when I worked there (1996-1999,2000-2005) but today is finally the day. I always liked the teams I worked on for EDS but the company as a whole never really seemed like a real winner as evidenced by their really low profit margins over the year.

Well I yanked my 401K out last year and here's hoping that my pension fares well.

Farewel, EDS. You opened a world of opportunity for a young former Marine. I learned a lot from you and this eagle will miss you.

You may have seen from a recent post that I received a new laptop that was capable of running Hyper-V. Well, it's all fully installed and working, so I thought I might blog about it a bit. There are plenty of existing blogs on Hyper-V, so I thought I...(read more)