Doctor Deploys Blog

Thanks to everyone that gave feedback both on my blog and through other forums about .NET Framework installs. Beta2 just got released on MSDN so I thought I’d take this opportunity to talk a little but about the stuff we have done to improve the installation. My team and I have been focused over the past year on incorporating feedback and striving to make the installer better for the .NET Framework 4.0 . There has been a particular focus on making it better for client applications to install it with their apps.

The key focus areas for the .NET 4.0 installer have been Size, Robustness, and Performance. I’ll speak to some of the major things we did and give a brief description.

Size

Comparison Chart for Size improvements since 3.5 SP1

Better Compression Across Packages

We implemented the use of a better compression technology into our packages which reduced the size of our packages by around 15%.

Separate packages for AMD64 and IA64

We found that there was little to no need to ever install the same package on both amd64 and ia64. Because of this, we decided to produce amd64 packages that excluded ia64 binaries as well as ia64 packages that didn’t contain amd64 binaries.

Client Profile

We determined the subset of framework functionality that was used by 95+% of client applications and produced a first class package for this scenario. The result of this is that, unless you are taking advantage of features such as ASP.NET, you can now take a dependency on a smaller framework. More details of what is in the client profile can be found here <Will provide link once it is posted>.

Remove Duplicate MSIL

We identified many assemblies that were functionally identical but differed by the architecture they were built under. These assemblies were all managed CPU neutral assemblies which meant that it didn’t matter whether they were built for x86 or amd64. Their strong names and functionality are the same. We solved this by only carrying one of them.

Robustness

Remove Prerequisites

In a chain of installs, the chain is only as strong as its weakest link. In addition, small weaknesses in each part of the chain compound to lead to higher failure rates for the whole chain. By removing numerous prerequisites and combining the whole client install into a single MSI, we were able to get rid of the compounding effect of failures as well as focus our efforts on making the single MSI as solid as possible.

Simplify the MSI

Custom actions are very common places for installs to fail. The more you have, the more complex the installer gets and the number of points of failure goes up. Removing the need for customactions in many cases and in the cases where we needed them, simplifying them has increased our success rates.

Remove slipstreamed feature MSP’s

In Beta1, we slipstreamed features into the installer’s msi using patches. This proved to be a point of complexity and the root cause of many unsolvable bugs. Due to that, we simplified our install to be completely contained in a single msi per platform.

Fix and Retry

Through thorough investigation of our past installers, looking through KB articles, feedback from customers, and through our past Beta’s, we found numerous install failure conditions that were fixable after the error. We implemented the KB articles and other workarounds so, in failure cases, we can fix the users machine and try again. We’ve seen quite and increase in our success rates due to this feature. My hope is that this will also make the windows installer ecosystem cleaner and that msi’s installed after .NET 4.0 will have a better chance to succeed because our installer put the machine in a better state.

Triple fallback on Download failures

Through analysis of our download failures in the past, we determined that using a single implementation for downloads left you only as successful as that technology allows. We found that between Winhttp, URLMon, and BITS, their failures were in different scenarios and where one would fail, the others would succeed. In order to take advantage of this, our chainer falls back and retries on different download stacks to do everything we can to get a successful download.

Separate out server configuration from Client Profile

The Client Profile installer should be more robust for applications now because some of the most common failing custom actions in .NET 3.5 were in configuring things like ASP.NET and WCF which are mainly server scenarios and not used by client applications. By moving these to the full install, we are seeing higher success rates for the client install.

New Chainer

We implemented a new chainer in Dev10 that is being used by 4.0. It is smaller, faster, and more flexible than its predecessor. The flexibility is a major part of what allowed us to make investments such as the download fallbacks, Fix and retry, and better compression. I’m excited that this chainer is the foundation of what is being built into the WiX community under the name of Burn. This should be available for others to use in the WiX 3.5 release.

Performance

Smart Cabbing

Smart cabbing is a technique used to allow you to install the same file to multiple locations but only carry the file once in the msi’s cabs. This technique has been used for years but during our perf investigations, we found that, depending on how many duplicate files there were and where they were in the cab, performance degraded significantly. We made some bug fixes in the tools we use to smart cab (WiX) to reduce the impact of duplicated items while still gaining the benefits of smart cabbing.

