Setup Related Blogs

MSI 5 on Windows 7 introduces a new application compatibility setting, as Chris Jackson describes in his blog.

To work around too strict OS version checks in LaunchConditions, Windows Installer can automatically try several variations of values for the VersionNT and ServicePackLevel properties to circumvent the condition. For instance it will start with VersionNT=600 (Windows Vista) and ServicePackLevel=14, then count down the SP level (13, 12, …, 0), then repeat the same with VersionNT=502 (Windows Server 2003) and so on, until the LaunchCondition succeeds. This is a per-msi setting on the local machine, which can be turned on using this dialog:

According to the blog, Windows Installer also sets these properties which might be useful to detect that version lying is going on:

• SHIMFLAGS
• SHIMVERSIONNT
• SHIMSERVICEPACKLEVEL

As far as I know these properties are currently not documented in MSDN.

Original article:
Unraveling the Mysteries of MSI Compatibility Modes in Windows 7

When User Account Control (UAC ) was introduced in Windows Vista it would have caused problems for many existing setups because they required full administrator permissions. Therefore Microsoft added heuristical detection for installers. For instance if it detects a keyword like “setup” or “installer” in the exe file name or in the resources it assumes that this is a setup program and displays the UAC prompt to elevate the program to the full administrator token. This can however cause problems if your program actually isn’t a setup but is falsely identified as one by the installer heuristic (“false positive”). To avoid this you could add a manifest to your application to tell Windows Vista that it’s not a setup.

Windows 7 has similar functionality, but it ignores the information you put in the manifest for Windows Vista – you have to add another piece of data especially for Windows 7. Chris Jackson, who is an Architect and the Technical Lead for the Windows Application Experience SWAT Team, blogged about this problem, and a possible fix.

PCA Changes for Windows 7: How To Tell Us You are Not an Installer, Take 2 (because we changed the rules on you)

(Updated to fix broken hyperlinks)

On October 18, 2009 Acresso released the latest version of their setup authoring tool InstallShield, which reportedly is used by over 71,000 ISVs and enterprises to create installers for Windows and mobile devices.

What's new in InstallShield 2010

• Supports Microsoft App-V with new InstallShield Virtualization Pack - in addition to Windows Installer (MSI) and proprietary InstallScripts, developers can now create virtual application packages for Microsoft App-V (formerly Softgrid)
• New Microsoft technologies supported natively in InstallShield – InstallShield 2010 supports Windows 7 and MSI 5 features so developers can use them now on Windows XP and Vista platforms. It also has support for Windows Server 2008 R2.
• Improved support for Web applications – Expanded IIS features now include all IIS 7 settings.
• IDE usability improvements – New flattened architecture and dynamic and global searching significantly increase developer productivity. Developers can spend 10 minutes to learn the new IDE and then benefit from significant time saved on daily tasks.
• More options for runtime user-experience customization – ISVs have more customization options to create user experience and branding with new support for billboards, Flash, HTML, and hyperlinks. New branding options can help ISVs up/cross-sell their software by adding more user interaction through the installation process.
• Better support for multi-language installation – InstallShield now supports Unicode. Also developers will save significant time by having a single view of all languages with dynamic searching and replacing global settings at once.
• plus over 400 new and enhanced features from customer requests

Detailed information can be found in the datasheet and in the release notes:

• InstallShield 2010 Datasheet (PDF)
• InstallShield 2010 Release Notes - Premier and Professional (PDF)
• InstallShield 2010 Release Notes - Express (PDF)

If you’re in Europe you can buy InstallShield 2010 from the InstallSite Shop.

Changes in Activation Process and EULA

Changes in the End User License Agreement (EULA) and in the activation process include:

• Licenses can now be “de-activated” manually, even offline.
• Activation needs to be repeated on a yearly basis.
• Using InstallShield in a virtual machine is now allowed.

I have created a side-by-side comparison of the old and the new EULA and a summary of the changes in the activation process. For full details please read Acresso’s official documents:

• InstallShield 2010 EULA (PDF)
• InstallShield Activation User Guide (PDF)

End of Life announced for InstallShield 12 and InstallAnywhere 8

Together with the release of InstallShield 2010 Acresso also announced the end of life for InstallShield 12 and InstallAnywhere 8 (all language editions). This means that you can upgrade from these versions only until October 30, 2009. After that date you would have to pay the full license price.

October 31, 2009 is the deadline for the following product versions:

• InstallShield 12 (all languages)
• InstallShield 2008 German
• InstallShield 2009 German
• InstallAnywhere 8 (all languages)
• InstallAnywhere 2008 (German and French)
• InstallAnywhere 2009 (German and French)

The end of life for the localized German versions of InstallShield and the German and French versions of InstallAnywhere had already been announced two weeks ago.
The English versions of InstallShield 2008 and higher and InstallAnywhere 2008 and higher are not affected by this announcement.

More information about these end of life announcements can be found in the InstallSite Shop and the Acresso Website.

In der Reihe "Kompendium zur Virtualisierung" ist ein Heft mit Schwerpunkt Anwendungsvirtualisierung erschienen. Es behandelt unter anderem VMware ThinApp, Citrix XenApp, Microsoft App-V und InstallFree Bridge. Das 76-seitige Heft im DIN-A-5-Format erhält man kostenlos zugeschickt, wenn man sich auf SearchDataCenter.de registriert.

Mark Russinovich (of SysInternals fame and now employed as a Technical Fellow at Microsoft) has published an interesting article about User Account Control (UAC) in the July issue of TechNet Magazine.

He discusses the goal of UAC, why it could be circumvented by malware, and how auto-elevation on Windows 7 avoids elevation prompts from system tasks.

http://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx

Today Acresso announced the end of life for the German editions of InstallShield and for the German and French editions of InstallAnywhere.

There will be no German edition of InstallShield 2010, and upgrade pricing from the German to the English edition will end on October 31, 2009.

Here are the official announcements:

