Heath Stewart's Blog

WoW64 is optional in Windows Server 2008 R2 Server Core

2009-11-06T10:53:22Z

Installation bootstrap applications are increasingly common as products chain dependencies like the Microsoft .NET Framework. Because 64-bit Windows supports both 32- and 64-bit execution, but 64-bit executables on 32-bit Windows give what some users might consider cryptic error messages, installation developers often ship a 32-bit bootstrap application that runs in either environment. Then in scenarios when a required package installs only in 64-bit Windows, the bootstrap application can present a friendly actionable error message.

Microsoft Windows supports 32-bit execution on 64-bit Windows with Windows-on-Windows 64-bit (WoW64). But what if WoW64 wasn’t available?

To support deployment to more constrained systems and to install with a smaller footprint to secure and maintain, Windows Server 2008 R2 Server Core offers WoW64 as an optional feature.

What does this mean for installation developers? Overall, 32-bit executables will not execute since the WoW64 subsystem is not installed. More specifically,

32-bit custom actions will not execute. Windows Installer will fail create a custom action server with error code 308.
32-bit bootstrap applications will not execute. You can expect error code 308 and the error message, “The subsystem needed to support the image type is not present.”

However,

Packages attributed to support the Intel platform will install as long as they do not contain 32-bit custom actions.

But this is really no cause for alarm. This only applies to Windows Server 2008 R2 Server Core designed to provide one or a few roles or features in an enterprise. They aren’t designed to run client applications. Administrators aren’t likely to install many applications on Server Core. And in Windows Server 2008 R2 Server Core WoW64 is enabled by default based on customer feedback from beta 2.

If you need to support server core and have 32-bit components to install, consider separate packages for 32- and 64-bit instead of a 64-bit package that contains 32-bit components and custom actions. This will allow for flexibility in supporting 32-bit only, 32- and 64-bit mixed, and 64-bit only installation. More work may be required to support processor-independent data files and other resources.

But remember this is only if you need to support Server Core. Most installation developers should have no cause for worry regarding the absence of WoW64.

Visual Studio 2010 and .NET Framework 4 Beta 2 Released

2009-10-19T23:01:48Z

As announced on Soma’s blog this morning, Microsoft Visual Studio 2010 Beta 2 and the .NET Framework 4 Beta 2 have been released to MSDN Subscribers and will be available for everyone on Wednesday.

Visual Studio 2010 boasts a great new user interface with better contrast and lots of UI elements that tend to add confusion to the development process. It’s pretty amazing how getting rid of a few lines increases usability.

For developers redistributing the .NET Framework, perhaps the best news is how much smaller and faster runtime deployment is. Peter Marcu also describes robustness features added to .NET Framework 4 setup such as attempting to fix common problems and retrying installation automatically.

Check them out and give us your feedback on issues you find. We also have dedicated forums for more social interactions with both Microsoft employees and other community members.

Booting Windows to a Differencing Virtual Hard Disk

2009-10-14T01:51:20Z

Testing software can be fun and rewarding. You get to see new, upcoming features and provide valuable feedback to the developer. But as with most pre-release software, we recommend that you don’t install it on production machines. You could dedicate extra machines for testing, or even test in a virtual machine. Virtual machines are great for testing operating systems and applications, and maximizing system resource usage. You can even take snapshots of the system disk and memory states and roll back to previous states.

Besides requiring additional memory and processor time, another problem with virtual machines is that they run under a standard configuration of a basic display driver and no sound driver in Hyper-V. All your other devices attached to your machine are not always accessible, including your graphics card that provides a nice Aero glass experience in Windows Vista and Windows 7.

But by installing Windows to a virtual hard disk (VHD) – the same format used by virtual machines – and creating a differencing disk on top of that you can test multiple configurations on the same base platform. You can choose with physical or virtual hard disk to boot and also take advantage of all the system devices your machine has to offer.

Step 1 (Optional): Partition your hard disk to store your VHD files

If you already have installed Windows Vista or Windows 7 and have plenty of free space on your system partition or in another partition – almost twice the amount of the virtual partitions you want to create – you may proceed to step 2. This step is useful if you want to install only to VHD files on your machine.