Remove Prerequisites

This one is fairly self explanatory. We need to install less packages so we are faster. This is mostly the result of changing the .NET Framework itself to not have certain dependencies or carry subsets of the dependencies within the framework. In a few cases, this was possible because the base functionality was either built into all the supported OS’s or had enough ubiquity in the ecosystem to not warrant us carrying it.

Remove Slipstreamed Msp’s

We found that when applying large slipstreams to a product, there was a significant perf hit towards the end of the install when Windows Installer is caching the packages for source resiliency. By adding all the features into the MSI, we got rid of this performance hit.

Parallel Ngen and removal of synchronous 64bit assemblies

The CLR implemented the ability to ngen on multiple cores in parallel. We made changes in our installer to take advantage of this so now on a multicore machine, ngen times should be significantly reduced. Also, on 64bit machines, most .NET applications run as 32bit. This means that paying the price of creating 64bit native images is not something most apps need to do.

Client Profile

By producing a subset of the .NET install that contains the features most client applications need, most client applications can take advantage of shorter install times by installing less.

Parallel Download and Install

If you are using the web bootstrapper which we made available for the first time in Beta2, you can use the web bootstrapper to install .NET Framework 4.0. This has the advantage of downloading and installing the payload in parallel. For example, as it is installing the Client Profile, it will be downloading the rest of the framework. In cases where you have enough bandwidth to download the rest before the Client Profile install finishes, you essentially save the time it took to download the rest.

Original post by Petermarcu

Recently there were reports that the WiX toolset was breaking unit test projects in Visual Studio 2008. This was surprised us because we thought unit test projects were working fine when we shipped. Well, it turns out this time the bug wasn’t in the WiX toolset.

If I’m understanding this correctly (I’m not a Votive expert), it appears that Visual Studio 2008 Service Pack 1 introduced a bug that caused the "Create Unit Test" wizard to show up blank when the WiX toolset was installed. The root issue seems Visual Studio mishandling projects that do not implement unit test information. The WiX toolset is such a project.

Fortunately, Microsoft provided a hotfix for the problem. The hotfix’s KB article even mentions the WiX toolset. I have verified with three people who reported the issue that the hotfix does seem to address the problem.

Original post by Rob Mensching

Music makes the coding go better and I’ve come to like the way the Zune software organizes and plays music. So when I was setting up the machine for RobMensching.com LLC (where I would undoubtedly be spending some hardcore coding time), I was disappointed to see that the Zune software refused to install on Windows 2008 R2.

In my experience, Microsoft products that target consumers often disable the ability to install on server operating systems to minimize their testing and support burden. Unfortunately, that means programmers who often use server operating systems as their “all in oneâ€� development machine are out of luck. Fortunately, programmers are usually good with software and can find other ways to make it work… even if that means the result isn’t supported.

So, if you really want the Zune software and are prepared to go unsupported, follow these few steps:

1. Download Zune Software - note that there is a 32-bit and 64-bit option. If you’re running Windows 2008 R2, you’re probably running 64-bit. Pick the right one.

   Note: I download all my software to "C:\Users\robmen\Downloads" so the rest of these instructions will use that directory. In future steps, be sure to change that part of the example.

2. Start elevated command shell - to successfully install the Zune software, we will need full administrative privileges. The easiest way to do that is start cmd.exe elevated.

   Start Button -> Type "cmd" -> Right click on "cmd.exe" -> Choose "Run as administrator".

   Note: You will be prompted to allow cmd.exe to run, click "Yes".

3. Extract the files from the Zune software package - it turns out the Windows 2008 R2 condition check is in the bootstrapper not the installation package. So we to extract the Zune software’s .msi file.

   Type "C:\Users\robmen\Downloads\zunesetuppkg-x64.exe /x" (without the quotes).
   
   Note: If you chose 32-bit option in step 1, change the "zunesetuppkg-x64.exe" to "zunesetuppkg-x86.exe".

4. Pick your extraction directory - the Zune software will prompt you for where you want the package extracted. I chose:

   Type "C:\Users\robmen\Downloads\ZuneSetup" (again, without the quotes).

