Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

August, 2007

  • Aaron Stebner's WebLog

    Updated version of the .NET Framework cleanup tool that can remove the .NET Framework 3.5

    • 15 Comments

    I've posted an updated version of the .NET Framework cleanup tool that now contains an option to remove the .NET Framework 3.5 (in addition to 1.0, 1.1, 2.0 and 3.0).  I also added some additional information to be removed when uninstalling the .NET Framework 1.1 (thanks to this comment on one of my other blog posts).

    You can use the following links to find more information about the .NET Framework cleanup tool and download it if you need it on your system:

    Note - at the time that I am writing this blog post, the .NET Framework 3.5 is still only a beta, so currently the cleanup tool is only able to remove the beta 1 and beta 2 versions of the .NET Framework 3.5.  I will update the tool in the future when future builds of the .NET Framework 3.5 are released publicly.

    <update date="5/19/2008"> Added an alternate download location for the cleanup tool in case the first site is down. </update>

     

  • Aaron Stebner's WebLog

    Updated alpha version of Yougle Vista available for download

    • 1 Comments

    Steven Harding recently posted an update about a couple of the projects he's been working on in this post on his Digital Lifestyle Developer Blog, and I wanted to link to it here and encourage folks to check out these applications.

    Updated alpha version of Yougle Vista

    The first is an updated alpha version of Yougle Vista.  You can use Yougle Vista to browse and view community video from sources such as YouTube, Google Video, MSN Soapbox and others.  You can find information about Yougle Vista at http://www.push-a-button.com.au/products/mce/vista/youglevista/index.php.

    As stated in the blog post, the Yougle Vista application is still in alpha and you may encounter some bugs, in particular on 64-bit versions of Windows Vista.  I've been using Yougle Vista for a few weeks on my 32-bit Windows Vista Ultimate system and the only real issue I had was the initial hurdle of getting it running in the first place.  Once I installed a recent build of the FFDShow codec pack, it worked fine in most scenarios.  I highly encourage you to check out this application, even in alpha form.

    Poker game timer

    The second application is a poker game timer.  It can be downloaded from http://www.push-a-button.com.au/downloads/BlindTimerSetup.msi and keeps track of blinds, antes, and time until they will increase.  It includes spoken announcements of blind increases and warnings as the timer is about to expire.  I'm not a big poker player myself, but if you are, this application could come in handy for you.

  • Aaron Stebner's WebLog

    .NET Framework 3.0 hotfix (KB932471) will fail to install if .NET Framework 3.5 beta 2 is installed

    • 9 Comments

    Recently, we have been hearing reports from customers who have installed the .NET Framework 3.5 beta 2 and then visited Windows Update and were offered .NET Framework 3.0 hotfix KB932471, but it continually fails to install.

    The .NET Framework 3.5 contains an updated version of the .NET Framework 3.0, and that updated version of 3.0 contains this hotfix already.  Unfortunately, there was some incorrect detection information in the Windows Update logic that is used to decide whether or not to offer this hotfix to a system.

    If you have the .NET Framework 3.5 beta 2 or later installed and run into issues while trying to install KB932471 (either from Windows Update or by downloading it directly from the Microsoft Download Center), you can safely ignore this failure and just skip installing this hotfix since the equivalent fix is already a part of the version of the .NET Framework 3.5 that you have on your system.

    The Windows Update authoring logic that is causing this error is in the process of being fixed, and will be refreshed on the live Windows Update site in the near future.

  • Aaron Stebner's WebLog

    Report VS 2008 or .NET Framework 3.5 beta installation issues directly to the setup team

    • 1 Comments

    I just noticed this post on Bret Grinslade's blog that I wanted to link to here to help raise visibility.  In that post, Bret describes how to gather more information about any installation failures that you might encounter while installing a beta version of Visual Studio 2008 and the .NET Framework 3.5, and also some resources where you can go to find more information about known issues and workarounds.

    Here are some useful links that were presented in that blog post.  If you are running into any problems installing VS 2008 or the .NET Framework 3.5, hopefully they will be helpful to you:

    Gathering information from your system and reporting bugs if you run into setup issues

    Finding information about known issues and workarounds

  • Aaron Stebner's WebLog

    Windows Installer 4.5 beta now available for download on the Microsoft Connect site

    • 4 Comments

    As reported this weekend by the Windows Installer team and Heath Stewart, the beta of Windows Installer 4.5 (including binaries, headers, libraries and help files) has been posted to the Connect site for members of the beta program to download and try out.  Here is some useful information about the Windows Installer 4.5 beta program:

  • Aaron Stebner's WebLog

    Links to useful ways to customize the Windows Vista Media Center SDK project template

    • 3 Comments

    As described in this blog post, a new version of the Windows Vista Media Center SDK was recently released.  That version of the SDK contains a new C# project template.  I just noticed a couple of new post on the Media Center Sandbox blog that describe some useful modifications that can be made to this project template in order to create different types of Windows Vista Media Center applications:

    I encourage you to check out these posts to see step by step instructions for these customizations that can be made to the standard Windows Vista Media Center SDK project template.

  • Aaron Stebner's WebLog

    Possible causes of Windows Vista hotfix install failures

    • 12 Comments

    The .NET Framework 3.5 beta 2 includes updates for the .NET Framework 2.0 and 3.0.  Since the .NET Framework 2.0 and 3.0 are installed as OS components on Windows Vista, the updates are delivered as Windows Vista hotfix packages.  We have seen some issues related to the installation of these .NET Framework 2.0 and 3.0 updates during .NET Framework 3.5 beta 2 setup that have turned out to be caused by known bugs with the Windows Vista hotfix installation engine.  The following items describe the issues we have seen so far with the Windows Vista hotfix installation engine and how to work around them to unblock .NET Framework 3.5 beta 2 installation:

    Issue 1 - Installer encountered an error 0x8007177f. This machine is disabled for file encryption.

    Aaron Ruckman described this issue in this blog post.  If you encounter this issue during .NET Framework 3.5 setup, the .NET Framework 2.0 update package will fail with error code 6015.  If you are running the .NET Framework 3.5 setup directly, you will see an error like the following in the setup error log:

    [07/01/07,11:30:00] Microsoft .NET Framework 2.0SP1 (CBS): [2] Error: Installation failed for component Microsoft .NET Framework 2.0SP1 (CBS). MSI returned error code 6015

    If you are running VS 2008 setup (which chains the .NET Framework 3.5 as a prerequisite), you will see an error like the following in the setup error log:

    [07/01/07,11:30:00] Microsoft .NET Framework v3.5: [2] Error code 6015 for this component means "This machine is disabled for file encryption."

    This error means that there is a domain policy in effect that prevents file encryption using the Encrypting File System (EFS) from working.  There is a Windows Vista hotfix available to correct this issue, and information about obtaining it can be found in the knowledge base article located at http://support.microsoft.com/kb/933595.

    Issue 2 - Installer encountered an error 0x80073712.

    On some Windows Vista systems, it is possible that the OS component store has gotten into a corrupt state.  When this happens, the Windows Features control panel will be empty, and any Windows Vista hotfixes that you attempt to install will indicate that they are not applicable.  If you are running the .NET Framework 3.5 setup directly, you will see an error like the following in the setup error log:

    [07/01/07,11:30:00] Microsoft .NET Framework 2.0SP1 (CBS): [2] Error: Installation failed for component Microsoft .NET Framework 2.0SP1 (CBS). MSI returned error code 1

    If you are running VS 2008 setup (which chains the .NET Framework 3.5 as a prerequisite), you will see an error like the following in the setup error log:

    [07/01/07,11:30:00] Microsoft .NET Framework v3.5: [2] Error code 1 for this component means "Incorrect function."

    There are steps in the knowledge base article at http://support.microsoft.com/kb/931712 that can be used to update the registry in order to repair the Windows Vista component store in order to work around this error.  To summarize the steps listed in that knowledge base article, you can do the following:

    1. Open an administrative command prompt by clicking on the Start menu, choosing All Programs, then Accessories, then right-clicking on the Command Prompt item and choosing Run as administrator
    2. Type the following command:  reg delete HKLM\COMPONENTS /v StoreDirty /f

    After running this command, you can re-run .NET Framework 3.5 or VS 2008 setup and hopefully resolve this error.

    Note that return code 1 from a Windows Vista hotfix package means that the package is not applicable on the system.  However, this StoreDirty registry value is not the only possible cause of this error for .NET Framework 2.0 and 3.0 hotfixes.  The same error can appear in the setup logs if you previously had the beta 1 version or some pre-beta 2 CTP version of the .NET Framework 3.5 installed on your Windows Vista system and the old beta was not uninstalled prior to installing beta 2.  If the above workaround does not help, you can try the following to remove any pre-beta 2 versions of the .NET Framework 2.0 and 3.0 update packages for Windows Vista:

    1. Go to the Programs and Feature control panel
    2. Click the link at the top left labeled View installed updates
    3. Locate any updates named Hotfix for Microsoft Windows (KB110806), Hotfix for Microsoft Windows (KB929300) and Hotfix for Microsoft Windows (KB930264), right-click on them and choose Uninstall if they are present on your system
    4. Reboot and try to install the .NET Framework 3.5 beta 2 again
  • Aaron Stebner's WebLog

    How to sign up for the Windows Installer 4.5 beta program

    • 2 Comments

    I just noticed a set of steps that have been posted on the Windows Installer team blog that can be used to sign up for the Windows Installer 4.5 beta.  If you are interested in trying out this beta and haven't signed up yet, I encourage you to check out http://blogs.msdn.com/windows_installer_team/archive/2007/08/21/walkthrough-for-signing-up-for-windows-installer-4-5-beta.aspx for more information.

    Currently, signing up for the 4.5 beta will allow you to access some white papers about agility in software packaging and how Windows Installer 4.5 can help achieve agility goals.  In addition, according to this post, the Windows Installer 4.5 beta will be available for download "any day now" to members of the beta program.

  • Aaron Stebner's WebLog

    Updated version of the .NET Framework cleanup tool that can remove the .NET Framework 3.0

    • 5 Comments

    I've posted an updated version of the .NET Framework cleanup tool that now contains an option to remove the .NET Framework 3.0 (in addition to 1.0, 1.1 and 2.0).  I also embedded a UAC manifest in this version so it will prompt you for elevation when running the cleanup tool on Windows Vista.

    You can use the following links to find more information about the .NET Framework cleanup tool and download it if you need it on your system: 

    One important note - the cleanup tool does not allow you to remove any versions of the .NET Framework that are installed as part of the OS that it is being run on.   So, it does not support removing the .NET Framework 1.0 on Windows XP Media Center Edition or Windows XP Tablet PC Edition, removing the .NET Framework 1.1 on Windows Server 2003, or removing the .NET Framework 2.0 or 3.0 on Windows Vista.

  • Aaron Stebner's WebLog

    TV Toolbox beta 2 now available for download

    • 2 Comments

    A new beta version of the TV Toolbox application for Windows Vista Media Center has been released on the MCEDev.com site.  You can check out the following links for more information about TV Toolbox:

  • Aaron Stebner's WebLog

    How to workaround issue where launching Outlook triggers a repair of VS 2005

    • 2 Comments

    Recently, I helped investigate this Visual Studio 2005 issue reported on the Microsoft Connect site that I wanted to describe here in case anyone reading this blog runs into a similar issue.  To summarize that bug report, a couple of customers had installed VS 2005, and they started to notice that a repair would be triggered for VS when they launched Microsoft Outlook.

    How to reproduce this issue

    In the cases that I investigated, the customers had large-capacity USB hard drives connected to their systems.  The repair would occur if they disconnected or powered off their USB hard drive, and it would not occur if the USB hard drive was connected.

    How to workaround this issue

    There are a few possible workarounds for this type of repair:

    1.  Uninstall VS, then re-install it with the external hard drive disconnected

    2.  Leave the external hard drive connected when starting Outlook

    3.  Use the following steps to remove a couple of registry values from the system:

    • Click on the Start menu, choose Run, type cmd and click OK
    • Run this command:  reg delete "HKCR\CLSID\{AC0714F6-3D04-11D1-AE7D-00A0C90F26F4}\InprocServer32" /v InprocServer32 /f
    • Run this command:  reg delete "HKCR\CLSID\{AC0714F7-3D04-11D1-AE7D-00A0C90F26F4}\InprocServer32" /v InprocServer32 /f 

    Option 3 (deleting the registry values) is the least invasive, and there will not be any functional side effects in VS 2005 or in Outlook if you choose to do this.  The values that are listed above are only used by Windows Installer to advertise features, but VS 2005 installs all features locally and does not support advertising, so those registry values do not serve any practical purpose anyway.

    More information about the root cause

    To track down the exact cause of this repair, I had the customers send me some information from their application event logs in order to narrow this down.  As I described in this blog post, when Windows Installer triggers a repair of an MSI, it will log a pair of warnings in the application event log with a source named MsiInstaller.  The first warning will provide the component GUID for the component in the MSI that triggered the health check, and the second warning will provide the component GUID for the component in the MSI that Windows Installer detected was broken and in need of repair.

    There is a component in the VS 2005 product that has been incorrectly authored to try to use the drive with the largest amount of free space (the TARGETDIR property in Windows Installer) as a destination location.  In these cases, this drive resolved to the USB hard drive, and when that drive was disconnected or powered off, a repair will be triggered in cases where a health check is initiated by the system.

    As I described in this blog post, COM objects that are advertised in the Class table of an MSI will cause Windows Installer to perform a health check for the feature(s) that advertise them each time an instance of the COM object is instantiated.  The VS 2005 MSI advertises a couple of COM objects that are related to VBA add-in development, and Microsoft Outlook will try to instantiate those COM objects when it is launched in some cases.  In these cases, a health check of the VS 2005 product will occur, and the incorrectly authored component will be reported as broken if the USB hard drive is not available.

    Fortunately, there are a couple of changes in VS 2008 setup that will prevent this scenario from happening in the future:

    • The VBA add-in COM objects are no longer advertised via the Class table of the VS 2008 MSI
    • The component that uses TARGETDIR as a destination location has been removed from the VS 2008 MSI
  • Aaron Stebner's WebLog

    Where to find a full .NET Framework 3.5 beta 2 layout on a VS 2008 beta 2 DVD

    • 2 Comments

    Yesterday, I posted a set of instructions that can be used to download the components that make up the .NET Framework 3.5 beta 2 in order to create a network or CD-based install point that will not require any downloads during setup.

    As a reader pointed out in the comments of that post, there is a much easier way to assemble this install point if you already have downloaded a copy of VS 2008 beta 2.  From your VS 2008 beta 2 DVD, you can go to the \wcu\dotnetframework folder and copy the entire contents to a network share or a CD, and then run dotnetfx35setup.exe from there to install the .NET Framework 3.5 beta 2 without needing to download any additional components.

    If you follow the steps in my previous blog post, you will see that you end up assembling the equivalent of that folder structure.  Those steps are primarily useful for folks who do not want to have to download the entire VS 2008 beta 2 DVD ISO in order to get access to the .NET Framework 3.5 beta 2 bits to create a network or CD-based install for it.

    Note that you can use the same size reduction tricks described in my previous blog post - meaning that you can remove Windows Vista-specific components if your product is not going to support that OS, you can remove downlevel components if your product is only going to support Windows Vista, and you can remove x86 or x64 components if your product is processor-specific.  These size reduction steps can be helpful if you are trying to fit the .NET Framework 3.5 beta 2 and your product onto a single CD for redistribution and you're running out of space to fit everything on the disc.

  • Aaron Stebner's WebLog

    How to create an installable layout for the .NET Framework 3.5 beta 2

    • 14 Comments

    A while back, I wrote a set of instructions that can be used to create a network install point for the Visual Studio 2005 Express Editions (because the only thing available for download is an ISO file that has to be burned to CD, or a web download bootstrapper that requires network connectivity during setup in order to work correctly).

    Recently, I was asked how to create a network install point for the .NET Framework 3.5 beta 2 using similar instructions (because currently, the only available downloadable package for the .NET Framework 3.5 beta 2 is a web download bootstrapper and this is not always useful for redistribution scenarios if you want to not require internet connectivity).  I decided to write up a set of instructions to do this.

    There are a couple of important caveats to keep in mind when using these instructions:

    • These instructions are specific to the beta 2 version of the .NET Framework 3.5.  They will not work once the final release of the .NET Framework 3.5 is ready, so if you are reading this post and want to create a layout for the final release, do not use these steps.  I will post updated steps when the product ships and add a link to the new steps to this post to hopefully reduce confusion.
    • Depending on your scenario, you can download only a subset of the packages listed below if you would like to try to conserve disk space on your network or CD-based install point.  For example, if you do not plan to support Windows Vista, you can skip the packages that have Windows Vista in the name.  Also, if you only need to support x86 or x64 but not both, you can selectively download only the x86 or only the x64 packages.
    • If you do not download one or more of the packages below and copy them into your network layout, the .NET Framework 3.5 setup wrapper will try to download the packages for you automatically if it detects that your system needs the package.  If this happens and the system does not have an active internet connection, setup will fail.

    The following steps will allow you to manually assemble an installable layout for the .NET Framework 3.5 beta 2:

    1. Create a new folder named c:\netfx35_beta2 (or one of your own choosing)
    2. Download the web download bootstrapper for the .NET Framework 3.5 beta 2 and save it to the c:\netfx35_beta2 folder created in step 1 above
    3. For each of the components listed below, follow the set of additional steps listed below to download them and place them in the correct location

    .NET Framework 2.0 with Service Pack 1 for Windows XP and Windows Server 2003 (x86) 

    Make a new folder named c:\netfx35_beta2\dotnetfx20 and download all of the following files into this folder:

    Note:  The above fwlinks come from the [gencomp760] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    .NET Framework 2.0 with Service Pack 1 for Windows XP and Windows Server 2003 (x64) 

    Make a new folder named c:\netfx35_beta2\dotnetfx20 and download all of the following files into this folder:

    Notes:

    • The above fwlinks come from the [gencomp761] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
    • The payload of the x64 version of the .NET Framework 2.0 with Service Pack 1 includes the payload of the x86 version in addition to some x64-specific files.  This is because the .NET Framework 2.0 x64 version includes both 32-bit and 64-bit payload.

    .NET Framework 2.0 with Service Pack 1 for Windows Vista (x86) 

    Make a new folder named c:\netfx35_beta2\dotnetmsp\x86 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp750] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    .NET Framework 2.0 with Service Pack 1 for Windows Vista (x64) 

    Make a new folder named c:\netfx35_beta2\dotnetmsp\x64 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp751] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    .NET Framework 3.0 with Service Pack 1 for Windows XP and Windows Server 2003 (x86) 

    Make a new folder named c:\netfx35_beta2\dotnetfx30 and download all of the following files into this folder:

    Note:  The above fwlinks come from the [gencomp780] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    .NET Framework 3.0 with Service Pack 1 for Windows XP and Windows Server 2003 (x64) 

    Make a new folder named c:\netfx35_beta2\dotnetfx30 and download all of the following files into this folder:

    Notes:

    • The above fwlinks come from the [gencomp781] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.
    • The payload of the x64 version of the .NET Framework 3.0 with Service Pack 1 includes the payload of the x86 version in addition to some x64-specific files.  This is because the .NET Framework 3.0 x64 version includes both 32-bit and 64-bit payload.

    .NET Framework 3.0 with Service Pack 1 for Windows Vista (x86) 

    Make a new folder named c:\netfx35_beta2\dotnetmsp\x86 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp752] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    .NET Framework 3.0 with Service Pack 1 for Windows Vista (x64) 

    Make a new folder named c:\netfx35_beta2\dotnetmsp\x64 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp753] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    .NET Framework 3.5 for all operating systems (x86) 

    Make a new folder named c:\netfx35_beta2\dotnetfx35\x86 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp301] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    .NET Framework 3.5 for all operating systems (x64) 

    Make a new folder named c:\netfx35_beta2\dotnetfx35\x64 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp302] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    RGB Rasterizer (x86) 

    Make a new folder named c:\netfx35_beta2\dotnetfx30 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp136] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    RGB Rasterizer (x64) 

    Make a new folder named c:\netfx35_beta2\dotnetfx30 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp137] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    MSXML 6.0 for Windows XP and Windows Server 2003 (x86) 

    Make a new folder named c:\netfx35_beta2\dotnetfx30\x86 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp707] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    MSXML 6.0 for Windows XP and Windows Server 2003 (x64) 

    Make a new folder named c:\netfx35_beta2\dotnetfx30\x64 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp708] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    WIC for Windows XP and Windows Server 2003 (x86) 

    Make a new folder named c:\netfx35_beta2\dotnetfx30 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp209] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    WIC for Windows XP and Windows Server 2003 (x64) 

    Make a new folder named c:\netfx35_beta2\dotnetfx30 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp210] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    XPS for Windows XP (x86) 

    Make a new folder named c:\netfx35_beta2\dotnetfx30 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp211] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    XPS for Windows XP (x64) 

    Make a new folder named c:\netfx35_beta2\dotnetfx30 and download the following file into this folder:

    Note:  The above fwlink comes from the [gencomp212] section of the file baseline.dat that is located inside of dotnetfx35setup.exe.

    <update date="8/16/2007"> Fixed incorrect links in the .NET Framework 2.0 with Service Pack 1 (x86) section above </update>

     

  • Aaron Stebner's WebLog

    .NET Framework 2.0 hotfix installation can cause temporary application performance problems

    • 5 Comments

    Some customers who have installed the recent .NET Framework 2.0 security update (KB928365 and MS07-040) on systems that also have the .NET Framework 3.0 installed have noticed performance degradation in their Windows Presentation Foundation (WPF, also formerly known as Avalon) applications for a short period of time after installing this update.

    As Heath Stewart previously described in this blog post, installing an update for the .NET Framework 2.0 causes native images to need to be re-generated for assemblies that depend on any updated .NET Framework 2.0 assemblies (including .NET Framework 3.0 assemblies).  The startup performance of some WPF applications depends greatly on having available native images, so if the existing native images are invalid and need to be re-generated, these WPF applications will take longer to load until the WPF native images have been re-generated.

    During the initial installation of the .NET Framework 3.0, some of the .NET Framework 3.0 assemblies were flagged as "critical," which will cause native images to be generated at initial setup time.  However, that flag is not currently respected in cases where an update to another product causes native images to need to be regenerated.  In this case, the security update only modifies the .NET Framework 2.0 product, and does not update the .NET Framework 3.0 product.  This causes the 3.0 assemblies to be queued for new native image creation in the background.  The NGEN service waits until the system is idle for 5 minutes before processing the background queue.

    Heath posted a workaround that can be used to cause the queued native images to be generated immediately so you do not have to wait for system idle time - you can run this command from a cmd prompt (if you are running Windows Vista, you need to use an elevated administrator cmd prompt):

    %windir%\Microsoft.NET\Framework\v2.0.50727\ngen.exe executeQueuedItems

    Fortunately, as Heath and Surupa (a program manager on the NGEN team here at Microsoft) point out in this blog post, the NGEN team and the .NET Framework setup team are implementing a fix in the next .NET Framework 2.0 update that will ensure that future updates made to .NET Framework 2.0 assemblies will trigger immediate native image re-generation for all critical .NET Framework assemblies (including those that are a part of the .NET Framework 3.0 and not just 2.0).  One important thing to note is that since this is a fix in the NGEN service, it will be in effect for updates that ship after the next update (because the first update is needed to change the behavior of NGEN itself, and then any future updates to the .NET Framework will be able to take advantage of that behavior change).

  • Aaron Stebner's WebLog

    Japanese .NET Framework 3.5 beta 2 and VS 2008 beta 2 now available

    • 3 Comments

    A couple of weeks ago, Microsoft released the beta 2 versions of the .NET Framework 3.5 and Visual Studio 2008, and I posted all of the download links here.  This week, Japanese versions of beta 2 have also been released for web download.  Here are the download locations for the Japanese versions of the .NET Framework 3.5 beta 2 and Visual Studio 2008 beta 2:

  • Aaron Stebner's WebLog

    Example WiX-based setup that can be used to build both 32-bit and 64-bit MSIs

    • 20 Comments

    I previously posted an example that allows you to build a WiX-based MSI that will install a Windows Vista Media Center application and create a custom start menu strip.  However, there is a limitation in this example (that was pointed out in this post on the Media Center Sandbox discussion forum) that affects the ability to install the application on 64-bit operating systems.  This blog post describes the limitations in my previous sample and presents a modified version of that sample that will allow you to build both 32-bit and 64-bit MSIs in order to work around the limitations.

    Description of the problem with my previous example

    As this forum post describes, you have to directly set registry entries in order to add custom strips to the Media Center start menu (which means that you have to author RegistryKey and RegistryValue elements in WiX).  However, if you create a 32-bit MSI and then try to install it on a 64-bit OS, the registry entries will get written to the WOW64 hive (HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft).  The 64-bit version of Windows Vista Media Center looks in the 64-bit registry hive and not the WOW64 registry hive when looking for custom start menu strips to load.  Therefore, the custom start menu strip will not appear in the Media Center start menu on a 64-bit OS in my previous example.

    Example that can be used to solve this problem

    To solve this issue, it is necessary to create separate 32-bit and 64-bit installers.  It is a little bit tricky to configure all of the settings and attributes that are necessary to create a 64-bit MSI just by reading through WiX and Windows Installer documentation, so I decided to create a WiX 3.0-based example that can be used to build 32-bit and 64-bit MSIs from the same WiX source (WXS) file.

    You can download this example from http://cid-27e6a35d1a492af7.skydrive.live.com/self.aspx/Blog%7C_Tools/start%7C_menu%7C_strip%7C_setup%7C_example%7C_with%7C_64bit.zip.  I started from my previous 32-bit-only example, and added 64-bit build support.  While this sample happens to install a Windows Vista Media Center application, it is intended to help demonstrate the general concepts required to create 64-bit MSIs in WiX.

    Changes made in this example to enable 64-bit builds

    The new sample includes a single WXS file that is processed twice in order to build 2 different MSIs (one 32-bit and one 64-bit).  In order to create a single WXS file that can build both types of MSI, I introduced a WiX pre-processor variable to pass in the name of the processor architecture, and then I added some if/then/else blocks to conditionally set some of the necessary MSI attributes based on whether the MSI being created will be 32-bit or 64-bit.

    If you look in the setup.wxs file in the example I posted, you can see all of the changes that I made to enable building a 64-bit MSI by looking for sections of the file that are enclosed in if statements such as the following:

    <?if $(var.ProcessorArchitecture)=x64 ?>
        <Package Description="!(loc.Package_Description)" Comments="!(loc.Package_Comments)" InstallerVersion="200" Compressed="yes" Platforms="x64" />
    <?else ?>
        <Package Description="!(loc.Package_Description)" Comments="!(loc.Package_Comments)" InstallerVersion="200" Compressed="yes" />
    <?endif ?>

    In order to set the ProcessorArchitecture variable, I added the following command line parameter when calling candle.exe to compile the WXS file:

    "%WIX_BUILD_LOCATION%\candle.exe" setup.wxs -dProcessorArchitecture=%PROCARCH% -out "setup_%PROCARCH%.wixobj"

    In addition, I added a second set of commands to call candle.exe and light.exe twice - one with the ProcessorArchitecture value set to x86 and the other with the ProcessorArchitecture value set to x64.

    Specific differences between a 32-bit MSI and a 64-bit MSI

    The following are the changes that I made in order to be able to create both 32-bit and 64-bit MSIs in WiX:

    • I created a unique product code for the x64 MSI that is different from the x86 MSI
    • In the Package element, the Platforms attribute must be set to the proper 64-bit operating system so that Windows Installer will recognize it as a 64-bit MSI.  In my example, I am creating an x64 MSI, so I set the Platforms value to "x64" for the 64-bit MSI, and left it blank (the default value) for the 32-bit MSI
    • I created a different default directory structure for each processor architecture.  The 64-bit MSI will install under the ProgramFiles64Folder and the 32-bit MSI will install under the ProgramFilesFolder by default.  This is necessary because Windows Installer requires 64-bit components to install under a 64-bit directory by default
    • I created a unique set of 64-bit components by copying the original set of 32-bit components, updating the Id values to be different than the 32-bit Id values, creating unique Guid values and adding the element Win64="yes" to indicate that these components are 64-bit.  A component must be marked as Win64="yes" in order to cause registry entries to be written under the 64-bit registry hive instead of the WOW64 registry hive
    • In order to prevent the 32-bit MSI from installing on a 64-bit OS (which will work by default, but that we do not want to work once we have a specific 64-bit MSI to install on a 64-bit OS), I added a custom action to the 32-bit MSI and scheduled it in the InstallExecuteSequence and InstallUiSequence tables.  The custom action checks to see if the Windows Installer 64-bit property is set (which indicates that the MSI is being invoked on a 64-bit system), and if that is set, it will block the MSI from installing

    Where to read more about 64-bit issues related to Windows Installer

    When working on this example, I relied heavily on the information in this post on Heath Stewart's blog and the links to Windows Installer MSDN topics that are included in it.  If you are looking for more detailed information about how Windows Installer works behind the scenes in 64-bit scenarios, I encourage you to check out this blog post and also the other topics in Heath's 64-bit blog category.

    <update date="3/23/2009"> Fixed broken link to sample download location. </update>

     

  • Aaron Stebner's WebLog

    Workarounds for some .NET Framework 3.5 beta 2 install issues we have seen so far

    • 5 Comments

    Since the release of the .NET Framework 3.5 beta 2 a couple of weeks ago, we have run into a few installation issues that I wanted to let folks know about.  The good news is that all of these issues will be fixed in time for the final release of the .NET Framework 3.5, but the bad news is that they can cause beta 2 to fail to install and you may need to apply one of the workarounds listed below.

    Issue 1: The IIS Admin Service is disabled

    The .NET Framework 3.5 beta 2 will fail to install if setup is being run on a system that has IIS installed, but the IIS Admin service is set to the disabled state.

    This issue will cause the following information to be written to the verbose MSI log file for the .NET Framework 3.5 component (named %temp%\dd_net_framework35_MSI*.txt):

    DDSet_Error: CFxInstaller::SetupComponents SetupScriptMaps failed. Error code: 0x80070422

    You can use the following steps to work around this issue:

    1. Click on the Start menu, choose Run, type services.msc and click OK
    2. In the Services snap-in that appears, locate the service named IIS Admin Service, right-click on it and choose Properties
    3. In the Startup type drop-down, change the value from Disabled to Automatic and click OK to save the changes
    4. Re-run .NET Framework 3.5 beta 2 setup
    5. (optionally) Change the Startup type back to Disabled after .NET Framework 3.5 beta 2 setup completes

    Issue 2: The IIS Admin Service is not installed

    The .NET Framework 3.5 beta 2 will fail to install if setup is being run on a system that has parts of IIS installed, but does not have the IIS Admin Service installed.

    This issue will cause the following information to be written to the verbose MSI log file for the .NET Framework 3.5 component (named %temp%\dd_net_framework35_MSI*.txt):

    DDSet_Error: CFxInstaller::SetupComponents SetupScriptMaps failed. Error code: 0x80070424

    You can use the following steps to work around this issue:

    1. Click on the Start menu, choose Run, type appwiz.cpl and click OK
    2. In the Add/Remove Programs control panel (or the Programs and Features control panel in Windows Vista), choose the item on the left side that is named Add/Remove Windows Features (or Turn Windows Features on or off in Windows Vista)
    3. Locate the Internet Information Services (IIS) feature and choose to either fully uninstall IIS, or choose to install the World Wide Web Service feature of IIS
    4. Re-run .NET Framework 3.5 beta 2 setup
    5. (optionally) Go back to the Add/Remove Windows Features control panel and change the install state of IIS features back to what they were before step 3 above after .NET Framework 3.5 beta 2 setup completes

    Issue 3: Insufficient privileges to modify application host config file

    In some cases, the .NET Framework 3.5 beta 2 will fail to install if the user account that setup is running under does not have permission to modify IIS configuration files located at %windir%\system32\inetsrv\config.

    This issue can cause one of the following entries to be written to the verbose MSI log file for the .NET Framework 3.5 component (named %temp%\dd_net_framework35_MSI*.txt):

    DDSet_Error: CWebServerHandlers::Install m_spAppHostAdminManager->CommitChanges failed. Error code: 0x80070002

    DDSet_Error: CWebServerHandlers::Install m_spAppHostAdminManager->CommitChanges failed. Error code: 0x80070005

    We know of an issue with the NoImpersonate attribute not being set for this custom action that could cause this type of error, but have had trouble reproducing this issue in our test labs.  In most cases, you can use the following steps to work around this issue:

    1. Click on the Start menu, choose All Programs, then Accessories, then right-click on the Command Prompt item and choose Run as administrator
    2. Run .NET Framework 3.5 beta 2 setup from the administrator cmd prompt that appears

    If the above work around does not help, you can use the following steps as an alternative:

    1. Click on the Start menu, choose Run, type appwiz.cpl and click OK
    2. In the Add/Remove Programs control panel (or the Programs and Features control panel in Windows Vista), choose the item on the left side that is named Add/Remove Windows Features (or Turn Windows Features on or off in Windows Vista)
    3. Locate the Internet Information Services (IIS) feature and choose to fully uninstall IIS
    4. Re-run .NET Framework 3.5 beta 2 setup
    5. (optionally) Go back to the Add/Remove Windows Features control panel and re-install IIS after .NET Framework 3.5 beta 2 setup completes
  • Aaron Stebner's WebLog

    Windows Vista Media Center SDK version 5.2 now available for download

    • 3 Comments

    A refreshed version of the Windows Vista Media Center SDK (version 5.2) has been released for download.  The download location is the same as the 5.0 and 5.1 versions - http://www.microsoft.com/downloads/details.aspx?FamilyID=A43EA0B7-B85F-4612-AA08-3BF128C5873E&displaylang=en.  If you have the 5.0 or 5.1 version of the Windows Vista Media Center SDK installed, you can run the MSI for version 5.2 and it will automatically upgrade the older versions for you.

    The features of this SDK refresh are described in more detail in this post on the Media Center Sandbox blog and also in the Getting Started page that appears at the end of SDK installation.  The key changes are the following:

    • The contents of the Media Center Application step-by-step guide that was previously released as a standalone document with source code has been incorporated into the SDK documentation
    • The C# project template included with the SDK has been greatly enhanced - it now creates a more interesting application based on the source code of the step-by-step guide.  This will hopefully make it easier to get up and running with MCML and C# code behind for Media Center applications.
    • The C# project template also now includes WiX 3.0-based setup source files to make it easier to get started creating an MSI-based installer for your Media Center application.  These files appear in a setup sub-folder when creating a new C# Media Center application project, and they include the necessary information to install an application assembly to the GAC and register the application using RegisterMceApp.  They also include some prerequisite checking so the resultant MSI will verify that the OS the user runs the installation on contains Windows Vista Media Center and that the user has administrative privileges to install the application for all users.  Essentially, these setup files look similar to the Q and Z sample application setup files (but they install a different set of application files).

      The MSI creation steps will not be a part of the build process until you hook up the post-build event to run the WiX compiler and linker (candle and light) - the steps for hooking this up are located in the readme file that opens when you create a new project in Visual Studio.
    • The MCML File item template that is included in the Media Center SDK for use in Visual Studio 2005 has been enhanced to include commonly used MCML elements (Properties, Locals, Rules and Content)

    If you're a Windows Vista Media Center developer or thinking about getting started, I encourage you to download this new version of the SDK and check it out.

  • Aaron Stebner's WebLog

    Possible issue using ASP.NET controls in VS 2008 beta 2

    • 9 Comments

    Description of this issue

    Since Visual Studio 2008 beta 2 and the .NET Framework 3.5 beta 2 were released, we have heard of a few issues related to using ASP.NET controls in the VS IDE after installing beta 2.  The issues we have seen so far include the following:

    • ASP.NET controls do not show up in the Visual Studio 2008 beta 2 toolbox
    • ASP.NET tag IntelliSense and schema validation is broken in HTML source view in the VS IDE

    In the cases we've seen so far, the systems are running Windows Vista, and the file version of %windir%\Microsoft.NET\Framework\v2.0.50727\system.web.dll is less than the official beta 2 version of 2.0.50727.1378.

    How to workaround this issue

    If you run into an issue like this, you can uninstall .NET Framework 2.0 hotfixes and then re-install the .NET Framework 3.5 as a workaround.

    There are some detailed instructions that explain how to do this at this location, including a list of the exact hotfixes that need to be uninstalled to resolve this issue.

    You do not need to re-install the previous hotfixes after working around this issue.  The .NET Framework 2.0 SP1 and 3.0 SP1 hotfix packages that are installed as prerequisites for the .NET Framework 3.5 beta 2 already include all of the fixes that were previously released as separate Windows Vista hotfixes for the .NET Framework 2.0/3.0.

    Root cause of this issue

    We have found a problem with how some Windows Vista-specific hotfixes for the .NET Framework 2.0 have been packaged in the past that can cause an incorrect version of files like system.web.dll to appear on the system.  This means that if you have some specific .NET Framework 2.0 hotfixes installed on your Windows Vista system, you might encounter this type of file version problem and therefore also run into some issues when trying to use VS 2008 beta 2.  Windows Vista is built from components, and these components have their own version information that is used to determine which files will be present on the OS.  The versions of the files contained in each of the components does not have to match the component version, and that can lead to newer versions of components having older versions of files in some cases such as this.

    <update date="8/6/2007"> Added more details about the issues seen within the VS IDE to improve discoverability of this issue and possible workarounds </update>

     

  • Aaron Stebner's WebLog

    Beta version of TV Toolbox (formerly Media Center Cutter) available for download

    • 0 Comments

    A news item was recently posted on the MCEDev.com web site that I wanted to draw your attention to if you haven't seen it already.  The post, located at http://www.mcedev.com/News.aspx?id=b88920c9-57a4-44fc-8feb-78c18b596fa8, announces a publicly downloadable beta of a Windows Vista Media Center application named TV Toolbox.  This application is a new version of the Media Center Cutter application that has been available for a while for Windows XP Media Center Edition and that was previously announced with feature details and screenshots on Niall's Big Screen Blog back in March.

    This application allows you to do things like the following from within Windows Media Center:

    • Edit recorded TV shows by choosing segments to include
    • Convert recordings to different file formats (for example, to watch recorded shows on a Zune device)
    • Queue conversion jobs for background processing
    • Create rules to automatically convert new recordings based on specific conditions

    I encourage you to check out the following locations for more information about TV Toolbox:

  • Aaron Stebner's WebLog

    Make sure to uninstall VS Orcas beta 1 before installing beta 2

    • 0 Comments

    Before installing Visual Studio 2008 beta 2 or the .NET Framework 3.5 beta 2, it is necessary to remove previous beta versions of VS 2008.  In most cases, when running beta 2 setup on a system that has an earlier beta still installed, setup will block installation and display a dialog with a list of previous beta products that need to be uninstalled.

    However, we discovered that there are a few previous beta products that are not being detected correctly.  This means that if they are installed on the system, they will not be listed in the blocking dialog when running beta 2 setup.

    If you have any of the following VS 2008 (formerly code named Orcas) editions installed on your system, make sure to remove them from Add/Remove Programs before installing VS 2008 beta 2:

    • Visual Basic Express Edition Codename Orcas - beta 1
    • Visual C# Express Edition Codename Orcas - beta 1
    • Visual C++ Express Edition Codename Orcas - beta 1
    • Visual Web Developer Express Edition Codename Orcas - beta 1
    • Visual Studio Professional Edition Codename Orcas - beta 1

    Note that for all of the beta versions of VS 2008, including the products listed above, setup will automatically uninstall beta versions of prerequisites and optional components that were chained in during the beta uninstall process.  This chaining was added in the VS 2008 products in order to help reduce problems we saw frequently during the VS 2005 beta program that were caused by uninstalling beta prerequisites out of order.

  • Aaron Stebner's WebLog

    What to do if VS 2008 or .NET Framework 3.5 beta 2 asks for Windows XP SP2 on Windows Vista

    • 9 Comments

    I previously posted a description of a bug in VS 2008 beta 1 and .NET Framework 3.5 beta 1 setup that can cause setup to prompt you to install Windows XP SP2 when running setup on Windows Vista.  That post includes a couple of workarounds that can be used to remove the setting that Windows Vista stores that controls whether or not to run a program in Windows XP compatibility mode.

    Why does this problem still happen in beta 2?

    The underlying problem that caused this type of error to appear was that the beta 1 setup packages did not include embedded UAC manifests, which caused Windows Vista to treat them as legacy applications.  The beta 2 setup packages now include the proper UAC manifests, so in most cases, this Windows XP SP2 prompt should no longer appear.

    However, in cases where beta 1 setup previously failed on the same system, the registry setting could still exist and that may cause beta 2 setup to continue to run in Windows XP compatibility mode.

    Workaround option 1 - manually clear application compatibility settings

    If you see this type of error when running VS 2008 or .NET Framework 3.5 beta 2 setup, the first step I suggest is to try the workarounds listed at the bottom of this previous blog post (either changing the compatibility settings by right-clicking on the setup EXE and choosing the Compatibility tab, or manually removing entries from the registry).

    Workaround option 2 - use the Program Compatibility Assistant

    In a few cases I have seen, those workarounds did not cause the Windows XP SP2 error dialog to stop appearing on Windows Vista.  If none of those other workarounds allow you to get past this issue, it may help to run the setup directly from within the Program Compatibility Assistant by using steps like the following:

    1. Click on the Start menu and choose Control Panel
    2. Select Control Panel Home view if you are currently using Classic View
    3. Click on the item named Programs
    4. Under Programs and Features, select Use an older program with this version of Windows – this will launch the Program Compatibility Wizard
    5. In the wizard, click Next on the first screen
    6. Choose I want to locate the program manually on the 2nd screen
    7. Browse to the path of the VS 2008 or .NET Framework 3.5 setup program that you want to install and click Next
    8. Select Do not apply a compatibility mode and click Next
    9. Do not select any display settings and click Next
    10. Do not check the Run this program as an administrator check box and click Next
    11. Click Next on the confirmation page to test these settings
    12. If setup launches and displays the welcome page instead of the Windows XP SP2 error dialog, choose Yes, set this program to always use these compatibility settings and click Next
    13. Optionally send the information from the Program Compatibility Wizard to Microsoft
  • Aaron Stebner's WebLog

    Case study - using MCML to create a Media Center application

    • 0 Comments

    Charlie recently posted a link on the Media Center Sandbox blog to an interesting case study on the Microsoft Case Studies web site that I wanted to also link to here.  There is a new case study posted at http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000000490 that describes how Showtime and Method created the Showtime Interactive application for Windows Vista Media Center using the following technologies/tools:

    If you have a Windows Vista Home Premium or Ultimate system, you can check out the Showtime Interactive application by launching Windows Media Center, going to the Online Media strip on the start menu, selecting Explore and then clicking on the Showtime Interactive link.  This application is a locally installed program, so you will have to download and run the MSI-based installer prior to using the application.

    If you're considering creating applications for Windows Vista Media Center, I encourage you to check out this case study for more information about how a real-world project project was designed and implemented.

  • Aaron Stebner's WebLog

    Tool to automatically collect and cab VS 2008 and .NET Framework 3.5 setup log files

    • 31 Comments

    I wrote a post yesterday with a list of the names and locations of all of the log files produced during Visual Studio 2008 and .NET Framework 3.5 setup.  As you can see in that post, the list of possible log files is very long, and that makes it annoying when attempting to gather the logs and send them back to Microsoft so that we can help troubleshoot installation issues.

    Fortunately, Sandhya, a colleague of mine, has written a tool that will automatically gather all of the VS 2008 and .NET Framework 3.5 setup log files it can find from your system and create a cab file containing them so you have a single compressed package that can be sent to Microsoft for troubleshooting purposes.

    How to use the Collect tool

    The tool can be downloaded from http://go.microsoft.com/?LinkId=8967043.  It is a Win32 console application, so you can extract it from the zip file and double-click on it to run it.  It will create a file named %temp%\vslogs.cab on your system after it has gathered all of the log files.

    Note - after the tool finishes running, you can get to your %temp% folder to find the file vslogs.cab by clicking on the Start menu, choosing Run, typing %temp% and clicking OK.

    What to do if the Collect tool does not work correctly on your system

    If the tool encounters any problems, you can do the following to re-run it from a cmd prompt and see more detailed error information:

    1. Click on the Start menu, choose Run, type cmd and click OK
    2. Run collect.exe from the cmd prompt that appears
    3. When doing this, you will see information displayed in the cmd prompt with more details about which actions it is performing, what log files it found, etc

    <update date="5/23/2008"> Updated link to log collection tool to point to the new location </update>

     

Page 1 of 1 (24 items)