You’ll need to create a partition to store the boot configuration data (BCD) as well as the virtual hard disk (VHD) files. These can exist in the same partition, but Windows will typically create separate partitions as you see in the screenshot below. This also allow you to encrypt the system partition with BitLocker drive encryption (BDE) while maintaining a boot-readable partition.

Insert your Windows Vista or Windows 7 installation disk.
Proceed through the installation wizard until you see the installation type selection dialog which reads, “Which type of installation do you want?” Click Custom (advanced).
Select the unallocated space and click the New button. Windows installation will warn you that it will create another partition. This will appear as “System Reserved”.
Select the other partition and click the Format button.
Press Shift+F10 to bring up a command prompt.

Step 2: Create the VHD file

You’ll create a base virtual hard disk (VHD) in a partition with enough space available to hold the base installation and the differencing disk. This should be roughly twice the amount of space you pass to the “maximum” argument in the steps below. The number you pass to the “maximum” argument is in MB. A typical Windows 7 (x86) installation with a half-dozen or so driver updates and Microsoft ForeFront took a little over 6GB before being compressed.

You’ll create an expandable VHD as the base since it won’t be modified when booting to a differencing VHD. The installation will take a little longer since the VHD will be expanded as necessary, but this will result in a small base VHD instead of wasting unused space for a fixed VHD.

For the following steps, if you’re already logged into Windows Vista or Windows 7 you’ll need to open an elevated command prompt. If you’ve completed step 1, you continue in the command prompt you already opened.

In the command prompt, type the following commands. Substitute the path to the VHD with a path of your choosing. You may also specify a different size (in MB), but make sure the partition you create them in contains about twice the space you specify.

diskpart create vdisk file=C:\Win7-base.vhd maximum=65536 type=expandable select vdisk file=C:\Win7-base.vhd attach vdisk exit

Switch back to the installation wizard and click the Refresh button.
Select the new unallocated partition and click Next. You may see a warning that reads, “Windows cannot be installed to this disk. (Show details)” but can often safely ignore this.

Step 3 (Optional): Update drivers and install minimal software

After the installation has finished and you have logged in, you may want to update or install additional drivers for your hardware. You might also consider installing a minimal amount of software like a virus scanner. This will yield a smaller differencing disk.

For example, with virus software there are program files that need to be installed. Incremental updates may be provided for virus definitions. By installing the virus software first before creating the differencing disk, only definition updates will be contained within the differencing disk.

If you have installed the same Windows version that was already installed on another partition (if any) you may also have duplicate boot entry descriptions. You can rename the VHD boot entry to be unique.

Type the following in an elevated command prompt.

bcdedit /v

Find the boot entry where the value of the “device” data type reads “vhd=C:\Win7-base.vhd”. Copy the GUID value of the “identifier” data type. If quick edit isn’t enabled for the command prompt, right click and select Mark. Highlight the GUID – including the curly braces – and press Enter. An example GUID looks like {f7bc2aa7-8ca2-11dc-936e-edd86d023230}.
Type the following commands into the command prompt. Replace {guid} below with the GUID you copied above.

bcdedit /set {guid} description “Windows 7 (VHD)”

Finally, you may wish to run Windows Update one last time before attempting to reduce the VHD file size. Be sure to reboot so that any changes made to disk after the reboot are contained within the base VHD.

Step 4 (Optional): Reduce the base VHD file size

If you wish to reduce the amount of physical disk space consumed by the base VHD, you can attempt to reduce space within the VHD and then compress it from another Windows installation. It’s interesting to note that if you are viewing the VHD file on a separate partition while booted into the VHD file, the file size will appear to be the maximum size of the VHD. If you created an expandable disk as described in these instructions that is not accurate. You will see the correct file size when booted into a different partition.

You might also wish to relocate the paging file to the physical hard disk to reduce space consumed in the base VHD and reduce changes in the differencing VHD.