• InstallShield German Language Editions All Versions
• InstallAnywhere German and French Language Editions All Versions

Additional information in German language:

Acresso Software, der Hersteller von InstallShield, hat bekannt gegeben, dass die deutsche Edition der InstallShield-Produktfamilie nicht fortgeführt wird. Somit sind InstallShield 2009 Premier, Professional und Express die letzten InstallShield-Produkte in deutscher Sprache. Ab InstallShield 2010 wird es die Software nur noch auf Englisch (und Japanisch) geben.

Bis 31.10.2009 gibt es einen Sonder-Rabatt beim Umstieg von der deutschen auf die englische Version. Danach ist kein Upgrade von der deutschen Version mehr möglich, d.h. ab 1.11.2009 muss der Preis der Vollversion bezahlt werden..

Hier habe ich einige Informationen für Besitzer und Interessenten von InstallShield German mit oder ohne Wartungsvertrag zusammengestellt:
http://www.installsite.biz/de/ix_ger_eol.htm

Ebenfalls betroffen ist InstallAnywhere, wo die deutsche und die französische Version eingestellt wird. Auch hier endet die Upgrade-Berechtigung am 31.10.2009.

It's been a few months now since the Windows Installer 4.5 redistributable was released [link]. Over the past couple months I have received several questions (quite often similar in nature) that warrants this blog post <grin>. In this post, I will attempt to answer some of the most frequently asked questions with regards to adoption & deployment of MSI 4.5.

1.       I’m considering taking a dependency on MSI 4.5 for my next release. I would like to know how prevalent MSI 4.5 might be in our target environments. Do you have any data on this?

We are pleased to hear that you are considering taking advantage of the new feature set and functionality provided in MSI 4.5. We have some data that may help you understand the current penetration of MSI 4.5 in the ecosystem.

a.       Statistics from the Microsoft download center:

As of March 2009, there have been over 5.6 million downloads of MSI 4.5 (combined across all supported platforms & OSes).

b.      Other ways in which MSI 4.5 is being deployed to users machines:

Yes, besides the fact that users are downloading MSI 4.5 from Microsoft download center, there are also other mechanisms via which MSI 4.5 is being deployed to users machines. For example;

-          SQL Server 2008 (both full server as well as express version) requires MSI 4.5 as a pre-requisite.

-          This dependency in turn has a cascading effect on other products that are already dependent on SQL Server 2008 or will be in the future.

c.       Future Windows service packs:

MSI 4.5 will be natively included in all future service packs of Windows. It is already included in Windows Vista and Server 2008 SP2. Release candidate for this service pack is presently available from the Microsoft download center.

2.       When will MSI 4.5 be deployed via Windows Update?

