Aaron Stebner's WebLog

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

September, 2007

  • Aaron Stebner's WebLog

    How to workaround .NET Framework 2.0 OS component uninstall failure on Windows Server 2003 R2

    • 5 Comments

    As I previously described in this blog post, the MSI-based .NET Framework 2.0 is included as an optional OS component on Windows Server 2003 R2.

    The .NET Framework 2.0 service pack 1 is designed to be a slipstreamed package behind the scenes.  If it is installed on a system that has the original release of the .NET Framework 2.0 installed, the .NET Framework 2.0 SP1 will perform a major upgrade of the original release of the .NET Framework 2.0, which means that it will uninstall the original 2.0 MSI and then installs the new 2.0 SP1 package.

    Because of the architecture of the .NET Framework 2.0 SP1 setup, if it is installed on a Windows Server 2003 R2 system that has the .NET Framework 2.0 optional OS component installed, it will essentially replace the optional OS component.  If you try to go back to the Add/Remove Windows Components control panel and uninstall the .NET Framework 2.0 optional OS component after installing the .NET Framework 2.0 SP1 (or a product that includes the .NET Framework 2.0 SP1 like the .NET Framework 3.5), that uninstall will fail.  This happens because the command line that Windows Server 2003 R2 uses to uninstall the .NET Framework 2.0 is specific to the initial release of the .NET Framework 2.0, and that command line no longer works for the .NET Framework 2.0 SP1 setup package.

    If you encounter this uninstall error for the .NET Framework 2.0 optional OS component on Windows Server 2003 R2, you can uninstall the .NET Framework 2.0 SP1 using the separate .NET Framework 2.0 SP1 entry in Add/Remove Programs instead of using the Add/Remove Windows Components control panel.

    Keep in mind that you will not be allowed to uninstall the .NET Framework 2.0 SP1 if you have the .NET Framework 3.0 SP1 or the .NET Framework 3.5 installed.  In that case, you need to first uninstall the .NET Framework 3.5, then uninstall the .NET Framework 3.0 SP1.  After that, you will be allowed to uninstall the .NET Framework 2.0 SP1 using its entry in Add/Remove Programs.

  • Aaron Stebner's WebLog

    Link to more detailed information about the Windows Media Center Internet TV beta

    • 2 Comments

    Earlier today, I posted some information about the Windows Media Center Internet TV beta that was released to Windows Vista Media Center users in the United States last night.  Today, I found a blog post at http://windowsvistablog.com/blogs/windowsexperience/archive/2007/09/27/streaming-internet-content-with-internet-tv-beta-to-windows-media-center.aspx that describes the functionality available in this beta in more detail.

    I encourage you to check out the feature descriptions listed there.  Better yet, if you are in the United States and have Windows Vista Home Premium or Ultimate, launch Media Center and check it out for yourself from the TV + Movies strip on the start menu.

  • Aaron Stebner's WebLog

    Windows Media Center Internet TV beta for Windows Vista Media Center

    • 10 Comments

    A beta of a new feature for Windows Vista Media Center was announced yesterday at the DigitalLife conference, and I wanted to post a link to it here for folks who haven't yet heard about it.  The feature, known as the Windows Media Center Internet TV Beta, will be available within Windows Vista Media Center on systems in the United States starting this morning, September 28, 2007.

    Windows Media Center Internet TV will allow you to stream free ad-supported video content from MSN video on Media Center PCs or on Media Center Extender devices.  Types of content that will be available include the following:

    • Full episodes of some TV shows
    • Full-length music concerts
    • Movie trailers
    • News and sports clips

    The music concerts and movie trailers will be presented in a hi-resolution format, and the team is working on adding more hi-resolution content in the future.  You can read more details about this beta and some of the content that will be available for streaming in this press release.

    The Windows Media Center Internet TV beta will be automatically downloaded if you opted in to receive CD album art, media information for DVDs and movies and Internet Services during the initial Media Center setup wizard that appeared the first time you launched Media Center on your Windows Vista Home Premium or Ultimate system.  It will appear as a new tile named "internet tv" in the TV + Movies strip on the Windows Vista Media Center start menu after it has been downloaded to your system.

    If you did not previously opt in for automatic downloads, you can opt in by doing that sense:

    • Launch Windows Vista Media Center
    • Go to the Tasks menu, choose Settings, then General, then Automatic Download Options
    • Check the box labeled Retrieve CD album art, media information for DVDs and movies, and Internet Services from the Internet
    • Click Save to save this change
    • If you would like to immediately download available updates, click the Download Now button at the bottom of the Automatic Download Options page - you may be prompted to configure internet settings if you did not do so the first time you launched Media Center
    • You will need to restart Media Center after clicking Download Now in order for the Windows Media Center Internet TV beta tile to appear on the start menu

    There will also be a public beta site for Windows Media Center Internet TV on the Microsoft Connect site.  You will be able to submit bug reports and other feedback about this beta on this site once it is available.

  • Aaron Stebner's WebLog

    TV Toolbox beta 3 now available for download

    • 2 Comments

    A new beta version of TV Toolbox for Windows Vista Media Center has been released recently on the MCEDev.com site.  This beta includes bug fixes and functional changes that address issues reported by customers who used the first 2 beta versions.  Here are some links to additional information about TV Toolbox:

    If you are interested in editing and converting your recorded TV shows to other formats in Windows Vista Media Center, I encourage you to check out TV Toolbox.

  • Aaron Stebner's WebLog

    Charlie Owen discusses Media Center development on Scott Hanselman's blog

    • 2 Comments

    Recently, Charlie Owen sat down with Scott Hanselman to discuss Windows Vista Media Center development for Scott's podcast.  This podcast session provides a really nice introduction to the Windows Vista Media Center platform, tools and SDK.  You can check out a timeline of the podcast topics and some links to supplemental information in this link on the Media Center Sandbox blog:

    http://blog.mediacentersandbox.com/Hanselminutes82DevelopmentForMediaCenter.aspx

    You can also access the podcast directly from this location on Scott's blog:

    http://www.hanselman.com/blog/HanselminutesPodcast8210FootDevelopmentForMediaCenter.aspx

    If you are interested in getting started with developing applications for Windows Vista Media Center, I encourage you to check out this podcast and the accompanying links.

  • Aaron Stebner's WebLog

    Mailbag: Can the .NET Framework cleanup tool be run in silent mode?

    • 11 Comments

    Question:

    I have read about the .NET Framework cleanup tool, and I would like to be able to automate running it on several systems.  Does the cleanup tool support any command line switches to run it in silent mode? 

    Answer:

    Yes, it is possible to run the cleanup tool in silent mode and unattended mode.

    Running in silent mode will cause the tool to run without showing any UI.  To run in silent mode, you need to download the cleanup tool, extract the file cleanup_tool.exe from the zip file, and then run it using syntax like the following:

    cleanup_tool.exe /q:a /c:"cleanup.exe /p <name of product to remove>"

    The value that you pass with the /p switch to replace <name of product to remove> in this example must exactly match one of the products listed in the file cleanup.ini that is included in the self-extracting package for the cleanup tool.

    Running in unattended mode will cause the tool to display a progress bar during removal, but will not show any other UI and will not require the user to interact with the UI at all.  After removal completes, the UI will disappear and the process will exit.  To run in unattended mode, you need to use the same syntax as silent mode and add the /u command line switch in addition to the /p switch.  For example:

    cleanup_tool.exe /q:a /c:"cleanup.exe /p <name of product to remove> /u"

    Currently, the cleanup tool includes the following product names that can be passed in using the /p switch:

    • .NET Framework - All Versions
    • .NET Framework - All Versions (Tablet PC and Media Center)
    • .NET Framework - All Versions (Windows Server 2003)
    • .NET Framework - All Versions (Windows Vista and Windows Server 2008)
    • .NET Framework 1.0
    • .NET Framework 1.1
    • .NET Framework 2.0
    • .NET Framework 3.0
    • .NET Framework 3.5

    For example, if you would like to run the cleanup tool in silent mode and remove the .NET Framework 1.1, you would use a command line like the following:

    Cleanup_tool.exe /q:a /c:"cleanup.exe /p .NET Framework 1.1"

    One important note – the cleanup tool will not allow you to remove a version of the .NET Framework that is installed as part of the OS it is running on.  That means that even if you try this example command line on Windows Server 2003, the tool will exit with a failure return code and not allow you to remove the .NET Framework 1.1 because it is a part of that OS.

    Similarly, you cannot use the cleanup tool to remove the .NET Framework 1.0 from Windows XP Media Center Edition or Windows XP Tablet PC Edition or remove the .NET Framework 2.0 or 3.0 from Windows Vista.  In addition, if you run the cleanup tool on an OS that has any edition of the .NET Framework installed as a part of the OS, it will prevent you from using the .NET Framework - All Versions option because there is at least one version that it cannot remove.

    If you are planning to run the cleanup tool in silent mode, you need to make sure to detect what OS it is running on and not pass in a version of the .NET Framework with the /p switch that is a part of the OS or make sure that you know how to handle the failure return code that you will get back from the cleanup tool in that type of scenario.

    The cleanup tool returns the following exit codes:

    • 0 - cleanup completed successfully for the specified product
    • 3010 - cleanup completed successfully for the specified product and a reboot is required to complete the cleanup process
    • 1 - cleanup tool requires administrative privileges on the machine
    • 2 - the required file cleanup.ini was not found in the same path as cleanup.exe
    • 3 - a product name was passed in that cannot be removed because it is a part of the OS on the system that the cleanup tool is running on
    • 4 - a product name was passed in that does not exist in cleanup.ini
    • 100 - cleanup was able to start but failed during the cleanup process
    • 1602 - cleanup was cancelled

    The cleanup tool creates the following log files:

    • %temp%\cleanup_main.log - a log of all activity during each run of the cleanup tool; this is a superset of the logs listed below as well as some additional information
    • %temp%\cleanup_actions.log - a log of actions taken during removal of each product; it will list files that it finds and removes, product codes it tries to remove, registry entries it tries to remove, etc.
    • %temp%\cleanup_errors.log - a log of errors and warnings encountered druing each run of the cleanup tool

    <update date="12/4/2007"> Added new product names that are supported by the latest version of the cleanup tool </update>

    <update date="6/9/2008"> Added information about unattended mode and the log files produced by the cleanup tool </update>

     

  • Aaron Stebner's WebLog

    Possible problem launching Visual Studio 2008 setup within a Parallels 3.0 virtual image on a Mac

    • 0 Comments

    I heard of an interesting issue from a customer today via the email contact form on my blog, and I wanted to post it here in case anyone else runs into a similar issue.  They saw a problem when launching Visual Studio 2008 beta 2 setup on a virtual Windows image that is running in Parallels 3.0 on a Mac.  In this configuration, VS 2008 setup failed during the initial load with an error like the following:

    "A problem has been encountered while loading the setup components. Canceling setup"

    In order to workaround the issue, the customer disabled DirectX support in the virtual machine settings in Parallels 3.0 and then re-opened the Windows image and re-ran VS 2008 setup.

    If you run into a similar issue running VS 2008 setup in a Windows image in Parallels 3.0, I encourage you to try out this workaround and hopefully it will be useful for you as well.

    Also, please note that since the same setup executable is used for the .NET Framework 3.0, the .NET Framework 3.5 and Visual Studio 2002, 2003, 2005 and 2008, this issue could affect all of these products and the workaround may be equally useful for all of these types of installations.

  • Aaron Stebner's WebLog

    Link to information about when to use NGen for your managed application

    • 2 Comments

    I noticed over the weekend that the CLR code generation team has started a blog to communicate about issues related to just-in-time (JIT) compilation and native image generation (NGen) for binaries that run on the .NET Framework.

    The first technical post on the blog, located at http://blogs.msdn.com/clrcodegeneration/archive/2007/09/15/to-ngen-or-not-to-ngen.aspx, provides a useful overview of the following topics:

    • Scenarios where it is helpful to run NGen for an application
    • Scenarios where it is not helpful (and can often do more harm than good) to run NGen for an application
    • Issues to keep in mind when running NGen for an application
    • Links to more detailed technical documentation about how NGen works behind the scenes

    I encourage you to take a look at this blog post if you are considering using NGen for your application, and I also encourage you to keep an eye on the CLR code generation team's blog for more technical discussions of JIT and NGen in the future.

  • Aaron Stebner's WebLog

    Uninstalling the 64-bit .NET Framework 2.0 can break the .NET Framework 1.1

    • 9 Comments

    Back when the .NET Framework 1.1 originally shipped, only a 32-bit version was released.  In addition, the MSI contains a launch condition that specifically blocks the .NET Framework 1.1 from being allowed to install on 64-bit operating systems.

    Since then, 64-bit systems have become much more mainstream, and some folks on the Windows team worked with some folks on the .NET Framework team to add a shim to newer 64-bit operating systems that allows users to bypass that launch condition and install the .NET Framework 1.1.

    However, since the .NET Framework 1.1 was not originally designed to install on 64-bit operating systems and co-exist with newer versions of the .NET Framework (such as 2.0) that are designed for 64-bit operating systems, some .NET Framework side-by-side uninstall scenarios ended up not working exactly correctly.

    In particular, the following scenario has proven problematic on a 64-bit operating system:

    1. Install the .NET Framework 1.1
    2. Install the .NET Framework 2.0
    3. Uninstall the .NET Framework 2.0

    When uninstalling the .NET Framework 2.0 in this type of scenario, some registry entries will be removed out from under the .NET Framework 1.1 and cause it to not function correctly.  You must repair the .NET Framework 1.1 after uninstalling the .NET Framework 2.0 in order to restore the necessary registry values.

    There are instructions for repairing the .NET Framework 1.1 in the file %windir%\Microsoft.NET\Framework\v1.1.4322\1033\repairRedist.htm on a system that has the .NET Framework 1.1 installed.  To summarize those instructions, you will need to do the following:

    1. Re-download the .NET Framework 1.1 setup package (dotnetfx.exe)
    2. Click on the Start menu, choose Run, type cmd and click OK
    3. Run this command:  <full path to dotnetfx.exe> /t:%temp% /c:"msiexec.exe /fvecms %temp%\netfx.msi"
  • Aaron Stebner's WebLog

    New simplified silent install switches are available for Visual Studio 2008 setup

    • 24 Comments

    Visual Studio 2002, 2003 and 2005 setups include a silent deployment mode that requires multiple steps (creating an INI file on the matching OS version and language, then running VS setup and passing it the INI file to perform the installation).  Those of you who have automated the installation of these versions of Visual Studio can attest to the difficulties that this multi-step, OS version-specific process has introduced.

    In order to make the most commonly needed automated installation scenarios easier to achieve, the following command line switches have been added to Visual Studio 2008 setup:

    • setup.exe /q - this will perform a silent default installation of VS 2008. This is the equivalent of running VS 2008 setup using setup UI and selecting the Default install type radio button.
    • setup.exe /q /full - this will perform a silent full installation of VS 2008. This is the equivalent of running VS 2008 setup using setup UI and selecting the Full install type radio button.

    Note - if you need to pass in a product key when running setup using these new silent switches, you will need to use the syntax described in this blog post.

    There are some important notes to keep in mind for these new silent install options:

    • When using these command line switches, you must make sure that you pass them to the setup.exe in the Setup subdirectory, and not to the setup.exe at the root of the VS 2008 installation disc.  Only the setup.exe in the Setup subdirectory understands these command line parameters.
    • If you run setup.exe /q on a system that already has that edition of VS 2008 installed, it will invoke a silent repair instead of a silent installation.
    • If you need to perform a silent non-default installation of VS 2008 (as opposed to a default or a full installation), then your best bet will be to use the INI creation mode that has existed in previous versions of VS 2008.
    • It is also possible to gather a list of feature names that you want to install by running VS 2008 setup once in UI mode, selecting the features you want to install in the setup UI feature tree, then looking at the verbose MSI log file that is created during installation to figure out the exact list of feature names to pass in during silent installation.  However, that option is more complicated and error-prone than INI creation mode, so I don't recommend using this method unless absolutely necessary.
    • If you want to be able to control reboots, you can also pass in the /norestart switch.  This will prevent setup from forcing a reboot during installation if one of the components it is installing requests one.  It does not, however, postpone the reboot until the end of setup.  In some cases, the setup team determined that it is not safe to defer reboot requests for a component, and have set a flag in a setup data file to indicate that (specifically, the flag RebootLaterOk=0 in baseline.dat).  If one of these components returns 3010, and you pass in the /norestart switch, then setup will exit but will not reboot.  It is up to the process running the silent install to reboot the system and re-start setup after the reboot in order to allow setup to continue.
    • To avoid reboots, you can configure your systems with any prerequisite packages that tend to cause reboot requests prior to deploying VS 2008.  Doing this will cause VS 2008 setup to skip installing those prerequisites because setup will detect that they are already present on the system.

    <update date="9/20/2007"> Added more details about how the /norestart switch works </update>

    <update date="12/17/2008"> Added a link to a separate blog post I wrote about how to pass a product key into setup when using the /q switch. </update>

     

  • Aaron Stebner's WebLog

    Download available for a supplemental set of Windows Vista Media Center project templates

    • 14 Comments

    I have posted an MSI that can be used to install an additional set of Windows Vista Media Center project templates.  You can download the MSI at http://astebner.sts.winisp.net/Tools/mce_project_templates.zip.  These project templates are designed to supplement (but not replace) the project templates included in the Windows Vista Media Center SDK v5.2.

    There are several specific scenarios that I was aiming to address by creating these supplemental project templates:

    1. Taking a first step towards integrating Media Center project templates into Visual Studio 2008 now that VS 2008 beta 2 has been released.  This was requested at http://discuss.mediacentersandbox.com/forums/thread/4330.aspx and I have heard from a few other folks privately asking about this.
    2. Adding the WiX setup files to the VB project template since they were only added to the C# project template in the Windows Vista Media Center SDK v5.2.
    3. Fixing the major upgrade issue that I described in more detail in the blog post at http://blogs.msdn.com/astebner/archive/2007/09/06/4798334.aspx.
    4. Offering a simpler project template that is closer to an empty project but still has some configuration settings in place that are needed for Media Center Markup Language (MCML) applications.  This is to address questions about the new project template in the Windows Vista Media Center SDK v5.2 like the one located at http://discuss.mediacentersandbox.com/forums/thread/4269.aspx.

    When you download and install these project templates, they will appear in any of the following products that you have installed on your system:

    • Visual Studio 2005 standard and higher
    • Visual Basic 2005 Express Edition
    • Visual C# 2005 Express Edition
    • Visual Studio 2008 standard and higher
    • Visual Basic 2008 Express Edition
    • Visual C# 2008 Express Edition

    To distinguish these project templates from the ones that ship in the Media Center SDK, they are named "Windows Media Center application with setup" (whereas the project templates installed by the SDK are named "Windows Media Center Application") in the Visual Studio new project dialog.  In addition, they appear after the project templates installed by the SDK in the sorted list of available project templates.

    I created the setup for this MSI in WiX v3.0, and in an upcoming blog post, I plan to enhance these instructions that I posted a while back in order to provide an easy-to-follow example of how to create an installer for Visual Studio project templates.  Hopefully this will encourage Media Center developers to create and share their own project templates for specific types of development scenarios (such as a full-fledged background application project template so that the steps described in this blog post can be simplified).

  • Aaron Stebner's WebLog

    Link to a preview of version 2.0 of Big Screen Headlines

    • 1 Comments

    I know I'm a little late posting about this, but better late than never.  Niall Ginsbourg has posted some information about an updated version of Big Screen Headlines that he has been working on recently.  This application is an RSS feed browser for Windows Vista Media Center.  You can check out Niall's post at http://mobilewares.spaces.live.com/Blog/cns!78533A1A2E078194!597.entry.  It contains screenshots and descriptions of several key new features in Big Screen Headlines v2.  Here is a summary of some of the changes:

    • Revamped UI system, including an Xbox 360 dashboard-style 4-way main menu to allow quicker access to content
    • Enhanced article parsing and display
    • Enhanced parsing of RSS feeds, including new source extensions and display of new elements (thumbnails, comments, ratings, etc)
    • Enhanced viewing, filtering, sorting and grouping when viewing feeds and lists
    • Support for dynamic OPML 2.0 include statements
    • Direct access to the latest items from subscribed feed sources in the main menu
    • Easy to export feeds to an OPML file so the application can be used by extenders

    I encourage you to check out the blog post, and also try out the beta when it is available (it sounds like the beta is imminent based on Niall's comments in the post).

  • Aaron Stebner's WebLog

    Subtle problem with major upgrades in WiX files in the Media Center SDK

    • 5 Comments

    One of the features included in the WiX v3.0 source files included in the C# project template in the latest version of the Windows Vista Media Center SDK is a group of settings to make it easy to implement a Windows Installer major upgrade when building new versions of the MSI-based installer.  A major upgrade allows users to run the install for the new version of the MSI and have it automatically uninstall any older version(s) of the MSI that are installed on the system.  Doing this will ensure that users will only have one version on their system at a given time, and that the installed version is the latest version.

    Recently, Charlie was working on a Windows Vista Media Center application using the new Media Center SDK project template, and he built an MSI-based installer using the WiX v3.0 source files that are included in the project template.  He ran into an issue when trying to deploy version 2 of his MSI on a system that already had version 1 installed.  In this scenario, he found that the application was left in an unregistered state with Media Center (meaning that it did not appear in the Media Center start menu or the Program Library).  The application files were all installed in the expected locations though.

    After looking at MSI log files and the WiX source code for a little bit, I found a subtle logic problem that caused this registration problem.  The WiX source files in the Media Center project template schedule the RemoveExistingProducts action after InstallFinalize in order to work around the bug in Windows Installer described in this knowledge base article.  However, the custom action to run RegisterMceApp.exe in uninstall mode is only conditioned on the REMOVE Windows Installer property, meaning it will run anytime the MSI is run in uninstall mode.  This scheduling sequence causes the uninstall of the previous version of the MSI to happen after the install of the new version of the MSI has been committed.  The combination of this scheduling sequence and the uninstall custom action condition causes the RegisterMceApp.exe custom action to run in uninstall mode after it has been run in install mode, and the application is left in an unregistered state after the major upgrade completes.

    There are a few possible ways to work around this issue, each with its own pros and cons.  I will start with a recommendation in order to make it easier to find (since this blog post ended up being fairly long), but I encourage you to read the entire contents of the post as well in order to learn more details about what is happening behind the scenes in this scenario so you can make an informed decision for your application's deployment logic.

    Recommendation:

    In general, I recommend adding the condition described in Option 1 below to the RegisterMceApp.exe uninstall custom actions in order to resolve this issue.  The condition is specifically based on the state of the component that owns the XML registration file used by RegisterMceApp, and because of that, it is most closely tied to the custom action from a logical perspective.  It will help prevent this custom action from being run in all side-by-side install scenarios, and not only during Windows Installer major upgrades (unlike the condition described in Option 2).

    In addition to adding this condition, I encourage you to review the alternatives for scheduling the RemoveExistingProducts action that are described in Option 3 below.  When creating the WiX files in the C# project template in the Media Center SDK, I attempted to choose a scheduling option that I thought would meet the widest range of Media Center application deployment scenarios.  However, there are definitely trade-offs that should be weighed here, and you may want to opt for a different solution depending on your application's scenarios.

    Option 1: Add a condition to the RegisterMceApp uninstall custom action so it will only run when the registration XML file is being removed.

    In this option, you can add the ($Registration.xml = 2) condition to the custom actions named CA_RegisterMceApp_AddIn_Unregister_Uninstall_Cmd and CA_RegisterMceApp_AddIn_Unregister_Uninstall.  To do this, you can change the conditions from the value <![CDATA[REMOVE]]> that is initially set for these custom actions to <![CDATA[REMOVE AND ($Registration.xml = 2)]]> in the setup.wxs file that is created when instantiating a new instance of the C# Media Center project template in version 5.2 of the Windows Vista Media Center SDK.

    The syntax of the ($Registration.xml = 2) condition will evaluate to true if the action state of the Windows Installer component named App.xml evaluates to INSTALLSTATE_ABSENT (meaning that the component is in the process of being uninstalled).  You can see this MSDN topic for more details about Windows Installer conditional syntax if needed.

    Option 2: Add a condition to the RegisterMceApp uninstall custom action so it will not run during the major upgrade.

    In this option, you can add the UPGRADINGPRODUCTCODE condition to the custom actions named CA_RegisterMceApp_AddIn_Unregister_Uninstall_Cmd and CA_RegisterMceApp_AddIn_Unregister_Uninstall.  To do this, you can change the conditions from the value <![CDATA[REMOVE]]> that is initially set for these custom actions to <![CDATA[REMOVE AND NOT UPGRADINGPRODUCTCODE]]> in the setup.wxs file that is created when instantiating a new instance of the C# Media Center project template in version 5.2 of the Windows Vista Media Center SDK.

    As described in this blog post, that property will only be set if an uninstall occurs as part of a Windows Installer major upgrade.

    Option 3: Change the sequencing of RemoveExistingProducts so that it happens before the custom action that runs RegisterMceApp in install mode for the new version of the MSI.

    In this option, you can change the relative sequence order of the RemoveExistingProducts action by changing the After value in the statement <RemoveExistingProducts After="InstallFinalize" /> to be a different action, or by removing the After value and using the Before value with a different action instead.

    As described in the MSDN RemoveExistingProducts action topic, there are a few commonly used scheduling options for the RemoveExistingProducts action:

    1. Between the InstallValidate and InstallInitialize actions.  In this case, Windows Installer will completely remove the old version of the application before installing the new version.  This option is inefficient because all files that are the same between versions of the application will have to be deleted and re-copied.
    2. After InstallInitialize, but before any actions that generate entries in the Windows Installer execution script.
    3. Between the InstallExecute (or InstallExecuteAgain) and InstallFinalize actions.  Typically, these actions are scheduled in the following order: InstallExecute, RemoveExistingProducts then InstallFinalize.  When using this sequence, the new version of the application is installed, then old files that are a part of the old version of the application are removed.  If the uninstall fails for some reason, Windows Installer will roll back both the uninstall of the old version and the install of the new version.
    4. After the InstallFinalize action.  This option is the most efficient placement for the action from an installation performance perspective.  In this option, Windows Installer updates files before removing the old applications, but only the files being updated in the new version of the application get installed during the installation. If the uninstall of the old version fails, then Windows Installer rolls back the uninstallation of the old application, but leaves the new version installed.

    The WiX files in version 5.2 of the Windows Vista Media Center SDK use the 4th scheduling option, which I chose initially when creating these files because it allows new versions of the application to use the same assembly version numbers as previous versions of the application.  This option also allows users to retain any customizations they have made to data files that are a part of your application's setup if the data files are used as key paths for the Windows Installer components that install them.  You can check out this blog post for more detailed information about how Windows Installer handles file replacement logic for unversioned key path files if you're interested.

    Choosing scheduling options 1 or 2 will allow you to avoid the unregistration problem during Windows Installer major upgrades, but these options will require you to change assembly versions each time you release a new version of your application (in order to avoid this issue).  This means you must update the metadata in the assembly itself and in the RegisterMceApp XML file and any other places where your application's assembly is referred to by its full strong name identity.  In addition, options 1 and 2 will cause somewhat slower installation performance during major upgrades because any unchanged files will have to be uninstalled and re-installed.

    Choosing scheduling option 3 will allow users to retain customizations that they make to data files like described in the explanation of scheduling option 4 above.  It will also allow for full transactionality during a major upgrade (meaning that if the uninstall of the old version fails, the old version will be rolled back to an installed state, and the new version will be rolled back so it is no longer installed).  However, this option also requires you to change the assembly version each time you release a new version of your application just like scheduling options 1 and 2.

  • Aaron Stebner's WebLog

    Link to information about upcoming plans for supporting Windows Installer 4.5 in WiX

    • 2 Comments

    I noticed a post on Rob Mensching's blog this weekend that I wanted to link to here as well.  In the post, located at http://robmensching.com/blog/archive/2007/09/03/Windows-Installer-4.5-and-the-WiX-toolset.aspx, he outlines some work he did this past week to start enabling support for Windows Installer 4.5 in WiX now that the beta of Windows Installer 4.5 has been released.

    To summarize that post, Rob checked in the first part of the work necessary to enable Windows Installer 4.5 support in WiX v3.0, but he is going to wait until the final release of Windows Installer 4.5 to enable the equivalent support in WiX v2.0.

    Part of the reason for his decision to wait to support Windows Installer 4.5 in WiX v2.0 is an interesting issue with the new msidbCustomActionTypePatchUninstall bit flag being introduced in Windows Installer 4.5 for the Type value in the CustomAction table.  Rob outlines the issue in his post, and this issue is also described in more detail in this post on Heath Stewart's blog.  If you are evaluating the Windows Installer 4.5 beta, I encourage you to read Rob and Heath's posts before deciding to use the msidbCustomActionTypePatchUninstall attribute and understand the patching implications for previously shipped packages.

  • Aaron Stebner's WebLog

    Mailbag: Why doesn't the green button on my remote work until I launch Media Center manually?

    • 6 Comments

    Question:

    I have a computer that is running Windows XP Media Center Edition 2005.  When I press the green button on my Media Center remote control, it will not launch Media Center for me.   I can use the mouse to launch Media enter, and after that the remote control will work fine.  Even if I close Media Center, I can re-open it by using the green button on my remote control once I have launched Media Center at least once.  However, if I reboot my computer, the same thing happens again.

    Why is my system acting like this, and is there a way I can fix it so that the green button on my remote control will work all the time without needing to start Media Center manually with the mouse the first time?

    Answer:

    There is an application named ehTray that normally runs in the background on a Windows Media Center PC that listens for the green button on the remote to let you start Media Center.  By default, when installing Windows XP Media Center Edition, the ehTray application is configured to start each time Windows starts.  In addition, if it is not running when you start Media Center for the first time, Media Center will launch it for you.

    It sounds like the registry entry to start that service when Windows starts was removed from this system.  The following steps can be used to create a registry value that will cause the ehTray application to run each time Windows is started so that the green button on a Media Center remote control will work without needing to first launch Media Center manually:

    1. Click on the Start menu, choose Run, type cmd and click OK 
    2. Run this command:  reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v ehTray.exe /t REG_SZ /d c:\windows\ehome\ehtray.exe /f 
    3. Reboot 
    4. Try to use your remote control to launch Media Center

    Note: On Windows Vista, the configuration of the ehTray application has changed a little bit.  The registry setting to automatically start ehTray when Windows starts is located under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE, and it will not appear by default when you install Windows Vista.  However, the green button on a Media Center remote will work correctly on a default install of Windows Vista Home Premium or Ultimate editions, even if you have not yet launched Media Center for the first time.

    <update date="9/4/2007"> Updated the not about Windows Vista behavior because I misunderstood the behavior on a newly installed OS.  Thanks to Fu for pointing this out to me. </update>

     

  • Aaron Stebner's WebLog

    How to repair a localization pack for Update Rollup 2 for Windows XP Media Center 2005

    • 1 Comments

    Recently, I heard from a customer who has a system with Update Rollup 2 for Windows XP Media Center Edition 2005 and a localization pack that is used to add support for one of the new locales that was added in the Update Rollup 2 product.  However, the customer ran into a problem that caused them to need to re-install their OS.  After re-installing the OS, they were unable to re-install the localization pack and their Windows and Windows Media Center UI displayed in English instead of the language of the localization pack.  Attempting to re-run the localization pack setup displayed an error stating "Installation of more than one Localization Pack for Update Rollup 2 for Windows Media Center 2005 is not supported."

    If you run into a similar scenario and need to be able to re-install a localization pack for Update Rollup 2 for Windows XP Media Center 2005, you can use steps like the following:

    1. Click on the Start menu, choose Run, type cmd and click OK
    2. Run this command:  reg delete "HKLM\Software\Microsoft\Windows\CurrentVersion\Media Center\Language Pack" /f
    3. Use steps like the ones in this blog post to locate and uninstall the MSI for the localization pack that was previously installed on the system

    You should be able to re-run setup for the localization pack after completing the above steps to clean off the previous installation of the localization pack.

Page 1 of 1 (16 items)