While booted to the VHD, click the Start button.
Type “Disk Cleanup” (without quotes), right click on program shortcut, and click Run as administrator.
Select the VHD drive letter and click the OK button.
Check all the options under “Files to delete” and click the OK button.
Click the Start button again.
Type “Disk Defragmenter” (without quotes) and select the program shortcut.
(Optional) You might want to click the Configure schedule button and disable automatic defragmentation. While booted into a differencing VHD, defragmenting the disk can lead to a big increase in the differencing disk size.
Click the Defragment disk button and wait for defragmentation to complete.

If you have formatted the VHD as NTFS (default for Windows Vista and Windows 7) you do not need to run the Virtual Disk Precompactor that ships with Virtual Server and Virtual PC. This may help for FAT-formatted partitions, though.

After you have defragmented, reboot into a different partition. You may boot into Windows and open an elevated command prompt, or start Windows installation and open a command prompt as described in step 1. Type the following commands.

diskpart select vdisk file=C:\Win7-base.vhd compact vdisk

This may take some time to complete, but you should notice a decrease in file size of C:\Win7-base.vhd.

Step 5: Create the differencing VHD and configure the boot entry

Next you’ll create a differencing VHD that will store all the differences between what you write to the disk and the base VHD. When you install software, it’s all contained within the differencing VHD and the base VHD is not modified. You can even create multiple differencing VHDs and boot to each of them separately, or create a chain of differencing VHDs.

In the following example you’ll create a differencing VHD for installing Visual Studio 2010 Beta 2, but you could use any file name and path or install any software you like instead.

You cannot be booted into the base VHD when creating the differencing VHD. If you have rebooted into another partition with Windows Vista or Windows 7, or into a Windows installation, do so now. Open an elevated command prompt as described in previous steps.

Type the following into the command prompt. Substitute the path to the differencing VHD with a path of your choosing.

diskpart create vdisk file=C:\Dev10-Beta2.vhd parent=C:\Win7-base.vhd exit

Enumerate the existing boot entries. Find the boot entry where the value of the “device” data type reads “vhd=C:\Win7-base.vhd”. This is the same GUID as the one you may have copied in optional step 3.
Type the following into the command prompt. Replace {guid} below with the GUID you copied.

bcdedit /v bcdedit /copy {guid} /d “Dev10”

You’ll see a message printed like, “The entry was successfully copied to {f7bc2aaa-8ca2-11dc-936e-edd86d023230}.” Copy this new GUID and replace {guid} below with this new GUID when typing the following commands. The last command will set this boot entry as the default. You should not boot to the base VHD again or you will invalid the differencing VHD.

bcdedit /set {guid} device vhd=[locate]\Dev10-Beta2.vhd bcdedit /set {guid} osdevice vhd=[locate]\Dev10-Beta2.vhd bcdedit /default {guid}

Step 6: Install Visual Studio 2010

After you have rebooted the machine into the new differencing VHD you can begin installing software. In this example you’ll install Visual Studio 2010. Download and run the web installer or insert your installation media and run setup.exe.

Follow the installation wizard choosing either the default installation or a custom installation. After the install is completed explore the new features of Visual Studio 2010 and enjoy.

Summary

Virtual hard disks are an integral part of virtual machines, but if you want to test on real hardware booting to a VHD is a good alternative. Microsoft TechNet has a lot of details about preparing, deploying, and booting to VHDs; and the Microsoft Virtualization team blog has more great information.

ATL Security Update KB971092 still offered on Microsoft Update

2009-08-10T05:10:45Z

A security update for ATL, KB971092, is currently offered for Visual Studio 2008 Service Pack 1 customers who have Visual C++ installed. If Microsoft Update is continuously offering this patch to you, you may need to clear up some disk space. The patch is 365MB and contains headers, libraries, and executables for most of Visual C++ including ATL and the CRT. This patch, however, may require up to 3.7GB to install with a possible residual footprint of about 1.7GB if you have all Visual C++ features installed.

How to workaround this issue

If you are continuously being offered ATL security update KB971092, most likely you need to free up some additional space. You’ll need about 3.7GB to install this patch. If you’ve already downloaded it from the Download Center, you’ll need about 3.4GB.

