Aaron Stebner's WebLog

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

January, 2008

  • Aaron Stebner's WebLog

    Creating an installable layout for the .NET Framework 3.5 that includes language packs

    • 15 Comments

    A little while ago, I posted this item on my blog that describes a potential issue when installing the .NET Framework 3.5 on a non-English operating system.  Over this past weekend, I noticed a related item on Aaron Ruckman's blog that I wanted to link to here.  In his post, Aaron describes some .NET Framework installation scenarios related to language packs.

    To summarize his post, there are a few key things to keep in mind when installing the .NET Framework 3.5 along with .NET Framework 3.5 language packs:

    1.  Using the /lang switch with .NET Framework 3.5 setup

    By default, the .NET Framework 3.5 setup will detect the language of the OS that setup is running on and attempt to install a .NET Framework 3.5 language pack to match the OS language if one is available.  The .NET Framework 3.5 setup contains a command line switched named /lang.  This switch allows you to override the default behavior and force .NET Framework 3.5 setup to install a specific language pack (or no language packs at all) instead of installing a language pack that matches the OS language.

    For example, this command line will cause the .NET Framework 3.5 to not install any language packs:

    dotnetfx35setup.exe /lang:ENU

    This command line will cause the .NET Framework 3.5 to install the French language pack:

    dotnetfx35setup.exe /lang:FRA

    Note that the /lang switch only works during initial installation of the .NET Framework 3.5.  If you run .NET Framework 3.5 setup in repair mode and attempt to pass in the /lang switch, the value you provide with /lang will be ignored.

    2.  Creating an installable .NET Framework 3.5 layout that includes language packs

    I previously posted some information about creating an installable layout for the .NET Framework 3.5 in this blog post.  If you want to create an installable layout for the .NET Framework 3.5 that includes one or more .NET Framework 3.5 language packs, you can first follow the instructions in that previous blog post to create an installable layout for the .NET Framework 3.5 core package.  Then you can download and copy the setup packages for the .NET Framework 3.5 language packs into the .NET Framework 3.5 layout you previously created.  There are separate language packs for each processor architecture, and they must be copied to the appropriate sub-folders of the .NET Framework 3.5 layout as follows:

    • For x86, you will copy the .NET Framework 3.5 language pack setup packages to the subfolder named \wcu\dotnetframework\dotnetfx35\x86
    • For x64, you will copy the .NET Framework 3.5 language pack setup packages to the subfolder named \wcu\dotnetframework\dotnetfx35\x64
    • For ia64, you will copy the .NET Framework 3.5 language pack setup packages to the subfolder named \wcu\dotnetframework\dotnetfx35\ia64

    3.  Deploying the .NET Framework 3.5 with multiple language packs

    The most reliable way to deploy the .NET Framework 3.5 along with one or more .NET Framework 3.5 language packs is to first deploy the .NET Framework 3.5 core package and then individually deploy each of the desired language packs.  This method will prevent the .NET Framework 3.5 from installing potentially undesired language packs depending on the language of the user's OS.  The steps to do this look like the following:

    • Create an installable .NET Framework 3.5 layout using the method described in item 2 above
    • Install the .NET Framework 3.5 core package by running dotnetfx35setup.exe /lang:ENU /q /norestart
    • Install each language pack by running the individual language pack setup EXE.  For example, to install the x86 French language pack, you would run \wcu\dotnetframework\dotnetfx35\x86\dotnetfx35langpack_x86fr.exe /q /norestart
  • Aaron Stebner's WebLog

    .NET Framework 3.5 deployment guides have been published on MSDN

    • 14 Comments

    The official deployment guides for system administrators and application developers have been posted on MSDN, and I wanted to provide links here to help raise visibility for them.  Here they are along with some additional information about what is contained in each of them:

    Microsoft .NET Framework 3.5 Deployment Guide for Application Developers

    You can find the deployment guide for application developers at the following location:

    http://msdn2.microsoft.com/library/cc160716.aspx

    The deployment guide for application developers is targeted at developers creating applications that depend on the .NET Framework 3.5 and that will need to incorporate the .NET Framework 3.5 into their installation process.  It contains the following information:

    • System requirements
    • Where to download the redistributable package from
    • How to chain the redistributable package into an application setup
    • How to detect whether or not the .NET Framework 3.5 is installed on a system
    • Command line switches for .NET Framework 3.5 setup
    • Error codes that can be returned by .NET Framework 3.5 setup
    • Payload included with .NET Framework 3.5 setup
    • How to minimize payload in specific installation scenarios

    Microsoft .NET Framework 3.5 Administrator Deployment Guide

    You can find the administrator deployment guide at the following location:

    http://msdn2.microsoft.com/library/cc160717.aspx

    The administrator deployment guide is targeted at system administrators that manage software installation on corporate networks and who want to plan a deployment of the .NET Framework 3.5 to networks that they manage.  It contains the following information:

    • How to deploy the .NET Framework 3.5 in silent mode using the setup EXE
    • How to create an administrative install point (AIP) for the components of the .NET Framework 3.5
    • How to create Group Policy objects to deploy the components of the .NET Framework 3.5 using Active Directory
    • Names and locations of .NET Framework 3.5 setup log files
    • A sample script that can be used to create an administrator installation point for the .NET Framework 3.5

    Links with additional information


    I have previously posted a few items on my blog that are not covered (or are touched on but not covered in much detail) in the above deployment guides.  Here are links to those posts in case you need additional information about deploying the .NET Framework 3.5 or its prerequisites (such as the .NET Framework 2.0 SP1 and/or 3.0 SP1):

  • Aaron Stebner's WebLog

    Link to .NET Framework 3.5 readme with known installation issues

    • 11 Comments

    I often receive emails and blog comments from customers who are having trouble installing the .NET Framework 3.5.  Many of the issues that I have been asked about are documented in various places but are unfortunately hard to find with some web searches.  In order to try to improve the ability of search engines to find these documents, I wanted to post links to them here.

    The following link is for the official .NET Framework 3.5 readme, which includes known installation issues and workarounds:

    http://download.microsoft.com/download/9/a/e/9ae0f6cc-7032-408e-9ca7-989f9e4af4ec/dotNetReadMe.htm

    In addition to the readme, here is a summary of some other useful items regarding .NET Framework 3.5 setup troubleshooting:

    As always, if you run into .NET Framework installation/deployment issues that you are having trouble finding solutions for at any of the above locations, please post a comment on one of my blog posts or contact me and I will attempt to help resolve the issue and then update my blog to hopefully help others in the future as well.

  • Aaron Stebner's WebLog

    How the full install packages for the .NET Framework 3.0 and the .NET Framework 3.5 differ

    • 11 Comments

    Question:

    When the .NET Framework 3.0 shipped, 3 packages were made available for download - a 2.8 megabyte web download bootstrapper, an approximately 50 megabyte full install package for x86 processor architectures and an approximately 90 megabyte full install package for x64 processor architectures.

    When the .NET Framework 3.5 shipped, 2 packages were made available for download - a 2.7 megabyte web download bootstrapper and an approximately 200 megabyte full install package.

    Why is the .NET Framework 3.5 full install package so much larger than the 3.0 full install package, and what exactly does it contain?  If I need to redistribute the .NET Framework 3.5 as a part of my installer, do I have any options to reduce the size?

    Answer:

    The .NET Framework 3.5 full install package includes all prerequisites and product components that could need to be installed for any processor architecture.  Basically, it is the union of the x86, x64 and ia64 packages and prerequisites.  The .NET Framework 3.5 includes the following prerequisites in addition to the main .NET Framework 3.5 product payload:

    • .NET Framework 2.0 with SP1
    • .NET Framework 3.0 with SP1
    • MSXML 6.0
    • RGB Rasterizer
    • Windows Imaging Components (WIC)

    The 200 megabyte full install package was not really designed to be redistributed as is by installers that require the .NET Framework, although it will work fine for that purpose if the installer does not have any sensitivity to the larger package size.

    Installers that want to reduce the .NET Framework 3.5 payload size have a couple of options:

    1. Carry the web download bootstrapper and let it decide what payload is needed based on the state of the system it is being installed on.  This can be a good option if it is acceptable for the setup to require internet access during installation.
    2. Extract the contents of the full install package and selectively remove payload that is not needed or supported by the scenarios that the setup that requires it supports.  I describe this option in a bit more detail in this blog post.  At a high level, this option involves identifying supported OS's and processor architectures and then selectively removing prerequisite payload from the .NET Framework 3.5 install location for platforms that the setup carrying the .NET Framework 3.5 does not plan to support.

    There is some more specific .NET Framework 3.5 deployment documentation that will be published soon to provide more details about how to redistribute the .NET Framework 3.5 in various types of scenarios.  The prerequisites and install options will be described in much more detail than I am going into in this blog post once it is published.  I will update my blog with a link to the .NET Framework 3.5 deployment guide once it is available.

    As a side note, I have seen some size comparison charts that show the .NET Framework size growing from 20 megabytes in 1.0 up to 50 megabytes in 3.0 and then 200 megabytes in 3.5.  It looks like this type of size chart was based on the size of this full install package for the .NET Framework 3.5.  That isn't really an accurate comparison though.  The 50 megabyte size for the .NET Framework 3.0 only includes x86 components, so an equivalent size for x86 components for the .NET Framework 3.5 is approximately 57 megabytes.  That means that the size of features that are new between the .NET Framework 3.0 and 3.5 is approximately 6 or 7 megabytes.  That is still fairly large for something that has to be redistributed by other installers for their applications to use at runtime, but it is not nearly as dramatic as saying that the .NET Framework 3.5 is 200 megabytes in size compared to 50 megabytes for the .NET Framework 3.0.

  • Aaron Stebner's WebLog

    Web Authoring Component can fail during VS 2008 setup if Program Files has a trailing backslash

    • 10 Comments

    I heard from a customer who ran into an interesting issue during Visual Studio 2008 setup that I hadn't seen until now.  I wanted to post a description of the issue, how we diagnosed it and how to work around the issue in case anyone else runs into a similar issue in the future.

    Description of this issue

    On this customer's system, the Web Authoring Component prerequisite component failed to install and Visual Studio 2008 setup failed as a result.  There are many possible causes for this type of failure, so we need to dig deeper to try to find the exact cause of the failure.

    How to diagnose this issue

    Visual Studio 2008 setup runs the Web Authoring Component setup package in silent mode, so the next step is to take a look at the log file for the Web Authoring Component to narrow down the issue further.  This issue will cause the following information to be written to the log file for the Web Authoring Component (named %temp%\SetupExe(*).log):

    Catalyst valid path check failed: The path c:\Program Files\\Microsoft Web Designer Tools is invalid

    Notice that there is an extra backslash between Program Files and Microsoft Web Designer Tools in this log file.  I had the customer check their registry and we found that the path to the Program Files folder was being stored there with a trailing backslash, but Windows typically stores the path to Program Files and other system folders without trailing backslashes.

    In this scenario, it is also possible to run Web Authoring Component setup directly from <VS install path>\WCU\WebDesignerCore\WebDesignerCore.exe in order to see a specific error message instead of looking at the log files.

    How to work around this issue

    To work around this issue, you can change the value that Windows uses for the Program Files directory on your system by doing the following:

    1. Click on the Start menu, choose Run, type regedit and click OK
    2. Locate the following registry value:
    3. [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion]
      ProgramFilesDir

    4. Remove the trailing backslash from this ProgramFilesDir registry value
    5. Close regedit and reboot the computer
    6. Re-run Web Authoring Component setup from <VS install path>\WCU\WebDesignerCore\WebDesignerCore.exe
    7. Look at %temp%\SetupExe(*).log and verify that installation succeeded this time
    8. Re-run Visual Studio 2008 setup to complete installation

    One note about this issue - the Web Authoring Component setup package uses the same setup wrapper as the Office 2007 family of products.  It appears that other Office 2007 products may have similar installation errors if the ProgramFilesDir value has a trailing backslash like this.

  • Aaron Stebner's WebLog

    Some behind-the-scenes details about .NET Framework 2.0 SP1 and 3.0 SP1 setup

    • 10 Comments

    Since the .NET Framework 3.5 shipped, I've written a few blog posts about some of the setup and deployment issues that can affect this product.  Behind the scenes, the installer for the .NET Framework 3.5 has some architectural differences from previous releases of the .NET Framework that I've alluded to in a few of those previous posts, and I wanted to take a little time to describe these differences in a bit more detail.

    How the .NET Framework 2.0, 3.0 and 3.5 fit together

    The .NET Framework 3.5 is essentially an add-on that introduces new features to the .NET Framework 2.0 and 3.0 products but continues to run on the version of the common language runtime (CLR) that shipped in the .NET Framework 2.0.  This is similar to the model introduced in the .NET Framework 3.0, which is essentially an add-on for the .NET Framework 2.0 but did not introduce a new version of the CLR.  As a result of this add-on model, the .NET Framework 3.0 setup requires the .NET Framework 2.0 as a prerequisite, and the .NET Framework 3.5 requires both the .NET Framework 2.0 and the .NET Framework 3.0 as prerequisites.  This is sometimes called a "nesting doll" model for creating a product.

    .NET Framework 3.5 setup includes service packs for both the .NET Framework 2.0 and 3.0.  These service packs install as prerequisites because some of the new features introduced in the .NET Framework 3.5 require updates to the originally released versions of both the .NET Framework 2.0 and 3.0.

    When the .NET Framework 3.5 project first got started, the service packs for the .NET Framework 2.0 and 3.0 were being built as a series of Windows Installer patches (MSP files).  It quickly became clear that the number of files being changed by these service packs was going to lead to the service packs being nearly as large as the original versions of the products.  This would mean that any customers needing to redistribute the .NET Framework 3.5 with their products would have to include the original versions of the .NET Framework 2.0 and 3.0 and nearly equal-sized service packs for each of them, which would have caused the overall size to grow even larger than it already has.

    As a result, the decision was made to create slipstream releases for both the .NET Framework 2.0 SP1 and 3.0 SP1.  These slipstream releases include the original payload plus all of the fixes that are a part of the service packs.  They will successfully install on systems that had the original releases of the .NET Framework 2.0 and 3.0 as well as on systems that did not yet have either version installed (whereas, standalone service packs only install if the original version of the product was previously installed).

    .NET Framework 2.0 SP1 and 3.0 SP1 slipstream behind-the-scenes details

    Typical slipstreams for MSI-based products are produced by building a layout that is identical to the original release, but with updated binary content.  However, the slipstream releases of the .NET Framework 2.0 and 3.0 are constructed differently behind the scenes than a typical slipstream release.

    The .NET Framework 2.0 SP1 and 3.0 SP1 setup packages consist of the following payload:

    • A base MSI that contains no files of its own - it only writes some registry values used for product-level detection
    • A series of MSPs that contain the file payload for .NET Framework features, divided up logically into sub-features that will likely need to be updated as a unit in the future

    The .NET Framework 2.0 SP1 and 3.0 SP1 setup packages include logic to do the following:

    • Detect the processor architecture and install the base MSI and the appropriate set of MSPs during the initial installation transaction.  The ability to install multiple patches in a single transaction like this is a new feature available starting in Windows Installer 3.0.
    • Use the Windows Installer major upgrade feature to automatically uninstall the original version of the .NET Framework 2.0 or 3.0 during SP1 setup if they are present on the system.  This ensures that all systems are baselined at the new service pack level after installing the slipstream package.

    Each of the MSPs installed during .NET Framework 2.0 and 3.0 SP1 setup is marked to not allow uninstall, which is why you see a series of updates that do not have Uninstall buttons listed in Add/Remove Programs for each of these products (if you check the Show updates box at the top of the Add/Remove Programs control panel).

    Implications of this slipstream design

    There are a few interesting results that fall out of this slipstream design that warrant a bit more in-depth discussion:

    • Because all of the files that are a part of the .NET Framework 2.0 SP1 and 3.0 SP1 are installed via patches, the source files are cached automatically by Windows Installer so they will be available for repair and uninstall scenarios.  The original releases of the .NET Framework 2.0 and 3.0 had to include specific logic to cache the source files for repair scenarios, but this logic is no longer needed in the slipstream service packs.
    • The original version of the .NET Framework 3.0 consisted of multiple MSIs with payload for different features (Windows Communication Foundation, Windows Presentation Foundation, Windows Workflow Foundation).  The slipstream 3.0 SP1 release consolidates this payload down to a single MSI with a set of associated MSPs.  This means that repairing or uninstalling the .NET Framework 3.0 SP1 only requires interacting with one MSI instead of several.
    • The .NET Framework 2.0 and 3.0 both support installing on 32-bit and 64-bit platforms.  In the original releases, the 64-bit packages were separate from the 32-bit packages and carried both 32-bit and 64-bit payload.  This meant that customers who needed to redistribute both the 32-bit and 64-bit versions had to carry the 32-bit payload twice - once in the 32-bit setup package and a second time in the 64-bit setup package.  Splitting the payload of the .NET Framework 2.0 SP1 and 3.0 SP1 into MSPs allows the .NET Framework 2.0 SP1 and 3.0 SP1 to use the same 32-bit source files for both 32-bit and 64-bit setup.  This will reduce the overall package size for customers who need to redistribute both the 32-bit and 64-bit versions of 2.0 SP1 and/or 3.0 SP1.
    • Partitioning the payload of the .NET Framework 2.0 SP1 and 3.0 SP1 into a series of patches allows for more easy creation of future slipstream packages that include updates to a subset of the collection of patches.  It becomes as simple as building the patches that include updated payload and then packaging them with the MSI and the rest of the MSPs that are included with SP1.  These future patches could also be delivered as standalone hotfixes that can be independently uninstalled if desired.

    Additional information

    • There are links in this blog post to more detailed information about the fixes included in the .NET Framework 2.0 SP1, 3.0 SP1 and 3.5 and the install locations of each version.
    • You can find instructions for creating an administrative install point for the .NET Framework 2.0 SP1 in this blog post
    • You can find instructions for creating an administrative install point for the .NET Framework 2.0 SP1 in this blog post

    It is also interesting to note that the Silverlight 1.0 installer uses a similar packaging scheme behind the scenes.  It includes an MSI that does not have any files of its own, and an MSP that includes the file payload.

    <update date="1/21/2008"> Added links to the instructions for creating administrative install points for the .NET Framework 2.0 SP1 and 3.0 SP1 so they'll be easier to find </update>

     

  • Aaron Stebner's WebLog

    How to use Group Policy to enable and disable Windows Media Center in Windows Vista Home Premium and Ultimate editions

    • 8 Comments

    Description of the issue

    Recently, I was contacted by a customer who is running Windows Vista Home Premium, but who was unable to launch Windows Media Center.  There was not a shortcut available on the Windows Vista start menu, and when they tried navigating directly to c:\Windows\eHome\ and running ehShell.exe directly, they received an error dialog with the following information:

    • Title: Windows Media Center
    • Text: Windows cannot open this program because it has been prevented by a software restriction policy. For more information contact your system administrator.

    The dialog looks like this:

    In Windows Vista, a Group Policy setting was introduced to allow administrators to configure systems to not allow Windows Media Center to run.  This setting was designed to be used in locked down environments such as corporate networks where Windows Media Center is not needed on a day-to-day basis.  However, it is possible that this setting could end up getting configured on home systems as well.

    How to work around the issue

    If you see the above dialog when attempting to launch Windows Vista Media Center, you can use the following steps to disable the Windows Media Center Group Policy settings using the Group Policy Object Editor in Windows Vista:

    1. Click on the Start menu and type gpedit.msc to locate the Group Policy Object Editor
    2. Run gpedit.msc and click Continue to allow it to run elevated
    3. Expand Computer Configuration (for per-machine settings), then Administrative Templates, then Windows Components
    4. Click on the Windows Media Center item under Windows Components
    5. Right-click on the setting named Do not allow Windows Media Center to run and choose Properties
    6. In the Properties dialog, change the setting from Enabled to either Disabled or Not Configured and click OK
    7. Expand User Configuration (for per-user settings), then Administrative Templates, then Windows Components
    8. Click on the Windows Media Center item under Windows Components
    9. Right-click on the setting named Do not allow Windows Media Center to run and choose Properties
    10. In the Properties dialog, change the setting from Enabled to either Disabled or Not Configured and click OK
    11. Close the Group Policy Object Editor
    12. Try to launch Windows Vista Media Center again

    If you see this dialog on your system, it is important to check both the Computer Configuration (per-machine) and User Configuration (per-user) locations for this setting because if either one of them is enabled, Windows Media Center will not launch and will display the above dialog.

    What is happening behind the scenes

    Behind the scenes, the Group Policy Object Editor sets the following registry values:

    • For per-user settings available in the User Configuration tab:
    • [HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\WindowsMediaCenter]
      MediaCenter

    • For per-machine settings available in the Computer Configuration tab:
    • [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsMediaCenter]
      MediaCenter

    The logic for this setting is backwards from what you might typically expect because the setting indicates whether or not Windows Media Center should be disabled (as opposed to enabled).  If the setting is enabled, it means that Windows Media Center will not be allowed to run.  The MediaCenter registry value will be set to 1 in that case.  If the setting is disabled or not configured, it means that Windows Media Center will be allowed to run.  If the setting is disabled, the MediaCenter registry value will be set to 0.  If the setting is not configured at all, the MediaCenter registry value will not exist on the system.

    Where to find additional information

    This Windows Media Center Group Policy setting and others that are supported in Windows Vista are described in more detail in the Windows Vista Group Policy Settings Reference.  This spreadsheet is available for download at http://www.microsoft.com/downloads/details.aspx?FamilyID=41dc179b-3328-4350-ade1-c0d9289f09ef.

  • Aaron Stebner's WebLog

    Link to Channel9 video about Windows Installer application compatibility issues on Windows Vista

    • 7 Comments

    A new Channel9 video has been posted that I wanted to link to here.  The video is located at http://channel9.msdn.com/ShowPost.aspx?PostID=374129, and in it, Robert Flaming discusses application compatibility issues that can affect Windows Installer-based setups on Windows Vista and Windows Server 2008.

    If you are a setup developer and will be targeting Windows Vista or Windows Server 2008 for your MSI-based setup, I encourage you to check out this video.

    One of the key application compatibility challenges that Robert discusses in this video is how to author custom actions that will interact correctly with UAC on Windows Vista and Windows Server 2008.  Robert has written a series of blog posts that contain much more detail about how Windows Installer interacts with UAC, and I encourage you to also review these posts if you are creating MSIs that will install on Windows Vista and/or Windows Server 2008.

  • Aaron Stebner's WebLog

    How to re-enable Windows Media Center in the Default Programs control panel on Windows Vista Home Premium and Ultimate

    • 6 Comments

    Yesterday, I posted some information about a Group Policy setting that can prevent Windows Media Center from launching on a Windows Vista Home Premium or Ultimate system.  Since then, I have heard from a couple of people who have been receiving the same error message but who did not have this Group Policy setting enabled on their systems.  After some further investigation, I found another possible cause of this type of error that I wanted to describe here as well.

    Description of the issue

    To summarize some information from my previous post, it is possible that launching Windows Vista Media Center will fail and will instead display the following error message:

    • Title: Windows Media Center
    • Text: Windows cannot open this program because it has been prevented by a software restriction policy. For more information contact your system administrator.

    The dialog looks like this:

    I looked at the startup code for Windows Media Center, and found that in addition to the Group Policy setting that I previously described, it is also possible for this error dialog to appear if Windows Media Center is marked as disabled in the Set Program Access and Computer Defaults control panel on Windows Vista.

    How to work around the issue

    You can use the following steps to enable Windows Media Center in the Set Program Access and Computer Defaults control panel if it is currently disabled:

    1. Click on the Start menu and choose Default Programs
    2. Click on the item named Set Program Access and Computer Defaults
    3. Choose the Custom configuration
    4. Under the Choose a default media player item, make sure that the box to the right of the Windows Media Center item that is labeled Enable access to this program is checked

    Note - you do not have to select the radio button to the left of the Windows Media Center to make it the default media player if you don't want to, but the Enable check box must be checked or Windows Media Center will refuse to launch on your system.

    What is happening behind the scenes

    The Enable access to this program check box for the Windows Media Center Item in the Set Program Access and Computer Defaults control panel will result in the following value being changed in the registry on Windows Vista:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\Windows Media Center\InstallInfo]
    IconsVisible

    If the IconsVisible value is set to 0, then Windows Media Center will not run on a Windows Vista system.

    <update date="10/7/2011"> Fixed broken link to image embedded in this post. </update>

     

  • Aaron Stebner's WebLog

    Votive in WiX v3.0 now supports Visual Studio 2008

    • 6 Comments

    Since Visual Studio 2008 shipped last November, I have been asked a few times via my blog about if/when the Votive Visual Studio add-in that is a part of the WiX toolset will support integrating into VS 2008.  It was not very well publicized initially, but the version of Votive included with WiX v3.0 has supported integrating into VS 2008 since the VS 2008 beta 2 timeframe.  Specifically, this has been available since the 3.0.3328.0 build of WiX v3.0 on SourceForge.  The version of Votive in builds between 3.0.3328.0 and 3.0.3621.0 were built using the beta 2 version of VS 2008 and the August 2007 CTP of the VS 2008 SDK.  However, those builds of Votive will work correctly when installed on a system that has the final release of VS 2008 installed as well as systems that have VS 2008 beta 2 installed.

    Votive in WiX v3.0 has also recently been updated to build with the final release of VS 2008 and the VS 2008 SDK.  Builds starting with the 3.0.3621.0 build on the WiX releases page contain these changes.  An announcement was also added to the front page of the WiX SourceForge site about Votive support for VS 2008.  That announcement states that builds starting with 3.0.3607.0 contain these Votive build changes, but that build number is slightly incorrect because of some issues related to porting the changes into the source tree available on SourceForge.

    One of the nice things about Votive in Visual Studio 2008 is that you no longer have to install ProjectAggregator2.msi prior to installing wix3.msi in order to be able to install and use Votive in the Visual Studio 2008 IDE.  You can simply install VS 2008 standard edition or higher, then install wix3.msi and you're ready to launch the VS IDE and create WiX projects using the Votive add-in.

  • Aaron Stebner's WebLog

    Why XNA Game Studio 2.0 setup switched from using WiX v2.0 to using WiX v3.0

    • 5 Comments

    The MSIs for the XNA Game Studio Express 1.0 and 1.0 Refresh releases were created using WiX v2.0.  The MSIs for the recently released XNA Game Studio 2.0 product were created with a recent build of WiX v3.0.  The decision to move from WiX v2.0 to v3.0 is interesting so I wanted to describe how this decision came about behind the scenes.

    XNA Game Studio Express 1.0 and 1.0 Refresh integrate into Visual C# 2005 Express Edition only.  As noted in this introductory blog post, XNA Game Studio 2.0 now integrates into Visual Studio 2005 standard edition and higher in addition to Visual C# 2005 Express Edition.

    XNA Game Studio 2.0 ships a Visual Studio starter kit for a game named Spacewar.  This starter kit takes the form of a .zip file for the Windows version of the game and a .zip file for the Xbox 360 version of the game.  Each of these .zip files is approximately 30 megabytes in size, and they must be installed to separate locations in order to integrate correctly into Visual C# 2005 Express Edition and the up-level editions of Visual Studio 2005. 

    In order to minimize the size of the payload for XNA Game Studio 2.0, we needed to find a solution that would allow us to carry only one source copy of each .zip file, but install each .zip file to multiple locations on the system.  In addition, we decided to continue to use embedded cab files inside of each MSI we create to deliver the setup payload.

    We could have used the DuplicateFile table, but there are some potential limitations with using this table that are related to conditional installs, repairs and patching, so we decided to not use it in XNA Game Studio 2.0 setup if we could avoid it.

    Fortunately, WiX v3.0 introduced a new feature last year known as smart cabbing.  This feature allows the WiX build process to embed a single physical copy of each file in the cab files it creates if the file is referenced by multiple File elements.  The WiX toolset will apply this feature automatically (and not require any setup authoring changes for the feature to take effect) if you author your setup to include multiple files with the same source location defined for them.

    By switching to WiX v3.0 and gaining access to the smart cabbing feature, we were able to eliminate 60 megabytes of payload from the XNA Game Studio 2.0 setup package without adding any new setup authoring.  This resulted in an overall packages size of approximately 100 megabytes as opposed to 160 megabytes - a size reduction of 37.5%!

  • Aaron Stebner's WebLog

    XNA Game Studio 2.0 product feedback survey now available on the Connect site

    • 1 Comments

    The XNA team has published a new survey on the Connect site to gather feedback about the XNA Game Studio 2.0 product.  The answers to this survey will be used to help guide the team as it makes plans for the future of the XNA Game Studio product line.  If you are an experienced XNA Game Studio user or even if you are holding off on trying XNA Game Studio for one reason or another, we encourage you to visit the site and take the survey.  You can find the survey at this link:

    https://connect.microsoft.com/Survey/Survey.aspx?SurveyID=5387&SiteID=226

    A couple of important notes about this survey:

    • The survey will only be available until next Wednesday, January 30, so please visit the site and fill out the survey while it is still available.
    • The Connect site will require you to log on with a Windows LIVE ID in order to view the survey.  Please let us know on the Creators Club forums if you have any trouble accessing the survey page.
  • Aaron Stebner's WebLog

    Link announcing Big Screen Global web site and Big Screen Photos and Weather v2

    • 1 Comments

    Niall Ginsbourg announced the launch of his new Big Screen Global web site and the release of the Big Screen Photos v2 and Big Screen Weather v2 applications for Windows Vista Media Center.

    I have been using the beta versions of a few of the Big Screen applications for a while and they're really nice.  I encourage you to check out these links for additional information about the Big Screen product line:

  • Aaron Stebner's WebLog

    Link to more detailed notes about changes in the weekly WiX build

    • 0 Comments

    Over the weekend, I noticed a couple of posts on Bob Arnson's blog that I wanted to link to here.  Bob indicated in this post that he was going to start publishing more detailed information about the changes included in each weekly build of WiX.

    For those of you familiar with WiX, each build includes a text file named history.txt that includes high-level summaries of each change that gets checked in.  The level of detail in history.txt is not very deep, and it varies based on which person checked in each change.  In addition, the contents of history.txt has not been available on a web page in the past.  I think these factors will make a web-based list of changes fairly useful to developers who use WiX in their setup/build processes.

    To kick off this effort, Bob posted a list of changes and fixes available in WiX build 3.0.3711.  You can view this initial list of changes at http://www.joyofsetup.com/2008/01/13/highlights-of-wix-v303711/.

    I also encourage you to keep an eye on Bob's blog in the future for additional information about changes in WiX.

Page 1 of 1 (14 items)