Aaron Stebner's WebLog

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

July, 2006

  • Aaron Stebner's WebLog

    Registry tweak for mini-guide behavior in Windows Media Center for Windows Vista

    • 2 Comments

    I ran across a thread on one of the team discussion aliases today that described a registry tweak for Windows Media Center for Windows Vista that I wanted to pass on.  There is a new feature in Windows Media Center for Windows Vista called the mini-guide.  It is a small window that appears as an overlay while you are watching live TV and you can quickly browse details of other shows on other channels.  You can get to the mini-guide by pressing More Info on the remote control while live TV is playing and choosing the Mini Guide option in the context menu.

    By default, when you use the arrow buttons on the remote control to scroll through the mini-guide, it navigates channels in what feels like a non-intuitive way to me.  When you press the up arrow, the mini-guide browses to the previous channel and when you press the down arrow, the mini-guide browses to the next channel.  In other words, if you are on channel 5, pressing up moves you to channel 4, and pressing down moves you to channel 6.  This is the opposite scrolling order to the channel change buttons - pressing the channel up button moves you to channel 6 and pressing the channel down button moves you to channel 4.

    Fortunately, there is a registry value you can change to invert the mini-guide scrolling behavior to force it to scroll the same way that channel up/down scrolls.  Here are the steps you can use to toggle this behavior:

    1. Click on the Start menu, choose All Programs, then Accessories
    2. Right-click on Command Prompt and choose Run as administrator
    3. Click Allow to launch an administrator command prompt
    4. Run reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Settings\VideoSettings" /v ChannelBrowserArrowUpMeansChannelUp /t REG_DWORD /d 1 /f
    5. Close and re-open Windows Media Center for the change to take effect

    If you want to change the mini-guide scrolling behavior back to the default (which will make it scroll the opposite direction of channel up/down scrolling), you can 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
    3. Click Allow to launch an administrator command prompt
    4. Run reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Settings\VideoSettings" /v ChannelBrowserArrowUpMeansChannelUp /t REG_DWORD /d 0 /f
    5. Close and re-open Windows Media Center for the change to take effect

    Hopefully this will be something we add to a future version of TweakMce.

     

  • Aaron Stebner's WebLog

    2 interesting new Media Center add-ins - Flickr photo browser and YouTube browser

    • 0 Comments

    I had a chance to try out a couple of relatively new Windows Media Center applications this past week and I thought I'd pass on some information about them in case you want to check them out as well.

    Flickr photo browser

    A while back, I posted a link to an announcement describing an upcoming Flickr photo browser application for Windows Media Center.  At that time, the only thing available was the announcement, but there have been working beta versions released since then.  Dave had it installed on a test machine in his office running Windows Vista build 5472.5 last week and I got to see it in action and try it out.

    This Flickr photo browser is written as an XBAP, which means that it can be viewed within Windows Media Center for Windows Vista or within a web browser on Windows XP, Windows Server 2003 or Windows Vista.  The UI looks and feels similar to the new Windows Media Center UI in Windows Vista (dark blue color scheme, vertical and horizontal navigation, etc).

    You can download beta versions at this location if you're interested in trying it out.  In addition, there is an interview with the creator of the Flickr photo browser (Niall Ginsbourg) with Ian Dixon on the Media Center Show.

    YouTube browser

    A few people on the team mentioned a recently released YouTube browser for Windows Media Center, so I decided to install it and check it out.  It is a Hosted HTML application and works with Windows XP Media Center Edition (and should also work fine with Windows Vista).  You can download the YouTube browser at this location.

    I installed it on a Windows XP Media Center system and a Windows Vista system at work, and ran into some kind of corporate network firewall policy that blocked it from working correctly.  I still need to try to straighten that out, but in the meantime I tried it on my home system and it installed and is running fine.  It frustrated me a little bit for 2 main reasons:

    • The text entry for searching for videos - I have a Media Center keyboard, so it was tolerable, but with only a remote control this would be pretty painful.  In my opinion, text entry is an overall weakness for Media Center and this isn't the fault of this application
    • The page navigation model - when I select a video to view it and then press back to go back to the search results, it does not remember where I was, so I have to remember the name of the video I just watched and then scroll back down to view the next video

    Overall, this is a really nice application and I had some fun this weekend looking through some clips from some favorite TV shows.  I get even more excited thinking about how this application would be able to look and behave as a Windows Media Center Presentation Layer application for Windows Vista!

    <update date="8/1/2006"> Fixed incorrect link to YouTubeMce download page </update>

     

  • Aaron Stebner's WebLog

    Update Rollup 2 setup failure when installing KB903157 (also known as KB895572)

    • 8 Comments

    Over the past couple of weeks, I have heard from a few customers who have run into an issue installing Update Rollup 2 for Windows XP Media Center Edition 2005 that is related to Windows Media Player 11.  Since I have seen the same issue multiple times recently, I wanted to post it here in case anyone else runs into the same issue in the future.

    The customers who saw this issue visited Windows Update and attempted to install Update Rollup 2, but it failed and reported a generic "setup failed" message.  When I looked at their log files, they showed that one of the prerequisite packages for Update Rollup 2 (a Windows Media Player 10 hotfix described by KB895572 and KB903157) failed to install because a later version of Windows Media Player was already installed on the system.

    The interesting thing about this scenario is that Windows Media Player 11 setup checks for Update Rollup 2 as a prerequisite, so it is strange to see a scenario where Update Rollup 2 installation happens after Windows Media Player 11 has already been installed.  This could happen if you install Update Rollup 2, install Windows Media Player 11, uninstall Update Rollup 2 and attempt to reinstall Update Rollup 2.  It could also happen if you try to re-run Update Rollup 2 setup to attempt to repair it on a system that has Windows Media Player 11 installed.

    How can I workaround this issue?

    In the cases I have seen so far, uninstalling Windows Media Player 11 and then attempting to reinstall Update Rollup 2 has proven successful.  The following steps can be used to accomplish this:

    1. Click on the Start menu, choose Run, type appwiz.cpl and click OK to go to the Add or Remove Programs Control Panel
    2. Check the box labeled Show updates in the top middle of the Add or Remove Programs window
      Locate the item named Microsoft Windows Media Player 11 and choose to uninstall it
    3. Attempt to install Update Rollup 2 again by returning to Windows Update or running the setup package located here
    4. After successfully installing Update Rollup 2, re-install Windows Media Player 11

    How can I tell if this issue is the one affecting my system?

    You can diagnose this issue by looking at a couple of the log files that Update Rollup 2 setup creates.  First, you can open %windir%\mcsetup.log in a text editor such as Notepad.  If KB903157 (also known as KB895572) is the package that has failed on your system, you will see the following entry at the end of mcsetup.log:

    Generic Package:   07/26/06. 10:46:40
    Looking for existing install of the generic package
    Creating Process: WindowsMedia10-KB895572-x86.exe /quiet /norestart
    Process returned 0x00000643

    The 0x00000643 return code (which translates to 1603 in decimal) represents the return code for a generic error in a Windows hotfix package.

    Now, you can look at %windir%\kb903157.log to determine the exact reason why this hotfix failed to install.  In the cases I have seen so far, the error in kb903157.log looks like the following:

    0.312: KB903157 Setup encountered an error:  This software update can only be applied to Windows Media Player 10. If you have Windows Media Player 10 installed but still see this message, your version already includes this software update.

    <update date="1/15/2007"> Removed references to the Windows Media Player 11 beta.  This issue can affect systems that have the Windows Media Player final release in addition to any beta releases. </update>

     

  • Aaron Stebner's WebLog

    Post-beta 2 Windows Media Center development tips

    • 0 Comments

    We recently released a couple of post-beta 2 builds of the Windows Media Center SDK for Windows Vista.  Since then, I've posted some items on the Media Center Sandbox site with some tips and tricks for debugging Windows Media Center applications using post-beta 2 builds of Windows Vista.  I wanted to cross-link to those posts here in case folks didn't notice them on the Sandbox site.  Here are the topics I've written so far:

    More posts related to Windows Media Center development in Windows Vista are planned for the near future....stay tuned!

     

  • Aaron Stebner's WebLog

    New downloads for Windows XP Embedded - .NET Framework 2.0 component and resource documentation

    • 0 Comments

    There have been a couple of new items released in the past couple of weeks for Windows XP Embedded that I wanted to draw your attention to in case you missed them.

    .NET Framework 2.0 component for Windows XP Embedded SP2

    This is a new component that you can add to your XP Embedded SP2 database and runtimes to install the .NET Framework 2.0.  This version of the .NET Framework 2.0 is a true XP Embedded component and not just the same MSI-based installer that was previously released.  Depending on your scenario, you may choose to install this or the MSI component.

    Windows XP Embedded SP2 Resource Kit

    This is a collection of valuable documentation about various aspects of Windows XP Embedded development.  It includes the following items:

    • Windows XP Embedded SP2 overview and evaluation - introduction to Windows XP Embedded, what products are available, how XP Embedded differs from XP Professional
    • Windows XP Embedded SP2 development guide - how to use the XP Embedded tools to build, deploy and test XP Embedded runtime images
    • Embedded enabling features (EEFs) - this includes tons of detailed information about device update agent (DUA), enhanced write filter (EWF), El Torito and bootable CD-ROMs, CMI Explorer, and remote boot; I highly recommend looking at this document if you plan on using any EEFs in your runtime images
    • Windows XP Embedded SP2 troubleshooting guide - how to narrow down issues when your images don't build, boot or function like you would expect
    • Windows XP Embedded SP2 servicing guide - technical options for servicing existing runtime images, and how to approach choosing between the available technologies
    • Installing and Servicing .NET Framework in Windows XP Embedded Devices - behind-the-scenes look at how the .NET Framework Windows XP Embedded components are built and how to service them in runtime images.  This document was written during the process of creating the XP Embedded component for the .NET Framework 2.0 from the MSI-based .NET Framework 2.0 setup.  As a result, this document provides an in-depth look into .NET Framework setup in general and I recommend looking at it even if you are not an embedded developer but are curious about what the .NET Framework setup does behind the scenes
    • Windows XP Embedded SP2 component manifest - a spreadsheet listing each component in XP Embedded SP2, including a brief description of what the component is for, whether or not the component offers customizable settings in Target Designer, what macro component(s) the component is a member of, and any Windows service binaries that are a part of the component

     

  • Aaron Stebner's WebLog

    New hotfix available for Update Rollup 2 for Media Center 2005 - July 2006 rollup

    • 0 Comments

    Today is the monthly release of new hotfix packages and updates to Windows Update, and there is a new Media Center hotfix that has been released today that I want to draw your attention to:

    July 2006 Update Rollup for Windows XP Media Center Edition 2005 (KB919803)

    This package includes all previous hotfixes issued for Update Rollup 2 for Windows XP Media Center Edition 2005 and also addresses some other bugs that have not been fixed by previous hotfixes. 

    This package will be offered as a recommended update if you visit Windows Update, and you can also download it directly from this location

    This package includes the following fixes in addition to all previously released fixes.  There is more detail about each of these fixes in the knowledge base article for this hotfix:

    • Horizontal white lines appear when playing a DVD
    • Media Center may crash when using the ListMaker SDK sample application
    • Media Center may crash when you open a menu page
    • A black screen appears when trying to play a DVD

    Update Rollup 2 is a prerequisite for this package, and this package supercedes the April 2006 Update Rollup (KB914548), the January 2006 Update Rollup (KB912067) and Update Rollup KB908250.

     

  • Aaron Stebner's WebLog

    Mailbag: How to perform an unattended installation of Visual SourceSafe 2005

    • 0 Comments

    Question:

    I have seen your documentation related to deployment and unattended installation of Visual Studio 2005 and the .NET Framework 2.0.  I would like to also perform an unattended installation of Visual SourceSafe 2005.  How can I do that?

    Answer:

    Visual SourceSafe 2005 uses the same setup.exe wrapper and same installation logic as the Visual Studio 2005 family of products.  As a result, you can use the same techniques to deploy Visual SourceSafe 2005 or perform an unattended installation.  In particular, the following topics will probably be most useful to you:

     

  • Aaron Stebner's WebLog

    Mailbag: How to run .NET Framework setup in reduced UI mode

    • 0 Comments

    Question:

    Windows Installer has a reduced UI mode that can be invoked by running msiexec.exe /qr.  When I start the .NET Framework 1.0 or 1.1 in reduced UI mode by running dotnetfx.exe /q:a /c:"msiexec.exe /i netfx.msi /qr", I see UI that looks like the following:

    .NET Framework 1.1 setup in reduced UI mode

    However, when I use the same command line to run .NET Framework 2.0 setup in reduced UI mode, I see UI that looks like the following:

    .NET Framework 2.0 setup in reduced UI mode

    Why is there a difference?  How can I make .NET Framework 2.0 setup behave the same way as .NET Framework 1.0 and 1.1 setup do in reduced UI mode?

    Answer:

    The .NET Framework 1.0 and 1.1 use built-in Windows Installer setup UI dialogs.  The .NET Framework 2.0 uses an external UI handler, and as a result, it does not have any Windows Installer UI authored into its MSI.

    According to the MSDN documentation, reduced UI mode causes Windows Installer to display any modeless dialog boxes and error dialog boxes that have been authored into the UI.

    Because .NET Framework 1.0 and 1.1 setup use built-in Windows Installer setup UI, running setup in reduced UI mode displays the same (modeless) progress dialog that appears during full UI mode.  Because the .NET Framework 2.0 does not have any Windows Installer UI, running setup in reduced UI mode causes Windows Installer to fall back to using built-in modeless dialog boxes and error dialog boxes (which is the equivalent of basic UI mode).

    Unfortunately, there is not any way to cause the .NET Framework 2.0 setup to display more detailed progress UI like the .NET Framework 1.0 and 1.1 setups do.

    Note that there is a bug in Windows Installer that causes the progress dialog to appear with no text during .NET Framework 2.0 setup in reduced and basic UI scenarios (like in the above screenshot).  This blog post describes that scenario in more detail, and it includes a workaround you can use to cause explanatory progress text to appear during installation.

     

  • Aaron Stebner's WebLog

    Troubleshooting problems while installing .NET Framework 2.0 hotfix MS06-033 (KB 917283)

    • 6 Comments

    Microsoft recently released a hotfix to address a vulnerability in ASP.NET for the .NET Framework 2.0.  Security bulletin MS06-033 contains more details about this hotfix.

    This is one of the first hotfixes that has been released for the .NET Framework 2.0 (possibly the first, but I'm not sure).  There have been some issues that we've seen with the installation of this hotfix, and as a result the following knowledge base articles have been published:

    The set of steps that I typically use when a .NET Framework hotfix fails is not listed in any of the above knowledge base articles, so I thought I'd list them here in case they are useful to anyone out there:

    1. Click on the Start menu, choose Run, type appwiz.cpl and click OK
    2. Locate the item named Microsoft .NET Framework 2.0 (the name will contain x64 or ia64 on 64-bit operating systems) and click the Change/Remove button
    3. Choose the Repair option to attempt to repair/reinstall the .NET Framework 2.0
    4. Download and attempt to install the .NET Framework hotfix by running the setup package directly instead of using Windows Update.  Running it directly will allow the service pack setup to display more useful error dialogs instead of having Windows Update suppress them

    If repairing the .NET Framework 2.0 does not solve this issue, then I would suggest trying the following steps as a last resort:

    1. Download the .NET Framework cleanup tool and choose to cleanup the .NET Framework 2.0
    2. Download and re-install the .NET Framework 2.0
    3. Download and attempt to install the .NET Framework hotfix by running the setup package directly instead of using Windows Update.  Running it directly will allow the service pack setup to display more useful error dialogs instead of having Windows Update suppress them

    <update date="7/22/2006"> Updated workaround steps to suggest repairing the .NET Framework 2.0 before resorting to uninstalling and reinstalling it </update>

     

  • Aaron Stebner's WebLog

    Repairing the Windows Installer service on a 64-bit OS

    • 49 Comments

    A customer recently contacted me due to a problem they were experiencing while trying to install the .NET Framework 2.0 on the x64 version of Windows Server 2003.  I took a look at the verbose log file for this scenario and saw the following error:

    Action start 9:16:59: CA_InstallAssembly.3643236F_FC70_11D3_A536_0090278A1BB8.
    MSI (s) (B0:F8) [09:17:03:906]: Product: Microsoft .NET Framework 2.0 (x64) -- Error 1719.The Windows Installer Service could not be accessed. This can occur if you are running Windows in safe mode, or if the Windows Installer is not correctly installed. Contact your support personnel for assistance.

    Usually when I see error 1719, I recommend that the user try to repair the Windows Installer service.  However, in this case, that didn't seem to help, and I had to refer this customer to the Microsoft technical support team for further assistance.

    Our technical support team looked at this scenario in more detail and found that there was an additional set of steps needed to repair the Windows Installer service on a 64-bit OS.

    Here is a complete set of steps that should allow you to repair the Windows Installer service on a 64-bit OS:

    1. Click on the Start menu, choose Run, type cmd and click OK
    2. Run %windir%\system32\msiexec.exe /unregister
    3. Run %windir%\syswow64\msiexec.exe /unregister
    4. Run %windir%\system32\msiexec.exe /regserver
    5. Run %windir%\syswow64\msiexec.exe /regserver
    6. Restart the computer

    After executing all of the above steps, you can try to re-run the failing setup and hopefully get better results.

    Note that this workaround is documented in this knowledge base article, but the extra steps that are needed on 64-bit operating systems are somewhat buried in the middle of that article and can be easy to miss.

     

  • Aaron Stebner's WebLog

    Creating an installable layout for Visual Studio 2005 Express Editions with SQL Express SP1

    • 0 Comments

    I previously posted an article describing how to download and create an installable network layout of the Visual Studio 2005 Express Editions.  The instructions in my blog article describe how to download the version of SQL Express that originally shipped with the Express Editions.  However, there has been a new version of SQL Express shipped since then - SQL Express 2005 Service Pack 1.

    A customer recently found that article and asked me if it is possible to swap out SQL Express 2005 SP1 in the instructions for creating an installable layout.  The problem that the customer observed is that there is only a single version of SQL Express SP1 (named sqlexpr.exe) available for public download, but the intructions in my blog article list a version named sqlexpr32.exe for 32-bit Express Edition install scenarios.

    I asked around about the different versions of SQL Express, and it turns out that sqlexpr.exe is a superset package that contains both 32-bit and 64-bit binaries.  The Visual Studio and SQL teams decided to create a separate 32-bit-only version named sqlexpr32.exe in order to reduce download size and time for what is likely to be the most common scenario - installing a Visual Studio 2005 Express Edition on a 32-bit OS.

    If you would like to create an installable Visual Studio 2005 Express Edition layout with SQL Express 2005 SP1 instead of the original version of SQL Express, you can use the following instructions in place of the SQL Express instructions listed in my previous blog article:

    SQL Server Express (x86)

    1. Make a new folder named c:\visual_webdev\wcu\SSE
    2. Navigate to the URL http://go.microsoft.com/fwlink/?LinkId=65212 and choose to save the file sqlexpr.exe to the folder c:\visual_webdev\wcu\SSE
    3. Go to the folder c:\visual_webdev\wcu\SSE and rename sqlexpr.exe to sqlexpr32.exe to match the name that setup expects the file to have

    SQL Server Express (x64)

    1. Make a new folder named c:\visual_webdev\wcu\SSE
    2. Navigate to the URL http://go.microsoft.com/fwlink/?LinkId=65212 and choose to save the file sqlexpr.exe to the folder c:\visual_webdev\wcu\SSE

     

  • Aaron Stebner's WebLog

    5472.5 and 5456.5 builds of the Windows Media Center SDK are now available

    • 12 Comments

    I posted an item on the Media Center Sandbox site earlier today that I wanted to make sure everyone sees, so I wanted to link to it here as well.  We've released 2 new builds of the Windows Media Center SDK (builds 5456.5 and 5472.5) on the Microsoft Connect site.  These SDK builds are designed to work with Windows Vista builds 5456.5 and 5472.5, which have previously been released on the Microsoft Connect site as well.  Members of the Windows Vista beta program should have access to these builds of Windows Vista and the Windows Media Center SDK.

    There is a description of some of the key changes in these new SDK builds on the Sandbox post.  Please let us know what you think about these new builds of the Windows Media Center SDK by reporting bugs and suggestions and posting comments on the Media Center development forum.

     

  • Aaron Stebner's WebLog

    Mailbag: What is the complete list of valid language codes for Visual Studio IDE language switching?

    • 0 Comments

    Question:

    I saw your blog post demonstrating how to enable Visual Studio IDE language switching.  That post uses examples of French and English language versions of Visual Studio.  I would like to know what the language codes are for other Visual Studio languages so I can enable IDE language switching via the /LCID command line parameter for other Visual Studio languages.

    Answer:

    The following list represents the LCID values for the available versions of Visual Studio:

    • 1028 - Chinese (Traditional)
    • 1031 - German
    • 1033 - English
    • 1036 - French
    • 1040 - Italian
    • 1041 - Japanese
    • 1042 - Korean
    • 2052 - Chinese (Simplified)
    • 3082 - Spanish

    Each of the above numerical values can be used as a parameter for the /LCID switch for the Visual Studio IDE.

     

  • Aaron Stebner's WebLog

    Using custom actions versus using launch conditions in an MSI

    • 4 Comments

    I ran into an interesting issue when I was working on some of the very early builds of the Windows Media Center SDK for Windows Vista.  A customer reported that they tried to install the SDK on Windows Vista and it blocked them and reported an error stating that the product could not be installed because it requires the .NET Framework 2.0.  This error message was particularly confusing because the .NET Framework 2.0 is included as part of the OS on Windows Vista, so there is no way for it to not be present in this customer's scenario.

    When I investigated this issue in more detail, I found that the user was trying to install the SDK when logged in as a normal user (as opposed to a user that was a member of the Administrators group on the computer).  That was the first clue that led to figuring out the root cause of the inaccurate error message.

    In early builds, the SDK setup contained 2 entries in the LaunchCondition table:

    1. A check for the Privileged property to validate that the user running setup has administrative privileges
    2. A check of the .NET Framework 2.0 detection registry hive to verify that the .NET Framework 2.0 is installed on the system

    The problem in this scenario was that the launch condition to check for the .NET Framework 2.0 was running before the check for administrative privileges.  Because that check needed to access a registry value under HKEY_LOCAL_MACHINE, it failed if the user running setup did not have administrative privileges, and setup would block with an error stating that the .NET Framework 2.0 was not installed.  It never got the chance to check for administrative privileges.

    I did some research and asked some friends I know who have worked with Windows Installer pretty extensively, and I found that there are not any reliable ways to control the order in which the entries in the LaunchCondition table of the MSI are executed.  Because of this, many setups choose to use custom actions to validate prerequisites instead of launch conditions.

    In the end, I solved this issue by creating a type 19 custom action to check for the presence of the .NET Framework 2.0.  By using a custom action instead of a launch condition, I was able to control the exact execution order by placing it in the desired sequential order in the InstallUISequence and InstallExecuteSequence tables of the MSI.

    You can see an example of how to use this prerequisite checking strategy with an MSI built with the WiX toolset in this example WXS file I previously posted about the .NET Framework 2.0 configuration tool.

     

  • Aaron Stebner's WebLog

    Mailbag: What version of the .NET Framework can be used with what version of Visual Studio?

    • 0 Comments

    Question:

    I have the .NET Framework 2.0 installed.  Can I make Visual Studio .NET 2002 work with it instead of with the .NET Framework 1.1?  What about Visual Studio .NET 2003?

    Answer:

    Versions 1.0, 1.1 and 2.0 of the .NET Framework each shipped with a specific version of Visual Studio, and it is installed as a prerequisite during Visual Studio setup.

    A managed application is capable of running on the version of the .NET Framework that it was originally written against.  In addition, in most cases, it will run correctly even if only one of the future versions of the .NET Framework is installed on the system.

    Visual Studio is somewhat of a special case though, because it is a development tool.  Each version of Visual Studio listed above will only work correctly with the exact version of the .NET Framework that shipped with it as a prerequisite.

    In some cases, you can use Visual Studio to build managed applications that will run against earlier versions of the .NET Framework.  The MSBee tool (which can be downloaded here) is a plug-in for MSBuild that will allow you to build applications in Visual Studio 2005 that can run on the .NET Framework 1.1, assuming that you do not use any features that are new in the .NET Framework 2.0 and don't exist in .NET 1.1.  Also, there is a configurable setting in Visual Studio .NET 2003 that lets you add settings to your application config file to allow it to run on the .NET Framework 1.0.

     

  • Aaron Stebner's WebLog

    List of Microsoft Knowledge Base articles related to installing and using an Xbox 360 Media Center extender

    • 7 Comments

    I have posted a few items related to issues I've seen with Xbox 360 PC setup.  Ever since I did, I've gotten several customers asking other questions about configuring an Xbox 360 as a Windows Media Center extender that I have not known the answer to.

    I asked a colleague for some advice yesterday and received back a list of official Microsoft knowledge base atricles that have been published about various Xbox 360 Media Center extender issues.  I hadn't realized that so many articles had been published, and I don't think they appear in some of the web searches that customers have been doing (based on some analysis I did on the referral statistics for my blog posts).  Therefore, I wanted to post a list of knowledge base articles here in the hopes of making them easier to discover via search engines for customers who need help configuring and using their Xbox 360s as Windows Media Center extenders in the future.

    Most commonly used Media Center troubleshooting articles

    Articles about Media Center Extender for Xbox 360 setup

    Articles about using Media Center on Xbox 360

    <update date="7/15/2006"> Added links to Windows Live OneCare help articles </update>

     

  • Aaron Stebner's WebLog

    A note about the logging switch in .NET Framework 2.0 setup

    • 1 Comments

    I previously posted a couple of blog items (here and here) where I mentioned the verbose logging command line switch for .NET Framework 2.0 setup.  I heard from a friend of mine last week who was trying to run .NET Framework 2.0 setup using the same command line that he previously used for .NET Framework 1.1 setup but did not see a verbose log produced at all on his system, and asked me why.

    After looking at this in more detail, I found a subtle difference in the command line switch parsing code for the .NET Framework setup in version 2.0 that I had not noticed until I heard about this scenario.

    The command line to run the .NET Framework 1.1 setup in silent mode with verbose logging enabled is the following:

    dotnetfx.exe /q:a /c:"install.exe /l /q"

    This command line will cause a verbose log named %temp%\netfx.log to be created during installation. 

    In the .NET Framework 2.0, verbose logging is enabled by default, so you do not need to pass any extra command line switches during setup.  As a result of this change, the code was changed so that the /l switch will only work correctly when you also pass a log file name immediately after it.  When my friend tried to run .NET Framework 2.0 setup with the command line dotnetfx.exe /q:a /c:"install.exe /l /q" setup tried to create a log with the name /q, and that is not a valid file name so setup ended up not creating a verbose log at all.

    This means that you can use the following command line to install the .NET Framework 2.0 in silent mode with verbose logging enabled:

    dotnetfx.exe /q:a /c:"install.exe /q"

    -or-

    dotnetfx.exe /q:a /c:"install.exe /l %temp%\mynon-defaultlog.txt /q"

    I've updated the above linked blog posts to reflect this, and I apologize for any inconvenience I may have caused based on the original content of those blog posts.

     

  • Aaron Stebner's WebLog

    Eliminating redundant pre-installation checks when deploying the .NET Framework 2.0

    • 0 Comments

    A few days ago, I wrote a blog entry describing the prerequisites for the .NET Framework 2.0 and how to detect them if you are deploying or redistributing .NET 2.0 with your setup package.  There are a couple of shortcuts you can take when checking for some of these prerequisites, depending on what operating system versions and service packs your scenario requires.

    Windows Installer 3.0

    This version of Windows Installer is included with Windows XP SP2.  In addition, a higher version of Windows Installer is included with Windows Server 2003 SP1.

    If your application only supports one of the above OS platforms or if you are going to deploy the .NET Framework 2.0 on a network that only includes the above OS platforms, you do not need to perform an additional check for Windows Installer.

    Internet Explorer 5.01

    This version of Internet Explorer is included with Windows 2000 SP4.  In addition, higher versions of Internet Explorer are included with Windows XP, Windows Server 2003 and Windows Vista.

    If your application only supports one of the above OS platforms or if you are going to deploy the .NET Framework 2.0 on a network that only includes the above OS platforms, you do not need to perform an additional check for Internet Explorer.

     

  • Aaron Stebner's WebLog

    How an add-in setup package should detect the version of Media Center

    • 2 Comments

    I was recently looking at an application compatibility bug reported by a Windows Vista beta program customer.  The bug stated that one particular Windows Media Center application refused to install on Windows Vista because it reported that Windows Media Center was not installed.  Windows Media Center is a part of Windows Vista Home Premium and Ultimate editions, so the error message in this setup package was incorrect.

    After further investigation, we found that the application setup was looking at the following registry value to determine whether or not the OS contained Windows Media Center:

    • Key name: HKEY_LOCAL_MACHINE\SYSTEM\WPA\MediaCenter
    • Registry value name: Installed
    • Registry value data type: REG_DWORD
    • Registry value data: 1

    This particular registry value is a Windows product activation registry value that is specific to Windows XP, and it does not exist on Windows Vista at all.  In addition, it was not documented as an official means of detecting whether or not Windows Media Center is present on the OS.  Therefore using the above registry value to decide whether or not to allow installation of a Windows Media Center application is incorrect and should not be used.

    Unfortunately, it does not look like we documented any official way that Windows Media Center application setup packages should use to detect the presence/absence or exact version of Windows Media Center installed on a system.

    Here is the information about the registry key that we designed specifically to contain this version information.  This key is used by Windows Media Center hotfixes to detect the exact version, and this key exists on both Windows XP Media Center Edition and Windows Vista:

    • Key name: HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\Media Center
    • Registry value name: Ident
    • Registry value data type: REG_SZ

    The Ident value will contain the following data depending on what version of Windows Media Center is present on the system:

    • Windows Media Center 2002 - Ident values less than 2.7
    • Windows Media Center 2004 - Ident values 2.7 and 2.8
    • Windows Media Center 2005 - Ident value 3.0
    • Windows Media Center 2005 with Update Rollup 1 - Ident value 3.1
    • Windows Media Center 2005 with Update Rollup 2 - Ident value 4.0
    • Windows Media Center for Windows Vista - Ident value 5.0

    If you are creating a setup package for a Windows Media Center application, you should detect the presence of Windows Media Center before allowing installation of your application.  Checking for the existence of the Ident value described above (regardless of the exact value string that it contains) will achieve that.

    In addition, if your application has a dependency on a specific version of Windows Media Center, your setup package should also detect the presence of that specific version and block installation if it is not installed.

    Additional information related to Windows Media Center hosted HTML applications can be found in the Windows Media Center SDK topic entitled Identifying Media Center from an HTML Page.

     

  • Aaron Stebner's WebLog

    Beta version of Feature Pack 2007 for Windows XP Embedded is now available

    • 0 Comments

    I wanted to pass on some exciting news that was posted this morning on the Windows Embedded team blog - there is a beta version of Feature Pack 2007 for Windows XP Embedded available for download.

    Andy Allred posted this blog item with more details.  There are several improvements included in Feature Pack 2007:

    • Ability to boot from a USB drive
    • New embedded enabling features (EEFs) such as a file-based write filter and a registry filter
    • Tools enhancements including support for scripting XP Embedded image build processes
    • Component refactoring for reduced image footprint
    • New macro components to make image configuration faster and more reliable
    • All previously released XP Embedded SP2 security hotfixes
    • Other bug fixes in the tools

    In addition, the blog post contains instructions for how to enroll and participate in the beta program so you can download the bits.

    If you are an XP Embedded developer or system builder, I strongly encourage you to check out the beta version of Feature Pack 2007 and provide feedback to the Windows Embedded team.

     

  • Aaron Stebner's WebLog

    Pre-installation checks performed by .NET Framework 2.0 setup

    • 12 Comments

    The setup wrapper for the .NET Framework 2.0 performs several system and prerequisite checks before it allows the user to start installing.  This blog post will explain the implementation details of each of the checks that .NET Framework 2.0 setup performs behind the scenes so that you can implement your own checks or enforce higher prerequisite levels if necessary.

    If you are planning to deploy the .NET Framework 2.0 to your network or include it as a prerequisite in your setup package, it is very important that you understand what these checks do so that you can verify that the computers on your network will meet the minimum system requirements and deployment will be able to proceed correctly.

    In addition, if you are planning to install the .NET Framework 2.0 in silent mode as a part of your installation package, you must be able to check for these conditions yourself or be able to handle cases where these conditions are not met and .NET Framework 2.0 setup fails as a result.

    Single instance of setup check

    .NET Framework 2.0 setup attempts to acquire a mutex at the beginning of execution.  If it is already owned by another process, it exits and tells the user that another instance of setup is already running.

    Administrative privileges check

    .NET Framework 2.0 setup uses the algorithm documented in this knowledge base article to check whether or not the setup process has the necessary administrative privileges.

    OS version check

    .NET Framework 2.0 setup first calls the GetVersionEx API.  If the dwPlatformId member of the returned OSVERSIONINFO structure equals VER_PLATFORM_WIN32_WINDOWS, then the OS version is Windows 9x and the OS version check is done.

    If dwPlatformId equals VER_PLATFORM_WIN32_NT, then setup checks the dwMajorVersion and dwMinorVersion members of the returned OSVERSIONINFO structure.

    If dwMajorVersion < 5, then setup blocks installation because Windows NT 4.0 and earlier versions of Windows NT are not supported platforms for installing the .NET Framework 2.0.

    If dwMajorVersion is greater than or equal to 5, then the OS is a valid OS to install the .NET Framework 2.0, and the following logic is used to determine exact OS version:

    • Windows 2000: if dwMajorVersion = 5 and dwMinorVersion = 0
    • Windows XP: if dwMajorVersion = 5 and dwMinorVersion = 1
    • Windows Server 2003: if dwMajorVersion = 5 and dwMinorVersion = 2

    64-bit OS check

    The .NET Framework 2.0 shipped both as 32-bit and 64-bit packages.  Setup requires that the version of the .NET Framework 2.0 that matches the current processor architecture be installed, and attempting to install mismatched versions will be blocked.

    The 32-bit version of .NET Framework 2.0 setup blocks the user from installing on a 64-bit OS.  It does this by checking to see if the current setup process is running in the WOW64 layer.  To do this, .NET Framework 2.0 setup attempts to locate the GetSystemWow64Directory API.  If this API exists on the system and it returns a valid path, then setup reports that the system is a 64-bit OS and the current instance of setup is a 32-bit process running in the WOW64 layer, and it blocks the user from installing.

    The 64-bit version of .NET Framework 2.0 setup will not run on a 32-bit OS.  There is not a specific block implemented in setup for this.  Instead, setup will display a generic error just like all 64-bit executables do when they are launched on a 32-bit OS.  It could be one of the following:

    • If setup is launched from the self-extracting EXE: Error creating process <C:\DOCUME~1\username\LOCALS~1\Temp\IXP000.TMP\Install.exe>.  Reason: C:\WINDOWS\system32\advpack.dll
    • If setup is launched by running install.exe directly: install.exe is not a valid Win32 application.
    • If setup is launched by running msiexec.exe /i netfx.msi: This installation package is not supported by this processor type. Contact your product vendor.

    Check to see if the .NET Framework 2.0 was installed as part of the OS

    .NET Framework 2.0 setup checks to see if it is being run on an OS that already has the .NET Frameowork 2.0 installed as part of the OS.  To do this, it checks the following registry value:

    • Key name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727
    • Value name: OCM
    • Value data type: REG_DWORD
    • Value data: 1

    Currently, the only OS that includes the .NET Framework 2.0 is Windows Vista.  However, that could change in the future, so the safest way to detect whether the .NET Framework 2.0 is installed as an OS component is to check the above registry value as opposed to trying to detect the OS version.

    Microsoft Internet Explorer 5.01 version check

    .NET Framework 2.0 setup verifies that the version of Internet Explorer installed on the system is at least version 5.01.  To do this, it checks the following registry value:

    • Key name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer
    • Value name: Version
    • Value data type: REG_SZ
    • Value data: greater than or equal to 5.0.2919.6307

    Note that this check requires splitting the Version registry value into 4 different parts by splitting on the period and comparing each part of the version against the minimum values 5, 0, 2919 and 6307.  A simple string comparison will not work because, for example, version 2.0.0.0 would be greather than 10.0.0.0 when using a string comparison.

    Windows Installer version check

    .NET Framework 2.0 setup validates the Windows Installer version installed on the system.  To do this, it first determines the location of msi.dll by checking the following registry value:

    • Key name: HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\ Installer
    • Value name: InstallerLocation
    • Value data type: REG_SZ

    The InstallerLocation value will contain a folder path.  .NET Framework 2.0 setup then appends msi.dll to the value of the InstallerLocation value, and loads and attempts to call the DllGetVersion API in msi.dll.  If that API returns success, setup checks for the following return values:

    • If the OS is Windows 9x: dwMajorVersion is greater than or equal to 2 and dwMinorVersion is greater than or equal to 0
    • If the OS is Windows 2000 or later: dwMajorVersion is greater than or equal to 3 and dwMinorVersion is greater than or equal to 0

    Note that while the initial .NET Framework 2.0 setup only checks for Windows Installer 3.0 or later on Windows 2000 and later, hotfixes and service packs for the .NET Framework 2.0 will require Windows Installer 3.1 or later in order to install correctly.  As a best practice, your setup should enforce that Windows Installer 3.1 is present as well.

    Previous beta product check

    .NET Framework 2.0 setup uses the algorithm in this blog post to check for previous beta products that are installed on the system.

    .NET Framework 2.0 already installed check

    In order to determine whether or not to enter maintenance (repair/uninstall) mode or not, .NET Framework 2.0 setup checks to see if the .NET Framework 2.0 MSI is already installed on the system.  It retrieves the product code for netfx.msi, then calls the MsiQueryProductState API and passes in this product code.  If MsiQueryProductState returns INSTALLSTATE_DEFAULT, then setup enters maintenance mode.  Otherwise, setup enters initial install mode.

     

  • Aaron Stebner's WebLog

    Windows Installer best practices

    • 1 Comments

    I recently noticed a series of in-depth articles that have been posted on the Windows Installer team blog, and I wanted to link to them here as well to try to increase visiblity for them.  These articles are nicknamed the Tao of Windows Installer, and are intended to be a set of best practices for creating, deploying, servicing and maintaining Windows Installer-based setup packages.

    Here is a list of links to the individual topics that have been posted:

    I strongly encourage anyone working in the setup and deployment space to take a look at these.  I've been working with Windows Installer for years now and even with that background I found interesting things that I didn't know or hadn't thought of in these articles.

     

  • Aaron Stebner's WebLog

    How to fix .NET Framework 1.1 setup failure on Windows Vista build 5456

    • 19 Comments

    Important note: The issue described in this blog post only affects pre-RC1 builds of Windows Vista.  If you are running Windows Vista RTM and have problems installing the .NET Framework, do not try this workaround because it does not apply to the RTM build and will not help.  Please see http://blogs.msdn.com/astebner/articles/454956.aspx instead of this blog post if you have problems installing the .NET Framework 1.1 on Windows Vista RTM.....

    The .NET Framework setup team recently discovered a compatibility bug that will prevent the .NET Framework 1.1 from installing on the most recent build of Windows Vista that was released to the Windows Vista beta program members (build 5456). 

    The underlying problem is that one of the type libraries registered by .NET Framework 1.1 setup is attempting to write to a registry sub-key that is incorrectly marked read-only in this build of Windows Vista.  In order to workaround this issue, you will need to change owners and modify permissions on a registry sub-key on your system.

    You can perform the following steps before installing the .NET Framework 1.1 to workaround this issue on Windows Vista build 5456:

    1. Click on the Start menu, choose All Programs, then Accessories
    2. Right-click on Command Prompt and choose Run as administrator
    3. From the command prompt, type regedit
    4. Navigate to HKEY_LOCAL_MACHINE and then Software\Classes\Interface\{65074F7F-63C0-304E-AF0A-D51741CB4A8D}\TypeLib
    5. Right-click on the TypeLib sub-key and choose Permissions
    6. Click the Advanced button
    7. Click on the Owner tab
    8. Select the Administrators group in the Change owner to: list and click Apply to change the owner of this sub-key
    9. Click on the Permissions tab, highlight SYSTEM and click the Edit button
    10. Check the Full Control check box and click OK to change the permissions on this sub-key for the SYSTEM account
    11. Close regedit

    After performing the above steps, you should be able to re-run .NET Framework 1.1 setup and install successfully.

    <update date="4/4/2007"> Added note at the top of this blog post to try to let users know that this workaround will not help in the final RTM release of Windows Vista.  </update>

     

  • Aaron Stebner's WebLog

    .NET Framework 3.0 (WinFX runtime) deployment guide

    • 2 Comments

    I noticed this weekend that a deployment guide for the .NET Framework 3.0 (previously known as the WinFX runtime components) has been published.  This deployment guide contains the following information that can be useful if you are going to create a setup package that includes the .NET Framework 3.0 as a prerequisite:

    • System requirements (OS versions and hardware requirements)
    • Installation location and file/assembly versioning information
    • Detecting if the .NET Framework 3.0 is installed on a system using the registry
    • Detecting if the .NET Framework 3.0 is installed on a system using Internet Explorer user agent strings
    • Command line switches for .NET Framework 3.0 setup
    • Return codes for .NET Framework 3.0 setup
    • Detecting if .NET Framework 3.0 language packs are installed on a system using the registry
    • Sample script for detecting the .NET Framework 3.0 using Internet Explorer

    I encourage you to take a look at this guide if you are planning to build and ship an application that requires the .NET Framework 3.0.

    Please note that there is a factual error in the list of registry keys to detect .NET Framework versions in the guide.  For the .NET Framework 1.0, there is not an Install registry value, so the documented detection method will always return false.  Instead, you should check for the existence of the following registry value (like the sample code I previously published does):

    • Key name: HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\Policy\v1.0
    • Value name: 3705
    • Value data type: REG_SZ
    • Value data: 3321-3705

    If you are working on implementing .NET Framework 3.0 deployment or redistribution solutions and run into any questions or problems, please let me know and I can post follow-up information with more detailed information in the future....

     

  • Aaron Stebner's WebLog

    Available installation modes for the .NET Framework 2.0

    • 11 Comments

    I have gotten several questions in the past from customers who need to install the .NET Framework 2.0 as part of their setup package or deploy it to systems in a network.  There are multiple options avaiable in this scenario, and each has their own strengths and weaknesses.  This post describes the major installation modes that are available for the .NET Framework 2.0 and some important things to consider when deciding which mode is best for your installation or deployment scenario.

    Silent mode

    Installing the .NET Framework 2.0 in silent mode suppresses all UI screens during installation.  You can run setup in silent mode with one of the following command line switches:

    dotnetfx.exe /q:a /c:"install.exe /q"

    -or-

    msiexec.exe /i netfx.msi /qn /l*v netfx20install.log ADDEPLOY=1

    Silent mode is useful when installing the .NET Framework as part of another setup package and you want to control the UI experience from the other setup package.

    When installing in silent mode, you need to handle any scenarios where .NET Framework 2.0 setup would ordinarily display error dialogs or reboot prompts.  The following blog posts provide more information about various scenarios that you will need to handle in your setup package when installing the .NET Framework 2.0 in silent mode:

    Unattended mode

    Installing the .NET Framework 2.0 in unattended mode suppresses all UI screens except for a small progress dialog during installation.

    You can run setup in unattended mode with one of the following command line switches:

    dotnetfx.exe /q:a /c:"install.exe /qb"

    -or-

    msiexec.exe /i netfx.msi /qb /l*v netfx20install.log ADDEPLOY=1

    Adding an exclamation point to make the command line switch /qb to make it /qb! in the examples above will hide the cancel button on the progress dialog.

    Unattended mode is useful if you want to install or deploy the .NET Framework and provide feedback to the user during installation, but do not want the user to have to click through any other UI screens.  Hiding the cancel button can be useful if you do not want the user to be able to cancel the installation.

    If you run .NET Framework 2.0 setup in unattended mode using the above command line switches, you will notice that the progress dialog does not contain any explanatory text during installation.  Instead, it looks like the following:

    .NET Framework 2.0 unattended installation progress dialog

    Because we designed the .NET Framework 2.0 to be a multi-lingual installation package, the ProductLanguage property is set to 0 in the Property table of netfx.msi.  Unfortunately, there is a bug in Windows Installer 3.1 and earlier that causes incorrect string resources to be loaded when ProductLanguage = 0 like this.  In order to workaround this bug, we decided to ship the .NET Framework 2.0 so that it displays no text in this progress dialog instead of hard-coding English strings in this dialog.

    Heath Stewart explained this scenario in more detail in this blog post.  In addition, he provided a set of transforms that you can download and apply to display explanatory text in the language of your choice when installing the .NET Framework 2.0 in unattended mode.  If you want to use one of these transforms, you will need to choose a single language that you want the UI to be displayed in, and then you can use one of the following command lines:

    dotnetfx.exe /q:a /c:"install.exe /qb /msipassthru MSI_PROP_BEGIN""TRANSFORMS=<path>\strings.enu.mst""MSI_PROP_END"

    -or-

    msiexec.exe /i netfx.msi /qb /l*v netfx20install.log ADDEPLOY=1 TRANSFORMS=<path>\strings.enu.mst

    Standard mode

    Installing the .NET Framework 2.0 in standard mode displays all setup UI screens during installation.  When installing in standard mode, .NET Framework 2.0 setup will display any necessary dialogs regarding missing prerequisites, beta versions that need to be uninstalled, errors during installation or reboots after installation.

    The .NET Framework 2.0 setup package contains multi-lingual setup UI.  When running .NET Framework 2.0 setup in standard mode, the setup executable checks the user's operating system UI language settings and displays setup UI in the same language as the operating system.

     

Page 1 of 1 (25 items)