Alternatively, if you do not use Visual C++ you can also re-run setup and choose to uninstall the Visual C++ feature and all its children. The patch should no longer be offered to you after that.

Freeing additional space

To free additional space, first run the Disk Cleanup utility as an administrator. If you are prompted to clean up for the current users or everyone, choose everyone. On Windows 7, after the main user interface is displayed click on the Clean up system files button. Because this is a security update, it is recommended you check all options and click OK to delete those files.

You may also delete the Windows Installer baseline cache. These files are useful to help eliminate prompts for source when uninstalling patches, and even sometimes when installing certain types of patches. By deleting these files, if you are prompted for source you may need to insert your original installation media, or download and extract previously downloaded installations.

To delete these files, open an elevated command prompt and type the following command.

rmdir /q /s %WINDIR%\Installer\$PatchCache$

DO NOT delete %WINDIR%\Installer no matter how large it might be. The cached files in this directory are needed to repair, patch, and even uninstall Windows Installer products. Rebuilding the cache is very difficult and time consuming, and you may have to reinstall Windows. If you want to reduce space consumed in this directory, you may uninstall any products you do not use.

Description of the issue

Windows Installer may require a lot of space. It is a transactional installation engine, so it must make copies of the older files that will be replaced. To maintain security during installation, a copy of the patch itself is made after verifying security and possibly prompting for consent (UAC). To support uninstalling the patch without prompting for source, copies of the older files being replaced are also stored in the baseline cache mentioned above, %WINDIR%\Installer\$PatchCache$.

If you do not want the patch cache to be created for this or any other products when patched, you can set the MaxPatchCacheSize system policy to 0. You must stop the Windows Installer service for the change to take affect. Future Windows Installer installations will automatically start the service so merely stopping it is sufficient. It will automatically stop after 10 minutes of inactivity as well.

After the patch is installed, a copy of the patch is kept for future installation operations – to support patch uninstall, for example – and cannot be deleted until all applicable products are uninstalled.

If you did not already disable the baseline cache, copies of files replaced under %ProgramFiles% (default) are left behind to reduce source prompts. You can delete these as described above, with the understanding you may be prompted for the source of Visual Studio 2008 in the future, especially if you uninstall this ATL security update.

Microsoft .NET Framework 4.0 Beta 1 should be removed before upgrading to Windows 7

2009-08-10T03:16:00Z

If you have been beta testing Microsoft .NET Framework 4.0 Beta 1, we recommend you install a fresh copy of Windows 7 on your machine. Alternatively, you may also choose to uninstall Visual Studio 2010 Beta 1 and .NET 4.0 Beta 1 prior to upgrading to Win7.

Microsoft Windows 7 is available to MSDN and TechNet subscribers.

Problem

If you have installed .NET Framework 4.0 Beta 1 on your Windows Vista machine, after upgrading to Windows 7 you may encounter some problems. Managed code may not function, especially applications built to target .NET 4.0 Beta 1. Also, if you have any ClickOnce applications installed, Windows Explorer may crash continuously when you log in.

Status

This issue has been fixed in .NET Framework 4.0 Beta 2.

Trouble installing other products after Visual Studio

2009-07-31T12:48:00Z

Customers have commented that whenever they try to install other products or patches they continually see the following message,

Another installation is in progress. You must complete that installation before continuing this one.

Customers may also see instances of msiexec.exe or msiexec.exe*32 appear continuously in Task Manager or other process monitoring software.

This may occur after installing either Visual Studio 2008 or Visual Studio 2010 Beta 1. If you look in your Application event log as described below, for the MsiInstaller source you may see a message like either of the following,

Detection of product '{AA4A4B2C-0465-3CF8-BA76-27A027D8ACAB}', feature 'VSTA_IDE_12590_x86_enu', component '{FF4A39EF-8F8B-4557-9F81-50DC44C6D30A}' failed. The resource 'c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\en\' does not exist.

Or,