MSI 4.5 will be on Windows Update as part of future service packs to Windows (see #1, part c). It will not be available independently as a required mandatory update like Windows Installer 3.1 v2.

3.       Is it true that there is a forced reboot required on Windows Vista and Windows Server 2008 with MSI 4.5? Unlike Windows XP and Windows 2003, this reboot can't be deferred?

Yes, it is true that servicing Windows Installer always requires a reboot on Vista and above. The new changes made to the Windows Vista servicing stack in combination with the change made by Windows Update to always have the Windows Installer loaded, causes the update to be “pended” until a subsequent reboot thus generating the mandatory reboot requirement when servicing the Windows Installer. We understand that a reboot can be difficult to absorb for applications taking a dependency on MSI 4.5. Unfortunately, none of the solutions that could be pursued were low cost and low risk enough to be acceptable at that point in the Windows Vista SP1 and Windows Server 2008 ship cycle. However, the growing prevalence of MSI 4.5 (details provided in #1), is mitigating the reboot issue to some extent.

4.       We are considering the possibility of bootstrapping Windows Installer 4.5 with our product’s setup. Is there a single 4.5 redistributable that can cover multiple OS versions and CPU architecture that is of a smaller size?

No, there is no single redistributable package to install MSI 4.5. There exist different installation technologies to install a Windows component like Windows Installer on Vista and above OSes versus down-level OSes (Windows XP and Server 2003). Additionally, the binaries itself are different based on OS version and platform architecture.

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

Setting appropriate permissions for an object is one of the core operations in creating an application installer. One of the most frequent pieces of feedback has been to provide enhanced capabilities around securing resources installed on the system. MsiLockPermissionsEx Table in Windows 7 enhances the functionality over LockPermissions Table. With MsiLockPermissionsEx table, users now have the ability to set access permissions on objects impacted by the application install that previously required using custom actions or other methods outside of Windows Installer.

·         Expanding the set of permissions that can be applied to a resource by incorporating the Security Descriptor Definition Language(SDDL) in Windows Installer. This allows the security settings for an object to be more flexible, including;

o   Ability to apply Deny ACLs to objects

o   Indicate inheritance properties for permissions

o   Expand the set of well-known SIDs

o   Ability to set Owner, Group, and SACLs to the objects in addition to the regular access permissions

·         Security settings can be applied to services as well in addition to Files, Folders, Registry keys

·         Ability to apply permissions specific to user accounts – including accounts that are newly created on the system during the course of installation

FormattedSDDLText is a new column data type used by the SDDLText field of the MsiLockPermissionsEx Table to secure a selected object.

Q: How does new MsiLockPermissionsEx table change the semantics or behavior of the older LockPermissions table?

A: Packages using the older LockPermissions table will continue to work as expected. However, we encourage you to author your packages targeted for Windows 7 and above to use the new MsiLockPermissionsEx table to take advantage of the power and flexibility provided by SDDL while customizing security settings for your resources.

Q: Can I author both LockPermissions and MsiLockPermissionsEx tables in my package?

A: No, in the interest of simplifying authoring and avoiding collisions, it is not allowed to have both LockPermissions and MsiLockPermissionsEx tables in the same package. If both tables are present, the installation will fail. ICE 104 verifies that only one of the two tables: MsiLockPermissionsEx or LockPermissions is present in the package.

Q: What happens if two conditions in different rows evaluate to true for the same LockObject/Table pair in MsiLockPermissionsEx table? Which SDDLText will be applied?

A: If a LockObject/Table pair has multiple conditional expressions that evaluate to true, the installation will fail. So, be careful while authoring your conditions: if you have more than one security setting in your package for an object – make sure the corresponding conditions are mutually exclusive.

Q: What happens if the SDDL specified in MsiLockPermissionsEx is incorrect, or if the user does not have permissions to apply the security settings described by the SDDL?

A: The installation fails if Windows Installer is unable to resolve the SDDL specified in the MsiLockPermissionsEx table into a valid security descriptor, or if the user doesn’t have the permissions to apply those settings, unless the package is blessed by an administrator.

Q: When is the resolution of SDDLText into the binary security descriptor done?

A: Unlike the older LockPermissions table, the resolution of permissions into the binary security descriptor for MsiLockPermissionsEx is done during the execution phase, at the time when an object is actually being installed. This is important because it means you can even set security settings referencing a new user account that is being created as part of the installation as long as the account creation is scheduled before the object is installed.

Q: Now that I can set security attributes on a service installed by a package via the MsiLockPermissionsEx table, can I do so with the LockPermissions table as well?

A: No, if you wish to set security attributes on a service, you will have to use the MsiLockPermissionsEx table. The behavior and semantics of the LockPermissions table will not change.

Q: My product has already been released. Can I use MsiLockPermissionsEx table to secure objects that are already installed? Can I use this feature to secure objects via a patch?

A: Similar to the LockPermissions table, you can use a patch to secure objects that are being installed on the machine with MsiLockPermissionsEx table, including objects that replace existing ones on the machine as part of the installation. If an object is not installed as part of the current installation, security settings specified in MsiLockPermissionsEx will not be applied to it. It should be kept in mind that a patch that includes either of these two tables – MsiLockPermissionsEx or LockPermissions – will be marked as not uninstallable.

Q: Will there be an ICE validation test to help me author the new table?

A: Yes, ICE 104 is being introduced to help validate the MsiLockPermissionsEx table.

 Q: Will this feature be available on down-level platforms?

A: No, as of now, this feature is being introduced only in Windows 7. Down-level platforms will ignore MsiLockPermissionsEx table, if present. See the table below for behavior on various platforms:

*“Default security settings” mean that if an object does not replace an existing object, it receives no explicit security descriptor: the access to the new object is based on the attributes of its parent or container object. If an object replaces an existing object on the system, the replacement gets the security settings of the object it replaces. If the replaced object had no explicit security descriptor, the access to the new object is based on the attributes of its parent or container object.

 [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

Windows Installer 4.5 introduced a feature to install multiple packages in a single transaction. Multi-package transactions allow setup developers to install multiple packages as an atomic unit that are installed together, or rolled back completely. You can also apply patches to multiple products or even repair multiple products – any maintenance mode installation – within a single transaction. Installation scripts are not merged but executed in the order that packages are installed, and commit actions are deferred till the very end.

There is an installation sequence restriction, however: if you are installing both 32- and 64-bit packages – marked in the Template summary property of an MSI package – you must install the 64-bit packages first before the 32-bit packages.

Within a single transaction, if you install a 32-bit package and then a 64-bit package, any attempts to install files to 64-bit directories like ProgramFiles64Folder will be redirected as highlighted below.

    ******* Product: x86.msi

MSI (s) (3C:4C) [22:35:38:008]: Running installation inside multi-package transaction MultiMsi 

MSI (s) (3C:F4) [22:35:45:821]: Target path resolution complete. Dumping Directory table...
MSI (s) (3C:F4) [22:35:45:822]: Note: target paths subject to change (via custom actions or browsing)
MSI (s) (3C:F4) [22:35:45:831]: Dir (target): Key: TARGETDIR    , Object: C:\
MSI (s) (3C:F4) [22:35:45:831]: Dir (target): Key: ProgramFilesFolder    , Object: C:\Program Files (x86)\
MSI (s) (3C:F4) [22:35:45:841]: Dir (target): Key: ManufacturerDir    , Object: C:\Program Files (x86)\Heath Stewart\
MSI (s) (3C:F4) [22:35:45:849]: Dir (target): Key: INSTALLLOCATION    , Object: C:\Program Files (x86)\Heath Stewart\MultiMsi (x86)\ 

    ******* Product: x64.msi

MSI (s) (3C:4C) [22:35:48:404]: Running installation inside multi-package transaction MultiMsi 

MSI (s) (3C:38) [22:35:48:793]: WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute 17 characters in 'C:\Program Files\' folder path. (mask argument = 0, the folder pair's iSwapAttrib member = 0).
MSI (s) (3C:38) [22:35:48:793]: PROPERTY CHANGE: Modifying ProgramFiles64Folder property. Its current value is 'C:\Program Files\'. Its new value: 'C:\Program Files (x86)\'.

MSI (s) (3C:38) [22:35:48:797]: Target path resolution complete. Dumping Directory table...
MSI (s) (3C:38) [22:35:48:798]: Note: target paths subject to change (via custom actions or browsing)
MSI (s) (3C:38) [22:35:48:799]: Dir (target): Key: TARGETDIR    , Object: C:\
MSI (s) (3C:38) [22:35:48:799]: Dir (target): Key: ProgramFiles64Folder    , Object: C:\Program Files (x86)\
MSI (s) (3C:38) [22:35:48:800]: Dir (target): Key: ManufacturerDir    , Object: C:\Program Files (x86)\Heath Stewart\
MSI (s) (3C:38) [22:35:48:801]: Dir (target): Key: INSTALLLOCATION    , Object: C:\Program Files (x86)\Heath Stewart\MultiMsi (x64)\

You can see the Windows Installer is redirecting ProgramFiles64Folder to ProgramFilesFolder. Files intended for 64-bit locations end up in 32-bit locations. However, if you reverse the sequence of packages to install the 64-bit package first before the 32-bit package, the directories are resolved correctly as shown below.

    ******* Product: x64.msi

MSI (s) (F4:CC) [22:39:19:277]: Running installation inside multi-package transaction MultiMsi

MSI (s) (F4:70) [22:39:21:325]: Target path resolution complete. Dumping Directory table...
MSI (s) (F4:70) [22:39:21:353]: Note: target paths subject to change (via custom actions or browsing)
MSI (s) (F4:70) [22:39:21:361]: Dir (target): Key: TARGETDIR , Object: C:\
MSI (s) (F4:70) [22:39:21:375]: Dir (target): Key: ProgramFiles64Folder , Object: C:\Program Files\
MSI (s) (F4:70) [22:39:21:407]: Dir (target): Key: ManufacturerDir , Object: C:\Program Files\Heath Stewart\
MSI (s) (F4:70) [22:39:21:430]: Dir (target): Key: INSTALLLOCATION , Object: C:\Program Files\Heath Stewart\MultiMsi (x64)\ 

    ******* Product: x86.msi

MSI (s) (F4:CC) [22:39:25:502]: Running installation inside multi-package transaction MultiMsi

MSI (s) (F4:FC) [22:39:25:896]: Target path resolution complete. Dumping Directory table...
MSI (s) (F4:FC) [22:39:25:896]: Note: target paths subject to change (via custom actions or browsing)
MSI (s) (F4:FC) [22:39:25:897]: Dir (target): Key: TARGETDIR , Object: C:\
MSI (s) (F4:FC) [22:39:25:898]: Dir (target): Key: ProgramFilesFolder , Object: C:\Program Files (x86)\
MSI (s) (F4:FC) [22:39:25:898]: Dir (target): Key: ManufacturerDir , Object: C:\Program Files (x86)\Heath Stewart\
MSI (s) (F4:FC) [22:39:25:899]: Dir (target): Key: INSTALLLOCATION , Object: C:\Program Files (x86)\Heath Stewart\MultiMsi (x86)\

To install components into their right directories, you must install 64-bit packages first before 32-bit packages. If you have a functional requirement to install the 32-bit packages first you must do so in a separate transaction and simulate rollback yourself: you must uninstall packages from previous transactions.

Microsoft Visual Studio 2010 Beta 1 customers have been reporting that when they start Outlook or any of the Office applications, VS2010 is repaired. This issue can also happen for VS2005 and VS2008, and for any products using Visual Basic for Applications (VBA).

Besides being an annoyance and potentially taking a while to complete, the repair attempt can prompt for source. Picking the right source may not always be obvious from the dialog caption especially if it is truncated. And all the while Outlook or whichever application you started is probably waiting to finish starting up.

Even if you successfully complete the repair operation, this issue may continue each time you start the same application.

How to workaround this issue

Windows Installer logs an event that describes the requested feature and which product it is repairing. For this simple workaround, you need to find the latest event log entry. Using information in that event log entry, you’ll remove and re-add a feature and all its components into directory that should always be available.

1. Click on Start
2. Click on Run
3. Type “eventvwr” (without quotes) and click OK. If you are prompted to elevated on Vista or newer, click Continue.
4. Expand Windows Logs and click Application
5. Find the recent warning where the Source is MsiInstaller. In Vista and newer,
   1. Click Filter Current Log… in the right action pane
   2. Check Warning
   3. Type “MsiInstaller” (without quotes) in the Event sources edit control
   4. Type “1001” (without quotes) in the event IDs edit control
   5. Click OK

You should see a message similar to the follow,

Detection of product '{316EE0C1-DB94-30BA-95E6-F4959035EE4B}', feature 'VB_for_VS_7_Ent_28_x86_enu' failed during request for component '{DD68FEE8-C369-11D1-A173-00A0C90AB50F}'

I've also attached an event viewer filter you can unzip and import as a custom view.

Keep the log viewer open with the recent warning of type 1001 and open an elevated command prompt.

• On XP as an administrator,
  1. Click on Start
  2. Click on Run
  3. Type “cmd” (without quotes) and click OK
• On Vista and newer.
  1. Click on Start
  2. Type “Command Prompt” (without quotes)
  3. Right click on Command Prompt and click Run as administrator. If you are prompted to elevated, click Continue.

You’ll now use the information in the warning message to run two commands consecutively. The first command removes the feature, and the second command reinstalls it locally. The reason you need to do this for this simple workaround is explained in detail below. Use the GUID after “product” along with the feature name as shown in the corresponding example below.

start /wait msiexec.exe /i {316EE0C1-DB94-30BA-95E6-F4959035EE4B} /L*vx "%TEMP%\1.remove.log" REMOVE=VB_for_VS_7_Ent_28_x86_enu
start /wait msiexec.exe /i {316EE0C1-DB94-30BA-95E6-F4959035EE4B} /L*vx "%TEMP%\2.addlocal.log" ADDLOCAL=VB_for_VS_7_Ent_28_x86_enu TARGETDIR="%ProgramFiles%\Microsoft Visual Studio 10.0"

You will likely be prompted for your installation media when running the second command, so be sure to have your installation DVD loaded or ISO mounted. If you installed from the web or your media is not available, you will be prompted to download the media from the web.

How to avoid this issue

If you have any external drives connected to your machine, consider disconnecting them when installing Visual Studio or make sure that they are plugged in when starting applications like Outlook if you have any add-ins for those applications installed.

Description of the issue

Some components in Visual Studio are authored to support advertised installations. By default, advertised components will not be installed until they are needed. For COM servers, Windows Installer writes encoded data to the server library registry value like InProcServer32. This information contains information about the product and feature that will install the component. Windows Installer will always trigger a health check when advertised data is present for COM objects since, inherently, the COM server path isn’t registered.

Even though the feature that installs these components is typically installed locally, Windows Installer still writes this encoded data to the registry. This isn’t normally a problem unless the components to be advertised also install to TARGETDIR or a descendant of TARGETDIR that is not otherwise redirected.

Because TARGETDIR must be the root directory of any Windows Installer package, technically every directory is a descendant of TARGETDIR; however, directories like ProgramFilesFolder are automatically redirected to their corresponding directories like C:\Program Files. Custom actions can also redirect directories, and this is typical in Visual Studio. If TARGETDIR itself isn’t redirected, it defaults to ROOTDRIVE which is the fixed drive with the most free space available, and “fixed drive” doesn’t necessarily mean its an internal drive. External drives these days are growing more common. Any descendants of TARGETDIR are also located relative to ROOTDRIVE then.

So if you have an external drive with a lot of free space connected when you installed Visual Studio, a number of components may have gotten installed there. Even if you do not see any files mysteriously appear after installing Visual Studio, components may still have gotten registered to the other drive. This can actually happen for any Windows Installer products.

Now if you start a product like Outlook that might have add-ins installed that use Visual Studio Tools for Office system Runtime (VSTOR) or Visual Basic for Applications (VBA), creating COM objects they install triggers a repair. This happens because Windows Installer requires the COM server path and this, in turn, triggers a health check. Since the component installation directory – TARGETDIR or a descendant when the component was installed – is no longer available, a repair begins but will ultimately fail in this case since the installation directory is unavailable.

Other problems may manifest. For example, if a file within the same feature is missing for unrelated reasons, Windows Installer installer may prompt for source to replace that file.

So if you had an external drive connected when you installed Visual Studio, make sure you keep it connected when starting applications like Outlook if you have add-ins installed – or at least if you’re experiencing this issue. Better yet for VS 2010 Beta 1, disconnect it when installing Beta 1 unless you intend to install Beta 1 to that drive but remember to keep it connected. On a related note, keep in mind that disk space on your Windows system drive is still consumed by Windows Installer, .NET Framework, and a few other components.

We are working to identify all possible components that may cause this issue for future releases, including VS2010.

The Visual Studio 2008 RTM and SP1 detection keys are largely the same as the Visual Studio 2005 SP1 detection keys, and are documented below. But there is a caveat for released and upcoming versions: the shared detection value can be overwritten by an older installation of the same release.

For example, if you installed VS2008 Professional, then installed VS2008 SP1, and after that installed Team Foundation Client (TFC) 2008 RTM, the shared detection value is reset to 0 instead of 1. To be sure SP1 is installed, you need to detect SP1 on specific editions of Visual Studio 2008 or any other of our 2008 product releases including .NET 3.5 RTM and SP1.

Product family detection value

Product families define a group of products with similar functionality. The “VS” product family, for example, includes many editions but defines all full SKUs of the Visual Studio IDE. To find the service pack level of a product family, search for the following registry value.

Key: HKEY_LOCAL_MACHINE\Software\Microsoft\DevDiv\[ProductFamily]\Servicing\9.0
Value (REG_DWORD): SP

The exception is for product families “NetFX” and “WPF” that use version 3.5 instead of 9.0.

If the registry value is 0, the RTM version of the product family is installed. If the value is 1, then SP1 is installed on the product family.

Keep in mind, however, that this value is shared by all editions within a product family. If an older product edition is installed after a newer product edition within the same product family, the value will be overwritten. To detect whether SP1 is installed you need to check individual product editions.

Product families released for the 2008 wave of products include,

• NetFX, WPF: .NET Framework 2.0, 3.0, and 3.5 including Windows Presentation Framework
• RDBG: Visual Studio 2008 Remote Debugger
• TRIN: Visual Studio Tools for the Office System 3.0 Runtime
• VB: Visual Basic 2008 Express Edition
• VC: Visual C++ 2008 Express Edition
• VCS: Visual C# 2008 Express Edition
• VNS: Visual Web Developer 2008 Express Edition
• VS: Visual Studio 2008 Professional, Visual Studio Team System 2008 Team Suite, etc.
• VSTF: Visual Studio 2008 Team Explorer, Visual Studio 2008 Team Test Load Agent, etc.

Product edition detection value

A product family may install one or more editions. The “VS” product family, for example, contains several editions including “PRO” (Professional"), “VSTS” (Team Suite), and more. To find the service pack level of a product edition, search for the following registry value:

Key: HKEY_LOCAL_MACHINE\Software\Microsoft\DevDiv\[ProductFamily]\Servicing\9.0\[ProductEdition]\[ProductLanguage]
Value (REG_DWORD): SP

The exceptions are for product families “NetFX” and “WPF” that use version 3.5 instead of 9.0, and do not specify a ProductEdition. For .NET itself, the language is always 1033 unless you’re detecting the SP level for a language pack that uses the LCID for a specific culture.

So for .NET, you would check the following registry value:

Key: HKEY_LOCAL_MACHINE\Software\Microsoft\DevDiv\NetFX\Servicing\3.5\1033
Value (REG_DWORD): SP

For either Visual Studio or .NET, if the registry value is 0, the RTM versions of the product family are installed. If the value is 1, then SP1 is installed on the product family.

The ProductLanguage is the LCID of the product installed, such as 1033 for English (US).

The following table contains the list of released product families, editions, and the product names.

Detection in Windows Installer XML

WiX v3 contains a number of properties to detect the SP level. Aaron Stebner has provided a good post that describes how.

Last Monday we shipped Visual Studio 2010 Beta 1 and .NET Framework 4.0 Beta 1 to MSDN customers, and made them publicly available Wednesday. More information about Visual Studio 2010 and .NET Framework 4.0 are available on MSDN, and Aaron Stebner has a good collection of direct links.

While we have worked hard to reduce install times and installation issues and hope you don’t encounter any, in case you do experience an issue we encourage you to gather and upload logs using our updated log collection utility available for download. This will automatically package a lot of logs and product information we can use to diagnose problems and compress them into %TEMP%\vslogs.cab by default. You can then open a bug from the support site and attach logs one the bug is submitted.

In an effort to reduce acquisition times by downloading only what you need for your machine instead of an entire DVD image, we have made web installers available for the following SKUs,

• Visual Studio 2010 Processional Beta 1 – Web Installer
• Visual Studio Team System 2010 Team Suite Beta 1 – Web Installer

For help from the community and Microsoft engineers, please visit the forums for these beta 1 releases. We always appreciate your feedback.

When installing a patch package, Windows Installer first determines if the patch is applicable. Depending on how the patch is installed, this happens a little differently. Windows Installer can determine the list of applicable products, or it can be told to which products the patch should be applied.

Possible products

To have Windows Installer determine to which products the patch applies, you can execute msiexec.exe with /update or /p as shown in the following example.

msiexec.exe /update patch.msp

Windows Installer will enumerate the list of ProductCodes in the patch’s Template summary property. The same behavior is true when calling the MsiApplyPatch() function or the MsiApplyMultiplePatches() function when the second parameter is null.

You can also tell Windows Installer to which product the patch should applied using /package or /i as shown in the following example.

msiexec.exe /package {ProductCode} /update patch.msp

For the specified ProductCode or product package, Windows Installer will build the PATCH property and pass that in the command line similar to executing msiexec.exe as shown in the following example. When using the PATCH property, the full paths to each patch must be supplied.

msiexec.exe /package {ProductCode} PATCH=full\path\patch.msp

Windows Installer will evaluate each patch against the specified product. However, if installing the patch or patches using MsiApplyMultiplePatches() with a specific ProductCode, Windows Installer will modify the PATCH property to list only the patch packages with the specified ProdutCode in their Template summary property. If you’re not sure which patches apply to a product, this may be desirable behavior. If you pass in the PATCH property yourself and even one patch does not apply to the specified ProductCode, Windows Installer will terminate and return ERROR_PATCH_TARGET_NOT_FOUND (1642).

Verifying applicability

Once the list of patches has been passed into the installation session, Windows Installer will enumerate the transforms in each patch being applied. If a minor upgrade patch is being installed, Windows Installer will also enumerate the transforms in patches that have already been applied because minor upgrade may change which patches are applicable.

Within a patch package are sets of transforms: there is an authoring transform that describes the changes to the product, and a patch transform that describes how to install the patch and which files are updated. These transforms have the same name except the patch transform name begins with a hash (#).

Windows Installer will enumerate each authoring transform, using the following applicability information from their summary information stream.

• Character Count summary property: the upper 16 bits (word) contain the validation flags, and the lower 16 bits contain the error conditions. These flags are documented in detail for the MsiCreateTransformSummaryInfo() function.
• Last Saved By summary property: the platform and language of the product after it has been transformed.
• Revision Number summary property: the ProductCode, ProductVersion, and UpgradeCode of the target product database, and the new ProductCode and ProductVersion of the product after transformation. Changing the UpgradeCode in a patch is not recommended.
• Template summary property: the platform and language of the target product database. This value may be left blank if the transform does not validate the language. Windows Installer does not currently support validation of the platform.

The transform validation bits in the Character Count summary property determine which other summary properties are relevant. The typical validation bits of 0x0922 specify that the target ProductCode and UpgadeCode are equal to those specified in the Revision Number summary property of the transform, and that the full ProductVersion is equal to the value also in the Revision Number summary property. It’s also important to note that Windows Installer only validates up to the first three fields of the ProductVersion. The fourth field can be changed freely in a small update as a means of tracking and diagnosing updates.

If the ProductLanguage was validated, the ProductLanguage of the target product must match the value in the Template summary property.

When an authoring transform has been validated as applicable to the current product, the related patch transform is assumed to be applicable (validation bits are ignored). The remaining transforms in a patch are ignored, though Windows Installer will still log verbose validation information for each remaining transform.

If a valid transform is found within a patch, the patch is applicable to the product. That still doesn’t mean the patch will be applied, however, since the patch must still be sequenced and supersedence determined. But if a patch is applicable, it will at least be registered to the product. This means that it may be applied in the future if other patches are installed or removed from the product, and that it will be uninstalled with the product. However, since a single patch package is cached for all applicable products, the patch package itself is not deleted from the system until all products to which it’s registered are uninstalled or the patch is uninstalled from all applicable products.

Once all applicable patched are determined, a verbose log will display applicable, obsolesced, superseded, and invalid patches as shown in the following log example.

MSI (c) (88:38) [21:17:01:707]: Final Patch Application Order:
MSI (c) (88:38) [21:17:01:707]: {C26A5DDB-E2C5-4D2E-BC6E-449CBA57184E} -
MSI (c) (88:38) [21:17:01:707]: {A4AC638D-2C4F-4C9E-8962-9A674E782259} -
MSI (c) (88:38) [21:17:01:707]: {C697D8F7-E77A-4DA1-9CED-3F3E5115400D} - c:\Users\Test\AppData\Local\Temp\patch1.msp
MSI (c) (88:38) [21:17:01:707]: {73F7C9E3-08EC-4910-8D5B-3BF90C07EC1C} -
MSI (c) (88:38) [21:17:01:707]: Other Patches:
MSI (c) (88:38) [21:17:01:707]: Superseded: {B45F8725-6450-44D0-9284-01F321026767} -
MSI (c) (88:38) [21:17:01:707]: Superseded: {B0BB7DD1-D63A-4B73-8E73-6F055CB541AC} -
MSI (c) (88:38) [21:17:01:707]: Unknown\Absent: {402ADF4A-1B3D-4824-AE69-3606DDC2CE70} - c:\Users\Test\AppData\Local\Temp\patch2.msp

The names of the valid transforms are also registered to the product to save time by not re-evaluating applicable patches and transforms again during repair operations. The names of the valid transforms can be retrieved using the MsiGetProductInfo() or MsiGetProductInfoEx() functions with the INSTALLPROPERTY_TRANSFORMS property.

Transforming the database

Windows Installer will not actually modify the target database unless applying the patch to an administrative installation, which is created by using msiexec.exe /a. The vast majority of time, you will install a patch on a client machine.

Windows Installer will create views on the product database transformed by each applied transform. When Windows Installer queries the package for information, typically the transforms will add to, update, or remove data and tables. However, the transform error condition flags will fail the installation if not satisfied. With the typical transform error condition flags of 0x001f, Windows Installer will only err if the transforms attempt to change the database code page.

Order of events

Determining patch applicability and validating transforms always occurs before installation execution begins. Any code that needs to modify the list of patches must execute before installing or updating a product. This includes calling APIs like the MsiInstallProduct() function. Custom actions scheduled to execute during installation cannot modify the list of patches, and returning an error from any custom action added by a patch will terminate the entire installation session.

Today, this very day, 10 years ago, before the new millennium, I joined Microsoft as a full time employee. I can remember sitting in NEO (New Employee Orientation) on my first day listening to instructions on what forms to sign where and later experienced employees spoke about tips on how to be successful at Microsoft. I don't remember the specifics of what was said. I just remember being so excited to get started writing code. For real.

Ten years seems like a long time, especially in the computer industry. Microsoft recognizes the time with an award (displayed to the right) which is presented by your manager at a convenient team meeting sometime near the month of the anniversary. Honestly, I was a bit surprised when the incredibly heavy box was handed over. Had it already been 10 years?

Some people ask, "Did you ever imagine you'd spend 10 years at Microsoft?" Others are more critical, "How could you work at one company for 10 years?" To be honest, it doesn't feel like 10 years at one company. Instead, it feels more like about 3.5 years at Microsoft Office then 2 years in Microsoft Windows Server then 2 years in Microsoft Windows Core then 2 years at Microsoft Store/Windows Marketplace and now a little over a half a year working on Microsoft Live Mesh. Sure all those groups start with the name "Microsoft" but each of them have a unique culture and purpose. It's like working at 5 different companies without needing to migrate my 401K.

Nonetheless, it has been 10 years at Microsoft so it seems like some celebration is in order. To celebrate, I will be hosting 10 pounds of M&Ms outside my office door. Bringing one pound of M&Ms for each year of your anniversary is a tradition that I learned when I started in Office. As I moved across the company, I found that not all teams shared the tradition but I always observe the ritual. So, if your on Microsoft campus in the next couple days then swing by my office and grab a cup full of M&Ms. To recognize the decade, I'm mixing in a pound of Reese's Pieces just for grins.

Trust me the sugar'll help your coding... or something like that. <smile/>

Remember last time when I mentioned that if you didn't hear me talking about WiX v3.0 that would be a good thing? Well, all is not lost but we did take a bug fix tonight so I would appreciate it if everyone would download the latest WiX v3.0 build (with today's date or newer) and make sure all is well for you. The fix is small and very targeted so I'm not expecting problems.

The bug fixes was SFBUG:280526. It was found while Heath was investigating another bug related to language transforms. The issue boils down to bogus logic skipping the validation flags that determine how/when a transform applies. This means that if you use the WiX toolset to build language transforms or patches (which contain embedded transforms) then you need to pick up this drop to make sure everything works correctly.

We've been punting a lot of bugs to WiX v3.5 when there is some sort of work around. This bug, unfortunately, had no work around. Hopefully this is the last bug we take for WiX v3.0 and we will still ship on July 4th.

Below is the pie chart representing our bug count. Yes, it's zero again.

Below you will see an empty box. That is not a mistake. Robert suggested I have a picture of a blue pill there: You take the blue pill, the story ends, you wake up in your bed and believe whatever you want to believe.

Well, the story isn't quite over but we do have zero bugs filed against the WiX toolset for v3.0 now. As noted in previous weeks, we were working towards a lockdown date of the 28th that would punt all bugs that did not block key scenarios to WiX v3.5 or 4.0. Last night was Votive's last night for bugs and the remaining Visual Studio 2005 specific issues were all punted.

Now the Visual Studio test team has offered to do a full test pass over all the key scenarios to help ensure that we haven't regressed anything in the last few weeks. We'll let the whole toolset bake for the month of June. Assuming we don't find anything that causes us to modify any code then we release the final build of WiX v3.0 on July 4th.

So if you don't hear me talking about WiX v3.0 over the next few months that means all is well. What am I going to talk about instead? Not much. I'm busy writing code for WiX v3.5 and I'll talk more about that when it does something useful (right now it's just a bunch of code).

In the meantime, keep coding. You know I am.

I have posted updated versions of the .NET Framework detection code that I have previously written about on my blog that now support detecting the install state of the .NET Framework 4 client and full products.  In addition, I decided to create a new landing page that introduces the 2 versions of the sample code and provides usage information and download locations.

You can find the landing page at http://blogs.msdn.com/astebner/pages/9763379.aspx.

The downloads for the updated sample code are listed in this landing page.  There will need to be some slight updates to this sample code when the final version of the .NET Framework 4 releases.  I will keep this code up-to-date as needed in the future.

Last week, we posted a few Avatar samples on the Creators Club site to help people get started using Avatars in XNA Game Studio 3.1 games.  We’ve just released another useful Avatar sample that I wanted to make sure everyone saw:

• Object Placement on Avatars Sample - http://creators.xna.com/samples/objectplacementonavatar; this sample demonstrates how to find the world space transform needed to draw an object (in this case a baseball bat) in an Avatar’s hand

As always, make sure to keep an eye out on the Creators Club site for additional sample content in the future as well.

One of my colleagues, Ashu Tatake, started a blog last week.  This week he wrote a helpful post about updates in the XNA Framework sound effect APIs in XNA Game Studio 3.1, so I wanted to link to it here to help more people find it.

As Shawn Hargreaves described in this blog post, we made some changes in XNA Game Studio 3.1 to fix some issues we discovered with the sound effect APIs originally introduced in XNA Game Studio 3.0.  Shawn’s post describes the scenarios, the problems we found with the 3.0 APIs, and an overview of the changes.

Ashu follows that up by providing more detailed information about how to migrate existing 3.0 code to 3.1.  If you have any XNA Game Studio 3.0 projects that use sound effect APIs and are planning to upgrade the projects to 3.1, I encourage you to check out Ashu’s blog post for more details about how to identify which audio playback scenarios are most appropriate for your game and how to update your code to adjust for the breaking changes in the sound effect APIs in 3.1.

If you have an XNA Game Studio project that includes an XACT2 audio project and plan to upgrade it to XNA Game Studio 3.1, there is an additional manual step you must take to upgrade your XACT2 project to XACT3 format.

There is some information about this scenario in the XNA Game Studio 3.1 documentation.  Unfortunately, the documentation topics don’t list the full error message that you will see if you compile your upgraded project without also upgrading the XACT project, so searching for the error message doesn’t lead to the exact documentation topics that are intended to help in this scenario.  Hopefully this blog post will help guide folks who hit this error in the right direction.

Description of the issue

If you have an existing XNA Game Studio 3.0 project that uses an XACT2 audio project, then you upgrade to XNA Game Studio 3.1, you will see an error like the following in the Visual Studio error list when you attempt to compile it with XNA Game Studio 3.1:

The .xap file was created with a version of XACT that is incompatible with the XNA Framework Content Pipeline version used by this project. Refer to the documentation for options to resolve this mismatch.

Some guidance about this upgrade issue with XACT projects can be found in the following topics in the documentation:

• Upgrading XNA Game Studio Projects - in the table of contents, this topic is located at XNA Game Studio 3.1 | Getting Started with XNA Game Studio | Upgrading XNA Game Studio Projects (or via this link if you have XNA Game Studio 3.1 installed).
• Upgrade Guide: XNA Game Studio 3.0 to XNA Game Studio 3.1 – in the table of contents, this topic is located at XNA Game Studio 3.1 | Getting Started with XNA Game Studio | Upgrading XNA Game Studio Projects | Upgrade Guide: XNA Game Studio 3.0 to XNA Game Studio 3.1 (or via this link if you have XNA Game Studio 3.1 installed).

The following information in the above topics is applicable to help resolve this XACT compilation error message:

XNA Game Studio 3.1 projects must use the Microsoft Cross Platform Audio Creation Tool version 3 (XACT3), which is new to XNA Game Studio 3.1. The version of XACT provided with XNA Game Studio 3.0, XACT2, writes project files (.xap) that are incompatible with XNA Game Studio 3.1 projects. XNA Game Studio 3.0 projects must continue to use XACT2. Both versions of XACT are available in the Start menu, under All Programs | Microsoft XNA Game Studio 3.1 | Tools.

How to update from XACT2 to XACT3 in XNA Game Studio 3.1

Here are some more specific steps you can use to upgrade an XACT2 project used in XNA Game Studio 3.0 to the version of XACT3 so they can be used by an XNA Game Studio 3.1 project:

1. On a system with XNA Game Studio 3.1 installed, click on the Start menu, choose All Programs, then Microsoft XNA Game Studio 3.1 | Tools | Microsoft Cross-Platform Audio Creation Tool 3 (XACT3).
2. In the Microsoft Cross-Platform Audio Creation Tool (XACT) v3.0 tool, open the .xap file from the project that you upgraded from XNA Game Studio 3.0 to XNA Game Studio 3.1.  When it loads, you should see the following message in the XACT UI:
   
   ---------------------------
   XACT Version Mismatch
   ---------------------------
   This project file was created with the August 2007 release of XACT. You are running the March 2009 release.
   If you save this project, it will be saved as the current version and may no longer work with the version of XACT it was originally created with.
   ---------------------------
   OK  
   ---------------------------
   
   
3. Back up your .xap file before clicking OK if you would like to keep a copy of the old project (an upgrade does not happen automatically).
4. Click OK to upgrade the .xap project to 3.0 format.
5. Save the .xap project in the XACT UI and close the XACT UI.
6. Go back to Visual Studio 2008, open the project that you upgraded from XNA Game Studio 3.0 to 3.1 and choose to build it again.

Additional notes about this error message

The steps above explain how to upgrade an XACT2 project created with a previous version of XNA Game Studio to an XACT3 project that can be used with XNA Game Studio 3.1.  However, there are a few different scenarios where the “.xap file was created with a version of XACT that is incompatible with the XNA Framework Content Pipeline version used by this project” error message can occur, so the above workaround may not successfully resolve this error in all cases.

Here are some of the possible configurations where this error will occur:

• Attempting to compile an XNA Game Studio 3.1 project that includes an XACT2 project
  
  This is the scenario that the workaround above applies to
  
  
• Attempting to compile an XNA Game Studio 3.0 project that includes an XACT3 project
  
  This is the inverse of the above scenario. You need to create a new version of your XACT project using the tool included with XNA Game Studio 3.1 at the following location on the start menu:  All Programs | Microsoft XNA Game Studio 3.1 | Tools | Microsoft Cross-Platform Audio Creation Tool 2 (XACT2).
  
  
• Attempting to compile an XNA Game Studio 3.0 or 3.1 project that includes an XACT project created with a version of the XACT tool other than the ones that ship with XNA Game Studio 3.1 (for example, the version of XACT in the DirectX SDK)
  
  This is similar to both of the above scenarios.  If you’re using an XNA Game Studio 3.1 project, you need to make sure the XACT project is saved in the format of the version of XACT3 that ships with XNA Game Studio 3.1.  If you’re using an XNA Game Studio 3.0 project, you need to make sure the XACT project is saved in the format of the version of XACT2 that ships with XNA Game Studio 3.0 and 3.1.

• Why Custom Actions get a Windows Vista Version Lie on Windows 7
• PCA Changes for Windows 7: How To Tell Us You are Not an Installer, Take 2 (because we changed the rules on you)