5. Install Zune software elevated - elevated is the key word here. The Zune install expects to be elevated when running and will fail if not. Fortunately, in step 2 we made sure our command shell was elevated.

   Type: "C:\Users\robmen\Downloads\ZuneSetup\packages\Zune-x64.msi"
   
   Note: If you chose the 32-bit option in step 1, change the "Zune-x64.msi" to "Zune-x86.msi".

If all goes well, you should see a progress bar and when it disappears the Zune software should be installed. Remember this isn’t a Microsoft supported configuration but I’ve been using it for a while now and everything works perfectly.

Original post by Rob Mensching

I recently came across several resources that are available from Microsoft to help developers get their applications ready and shining on Windows 7! Since these resources are scattered in several places, I thought it would be beneficial to have a post with a compilation of these. So here you go…

1.       Training Kit for Developers (Windows 7 RTM version)

This kit includes presentations, hands-on labs, and demos designed to help you learn how to build applications that are compatible with and shine on Windows 7 by utilizing key Windows 7 features. You can find topics such as: Taskbar, Sensor and Location, Libraries and Shell, DirectX, Multi-touch, Ribbon, etc. The kit is built for both native Win32 C++ developers and .NET developers. The kit also includes Application Compatibility labs for: Version Checking, Data Redirection, UIPI, Installer Detection, Session 0 Isolation, and High DPI, to help you get over the most common application compatibility issues.

Available for download on Microsoft download center.

2.       Application Quality Cookbook

This Cookbook provides you with the means to become familiar with how to verify the compatibility of your applications with the new operating system and provides an overview of the few known application incompatibility issues in Windows 7 and Windows Server 2008 R2. But more than that, it also points out differences in performance, reliability, and usability, and provides links to detailed white papers and other developer guidance.

You can download the complete version (available in .docx and .xps formats) of the Application Quality Cookbook from its location on Code Gallery.

3.       Developer Guide

The Windows 7 platform makes it easy for developers to create engaging, user-friendly applications by providing familiar tools and rich development features that allow them to take advantage of the latest PC capabilities. This guide summarizes the key developer advances in each of the following three areas:

·         Solid Foundation

·         Richer Application Experiences

·         The Best of Windows and the Web

You can download the Windows 7 version of the Developer Guide (available in .docx and .xps formats) from its location on Code Gallery.

4.       Application Compatibility

If you are facing Compatibility problems with your applications on Windows 7, here are some excellent application compatibility resources to get you started!

·         Application Compatibility Factory (ACF) Program – Helps customers identify and resolve potential compatibility issues they may face when migrating desktops and applications to Windows 7.

·         Windows XP to Windows 7 Migration – Tools and resources available from Microsoft to help you each step along the way when migrating from a Windows XP environment to Windows 7.

·         Microsoft Application Compatibility Toolkit 5.5 – contains the necessary tools and documentation to evaluate and mitigate application compatibility issues before deploying Windows 7.

·         Win7 App Compat FAQ for developers

·         MSDN forum Application Compatibility for Windows Development

5.      The Windows 7 Blog for Developers

A blog focusing mainly on the developer aspects of Windows 7.