Detection of product '{874D5E2B-AACE-303A-B3EC-2563E071473E}', feature 'VS_IDE_657_x86_enu', component '{A5854250-7B92-4A50-935F-6A486589F87D}' failed. The resource 'd:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\en\' does not exist.

In either case, some of the quoted values may be different but the path may still reference “Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\en”.

How to workaround this issue

To determine if the issue affecting you is the one described here, you must start the event viewer. This is also necessary to identify the missing resource, if any, that needs to be created.

Click on Start
Click on Run
Type “eventvwr” (without quotes) and click OK. If you are prompted to elevated on Vista or newer, click Continue.
Expand Windows Logs and click Application
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 “1004” (without quotes) in the event IDs edit control
5. Click OK

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

You should see a message similar to those above, stating stating that a directory like “C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\en\” does not exist. If you do not find such a message, you might search for event ID 1001 as logged during a similar event.

To workaround this particular issue, simply create the directory that is missing.

Description of the issue

This is another example of the potential problems when advertising Windows Installer features. When COM registration is advertised, serialized data identifying the product feature that provides the COM server is written to the registry. When the class loader reads this value in this format that identifies a Windows Installer product feature, Windows Installer is queried for the component path which starts a resiliency check against the feature.

Because in this case a directory is missing for a component, Windows Installer logs an event and begins a maintenance installation to repair affected features. If you cancel this repair operation the issue will continue to surface. If allowed to continue, you might be prompted for source. However, unlike another example of a similar event, repairing the product will not resolve the issue.

As described for ICE18, a component that does not have a key path set must declare a related entry in the CreateFolder table. Of course, a versioned file is always preferred as a key path for a component if available, but an unversioned file or registry value will suffice.

So because the component referenced in the event log does not declare a key path nor create the “en” sub-directory, a repair triggered by a resiliency check will always be performed. And because only one Windows Installer transaction can run at a time, other Windows Installer installations are blocked.

Installation sequence restrictions for multi-package transactions

2009-07-03T10:02:11Z

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.

How to workaround the issue when opening Office applications repairs Visual Studio

2009-05-30T03:52:00Z

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.

Click on Start
Click on Run
Type “eventvwr” (without quotes) and click OK. If you are prompted to elevated on Vista or newer, click Continue.
Expand Windows Logs and click Application
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.

Detecting Visual Studio 2008 Service Pack 1

2009-05-29T13:40:00Z

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.

ProductFamily	ProductEdition	ProductName
dynamicanalysis	collectionbits	Microsoft Visual Studio 2008 Performance Collection Tools - ENU
HH	DEX	Microsoft Document Explorer 2008
MSDN	EXP	MSDN Library for Microsoft Visual Studio 2008 Express Editions
MSDV	MSDN9.0	MSDN Library for Visual Studio 2008 - ENU
RDBG	STD	Microsoft Visual Studio 2008 Remote Debugger - ENU
SDE	VSD	Microsoft Device Emulator version 3.0 - ENU
TRIN	AIDE	Microsoft Visual Studio Tools for Applications 2.0 - ENU
TRIN	ART	Microsoft Visual Studio Tools for Applications 2.0 Runtime
TRIN	TRIR	Visual Studio Tools for the Office system 3.0 Runtime
VB	ROS	Microsoft Report Viewer Redistributable 2008
VB	EXP	Microsoft Visual Basic 2008 Express Edition - ENU
VCS	EXP	Microsoft Visual C# 2008 Express Edition - ENU
VC	RED	Microsoft Visual C++ 2008 Redistributable - x86 9.0.21022
VC	STD	Microsoft Visual C++ 2008 Standard Edition - enu
VC	EXP	Microsoft Visual C++ 2008 Express Edition - ENU
VNS	EXP	Microsoft Visual Web Developer 2008 Express Edition - ENU
VSS	STD	Microsoft Visual SourceSafe 2008 - ENU
vstf	at	Microsoft Visual Studio 2008 Team Foundation Server - ENU
VSTF	ATP	Microsoft Visual Studio 2008 Team Foundation Server Proxy - ENU
VSTF	bb	Microsoft Visual Studio 2008 Team Foundation Server Build - ENU
VSTF	dtea	Microsoft Visual Studio 2008 Team Test Load Agent- ENU
VSTF	dtec	Microsoft Visual Studio 2008 Team Test Load Controller- ENU
VSTF	PERF	Microsoft Visual Studio 2008 Performance Tools - ENU
vstf	tfc	Microsoft Visual Studio 2008 Team Explorer - ENU
vstf	wssExt	Microsoft Visual Studio 2008 Team Foundation Server SharePoint Extensions - ENU
VS	IDE	Microsoft Visual Studio Shell 2008 - ENU
VS	IDE	Microsoft Visual Studio 2008 Shell (integrated mode) - ENU
VS	PRO	Microsoft Visual Studio 2008 Professional Edition - ENU
VS	STD	Microsoft Visual Studio 2008 Standard Edition - ENU
VS	VSDB	Visual Studio Team System 2008 Database Edition - ENU
VS	VSR	Microsoft Primary Interoperability Assemblies 2005
VS	VSTA	Microsoft Visual Studio Team System 2008 Architecture Edition - ENU
VS	VSTD	Microsoft Visual Studio Team System 2008 Development Edition - ENU
VS	VSTS	Microsoft Visual Studio Team System 2008 Team Suite - ENU
VS	VSTT	Microsoft Visual Studio Team System 2008 Test Edition – ENU

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.

