Aaron Stebner's WebLog

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

August, 2006

  • Aaron Stebner's WebLog

    Mailbag: How can I customize an MSI in the Visual Studio setup/deployment project?

    • 114 Comments

    Question:

    I am using the Visual Studio setup/deployment project to create an MSI to install my application.  I would like to add some functionality to this MSI that does not appear to be supported in the Visual Studio IDE (such as modifying the default install path based on a registry value on the system).  I know how to do this by directly editing the MSI, but I don't want to have to manually edit the MSI each time I build.  Are there any other options I can use in this scenario?

    Answer:

    There is a limited set of customizations you can make to an MSI in the Visual Studio IDE UI for a setup/deployment project.  By limited, I mean that there are a lot of features that are natively supported in Windows Installer MSI format that are not exposed for customization in the Visual Studio IDE.  Examples include changing the default install path based on a registry value, advanced setup UI features such as updated banner text or a "launch my product" checkbox on the final screen, creating custom actions that reference external executable files, or setting various custom action attributes (among other things).

    If you would like to automate the ability to customize an MSI that is built by the Visual Studio setup/deployment project in a way that is not currently supported by the UI in the Visual Studio IDE, you can write a script that accesses the Windows Installer object model to perform these customizations.  Then you can create a post-build step in your Visual Studio setup/deployment project to run your script after the MSI has been built so that the final result each time you build will be an MSI package with your additional customizations made to it.

    As an example, you can use the sample script at this location to add a checkbox to your MSI's setup UI that will let the user choose whether or not to launch your product after setup finishes.

    If you would like to include this script as a post-build step in a Visual Studio setup/deployment project, you can use the following steps:

    1. Download the sample script and extract the contents to the directory that contains the Visual Studio setup project you are working on.

      Note: You should end up with the file EnableLaunchApplication.js in the same directory as the .vdproj file for your setup project.  The rest of these steps will not work correctly if you do not put EnableLaunchApplication.js in the correct location, so be careful about this step.

    2. Open the file EnableLaunchApplication.js in a text editor such as notepad, locate the variable at the top of the file that is set to the value WindowsApplication1.exe, and change it to the name of the EXE that is in your setup that you want to launch when the MSI is done installing
    3. Open the project in Visual Studio
    4. Press F4 to display the Properties window
    5. Click on the name of your setup/deployment project in the Solution Explorer
    6. Click on the PostBuildEvent item in the Properties window to cause a button labeled "..." to appear
    7. Click on the "..." button to display the Post-build Event Command Line dialog
    8. Copy and paste the following command line into the Post-build event command line text box:

      cscript.exe "$(ProjectDir)EnableLaunchApplication.js" "$(BuiltOuputPath)"


    9. Save your project
    10. Build your project in Visual Studio

    Note that the quotation marks in the command line in step 8 are very important because the script will not work correctly without them.  Make sure to double-check that you have put quotes in the proper places.

    You can find another example script that will update the MSI setup UI banner text in this MSDN forum post.

    <update date="8/23/2006"> Updated the steps needed to configure post-build commands in the Visual Studio UI because they are different for setup projects than for other Visual Studio project types </update>

    <update date="5/31/2007"> Updated steps to mention the need to rename WindowsApplication1.exe to the name of the EXE in each project that you want to launch.  Also fixed a typo in the variable BuiltOuputPath. </update>

    <update date="8/26/2008"> Updated steps to be more specific about what folder to save EnableLaunchApplication.js to </update>

    <update date="3/15/2009"> Fixed broken link to the sample script </update>

    <update date="7/26/2012"> Fixed bad HTML formatting and misnumbered steps </update>

     

  • Aaron Stebner's WebLog

    Mailbag: How to perform a silent install of the Visual C++ 8.0 runtime files (vcredist) packages

    • 47 Comments

    Question:

    Visual Studio 2005 includes redistributable setup packages to install the Visual C++ 8.0 runtime files such as msvcr80.dll, atl80.dll, etc.  I would like to run this setup in fully silent mode, but when I run it normally, it displays a progress page.  How can I run this setup package in fully silent mode?

    Answer:

    The Visual C++ 8.0 redist packages (vcredist_x86.exe, vcredist_x64.exe and vcredist_ia64.exe) support the following command line installation options.  The examples below use the file named vcredist_x86.exe, but you can substitute the 64-bit versions of the EXEs with equivalent command lines to achieve the same behavior for them as well.

    Unattended install

    This option will run setup and display a progress dialog but requires no user interaction.

    vcredist_x86.exe /q:a

    Unattended install with no cancel button

    This option is the same as the previous option, except that the user will not have the option to press cancel during installation.

    vcredist_x86.exe /q:a /c:"msiexec /i vcredist.msi /qb! /l*v %temp%\vcredist_x86.log"

    Silent install

    This option will suppress all UI during installation.

    Vcredist_x86.exe /q:a /c:"msiexec /i vcredist.msi /qn /l*v %temp%\vcredist_x86.log"

    Note about standalone VC++ redistributable packages

    The instructions above apply to the copies of the VC++ redistributable packages that ship with Visual Studio 2005.  If you are downloading and trying to install the standalone versions of the VC++ redistributable packages instead of using the copies included with Visual Studio 2005, you will need to use slightly different command line parameters.  Please refer to this blog post for information about the command line parameters you will need to use in that case.

    <update date="10/16/2009"> Added a link to a separate blog post with command line syntax for the standalone versions of the VC++ 2005 redistributable packages. </update>

     

  • Aaron Stebner's WebLog

    Adding strips and tiles to the Windows Media Center Start menu in Windows Vista

    • 22 Comments

    As those of you who have seen Windows Media Center in Windows Vista already know, there has been a redesign of the Start menu.  Windows Media Center now has the concept of strips and tiles on the Start menu as well as horizontal and vertical navigation.

    A strip is a top-level menu on the Windows Media Center Start menu that can be reached by scrolling vertically.  Examples include Music, Pictures + Videos, etc.  A tile is an item in a strip.  Each tile invokes a single action or entry point within Windows Media Center.

    With the redesign of the Start menu, Windows Media Center for Windows Vista also includes a new way of registering applications and entry points to appear on the Start menu.  It is possible to add up to 2 new strips to the Start menu using existing extensibility mechanisms in Windows Media Center, and each of those 2 strips can contain up to 5 tiles.

    The following steps provide a high-level overview of how to create a custom strip on the Windows Media Center Start menu in Windows Vista:

    1. Create an XML file that can be used by the RegisterApplication or RegisterMceApp.exe to register an application and one or more entry points
    2. Associate the entry points that you want to appear in the custom strip on the Start menu with a specific category name of your choosing
    3. Register the application and entry points using RegisterApplication or RegisterMceApp.exe
    4. Create a registry sub-key named HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Media Center\Start Menu\Applications\{APPLICATION GUID} where APPLICATION GUID is the one provided in the XML file in step 1 above
    5. Create the following values under this sub-key:
      Category (REG_SZ) - the name of the category name that you used in step 2 above
      OnStartMenu (REG_SZ) - set this to true
      Title (REG_SZ) - the display name for the custom strip on the Start menu

    The above steps are fairly abstract, so I have posted a set of example files on my file server to illustrate how to create custom strips.  The files in this ZIP package will allow you to register 2 custom strips with 5 tiles each on the Windows Media Center Start menu in Windows Vista.  To accomplish this, use these steps:

    1. Download the ZIP file and extract the contents to a Windows Vista Home Premium or Ultimate system
    2. Click on the Start menu, choose All Programs, then Accessories
    3. Right-click on Command Prompt and choose Run as administrator, then click Allow
    4. Run %windir%\ehome\registermceapp.exe TestApp1.xml to register the first application and 5 entry points
    5. Run %windir%\ehome\registermceapp.exe TestApp2.xml to register the second application and 5 entry points
    6. Run regedit.exe /s TestApp1.reg to add the first application to the Windows Media Center Start menu
    7. Run regedit.exe /s TestApp2.reg to add the second application to the Windows Media Center Start menu

    To remove these applications from the Windows Media Center Start menu, you will need to use these steps:

    1. Click on the Start menu, choose All Programs, then Accessories
    2. Right-click on Command Prompt and choose Run as administrator, then click Allow
    3. Run %windir%\ehome\registermceapp.exe /u TestApp1.xml
    4. Run %windir%\ehome\registermceapp.exe /u TestApp2.xml
    5. Run regedit.exe and remove the sub-key named HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Media Center\Start Menu\Applications

    Please note that I have only provided these XML and REG files as an example.  They are not real applications.  Each tile that is added to the 2 custom strips on the Start menu in this scenario launches the same Windows Media Center Presentation Layer Web Application for simplicity's sake.  If you want to create your own custom strip and tiles, you will want to make the following modifications to the sample files:

    • Update each entry point to launch a unique task
    • Change all of the GUIDs listed in the XML and REG files to be specific to your scenarios.  You can use guidgen.exe in Visual Studio or a website such as this to generate new GUIDs

    <update date="1/20/2011"> Fixed broken link to the sample referenced in this blog post. </update>

     

  • Aaron Stebner's WebLog

    Updated sample .NET Framework detection code that does more in-depth checking

    • 19 Comments

    I previously posted some sample code to detect the version(s) and service pack levels of the .NET Framework that are installed on a computer (here and here).  The original version of the sample code that I wrote queries the officially documented registry values that are used to detect the presence of each specific version of the .NET Framework.

    Since I posted this sample code, I have heard feedback from some customers who are including the .NET Framework as part of their setup packages.  They indicated that sometimes this code reports false positives - in other words, the sample returns true for a specific version of the .NET Framework but it isn't actually installed on the system.  I have seen this a couple of times in the past as well, and the root cause was that some of the registry entries used to detect the .NET Framework were orphaned on the system after an uninstall or OS reinstall scenario.

    In order to help address this type of issue, I've created a new version of the sample code that adds some new checks to help guard against orphaned registry values.  The logic it uses is to query the registry values like the previous sample used to, and then to supplement that with an additional check that loads mscoree.dll and uses some of its APIs to query for the presence of specific versions of the .NET Framework.  The underlying algorithm for this mscoree.dll-based check came from Junfeng Zhang and from a sample published on MSDN.

    This algorithm should prove more reliable in detecting whether or not a specific version of the .NET Framework is installed on the system because it does not rely solely on the registry.  In addition, it provides the side benefit of performing a quick health check for the .NET Framework itself because it attempts to invoke some APIs in the runtime.

    The new sample code contains the following specific changes from the previous version that I published:

    • Added the CheckNetfxVersionUsingMscoree and GetProcessorArchitectureFlag functions
    • Added logic in WinMain to call CheckNetfxVersionUsingMscoree in addition to the original calls to check .NET Framework registry data
    • Updated the code to use strsafe.h functions for string manipulations

    You will need the following in order to compile this sample:

    Please let me know if you have any trouble building or running this sample or incorporating it into your product setup logic.

    <update date="5/29/2009"> Fixed broken link to the sample code. </update>

     

  • Aaron Stebner's WebLog

    How to fix Visual Studio 2005 setup projects on Windows Vista post-beta 2 builds

    • 10 Comments

    I ran across a mail thread today describing some problems that folks have run into while trying to use the setup and deployment project types in Visual Studio 2005 on post-beta 2 builds of Windows Vista.  I want to describe the symptoms and how to workaround this issue in case you run to this in your development scenarios.

    What are the issues?

    When trying to create a new setup project in Visual Studio 2005 on post-beta 2 builds of Windows Vista, an error dialog appears stating "The Operation could not be completed. The parameter is incorrect."  The error dialog looks like this:

    New setup project error dialog on Windows Vista

    When trying to open an existing setup project in Visual Studio 2005 on post-beta 2 builds of Windows Vista, an error dialog appears stating "One or more projects in the solution could not be loaded for the following reason(s): The application for the project is not installed. These projects will be labeled as unavailable in Solution Explorer. Expand the project node to show the reason the project could not be loaded."  The error dialog looks like this:

    Open existing setup project error dialog on Windows Vista

    How can I fix these issues?

    The underlying issue will be fixed in Visual Studio 2005 service pack 1.  Until then, you can workaround this issue by using the following steps:

    1. Close all instances of Visual Studio 2005 that are running on your system
    2. Click on the Start menu, choose All Programs, then choose Accessories
    3. Right-click on Command Prompt and choose Run as administrator
    4. Click allow to launch an administrator command prompt
    5. Run reg delete "HKLM\SOFTWARE\Microsoft\VisualStudio\8.0\Deployment\Deployables\Setup\Plugins\VJSharpPlugin" /f
    6. Re-launch Visual Studio 2005 and try to open/create a setup project again

    This workaround will prevent you from including the Visual J# redistributable package in your project using the bootstrapper, but it will allow you to use the rest of the setup/deployment project infrastructure in Visual Studio 2005.

    What is the root cause?

    I didn't find detailed information about the root cause of this problem, but the information I found stated that the underlying cause is within Visual Studio 2005 and not Windows Vista.  Some Windows APIs that Visual Studio 2005 calls were being used in ways that were not officially documented or supported, and this behavior has been changed in Windows Vista.  This is one of the dangers of relying on undocumented API behaviors in an application.

    One additional note here - if you found this blog post and are using the Visual Studio 2005 setup/deployment projects, I highly encourage you to check out WiX if you haven't already.  The following references are very useful for getting started with WiX:

     

  • Aaron Stebner's WebLog

    Registry settings to control visibility of Windows Media Center mouse controls

    • 9 Comments

    There are 2 new settings available in Windows Media Center for Windows Vista that can be used to control the visibility of mouse-related controls in the Windows Media Center UI.  These settings are primarily designed for touch-screen development scenarios, but can be useful in other situations as well.  We will be documenting these settings in the Windows Media Center SDK for Windows Vista, but that documentation has not yet been written so I wanted to introduce these settings here in the meantime.

    Persisting mouse toolbars in the Windows Media Center shell

    When you launch Windows Media Center and then move your mouse, you will see toolbars appear in the top right, top left and bottom right of the screen.  By default, these toolbars are only visible when moving the mouse or for a short time afterwards, then they timeout and are hidden from view.  The following registry setting can be used to cause the mouse toolbars to remain visible at all times:

    • Key name: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Media Center\Capabilities
    • Value name: TBP
    • Value data type: REG_DWORD
    • Value data: 1

    Persisting mouse auto-scroll chevrons

    The Windows Media Center Start menu and galleries have automatic scrolling regions that can be activated by moving the mouse over small carat symbols (<, >, ^, V), also called chevrons.  The chevrons appear at the top, bottom, left and right of a scrolling region such as a menu or gallery.  By default, mouse auto-scroll chevrons are only visible when moving the mouse over the auto-scroll region of the scroller.  There is an additional registry value that can be changed to change the logic used to show these mouse auto-scroll chevrons:

    • Key name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Settings\MCE.GlobalSettings
    • Value name: bindNavHintsToToolbars
    • Value data type: REG_DWORD
    • Value data: 1

    Using TBP and bindNavHintsToToolbars together

    The bindNavHintsToToolbars registry value works in conjunction with the previously described TBP setting.  Here is a behavior matrix for all possible combinations of these two settings:

    • TBP = 0, bindNavHintsToToolbars = 0 - this is the default behavior; both the mouse toolbars and the auto-scroll chevrons will only appear when moving the mouse
    • TBP = 0, bindNavHintsToToolbars = 1 - when moving the mouse, the mouse toolbars and the auto-scroll chevrons will become visible; after a short period of inactivity, the toolbars and the auto-scroll chevrons will all be hidden again
    • TBP= 1, bindNavHintsToToolbars = 0 - the mouse toolbars will always be visible, except when over full-screen video, visualizations and slideshows; the auto-scroll chevrons will retain their default behavior
    • TBP= 1, bindNavHintsToToolbars = 1 - mouse toolbars and auto-scroll chevrons will always be visible, except when over full-screen video, visualizations and slideshows

    Note - in the cases above where it states that the mouse toolbars and/or auto-scroll chevrons will "always" be visible, there are a couple of global exceptions that you cannot override.  Mouse controls will never appear over the top of full-screen video, music visualizations or slideshows in Windows Media Center.

    As an example, the following screenshot demonstrates what the Windows Media Center Start menu will look like when setting TBP = 1 and bindNavHintsToToolbars = 1:

    Windows Media Center Start menu with mouse controls

     

  • Aaron Stebner's WebLog

    How to make Visual Studio 2005 ignore return codes from pre-build events

    • 8 Comments

    While working on some Windows Media Center development scenarios over this past weekend, I ran into an interesting scenario that I could not figure out how to accomplish in Visual Studio 2005 - I wanted to be able to run a pre-build event command line but have Visual Studio 2005 ignore the return code in case of failure.

    I searched around in the Visual Studio UI and in the MSDN documentation, but could not find a way to cause Visual Studio to continue if the pre-build event failed.  Eventually I found a way to do this, but I had to ask a friend of mine who works on the MSBuild team in Visual Studio.  Hopefully anyone else who searches for a way to do this will be able to find this post and figure it out more easily than I did.

    I started out by adding the pre-build event in the Visual Studio IDE by doing the following:

    1. Right-click on my project in the Solution Explorer window
    2. Choose Properties from the context menu
    3. Click on the Build Events tab in the property pages
    4. Add the command line in the Pre-build event command line text box

    When I built my project, if my pre-build event failed, it would report an error in the Task List and the build stopped at that point.

    What I found out from my friend is that the default syntax for the pre-build event is defined in %windir%\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets.  This is the file that defines all of the steps in the standard build process for .NET projects.  The syntax for the default pre-build event looks like the following:

    <Target
        Name="PreBuildEvent"
        Condition="'$(PreBuildEvent)'!=''"
        DependsOnTargets="$(PreBuildEventDependsOn)">
      <Exec WorkingDirectory="$(OutDir)" Command="$(PreBuildEvent)" />
    </Target>

    You will notice in the <Exec> command above that there is not any statement regarding return code processing.  That causes Visual Studio to always stop in the case of a non-zero return code from the command line that is executed as a pre-build step.

    There are a few options that I found that enabled Visual Studio 2005 to ignore errors in the pre-build event:

    Option 1 - Override the PreBuildEvent target in your project file using IgnoreExitCode

    In this option, you define your own customized version of the PreBuildEvent <Target> that will override the default version listed in Microsoft.Common.targets.  You can add the following to the end of your project file (such as a vbproj or csproj file):

    <Target
        Name="PreBuildEvent"
        Condition="'$(PreBuildEvent)'!=''"
        DependsOnTargets="$(PreBuildEventDependsOn)">
      <Exec WorkingDirectory="$(OutDir)" Command="$(PreBuildEvent)" IgnoreExitCode="true" />
    </Target>

    This <Target> section will cause the pre-build event to run if the command line is non-blank in the project file or in the Visual Studio IDE UI.  It will ignore the return code from the process and not report it back to you in the Task List, and the build will continue.

    If you choose this option, you will have to add the above <Target> section to each project file you want to ignore the pre-build event return code.

    Option 2 - Override the PreBuildEvent target in your project file using ContinueOnError

    In this option, you also define your own customized version of the PreBuildEvent target that will override the default version listed in Microsoft.Common.targets, but you use different return code processing logic than in option 1.  You can add the following to the end of your project file (such as a vbproj or csproj file):

    <Target
        Name="PreBuildEvent"
        Condition="'$(PreBuildEvent)'!=''"
        DependsOnTargets="$(PreBuildEventDependsOn)">
      <Exec WorkingDirectory="$(OutDir)" Command="$(PreBuildEvent)" ContinueOnError="true" />
    </Target>

    This <Target> section will cause the pre-build event to run if the command line is non-blank in the project file or in the Visual Studio IDE UI.  It will ignore the return code from the process, but it will report it back to you as a warning in the Task List.  The build will also continue even if any errors are encountered.

    If you choose this option, you will have to add the above <Target> section to each project file you want to ignore the pre-build event return code.

    Option 3 - Change the default PreBuildEvent target

    In this option, you directly modify %windir%\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets to add IgnoreExitCode="true" or ContinueOnError="true" to the PreBuildEvent <Target> section as shown above.

    If you choose this option, you will cause all .NET projects that you build in Visual Studio 2005 to ignore the pre-build event return code.

     

  • Aaron Stebner's WebLog

    How to configure post-build events for setup/deployment projects in Visual Studio 2005

    • 7 Comments

    While researching a previous blog post, I discovered a way to configure post-build events for setup/deployment projects in Visual Studio 2005.  I had not realized that previous versions of Visual Studio did not support configurable post-build events for setup projects, but Visual Studio 2005 does.  In addition, the way to access the UI needed to configure this setting for a setup project is different than for other project types in the Visual Studio 2005 IDE.

    The following steps can be used to add a post-build step to your setup/deployment project:

    1. Open or create a setup/deployment project in Visual Studio 2005
    2. Press F4 to display the Properties window
    3. Click on the name of your setup/deployment project in the Solution Explorer
    4. Click on the PostBuildEvent item in the Properties window to cause a button labeled "..." to appear
    5. Click on the "..." button to display the Post-build Event Command Line dialog
    6. Add a command line of your choice in the Post-build event command line text box
    7. Build your project in Visual Studio and verify that the post-build event is executed after the main MSI build

    You can also configure a pre-build event in a similar manner - there is also an item in the Properties window named PreBuildEvent.

    As I described in this previous blog post, it can be useful to run a script as a post-build event if you want to automatically modify the MSI that is built as a part of your project to include settings that are not available as part of the setup/deployment project options in the Visual Studio IDE UI.

     

  • Aaron Stebner's WebLog

    International Windows Media Center EPG error reporting sites

    • 6 Comments

    A while back, I posted a link to a site that allows you to submit problem reports for Windows Media Center television guide (EPG) data in the United States.  I recently found a list of similar sites that exist for some other locales that support EPG service for Windows Media Center.

    Here is a list of international sites that can be used to submit EPG problem reports:

    If you are in a locale not in the above list, there is not currently a site that allows you to submit EPG problem reports in your locale.  I apologize for the inconvenience.

     

  • Aaron Stebner's WebLog

    Adding custom tiles to built-in Windows Media Center Start menu strips

    • 5 Comments

    Last week, I posted some instructions explaining how to create custom strips on the Windows Media Center Start menu and populate the strips with tiles.  There is an additional way that you can customize the Start menu that I wanted to cover separately.

    There is a slot on each of the built-in Windows Media Center Start menu strips that you can add a single tile to by registering an application and entry point for a specific category.  The new tile will appear just to the left of the default selected tile in each relevant Windows Media Center Start menu strip.

    For example, the following sample XML file can be used with RegisterMceApp.exe to add a tile to the Windows Media Center Music strip:

    <application title="Custom Music Application" id="{PUT_GUID1_HERE}">
      <entrypoint id="{PUT_GUID2_HERE}"
                  addin="Microsoft.MediaCenter.Hosting.WebAddIn,Microsoft.MediaCenter"
                  title="Custom Music Entry Point"
                  description="Custom Music Entry Point Description"
                  context="
    http://play.mediacentersandbox.com/mcml/rc1/helix.mcml">
        <category category="Services\Audio"/>
      </entrypoint>
    </application>

    (note that you will need to use a tool such as guidgen.exe or a website such as this to replace the values of PUT_GUID1_HERE and PUT_GUID2_HERE in this example)

    Registering the above XML file on a Windows Vista system and launching Windows Media Center will show the following in the Start menu:

    Windows Media Center Start menu with custom music tile added

    The following table lists the categories that you can register an entry point for and what Start menu strip they will appear in within Windows Media Center:

    Category
    Start menu strip
    Services\Audio Music
    Services\Movies TV + Movies*
    Services\Pictures Pictures + Videos
    Services\TV TV + Movies*

    The TV + Movies strip is a special case because there are 2 distinct categories but only a single strip for the tile to appear in.  If you register an entry point in the TV category, it takes precedence over any entry point registered in the Movies category and will appear in the TV + Movies strip on the Start menu.  If you only have an entry point registered in the Movies category, then it will appear in the TV + Movies strip on the Start menu.

     

  • Aaron Stebner's WebLog

    Why not include the Visual Studio 2005 Express Editions in Windows Vista?

    • 5 Comments

    An interesting "philosophical" question was posed recently that I just noticed over this past weekend - why not include Visual Studio 2005 (such as the already free Express Editions) as a part of Windows Vista?  The idea was first suggested in this blog post at the end of June.  Then, last week, Dan Fernandez (the lead product manager for the Visual Studio Express product line) posted a response to the original suggestion on his blog.  Then, this blog exchange got picked up and published as an eWeek article.

    I wanted to talk a bit more about one of the bullet points that Dan posted in his blog response.  His 2nd bullet point reads as follows:

    Setup: Dropping bits on a CD is an easy task, but creating a way to service those bits (and every piece of the Windows OS is serviceable) is not straightforward. Without getting into the weeds of why this is, the short answer is that Windows have a wholly different setup (and therefore servicing model) than Visual Studio does. Servicing would basically be *way* too much work for the benefit. If, however, the setup/installer technologies were unified, this would be much easier.

    This is something that has proven challenging ever since we included the .NET Framework 1.1 as a part of the OS in Windows Server 2003.  As Dan stated in his post, the underlying installation engine for OS setup is not the same as the engine used to install applications.  Applications such as Visual Studio are packaged as MSIs and installed by Windows Installer.  As a result, MSP patches must be produced to patch those MSI setup packages and install hotfixes and service packs.  OS components are installed by the OS installation engine (sysocmgr and the OCM infrastructure in pre-Windows Vista system and a series of new technologies in Windows Vista).  They have their own requirements for creating hotfix and service pack packages that are different from the Windows Installer MSP format.

    Because of these differences, each time a product is released that packaged as both an MSI and an OS component, the teams have to create, test and release 2 separate patch packages.  In the case of the .NET Framework 1.1, there was significant work to create an additional hotfix package to target Windows Server 2003 in addition to the MSP that targets other operating systems.

    However, in the case of the Visual Studio Express Editions, that requires an even larger investment because there are 5 different Express Editions (Visual Basic, Visual C++, Visual C#, Visual J# and Visual Web Developer) and 9 different language versions.  That means that if the Express Editions were to be repackaged and included in Windows Vista OS setup, there would need to be 45 additional patch packages produced each time there is a hotfix or service pack that targets this product line.  Even with build and test automation and other economies of scale, that is an expensive proposition.

    In the future, I hope to see the OS installation engine and application installation engine converge so that a setup package can be authored once and installed and serviced the same way no matter what the installation vehicle is.  However, until something like that happens, this sort of complication makes it more difficult for setup developers and people who deploy software to architect agile solutions.

     

  • Aaron Stebner's WebLog

    Building and installing setup packages that require .NET Framework 1.1 on Windows Vista

    • 5 Comments

    I have run into this issue a couple of times recently while trying to install some of the currently available Windows Media Center applications and test them out on Windows Vista.  Many of the applications that are currently available were created with Update Rollup 2 for Windows XP Media Center 2005 as a target platform.  That means they were often built with Visual Studio .NET 2003 and the .NET Framework 1.1 and the setup was created using the VS 2003 setup/deployment project.

    The settings for the setup/deployment projects in VS 2003 include an option to add a .NET Framework launch condition.  You can add this launch condition by doing the following:

    1. Open/create a VS 2003 setup/deployment project
    2. Right-click on the project in the Solution Explorer and choose View, then Launch Conditions
    3. Right-click on the Requirements on Target Machine item and choose Add .NET Framework launch condition

    When you do this, your setup package will check for the existence of the .NET Framework 1.1 and block installation if it is not present.  This will likely cause confusion when users try to install this package on Windows Vista because Windows Vista already includes the .NET Framework 2.0 as part of the OS, and many users do not understand why they need to install an older version of the .NET Framework when a newer version is already present.

    If you would like to avoid this confusion, you can do the following in your VS 2003 setup/deployment project to allow it to install if the .NET Framework 2.0 is present on the system (even if the .NET Framework 1.1 is not):

    1. Open your VS 2003 setup/deployment project
    2. Right-click on the project in the Solution Explorer and choose View, then Launch Conditions
    3. Locate your .NET Framework launch condition, right-click on it and choose Properties Window
    4. In the Properties Window, set the SupportedRuntimes value to 1.1.4322;2.0.50727

    Note - you cannot use wildcards in the SupportedRuntimes value.  It must be set as listed in step 4 above to work as expected.

    It is also very important to note that if you decide to include the .NET Framework 2.0 in the list of SupportedRuntimes for your application that this implies some additional testing work on your part.  You need to make sure that you test your application in scenarios where it is installed on a computer that has the .NET Framework 2.0 but not the .NET Framework 1.1.  In general, this scenario should work fine, however there is a small set of functionality that will not work because a few breaking changes were made to the .NET Framework 2.0 APIs for things like security reasons.

    There are some good documents on the GotDotNet site with details about .NET Framework 2.0 breaking changes that will affect backwards compatibility:

    If you have code that is affected by any .NET Framework 2.0 breaking changes, you will need to enforce the .NET Framework 1.1 in your application setup and also include some config files or other means of binding your application so it will only use the .NET Framework 1.1 at runtime.

    If you do not have code affected by any .NET Framework 2.0 breaking changes, and your application setup currently checks for only the .NET Framework 1.1, I highly encourage you to try adding the 2.0.50727 SupportedRuntimes value and performing some application compatibility testing on systems that only have the .NET Framework 2.0.  This has the potential to offer customers a much smoother, less confusing installation scenario on Windows Vista.

     

  • Aaron Stebner's WebLog

    Checking for the .NET Framework at application runtime, not just at setup time

    • 4 Comments

    I posted some updated sample code last night that can be used to detect whether or not the various versions of the .NET Framework are installed on a system.  To go along with this sample code, I wanted to also mention a consideration that developers should keep in mind when building an application that relies upon the .NET Framework.

    It is common to see an application add code to their setup to check for the .NET Framework and install it as a prerequisite at setup time.  It is less common (at least in my experience) for an application to perform a runtime check in your application startup code to validate that the necessary version of the .NET Framework is installed.

    The .NET Framework can be independently uninstalled out from under your application if a user finds it and removes it in the Add/Remove Programs control panel.  I strongly recommend adding logic like I demonstrated in my sample code to your application's startup code paths.  Doing so makes your application more bulletproof and allows you to display more user friendly error messages with exact steps that users can follow to resolve issues related to the .NET Framework.

     

  • Aaron Stebner's WebLog

    Step-by-step instructions to create a Media Center application setup package in Visual Studio

    • 4 Comments

    Anthony Park has been working on a Windows Vista version of his MCEBrowser application.  As part of this process, he has posted a set of step-by-step instructions that can be used to create a setup package for a Windows Media Center hosted HTML application using Visual Studio.

    The techniques described in this blog post are roughly the same to what we will be documenting in the Windows Media Center SDK for Windows Vista.  If you are working on a Windows Media Center application, I encourage you to take a look at these instructions if you plan on using Visual Studio to create your setup package.

    One thing that Anthony does not mention is how to detect versions of the .NET Framework.  If you are planning to include .NET Framework version checking in your Visual Studio setup/deployment project, please take a look at this blog post for suggestions to make your setup package more flexible and support multiple versions of the .NET Framework.

    If you are developing Windows Media Center applications, I would also like to encourage you to take a look at the article I previously published that describes how to create a setup package for a Windows Media Center application using the WiX toolset.  There is a bit steeper learning curve to get started with WiX when compared to the Visual Studio setup/deployment project, but I find WiX much more powerful and easier to work with, plus it builds cleaner setup packages that can be more reliably serviced after they have been shipped.

     

  • Aaron Stebner's WebLog

    How to control the ordering of tiles in custom strips in Windows Media Center for Windows Vista

    • 3 Comments

    A couple of weeks ago, I posted an item describing how to add up to 2 custom strips to the Windows Media Center Start menu with up to 5 tiles each.  As I was working on the examples for that blog post, I noticed an annoying behavior - when creating a strip with multiple tiles, the tiles seemed to appear in a random order from left to right within the strip.

    After talking to a couple of developers and looking at some of the code, I found out that it is possible to control the order of the tiles in a custom strip, but it is non-intuitive to say the least.  To help folks combat this non-intuitiveness I'm going to post this blog post and this information will be included in a future build of the Windows Media Center SDK as well.

    The following registry value is used to sort the tiles based on the order in which they were installed, and then Windows Media Center selects the first 5 tiles that it finds based on the order that they were installed (from oldest to newest), and displays them as tiles in the custom strip on the Start menu:

    • Registry root: HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)
    • Key name: SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Extensibility\Categories\<custom category name>\<entry point GUID>
    • Value name: TimeStamp
    • Value data type: REG_DWORD
    • Value data: The number of seconds that have elapsed since midnight on January 1, 2000 C.E.

    The tricky part here is that if the TimeStamp value is the same for multiple entry points (tiles), then the sort order is indeterminate.  This is compounded by the fact that if you register your application using RegisterMceApp.exe or the RegisterApplication API, the TimeStamp values will nearly always be set to identical values because the operations that this EXE and API perform are fast enough to complete within a second.

    In order to control the exact order that tiles appear in a custom strip that you add to the start menu, you will need to modify the TimeStamp values to be unique and sequential so that the tile you want to appear on the far left has the smallest TimeStamp value and the tile you want to appear on the far right has the highest TimeStamp value.

    The easiest way I have found to accomplish this is the following:

    1. Register your application as usual
    2. Locate the ...\Extensibility\Categories\ sub-key for the <entry point GUID> that you want to appear on the far left in your custom strip
    3. Use that TimeStamp value in the registry as the baseline
    4. Locate the ...\Extensibility\Categories\ sub-key for the <entry point GUID> that you want to appear 2nd, and change the last digit of the TimeStamp value to be 1 higher than the baseline value defined in step 3
    5. Repeat step 4 for the remaining 3 <entry point GUID> TimeStamp values

    In order to demonstrate this concept, I have updated the Start menu customization example to include a registry file named TestApp1Ordered.reg.

    If you register TestApp1 as a custom strip using these instructions and then launch Windows Media Center, you will see the tiles listed in a non-sequential order.  If you then merge in TestApp1Ordered.reg to your registry and restart Windows Media Center, you will see the tiles displayed in sequential order from left to right. 

    If you look at TestApp1Ordered.reg in a text editor such as Notepad, you can see that I use the baseline value of DWORD:0c7e59da for Entry Point 1 and then increment this value by 1 for each subsequent entry point.

    Please note that I listed the HKEY_CURRENT_USER versions of the registry values in TestApp1Ordered.reg, so if you register the application for all users, you will need to update the syntax of TestApp1Ordered so that it works correctly.

    A couple of additional notes:

    • If you are planning to create an MSI package to install your Windows Media Center application (which I strongly recommend as a ship vehicle for your application!), then you can directly add TimeStamp registry values in sequential order in the Registry table of the MSI to control the placement of tiles in your custom strip.

    • If you register more than 5 entry points for a category and then add that category as a custom Start menu strip, Windows Media Center will only select the first 5 entry points to display as tiles in the custom strip.  Make sure that the 5 entry points that you want to appear have the 5 lowest TimeStamp values relative to the other entry points in the same category to ensure that they appear as you intend.

    • There are 2 locations where Windows Media Center creates TimeStamp registry values when you register applications.  For the purposes of ordering tiles on custom Start menu strips, make sure that you modify the TimeStamp values under ...\Extensibility\Categories and not the values under ...\Extensibility\Entry Points

     

  • Aaron Stebner's WebLog

    .NET Framework 3.0 (WinFX runtime) administrator mode and deployment readme

    • 2 Comments

    I previously posted an item describing the .NET Framework 3.0 (formerly known as the WinFX runtime components) deployment guide.  I noticed this morning that there is also a detailed administrator mode and deployment readme file for the .NET Framework 3.0.  This readme covers the following topics:

    If you are looking into deploying the .NET Framework 3.0 in a network setting, I encourage you to take a look at this readme as part of the deployment planning process.

     

  • Aaron Stebner's WebLog

    Mailbag: How to author an MSI that orders tiles in a custom strip in Windows Media Center

    • 2 Comments

    Question:

    I read your previous post about customizing the Windows Media Center Start menu in Windows Vista.  I would like to create an MSI that calls RegisterMceApp to register my application and also set the TimeStamp registry values to control the order of the tiles in my custom strip.  How can I accomplish this in an MSI?  Will I need to create a custom action to update the TimeStamp registry values (because they are created when I run RegisterMceApp)?

    Answer:

    You can use the InstallExecuteSequence table of the MSI to control the ordering of the actions to avoid needing a custom action to update the TimeStamp registry values.  The easiest way to accomplish this is to use something similar to the example that I posted in this article describing how to use WiX to build an MSI for a Media Center application.

    In the example WiX source file described in that article, the custom actions to run RegisterMceApp are sequenced to appear immediately after the InstallFiles action.  The only dependency that RegisterMceApp has is that the XML file it uses already be installed on the system, which will happen during the InstallFiles action.

    As a result of this sequencing logic, when you build your MSI and look at the InstallExecuteSequence table in Orca, you will see that the RegisterMceApp custom actions appears in between the InstallFiles action and the WriteRegistryValues action.  This will cause RegisterMceApp to create an initial set ofTimeStamp values.  Then you can override the initial TimeStamp values by creating alternate registry values in the Registry table of your MSI.

     

  • Aaron Stebner's WebLog

    Build 5536.16385 of the Windows Media Center SDK for Windows Vista is now available

    • 2 Comments

    We have posted the 5536.16385 build of the Windows Media Center SDK for Windows Vista on the Microsoft Connect site today.  I posted this item on the Media Center Sandbox blog with a list of some of the changes that you'll notice between the previous SDK build (5472.5) and this new build.  I encourage you to check out that post for more information, and if you're a member of the Windows Vista beta program, please download this new SDK build and let us know what you think.

     

  • Aaron Stebner's WebLog

    Adding HD DVD and Blu-ray movie playback in Windows Media Center for Windows Vista

    • 2 Comments

    I'm happy to welcome a new contributor to the Media Center Sandbox site - one of my colleagues Peter Dampier.  In his inaugural post, he introduces a new feature in Windows Media Center for Windows Vista that allows you to integrate an application to playback HD DVD or Blu-ray discs within Windows Media Center.

    Windows Media Center in Windows Vista does not natively support HD DVD or Blu-ray playback, but it is possible to easily integrate an application that does support these formats.  I encourage you to check out this blog post for more details about how to do this.

     

  • Aaron Stebner's WebLog

    Bug that blocks install of non-English Visual Studio 2005 on Windows Vista x64

    • 1 Comments

    A bug was discovered recently in the x64 .NET Framework 2.0 language pack setups.  This bug will cause attempts to install non-English, non-Japanese versions of Visual Studio 2005 on a non-matching language of x64 Windows Vista x64 to fail.  In other words, attempting to install the French Visual Studio 2005 on Windows Vista x64 English will fail (for example), but installing the French Visual Studio 2005 on Windows Vista x64 French will succeed.

    This bug will also cause the standalone x64 and ia64 .NET Framework 2.0 language packs (except for Japanese) to fail if you attempt to install them on a non-matching language version of x64 or ia64 Windows Vista.  If you try to install one of the affected language packs, you will get an incorrect message stating that this product cannot be installed because the files are already a part of the OS.

    Depending on how the setup package is implemented, this bug will likely also cause other products that include the x64 or ia64 .NET Framework 2.0 language packs (except for Japanese) to fail when installed on a non-matching x64 or ia64 Windows Vista OS language.

    How to workaround this issue

    If you are planning to install any non-English or non-Japanese edition of Visual Studio 2005 on any x64 build of Windows Vista where the OS language is not the same as the Visual Studio language, you can use the following steps to workaround this bug:

    1. Download this zip file and extract the registry file inside of it to your x64 Windows Vista system
    2. Right-click on the registry file and choose to add the contents to your registry
    3. When prompted for elevation, choose to allow the process to run
    4. After the registry values are added, re-run Visual Studio 2005 setup

    After applying this registry file, Visual Studio 2005 setup will react as though the .NET Framework 2.0 language pack is already installed and skip trying to install it, which will allow setup to succeed on your system.  You will be able to use Visual Studio 2005 and the IDE UI will be in the correct language, but there will be some error messages (such as compiler errors and warnings) that will not be able to be displayed in the Visual Studio language because the necessary .NET Framework 2.0 language pack files will not be installed.

    When and how this bug will be fixed

    This bug affects all publicly available builds of x64 and ia64 Windows Vista.  A fix will be put in place by the time Windows Vista ships, but I don't know exactly when yet.  Part of the fix will be to make Windows Vista OS setup write the registry values listed in the registry file that I listed in the workaround above.

    There is also some additional work that will need to be done as a part of this fix because this bug is a special case of a more general issue.  Currently, the .NET Framework 2.0 language pack binaries are installed by non-English builds of Windows Vista and by Windows Vista language packs.  Both of these are installed using the OS installation technology, whereas the redistributable versions of the .NET Framework 2.0 language packs are installed by Windows Installer MSI packages.  If we allowed mixing and matching of install technologies, that could potentially lead to servicing problems and end user confusion.

    I am going to provide more details about the fix in a separate future blog post once the exact fix is decided because it has the potential to impact non-English managed application deployment scenarios on Windows Vista.

    Explanation of the root cause

    There is some incorrect information in the install.ini file for all x64 and ia64 versions of the .NET Framework 2.0 language packs except for Japanese that causes this issue.  If you extract one of the langpack.exe files for a non-Japanese x64 or ia64 .NET Framework 2.0 language pack, you will see the following towards the top of the install.ini file in the package:

    ProductRegKey=SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727

    The bug is that this product registry key value should look like the following:

    ProductRegKey=SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727\LCID

    (where LCID is the 4-digit numerical value for the language in question - see this link for a complete list of these values)

    The effect of this bug is that the language pack setup looks for the existence of a registry value created by the core .NET Framework 2.0 package instead of one created by the .NET Framework language pack to decide whether or not to block because the product is already installed as a part of the OS.  All languages of Windows Vista will have the core .NET Framework 2.0 package installed, but not all of them will have the corresponding language version of the .NET Framework 2.0 language packs.

    This is complicated by the fact that Visual Studio 2005 setup uses the correct registry value (with LCID as a part of the key name) when deciding whether or not it needs to skip trying to install the language pack.  So you end up with a scenario where Visual Studio 2005 setup thinks it needs to install the language pack, but the language pack itself thinks it is already a part of the OS and returns error code 4123, which Visual Studio setup interprets as failure because it is not equal to 0 or 3010.

    The workaround listed above adds registry values that causes Visual Studio 2005 to not attempt to install the language packs.  It does not address the scenario where you try to run the .NET Framework 2.0 language pack setup directly.  If you really need to do that, you will have to open the langpack.exe package, update the line listed above in install.ini and then run install.exe.  However, the long-term fix for this issue will likely cause this workaround to not work as well so I would suggest avoiding doing this for now if possible.  I will post more information when I know more about the long-term fix.

    This problem only exists in install.ini for the x64 and ia64 versions of the .NET Framework 2.0 language packs, except for Japanese.  The reason that the Japanese language pack did not have this install.ini bug is that Japanese was the first non-English language that the Visual Studio team worked on for Visual Studio 2005 and the .NET Framework 2.0, and the processes used to create it were then used for the remaining languages.  This registry setting was added correctly for Japanese, but was not included in the template needed to correctly translate it into the other non-English languages.  As a result, the English information (the registry key name without the LCID value included as part of it) was left in each of the non-Japanese language packs.

     

  • Aaron Stebner's WebLog

    How to detect old versions when deploying the .NET Framework 3.0 (formerly WinFX)

    • 1 Comments

    I received an interesting question from a customer this weekend.  They are working on a setup package that will include the .NET Framework 3.0 (formerly the WinFX runtime components) as a prerequisite, and they wanted to automatically run the vs_uninst_winfx.exe cleanup tool to make sure that there were not any previous beta versions on the system that would cause setup to fail.  This cleanup tool does not have any silent switches, and it is only designed as an end user tool and not a redistributable setup component, so I advised the customer against including this.

    However, it is possible to implement logic in a setup wrapper to accomplish the underlying goal of ensuring that no previous beta versions are present on the system.  I previously outlined an algorithm to accomplish this for the .NET Framework 2.0, and a similar algorithm will also work for the .NET Framework 3.0.

    Here is an overview of the algorithm that .NET Framework 2.0 and 3.0 setup use to determine whether any previous beta products are on the system:

    For each (beta product code)
    {

    Call MsiQueryProductState to check if the install state for the product code equals INSTALLSTATE_DEFAULT

    if (install state == INSTALLSTATE_DEFAULT)
    {

    Call MsiGetProductInfo to retrieve the INSTALLPROPERTY_INSTALLEDPRODUCTNAME property for the product code
    Add the value of the INSTALLPROPERTY_INSTALLEDPRODUCTNAME property to the list of beta products that need to be uninstalled

    }

    }

    If (list of beta products is not empty)
    {

    If (setup is running in full UI mode)
    {

    Display UI with a list of product names that need to be uninstalled via Add/Remove Programs

    }

    Exit setup with return code 4113

    }

    The difference between the .NET Framework 2.0 and 3.0 is the location of the list of beta product codes.  You can find the beta product codes for the .NET Framework 3.0 by using these steps:

    1. Download the .NET Framework 3.0 web download bootstrapper and save it to your hard drive
    2. Extract the contents by running dotnetfx3setup.exe /x:c:\dotnetfx3
    3. Open the file c:\dotnetfx3\setup.sdb in a text editor such as notepad
    4. Look for the list of product codes in the [PrevProductIds] section of setup.sdb

     

  • Aaron Stebner's WebLog

    Using multiple MSIs to add a custom strip and tiles to the Windows Media Center Start menu

    • 1 Comments

    I have previously posted topics about creating custom strips on the Windows Media Center Start menu in Windows Vista and specifying an exact order for the tiles in a custom strip.  I have received additional questions about how to implement a more complicated solution - how to create multiple MSI installers to add/remove tiles in the same custom strip, and also allow the MSIs to be installed/uninstalled independently from each other and in any order.

    This scenario is a bit tricky to implement because of the following issues:

    • In order to separate the tiles into separate MSI installer packages, you must break them into distinct XML files that can be registered with RegisterMceApp.exe or the RegisterApplication API
    • You must choose a specific application GUID can be registered as a Windows Media Center Start menu strip, but if you break the tiles into separate XML files, they must each have a different application GUID that is registered

    In order to implement this solution and address the above issues, you can use the following algorithm:

    1. Create a "parent" application and register it
    2. Create registry entries (like the ones described here) to add this parent application to the Windows Media Center Start menu
    3. Create and register 2 or more "child" applications that contain entry points for each tile in the custom strip.  The child applications must both be registered for the category that is listed in the registry entries in step 2 or else they will not appear on the Start menu.
    4. Create MSI packages for each of the child applications.  You will need to include the parent application registration (step 1 above) and the registry entries (step 2 above) in all of your MSI packages in order to allow them to be installed in any order and still have the strip and tiles appear on the Windows Media Center Start menu

    I have posted a ZIP file that contains an example of how to create a parent application and 2 child applications that each register tiles on a custom strip on the Windows Media Center Start menu.  You can try out this scenario by using the following steps:

    1. Download the ZIP file and extract the contents to a Windows Vista Home Premium or Ultimate system
    2. Click on the Start menu, choose All Programs, then Accessories
    3. Right-click on Command Prompt and choose Run as administrator, then click Allow
    4. Run %windir%\ehome\registermceapp.exe TestApp_parent.xml to register the parent application
    5. Run regedit.exe /s TestApp.reg to add the parent application to the Windows Media Center Start menu
    6. Run %windir%\ehome\registermceapp.exe TestApp_divided1.xml to register the first child application and the first 2 entry points
    7. Run %windir%\ehome\registermceapp.exe TestApp_divided2.xml to register the second child application and the remaining 3 entry points

    After running the above steps, you can un-register the first or second child application, and the strip and tiles from the other child application will be left behind on the Windows Media Center Start menu.

    Note: You will see a dummy entry point listed in TestApp_parent.xml that is described as an "intentionally hidden" entry point.  This entry point is necessary because Windows Media Center will not display an application on the Start menu unless it has at least one entry point associated with it (even if that entry point is not actually designed to be shown on the Start menu).  In this case, we do not want this dummy entry point to not appear as a tile on the Start menu, so we register it with a category that is not listed in the registry file from step 5 above.  Even though the entry points in TestApp_divided1.xml and TestApp_divided2.xml are not associated with the parent application, they will still appear in the Start menu because they are members of the category that is listed in the registry file from step 5 above.

     

  • Aaron Stebner's WebLog

    Mailbag: Error codes for Document Explorer and J# redistributable package setups

    • 0 Comments

    Question:

    I am running into a problem while trying to install Document Explorer 2005 as part of my setup package.  In some cases, it fails with error code 4121 and rolls back.  I cannot find any information about this error code for Document Explorer setup.  What does it mean?

    Answer:

    The .NET Framework 2.0 setup uses an external UI handler, and that same UI handler is used by other setup packages that were shipped as a part of the Visual Studio 2005 family of products.  All setup packages that use this external UI handler will accept the same command line parameters and return the same return codes as the .NET Framework 2.0.

    The products that use this external UI handler and share the same command line parameters and return codes includes the following:

    • .NET Framework 2.0
    • .NET Framework 2.0 language packs
    • Document Explorer 2005
    • J# redistributable package
    • J# redistributable package language packs
    • Visual Studio Tools for Office runtime components

     

  • Aaron Stebner's WebLog

    Updated version of Yougle (formerly YouTubeMce) now available for download

    • 0 Comments

    I previously posted a description of a new add-in for Windows XP Media Center Edition 2005 called YouTubeMce.  It is a YouTube video browsing application for Media Center.  Since then, an updated version of the application has been released.  The name has been changed to Yougle because support has been added to browse videos from Google Videos in addition to the ones from YouTube.

    I tried out the new version at home this week, and I was happy to see that the page navigation issue that I previously mentioned has been fixed.  Now, when you navigate from a list of search results to an individual video and then press back, it returns you to the place where you left off in the search results list.  That way you do not need to remember the exact video you were just watching and scroll through the list over and over again.

    Hopefully, I can convince the authors to create an updated version of this cool application in Media Center Markup Language (MCML) for Windows Media Center for Windows Vista to take advantage of the new Media Center platform features and modern UI capabilities that are not available in hosted HTML applications.  :-)

     

  • Aaron Stebner's WebLog

    How to monitor progress and cancel .NET Framework 3.0 setup from a separate process

    • 0 Comments

    A white paper was published on the MSDN site today describing a new feature of .NET Framework 3.0 (formerly WinFX) setup - the ability of a 3rd party setup wrapper to register for progress messages and send cancellation requests when running setup in silent mode.  This is a feature that I have heard a lot of 3rd parties ask for in all previous versions of the .NET Framework, so it is really exciting to see that it has been implemented and is now ready for use in real deployment scenarios.

    In previous versions of the .NET Framework, if a developer wanted to run .NET Framework setup in silent mode, they did not have any way of tracking progress during installation or allow the user safely cancel .NET Framework setup.  This led to scenarios like the "fake" progress indicator that we implemented as part of Visual Studio setup to provide the semblance of progress to the user.

    The features described in this white paper allow a 3rd party setup package to register a callback function that can be used to listen for .NET Framework 3.0 setup progress messages.  This allows the other setup process to display a more accurate progress bar during download and installation when the .NET Framework 3.0 is launched in silent mode.  In addition, it allows the other setup process to request that the .NET Framework 3.0 setup cancel and rollback.

    If you are planning to include the .NET Framework 3.0 as a part of your setup package and launch it in silent mode, I strongly encourage you to take a look at this white paper and consider implementing a callback function to allow your setup to provide more accurate progress UI and cancellation UI to your users.

     

Page 1 of 2 (32 items) 12