[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.

Original post by Windows Installer Team

I am officially launching RobMensching.com LLC today, Labor Day 2009. This new business will begin by offering software installation consulting services for the Windows Installer and WiX toolset. You can read more details about the business on my consulting page.

Starting a business on my own has been a dream of mine for a number of years now. Early this year, I felt that the my life was becoming organized enough that I could direct some attention to a business. So throughout the month of August, I quietly laid the groundwork. I acquired a business credit card, filed the new business name with the Washington Secretary of State and ordered some new hardware.

There won’t be many other changes around here. I’m still working for Microsoft and will continue to lead the WiX toolset. RobMensching.com LLC simply provides me a new professional and independent identity to work with those people and organizations that require it.

If you have questions or comments, feel free to contact me. Otherwise, keep coding. You know I am.

Original post by Rob Mensching

Starting with Windows 7, Windows Installer enables native support for setting properties on shortcuts created during installation or re-installation. The MsiShortcutProperty table can be used to set any property defined by the IPropertyStore interface.

In order to use the new table, you need to specify the PropertyKey and PropVariantValue for the shortcut you want to set the properties on (you can set multiple properties on a shortcut). The properties are defined in propkey.h: many of them are new in Windows 7. You can use string representations for both – e.g. System.AppUserModel.ID for the PropertyKey PKEY_AppUserModel_ID, and a corresponding string representation for the PropVariantValue. Windows will automatically coerce the value to the correct type.

These properties are consumed by shell, not windows installer.

Examples:

1.       Allow an app to glom onto its shortcut on the taskbar

System.AppUserModel.ID property in Windows 7 defines an AppUserModelID. Applications can use this property to group its windows together with the shortcut on the Windows taskbar. This means that if the application sets an AppUserModelID in its process, and same AppUserModelID in the shortcut, then when the shortcut is pinned to the taskbar and the application is launched from it, the application icon will group together with the shortcut. This property is particularly useful for applications that wish to override the taskbar’s default grouping and unification – apps running under a host process, or an app that owns several different processes. PropertyKey, PropVariantValue that you would author in the MsiShortcutProperty table of your package would be “System.AppUserModel.ID� and “CompanyName.ProductName.SubProduct�, respectively.

2.       Prevent pinning of shortcuts

Setting “System.AppUserModel.PreventPinning� property to “1� prevents a shortcut from being pinned to the taskbar.

FAQs

Q: Is there a new standard action that I need to schedule?

A: No, setting of shortcut properties will be a part of the CreateShortcuts standard action.

Q: Can I set properties on shortcuts that are not a part of my installation?

A: No, you can only set properties on shortcuts created by your installation.

Q: What happens if the setting of a property fails?

A: If Windows Installer fails to set a shortcut property, it will return a warning and the installation will continue.

Q: What happens on downlevel platforms?

A: This functionality is only available on Windows Installer 5.0 and above. The MsiShortcutProperty table – if present – is ignored on Windows Installer 4.5 and below.

[Author: Ashish Awasthi]
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

Prior to the introduction of UAC in Windows Vista, setup authors were able to create a single package that could install for the current user (“Just for me�) or for all users on the computer (“Everyone�). With the introduction of UAC, setup authors were no longer able to create a single package that could install in both modes. This feature provides the functionality to aid the development of a dual-purpose package for installation on Windows 7.

Historical Perspective:

With the introduction of UAC in Vista, setting ALLUSERS=2 no longer provided the conditional logic to set the installation context based on user’s privileges. As a workaround, Windows Installer provided a way to declare a package is UAC compliant – setting bit 3 of the Word Count Summary property. If this bit is set, no elevation prompt is thrown – and the package is installed per-user. It is the responsibility of package author to ensure that there are no writes to per-machine locations and that elevated privileges are not required for installation; otherwise the installation would fail due to a lack of privileges.

This meant that the setup authors typically had to create two packages for Windows Vista – one with the UAC compliant bit set for per-user installation; and other without this bit, for per-machine installation. Also, setup authors had to ensure – in a per-user installation – that the common locations like ProgramFilesFolder were not used, because there were no per-user equivalents for them in Windows Vista.

Introducing dual-Mode Package:

With Windows Installer 5.0 on Windows 7 and higher, you can author a dual mode package that can be installed per user or per machine. Setup authors can set the MSIINSTALLPERUSER property to 1 and ALLUSERS to 2 to identify the package as a dual-purpose package. Note that MSIINSTALLPERUSER is only evaluated when ALLUSERS=2. These properties can be specified in the package, passed through the command line, modified by a transform, or – more commonly – selected through a user interface dialog.

Adhere to these Development guidelines for dual-mode packages to ensure your package can be installed in either the per-user or per-machine context. Windows 7 SDK includes a sample package PUASample1.msi to serve as an example of how to author a dual mode package.

Per-user capable known folders and registrations of the Windows Shell:

Prior to Windows 7, an app installed in the per-user context, only had its entry-points like shortcuts, installed per-user – the app binaries and registrations were (unless specified as per-user) written in per-machine locations like “Program Files� and HKLM, since there were no per-user equivalents for some of these locations. Windows 7 includes support for a per user equivalent version of FOLDERID_ProgramFiles and FOLDERID_ProgramFilesCommon as well known folders. These folders will be automatically created by Windows Installer if they do not exist.

FOLDERID_UserProgramFiles:                                    “%LocalAppData%\Programsâ€�.

FOLDERID_UserProgramFilesCommon:                    “%LocalAppData%\Programs\Commonâ€�.

As the author of a Windows Installer package, you simply continue to use the existing Windows Installer properties ProgramFilesFolder and CommonFilesFolder. At install time, Windows Installer will redirect to the per-machine version (i.e. the version that is globally available to all users) or the per user version that is available for the current user for whom the application is being installed. Note that the ProgramFilesFolder and ProgramFiles64Folder have the same per-user equivalent on a 64-bit system; similarly for CommonFilesFolder and CommonFiles64Folder. The MSDN article on Installation Context describes automatic redirection of various properties, registry keys, and shortcuts based on the context in which a package is installed.

Developing for multiple Windows platforms:

Dual mode packages are only recognized on Windows 7 and above. The MSIINSTALLPERUSER property will be ignored on down-level systems. ICE 105 is provided to help you verify that your package can truly be installed in either mode. It basically verifies that your package is not writing to any machine-wide locations. The table below explains the behavior of different kinds of installations on various platforms:

Some things to consider…

The target customers for dual mode packages are LOB ISVs who author lightweight applications that don’t need administrative privileges and don’t need to write to machine-wide locations during installation. So, there are cases where a per-user or dual mode package would not serve the purpose:

·         If there are any machine-wide prerequisites, you will have to install them separately.

·         Per-user apps are not supported by some OS Registration points, you cannot install services or drivers or global assemblies, etc.

·         Apps that are meant for all users – like firewall or anti-virus cannot be installed per-user.

·         A per-user package will only be serviced when the user who installed it, is logged on to the machine.

·         Also, “Set Program Access and Defaults (SPAD)â€� cannot be set for apps installed as per-user installation context.

FAQ’s

Q: If the MSIINSTALLPERUSER and ALLUSERS properties can be specified in the package, through the command line, or via the UI, what takes precedence?

A: Precedence of properties in decreasing order of priority

1.       What is specified via UI

2.       What is specified in command line

3.       What is set in package

 Note that the both MSIINSTALLPERUSER and ALLUSERS properties should be set at the same time. For example, you should not set ALLUSERS property via command-line and MSIINSTALLPERUSER property via UI.

Q: What about servicing for a per-user installed app?

A: Once a dual mode application is installed per-user, it can be serviced (patched/repaired/uninstalled) by a standard user, with no UAC prompt or elevation needed assuming the user is logged on.

Q: Can per-user and per-machine installations of the same app co-exist on the same machine?

A: It depends. If the  app is first installed per-machinethe app will already be visible to all users and cannot be installed per-user. However, if a standard user Jane installs an app per-user, another user Abby can install the same app per-machine, assuming she has admin credentials. Jane will continue to see and use her version of the application on shortcuts, start menu, etc. If Jane removes her version of the application from “Uninstall or Change Programâ€� wizard, she will then see the per-machine version of the application.

In the “Uninstall or Change Program� wizard, Jane would be able to see both the per-user and per-machine versions of the app, but she would not be able to uninstall the per-machine version without providing administrator credentials. She would, however, be able to uninstall (or repair) her per-user version of the app without seeing a UAC prompt. Abby will only see the per-machine version that she installed and made visible to all users on the system.

Q: Okay, if per-user and per-machine versions of an app can co-exist, which version gets updated when a patch is ready to be installed?

A: This depends on the context that the app was originally deployed and the context that the patch is being applied. For instance, let’s imagine that standard users Jane  and Toby have both installed an app per-user, before the administrator Abby decided to install it for all the users on the machine. If Jane is logged on when the patch is to be applied, then her version of the app will be updated, and she will not be presented with a UAC prompt. Same holds for Toby. When Abby is logged on, the per-machine version of the app will be updated.

Q: I manage an enterprise environment where I would like to block users from installing applications per-user. What can I do?

A: Setting the policy DisableMSI to 1 will block the per-user install operations of dual mode packages. Setting it to 1 will also block all the uninstall/patching/upgrade of the packages that were previously installed with MSIINSTALLPERUSER=1. Setting the DisableMSI to 2 will block windows installer from doing any operations on the machine. Setting the DisableUserInstalls policy to 1 disables install/uninstall/upgrade/patching of per-user applications.

 [Authored by Ashish Awasthi & edited by 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.

Original post by Windows Installer Team