Updated log collection utility available for Visual Studio 2010 and .NET 4.0 Beta 1

2009-05-23T02:25:36Z

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,

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

Patch Applicability

2009-04-13T09:32:32Z

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.

Microsoft .NET 1.x and Visual Studio 7.x patches may fail to uninstall

2009-03-13T02:54:37Z

When attempting to uninstall a patch from the products listed in the Applies To section below, the following error may occur.

Internal Error 2771. M953297

The last part of the error message will vary with each patch, where the last 6 digits are the knowledge base article related to the patch.

Applies To

Microsoft .NET Framework 1.0
Microsoft .NET Framework 1.1
Microsoft Visual Studio .NET 2002
Microsoft Visual Studio .NET 2003
Microsoft Visual C++ .NET 2003
Microsoft Visual C# .NET 2003
Microsoft Visual Basic .NET 2003

Workaround

One possible reason the error has occurred is because a system policy is set. You can temporarily disable this system policy and attempt to reinstall the patch.

Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

You need to disable the EnforceUpgradeComponentRules Windows Installer system policy using the steps below.

Click Start and then click Run.
In the Open box, type regedit.exe and click OK. If you are prompted with a User Account Control (UAC) dialog, please authenticate as an administrator or click Continue.
Browse to the key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer.
Delete the registry value EnforceUpgradeComponentRules and close the registry editor.
Click Start and then click Run.
In the Open box, type services.msc and click OK. If you are prompted with a User Account Control (UAC) dialog, please authenticate as an administrator or click Continue.
Right click on Windows Installer and click on Stop. It is okay if the Stop button is disable: the service was already stopped.
Attempt to reinstall the patch.

To optionally re-enable the EnforceUpgradeComponentRules system policy, follow the steps below.

Click Start and then click Run.
In the Open box, type regedit.exe and click OK. If you are prompted with a User Account Control (UAC) dialog, please authenticate as an administrator or click Continue.
Browse to the key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer.
Right click on the Installer key and select New, then DWORD.
Type the name EnforceUpgradeComponentRules and press Enter.
Double click the value you just created, then type 1 and press Enter.
Close the registry editor.

Details

Patches created for the products listed in the Applies To section above support the appearance of uninstall by installing an obsolescing patch and installing older baseline files. Back when these products were first released and entered the servicing lifecycle, Windows Installer did not support real patch uninstall. The only way to uninstall patches back then was to installing a patch that obsolesces (the predecessor to supersedence) another patch, optionally carrying a file payload to avoid prompts for source to replace older files. This is shown in the log fragment below where the "anti-patch" {D5C479FB-3609-4A1D-A106-830635BF50B0} obsolesces the related patch {AAC3F1F0-5649-4670-A698-F1523729F015}.

MSI (c) (14:DC) [02:44:31:310]: Final Patch Application Order: MSI (c) (14:DC) [02:44:31:310]: {411EDCF7-755D-414E-A74B-3DCD6583F589} - MSI (c) (14:DC) [02:44:31:310]: {D5C479FB-3609-4A1D-A106-830635BF50B0} - D:\Users\Test\AppData\Local\Temp\MSPE928.tmp MSI (c) (14:DC) [02:44:31:310]: Other Patches: MSI (c) (14:DC) [02:44:31:310]: Obsolete: {AAC3F1F0-5649-4670-A698-F1523729F015} -

So because another patch is being installed, it cannot remove components from an existing feature. When the EnforceUpgradeComponentRules Windows Installer system policy is set, the installation will fail as shown below.

MSI (s) (EC:C8) [02:44:34:835]: Machine policy value 'EnforceUpgradeComponentRules' is 1 MSI (s) (EC:C8) [02:44:34:835]: SELMGR: Component 'DDPatch.UpdateGac' is registered to feature 'M953297', but is not present in the FeatureComponents table. Removal of components from a feature is not supported! MSI (s) (EC:C8) [02:44:34:835]: Note: 1: 2771 2: M953297

This does not otherwise pose a problem because the patch is being uninstalled and the feature affected is specific only to that patch. And if the patch is reinstalled, the feature is explicitly added locally by a custom action anyway since Windows Installer back then also did not automatically determine feature actions during patch installation.

Why does ICE03 state my localized template string is invalid?

2009-02-13T12:35:31Z

Question

When I run ICE validation, why does ICE03 state the following error?

ICE03 ERROR Invalid template string; Table: Error, Column: Message, Key(s): 1958

The string reads,

ユーザー [2] の特権が不十分です。必要な特権をユーザーに付与してインストールを続行しますか? [いいえ] を選択するとインストールは終了します。

Answer

This ICE error can appear in several columns in several tables that use the Formatted column type or a derivative, like the Template column type used by the Message column of the Error table shown above. Formatted column types allow properties to be inserted between square brackets while the Template column type additionally allows field numbers to be inserted between square brackets. But because properties are of the Identifier column type which allows only alphanumeric ASCII characters, the period (.), and underscores (_), unsupported characters cannot appear between square brackets in a Formatted column type or its derivative.

Take a closer look at the highlighted substring below,

ユーザー [2] の特権が不十分です。必要な特権をユーザーに付与してインストールを続行しますか? [いいえ] を選択するとインストールは終了します。

Since that is not a valid property identifier, ICE03 pumps an error message to the validation message handler because it knows from the _Validation table that the containing column is a Formatted column.

To resolve this issue, escape the square brackets using [\[] in place of [ and [\]] in place of ] as shown below.

ユーザー [2] の特権が不十分です。必要な特権をユーザーに付与してインストールを続行しますか? [\[]いいえ[\]] を選択するとインストールは終了します。

Changes to Package Caching in Windows Installer 5.0

2009-02-03T04:57:21Z

Windows Installer 5.0 is shipping in Windows 7 as part of the operating system. To address the issue where the User Account Control consent dialog is displayed with an “Unidentified Publisher”, the .msi package is cached in its entirety.

Prior to Windows Installer 5.0, installation packages, or .msi files, were stripped of their embedded cabinets – if any – when cached on the system to save space. When repairing the product, if installed files were missing then Windows Installer would attempt to use the last used source location, an application-defined location, or prompt for the installation source. While these prompts can be annoying or even difficult to resolve sometimes, they do reduce the disk space required after an installation is complete.

When Vista added UAC, elevation even for administrators by default was required. Elevation was always required for per-machine installations, but administrator accounts already ran with full privileged tokens so elevation was implicit. To add validation to this elevation prompt - aka the consent dialog - the publisher for signed packages was displayed, and “Unidentified Publisher” was displayed for unsigned packages. But during uninstall, packages would display “Unidentified Publisher” even if they were signed because their embedded cabinets were stripped thus invalidating the digital signature and so Windows Installer wouldn’t verify the cached package as shown below using Windows Installer 4.5 on Vista.

MSI (s) (DC:0C) [16:46:44:058]: MSI_LUA: Elevation required to install product, will prompt for credentials MSI (s) (DC:0C) [16:46:44:059]: MSI_LUA: Entering Credential Request. hwnd = 1120166, MsiAction = 2, productname = Microsoft Visual Studio Team System 2008 Team Suite - ENU, version = 9.0.30729, language = 1033, manufacturer = Microsoft Corporation MSI (s) (DC:0C) [16:46:44:059]: MSI_LUA: (continued)... packagepath = , packagesource = , dwUpdates = 0

To resolve this issue, Windows Installer 5.0 in Windows 7 will cache the installation packages without stripping their embedded cabinets and verify the cached package as shown below using Windows Installer 5.0 on Windows 7.

MSI (s) (20:98) [16:51:25:386]: MSI_LUA: Elevation required to install product, will prompt for credentials MSI (s) (20:98) [16:51:25:386]: MSI_LUA: Entering Credential Request. hwnd = 1116208, MsiAction = 2, productname = Microsoft Visual Studio Team System 2008 Team Suite - ENU, version = 9.0.30729, language = 1033, manufacturer = Microsoft Corporation MSI (s) (20:98) [16:51:25:386]: MSI_LUA: (continued)... packagepath = C:\Windows\Installer\33e5a8b.msi, packagesource = C:\Windows\Installer\33e5a8b.msi, dwUpdates = 0

But this won’t prevent prompts for source even if all files are compressed into embedded cabinets. Windows Installer 5.0 does not consider the Installer-cached .msi files to be valid source and will still resolve possible source locations or prompt as it has in the past.

Installation developers should take this into account since Windows Installer already may require so much disk space and compress files if necessary in external cabinets. Consider your servicing scenarios carefully and determine if you should cache the installation source yourself using the Source List APIs like MsiSourceListAddSource provided by Windows Installer, or just let Windows Installer use its default source resiliency behavior.

Feature Changes in Visual Studio 2008 SP1 may prompt for SQLSysClrTypes.msi

2009-02-03T00:02:11Z

After installing Visual Studio 2008 Service Pack 1, adding or removing features from Visual Studio may prompt for the file SQLSysClrTypes.msi with the following text:

Setup is looking for file SQLSysClrTypes.msi.
Please insert Microsoft Visual Studio Team System 2008 Team Suite – ENU disk 1 now.

The text will read differently depending if you have Visual Studio 2008 Professional Edition or another edition or language installed.

Workaround

SQLSysClrTypes.msi is a product package installed with VS2008 SP1. To satisfied this prompt you’ll need to obtain that file again.

Download a complete layout of VS2008 SP1 if you haven’t already.
Open the directory were you copied VS2008 SP1.
Right click on SQLSysClrTypes.msi and select Copy.
Open an Explorer window (ex: Windows key + E) and browse to the directory where you installed Visual Studio 2008. By default this is “C:\Program Files\Microsoft Visual Studio 9.0” where C:\ is your system drive.
Double click on the folder that corresponds to the name of the product you installed (ex: “Microsoft Visual Studio Team System 2008 Team Suite – ENU”).
Right click on empty space in the window, click New, then Folder, and type “wcu” (without quotes).
Double click that new “wcu” folder to open it.
Right click on empty space in the window, click New, then Folder, and type “smo” (without quotes).
Double click that new “smo” folder to open it.
Right click on empty space in the window and click Paste.
In the dialog prompt requesting SQLSysClrTypes.msi, click the Browse button.
Expand folders to select the directory you opened in step 5 and click the OK button. Do not select the “wcu\smo” directory you created.
Click the OK button on the dialog prompt.

On 64-bit machines you will always see this prompt when adding or removing features so it is recommended you keep this file for future use. If you are a network administrator or have the installation source copied to your hard drive, you can also create this directory in the root of the original installation source directory and the setup executable will automatically find SQLSysClrTypes.msi.