Aaron Stebner's WebLog

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

November, 2006

  • Aaron Stebner's WebLog

    Vote for the Media Center Show Awards 2006

    • 0 Comments

    Ian Dixon has posted the voting page for the Media Center Show Awards 2006. If you haven't already, I encourage you to visit the voting page at http://iandixon.co.uk/nuke/TheMediaCenterShowAwards/tabid/81/Default.aspx and vote on entries in the following categories:

    • Best Media Center utility
    • Best Online Spotlight applications
    • Best communication tool
    • Best community resource
    • Best hardware manufacturer
    • Best enthusiast blog
    • Best Microsoft Media Center blog
    • Best free (non-commercial) application
    • Best commercial application
    • Outstanding design award
    • Best Windows Vista Media Center application

    My blog is a nominee for the best Microsoft Media Center blog, but I suggest that anyone who is going to vote for the awards do what I did when I voted this morning and vote for Charlie Owen's blog.  Charlie is a great writer and I find his blog easy to read.  Plus, he does a nice job of covering a wide range of Windows Media Center topics on his blog - from development topics to system building topics to end user design topics.

    Also, as a side note, I like Matt Goyer and read his blog regularly, but it would make me a little sad if his blog won for best Microsoft Media Center blog because he doesn't work at Microsoft anymore.  :-)

  • Aaron Stebner's WebLog

    Return codes for .NET Framework 3.0 setup

    • 2 Comments

    A while back, I posted a list of possible return codes for the .NET Framework 2.0.  I recently found out that the setup wrapper for the .NET Framework 3.0 can return a couple of other error codes in certain scenarios, so I wanted to list those here as well for completeness:

    0x0013EC (5100) - Generic setup block

    This error code will be returned in several different scenarios:

    • The user running setup does not have administrative privileges
    • A previous beta version is installed (the algorithm is similar to the one for the .NET Framework 2.0 described here, but the product codes are stored in the file named setup.sdb instead of install.ini)
    • A later version of the .NET Framework 3.0 is already installed
    • The OS that setup is being run on is not supported
    • The OS that setup is being run on does not have the minimum service pack installed

    0x002332 (9010) - A pending reboot must be completed before setup can run

    This error code is returned if some previous action on the system caused pending file rename operations to be scheduled by adding entries to the following registry value:

    • Registry root: HKEY_LOCAL_MACHINE
    • Registry key name: Software\Microsoft\Updates\UpdateExeVolatile
    • Registry value name: Flags -or- Flags_<reboot time>

    This error can typically be resolved by rebooting the system.  If the error continues to occur even after a reboot, you can manually delete this Flags value from the registry on your system to work around it.

    The reason that .NET Framework 3.0 setup contains a check for this registry value is that a couple of the prerequisite packages that it installs are Windows OS hotfixes.  These hotfixes include specific checks for this registry value and they will fail if it exists and is non-blank.  The .NET Framework setup team decided it would be best to catch this type of error at the beginning of the setup process instead of letting setup start running and then fail later on for a cause that could easily be validated up-front.

    <update date="11/29/2006"> Updated the registry value that .NET Framework 3.0 setup checks to determine whether a pending reboot must be completed.  The original value I posted (HKLM\System\CurrentControlSet\Control\SessionManager@PendingFileRenameOperations) is used by many Windows applications, but .NET Framework 3.0 setup does not check for that value because it will not result in any of its prerequisite packages failing. </update>

     

  • Aaron Stebner's WebLog

    Windows Vista OS image creation and deployment guide

    • 4 Comments

    I was looking at some of the Windows Vista information on the main Microsoft site this weekend, and I found an interesting document describing the process for creating and deploying OS images that I wanted to post here.  Windows Vista OS setup is built on an entirely new set of technologies than previous versions of Windows, and as a result the process of creating OS images and creating and using unattend files is different than you might be used to from the past.

    If you are planning to create and deploy OS images for Windows Vista, I encourage you to take a look at the Windows Vista deployment step-by-step guide at http://www.microsoft.com/technet/windowsvista/library/88f80cb7-d44f-47f7-a10d-e23dd53bc3fa.mspx for some helpful information.  The following sections are included in the deployment guide:

    In addition, it is worth reviewing the content of the Windows Automated Installation Kit (WAIK), which is located at http://go.microsoft.com/fwlink/?LinkID=53552.

  • Aaron Stebner's WebLog

    Design considerations for Windows Media Center applications on 64-bit operating systems

    • 4 Comments

    A little while ago, I wrote this blog post describing some changes that were made to the Q podcast and video blog client sample application that is included in the Windows Media Center SDK for Windows Vista.  Those changes were made to better support running the Q application on Windows Media Center extender devices.

    While we were working on this change, we ran into an interesting issue that affects 64-bit systems that I want to describe in more detail.  The specific issue involves how applications are hosted within Windows Media Center.  On 64-bit systems, applications are hosted by the 64-bit version of the ehExtHost.exe hosting process.  As a result, applications that attempt to access the registry using default registry API calls will be returned values from the 64-bit registry view (as opposed to the reflected 32-bit registry view).

    This caused some problems for the redesigned Q application because the new code attempts to read from a registry value under HKEY_LOCAL_MACHINE\Software\Microsoft\Q, which is a location affected by registry reflection on 64-bit operating systems.  However, the Q application's assembly is a processor-neutral (MSIL) assembly, and as a result, we wanted to create a single installer that would work for both 32-bit and 64-bit systems.

    Our initial solution was to create a 32-bit installer that installs the MSIL assembly to the GAC and writes the HKEY_LOCAL_MACHINE registry value, and to have the code use standard registry APIs to read data from this registry location.  With that version of the code and the installer, the registry value was written to the 32-bit registry (because it is a 32-bit MSI), but the Q application never found the registry value (because standard registry APIs attempt to read from the 64-bit registry), and no RSS feeds got registered by default.

    We next attempted to set the msidbComponentAttributes64bit value in the Component table for the component that installs this registry value.  This strategy created the registry value in the 64-bit registry and Q worked as expected.  However, this behavior cannot be relied upon - Windows Installer does not officially allow authoring 64-bit components in a 32-bit MSI.  Doing so will generate ICE80 validation errors, and part of the Windows Vista logo program requires that MSI packages not have ICE validation errors like this.

    That left us with the following options:

    1. Create separate MSI-based installers for 32-bit and 64-bit operating systems
    2. Modify the code to use P/Invokes to turn on/off mirroring at runtime to try to find the registry value - specifically, we can use the RegOpenKeyEx API with the KEY_WOW64_32KEY flag; P/Invokes are necessary here because this flag is not supported in .NET Framework registry classes
    3. Move the registry value to a part of the registry that is not mirrored (such as HKLM\System\*)
    4. Modify the code to check in HKEY_LOCAL_MACHINE\Software\Microsoft\Q and if that is not found, fall back and look in HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Q

    The first option is probably the cleanest, but was too involved for an SDK sample application so we decided not to do that at this time.  I will post a WiX-based sample in the near future for anyone who would prefer to use this option for their application.

    The second option involved writing a lot of additional code, which we did not have time for before the SDK was scheduled to ship.

    There is not a logical location in the registry to use for the third option, especially considering that we could not use HKEY_CURRENT_USER or else we would re-introduce the Windows Media Center extender problem we were trying to solve.

    Ultimately, we chose the fourth option, and the sample code that shipped in the final release of the Windows Media Center SDK for Windows Vista includes logic to look in the 64-bit registry and if the value that points to the OPML file is not found, it then looks in the 32-bit registry.  If the registry value is not found in either location, then Q skips populating RSS feeds altogether.

    The important overall point of this blog post is that if you are writing a Windows Media Center application that needs to access the registry, you will need to take special care in how you design your application and your installer in order to ensure that it works equally well on 32-bit and 64-bit versions of Windows Media Center on Windows Vista Home Premium and Ultimate editions.

  • Aaron Stebner's WebLog

    Disabling services with MSConfig to work around setup failures

    • 12 Comments

    I was talking recently with a colleague who works on the .NET Framework setup and Windows Installer technical support team here at Microsoft.  He told me about a set of steps that his team typically has customers try when they call in to report failed installations.  I wanted to post these steps here in case they are helpful to anyone else struggling to get an application installed.

    This set of steps allows you to easily find all services that are installed on your system and temporarily disable them so they cannot interfere with installation processes.  It also allows you to identify and temporarily disable programs that are scheduled to start every time the system reboots.  The System Configuration tool (also known as MSConfig) allows you to manage these and other settings.

    I recommend trying the following steps in cases where a product fails to install on your system and you've already tried other workarounds posted on my blog and elsewhere to attempt to resolve the issue:

    1. Click on the Start menu, choose Run, type msconfig and click OK
    2. In the System Configuration tool, click on the Services tab
    3. Check the box labeled Hide all Microsoft services
    4. Click the Disable All button to disable all non-Microsoft services
    5. In the System Configuration tool, click on the General tab
    6. Click the Selective startup radio button
    7. Uncheck the box labeled Load startup items
    8. Click OK to accept all changes in the System Configuration tool
    9. Reboot for the changes to take effect
    10. Attempt to install the application that previously failed
    11. Re-run the System Configuration tool and re-enable the services that you disabled in step 4 above

    In many cases, the above steps will allow a previously failing setup package to install successfully.  Hopefully they will be useful to you as well if you find yourself in this situation.

  • Aaron Stebner's WebLog

    Updated warning - .NET Framework 3.0 cleanup tool removes MSDN and SQL Express

    • 2 Comments

    Yesterday, I posted a warning that the .NET Framework 3.0 pre-release version uninstall tool will remove the final release of SQL Server 2005 Express Edition.  A customer posted a comment on that blog post indicating that they ran the uninstall tool and it also removed the final release of MSDN for Visual Studio 2005.

    I looked at the MSDN MSI and the data files for the uninstall tool, and I can confirm that the .NET Framework 3.0 pre-release version uninstall tool will also remove the final release of MSDN for VS 2005.  It will not remove the version of MSDN that is installed as part of the Visual Studio 2005 Express Editions though.

    So in summary, if you run the .NET Framework 3.0 uninstall tool on your system, it will remove the final release of both SQL Server 2005 Express Edition and MSDN for Visual Studio 2005, and you will have to reinstall both of these products on your system after running the uninstall tool.

  • Aaron Stebner's WebLog

    Media Center Show Extra #4 - the Z sample application

    • 0 Comments

    Ian Dixon wrote a blog post over the weekend on the Media Center Show site about the new Z sample application that is included in the Windows Media Center SDK for Windows Vista.  In addition, he posted Media Center Show Extra #4 today where he demonstrates the features of the Z application.

    I encourage you to check out Ian's Media Center Show Extra #4 at one of the following links:

    It really helps to see a video of the Z features in action to understand how powerful the MCML development platform for Windows Media Center can be.  I hope this sample application will serve as an inspiration and a learning tool for developers looking to add exciting new functionality to the Windows Media Center platform.

  • Aaron Stebner's WebLog

    Warning - .NET Framework 3.0 cleanup tool removes final release of SQL Express

    • 5 Comments

    When preparing to install the final version of the .NET Framework 3.0 on a system, it is necessary to uninstall any previous beta versions that are installed.  In order to make the beta uninstall process as painful as possible, we released a .NET Framework 3.0 pre-release version uninstall tool.

    The information on the uninstall tool download page states that the tool will uninstall pre-release versions of the .NET Framework 3.0 as well as pre-release versions of Visual Studio 2005, SQL Server 2005 Express Edition and MSDN for Visual Studio 2005.

    However, while I was investigating an issue on a colleague's machine over the weekend, I found out that this cleanup tool removes the final release of SQL Server 2005 Express Edition and SQL 2005 SP1 in addition to removing pre-release versions.  The uninstall tool uses Windows Installer product codes to figure out which products to remove, and the product codes for SQL Server 2005 did not change between the pre-release versions and the final release.

    Until the uninstall tool is revised to correctly handle this scenario, I wanted to post a warning to anyone who uses it - if you run the .NET Framework 3.0 pre-repease version uninstall tool on a system that has the final release of SQL Server 2005 Express Edition installed, it will remove SQL Express and you will have to re-install SQL Express after running the uninstall tool.

    <update date="11/21/2006"> A customer pointed out that the .NET Framework 3.0 uninstall tool also removes the final release of MSDN.  I have posted an updated warning in this new blog post </update>

     

  • Aaron Stebner's WebLog

    New Windows Media Center applications for Windows Vista from OABsoftware

    • 1 Comments

    OABsoftware has released 3 new Windows Media Center applications for Windows Vista.  All 3 are written in Media Center Markup Language (MCML), which is one of the new technologies introduced in the Windows Media Center SDK for Windows Vista.

    Here is more information about the applications:

    Vista Media Center Mail

    Vista Media Center RSS Reader

    Vista Caller ID

    Also, if anyone else creates any new applications for Windows Media Center for Windows Vista, please send me a link and I will try them out and post links to them on my blog in the future.

  • Aaron Stebner's WebLog

    How the Q sample application was redesigned to support Media Center Extenders

    • 0 Comments

    The Windows Media Center SDK for Windows Vista was released yesterday.  One of the changes that was made since the RC2 release that I didn't mention in my previous blog post is a rewrite of large portions of the Q podcast and video blog sample application.  I wanted to briefly explain one of the key reasons why we decided to partially rewrite Q, and also give an overview of the design used in the final release of the Media Center SDK.

    Around the time that Windows Vista RC2 was released, we put together a sample application CD for people on the Media Center team to try out at home.  That CD included the Q application and an early preview version of the Z application along with a build of the SDK for folks on the team interested in developing their own Media Center applications.

    When putting this CD together, we wanted to make it as easy as possible for people to start using Q, and back at that time you had to manually add feed sources to the Internet Explorer 7 feed store in order for Q to display anything in its UI.  Charlie asked Stephen Toub (the developer who originally wrote most of the Q application) to create a simple script that we could pass in an OPML file and have it automatically add feed sources.

    While working on this script, we quickly realized that RSS feeds are registered on a per-user basis in Windows Vista.  This prevented us from automatically registering RSS feeds for the user account that is used for Windows Media Center extender sessions because extender sessions connect to Windows Media Center across the netowrk via special user accounts that do not allow interactive login.  Therefore, the Q application could not be used on an extender without the user manually copying feed registration information into the extender user account folder under c:\Users from some other user account on the system.

    As a result of this experience, we decided to add a feature to Q to populate RSS feeds the first time each user account launches Windows Media Center after installing the Q sample application.  This feature works as follows:

    The Q sample application now registers an additional Windows Media Center entry point.  It is a background application that runs as soon as the user launches Windows Media Center.  This new background application attempts to read a registry value under HKEY_LOCAL_MACHINE.  This registry value specifies a path to an OPML file that contains a list of RSS feeds to register on the system.

    If the background application finds the registry value, it then looks for a second registry value under HKEY_CURRENT_USER that specifies a file hash for the OPML file.  Because the second registry value is located under HKEY_CURRENT_USER, it is possible to register RSS feeds for each user account on the system the first time that Windows Media Center is launched for each account.

    If the file hash registry value does not exist under HKEY_CURRENT_USER, the background application assumes that the OPML file has not yet been parsed, and it proceeds to register the feeds listed in the OPML file that are not yet registered for the current user.  When it is done, it calculates the hash of the OPML file and writes that value to the registry under HKEY_CURRENT_USER.

    If the file hash registry value already exists, the background application calculates the file hash for the the OPML file pointed to by the HKEY_LOCAL_MACHINE registry value.  If the calculated file hash matches the file hash stored in the registry, the background application assumes that the OPML file has already been parsed and silently exits.

    If the file hash value in the registry does not match the calculated file hash, the background application parses the OPML file and registers any RSS feeds that are not yet registered for the current user.

    While the background application is adding RSS feeds, it blocks the main Q entry point from launching and displays a dialog telling the user to try back in a couple of minutes.  Once the background application is done adding feeds from the OPML file, it displays a toast dialog telling the user that they can now launch the Q sample application and start viewing podcasts and video blogs.

    The Q sample application includes WiX source files and a script to allow you to easily build an MSI to install Q (similar to the information described in this blog post).  This MSI includes steps to install a sample OPML file to a location that is readable by all users and create a registry value under HKEY_LOCAL_MACHINE that points to the location that the MSI installs the OPML file to.

    If we had more time, we would have created some nice UI in MCML to allow users to configure RSS feeds from within Windows Media Center.  Maybe someone will be interested in adding a feature like this to Q in the future?  :-)

    I also want to take this opportunity to say a big thank you to Stephen Toub, who did most of the development work for the Q application (and in his spare time no less).  His responsiveness to questions and debugging requests were a huge help and we couldn't have shipped the Q sample application without his effort and enthusiasm.

  • Aaron Stebner's WebLog

    How to automatically suppress application compatibility warnings on Windows Vista

    • 3 Comments

    Recently, a fellow employee contacted me with a question about unattended installation of Visual Studio 2005 on Windows Vista.  They were following the instructions that I posted in this blog post to prevent unattended installation from trying to install the .NET Framework 2.0 and the instructions in this blog post to control reboots.

    However, when they ran the unattended install on the final version of Windows Vista, they saw a few pop-up application compatibility warning dialogs during installation that looked like the one I described in this blog post.  They asked me how to suppress these dialogs, and since I didn't know for sure how to do this automatically, I talked to some people who work on the Windows application compatibility team.

    I was able to use the following steps to automatically suppress the application compatibility warnings that normally appear during Visual Studio 2005 setup on Windows Vista:

    1. Click on the Start menu, choose All Programs, then Accessories
    2. Right-click on the Command Prompt and choose Run as administrator to open an elevated cmd prompt
    3. Run reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags" /v {2a0da30d-846f-4680-89da-2dbc457d7b44} /t REG_DWORD /d 4 /f
    4. Run reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags" /v {319b29ae-7427-4fbc-9355-22df056c27a4} /t REG_DWORD /d 4 /f
    5. Run reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags" /v {3d06c673-5e8a-41c0-b47f-3c3ca0a22e67} /t REG_DWORD /d 4 /f
    6. Run reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags" /v {5f66dbae-cad3-468a-83d0-77ace8abc1f6} /t REG_DWORD /d 4 /f

    The GUIDs listed in steps 3, 4 and 5 are associated with SQL Server 2005 Express Edition (which is installed during Visual Studio 2005 setup) and the GUID listed in step 6 is associated with the Visual Studio 2005 IDE (devenv.exe) which is launched during Visual Studio 2005 setup to configure some settings.

    I was able to figure out the exact list of GUIDs by using a really interesting tool - the Application Compatibility Toolkit 5.0.  You can download this toolkit at this location if you are interested in trying it out - http://www.microsoft.com/downloads/details.aspx?FamilyID=24da89e9-b581-47b0-b45e-492dd6da2971&displaylang=en

    The Application Compatibility Toolkit 5.0 includes a tool that lets you view, enable and disable all of the application compatibility fixes that are included as a part of Windows Vista.  These are the steps I used to determine what GUID values needed to be set in the registry to disable the application compatibility warnings for Visual Studio 2005:

    1. Download and install the Application Compatibility Toolkit 5.0 from http://www.microsoft.com/downloads/details.aspx?FamilyID=24da89e9-b581-47b0-b45e-492dd6da2971&displaylang=en
    2. Click on the Start menu, choose All Programs, then Microsoft Application Compatibility Toolkit 5.0
    3. Right click on the item named Compatibility Administrator and choose Run as administrator to launch it with elevated privileges
    4. Expand the Applications node under System Database and click on the application you are interested in to display a list of related binaries - in this case, I looked at Microsoft SQL Server 2005 and Visual Studio 2005
    5. In the list of binaries, locate the binary file that has an application compatibility AppHelp message associated with it, right-click on it and choose Disable Entry
    6. Open regedit.exe, browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags and verify that a REG_DWORD value has been added with a GUID for the value name name - this is the registry value that will prevent Windows Vista from displaying the application compatibility message when you run it 

    You can also use the Search and Query buttons in the Compatibility Administrator tool if you are not sure of the exact name of the application or binary that is causing the application compatibility message to appear.

    <update date="2/27/2007"> The final version of the Microsoft Application Compatibility Toolkit v5.0 has been released.  Updating links to point to the final version instead of the old beta version.  </update>

     

  • Aaron Stebner's WebLog

    Final version of Windows Media Center SDK for Windows Vista available for download!!

    • 1 Comments

    Today is a really exciting day for me.  After a lot of work, a ton of great beta feedback and a couple of last minute fire drills, we have released the final version of the Windows Media Center SDK for Windows Vista today.

    Since the RC2 build, we have done some additional work on the SDK and added the following features:

    • An all new end-to-end MCML sample application, code named Z (see this blog post for more information)
    • Lots more great documentation
    • Sample XML registration files for registering entry points in every supported location in Windows Media Center
    • Online version of MCML Sampler that we can use to provide new sample content even after the SDK has shipped
    • Additional developer scripts to make it easier to build and debug the MCML sample applications (Q and Z) after installing the SDK

    In addition to releasing the SDK, we have also released a power toy called the MCML Preview Tool Launcher.  This tool makes it much easier to preview markup as you write it by eliminating the need to type in file paths or URLs and adding the ability to track the history of previous files that you have viewed so you can jump back to them quickly.  Also, it makes it much easier to configure the command line switches supported by the MCML Preview Tool in the SDK.  This power toy requires that you install the SDK first.

    The links below provide download locations for the Windows Media Center SDK for Windows Vista and the MCML Preview Tool Launcher power toy.  There are also links to the blog posts that Charlie posted this afternoon on the Media Center Sandbox site where you can read more details about the SDK, the power toy, and the Z sample application that has been added to the SDK.

    Windows Media Center SDK for Windows Vista

    MCML Preview Tool Launcher SDK power toy

    Media Center Sandbox blog posts from Charlie

    I encourage anyone interested in Windows Media Center development to take a look at these posts, download and install the SDK and the power toy, and start digging in.  Please send any feedback you have and also send pointers to the great applications that you create!

  • Aaron Stebner's WebLog

    Using and customizing the Visual Studio 2005 setup bootstrapper

    • 2 Comments

    As many of you probably already know, Visual Studio 2005 ships with a setup bootstrapper that can be used to create a setup package that chains together prerequisite packages and then installs the product that you create an MSI for within Visual Studio.  The setup bootstrapper includes the necessary data files and binaries to install several Microsoft redistributable packages (the .NET Framework 2.0, Windows Installer 3.1, the Visual C++ 8.0 runtime files, SQL Express and a few others).

    The bootstrapper is designed to be data driven and generic, so you can add other packages to the list of prerequisites that it will let you install by adding some information to the directory where the bootstrapper is installed on your Visual Studio 2005 development system.

    Recently, I found a couple of good resources that can be useful to extend the functionality provided by the setup bootstrapper by authoring new packages that it will be able to install:

    If you are building a setup package that requires installing other packages as prerequisites, I encourage you to take a look at the Visual Studio 2005 setup bootstrapper to see if it will meet your needs.

  • Aaron Stebner's WebLog

    How to fix error code 25015 with access denied message during .NET Framework 2.0 setup

    • 11 Comments

    Recently, I saw a post on the MSDN .NET Framework Setup Forum indicating that a customer was having trouble getting the .NET Framework 3.0 to install on his system.

    How to diagnose this error

    The error log for the .NET Framework 3.0 setup (%temp%\dd_dotnetfx3error.txt) showed the following information:

    [11/10/06,11:30:12] Microsoft .NET Framework 2.0: [2] Error: Installation failed for component Microsoft .NET Framework 2.0. MSI returned error code 1603
    [11/10/06,11:30:36] WapUI: [2] DepCheck indicates Microsoft .NET Framework 2.0 is not installed.
    [11/10/06,11:30:37] WapUI: [2] DepCheck indicates Microsoft .NET Framework 3.0 was not attempted to be installed.

    Based on this information, I determined that the .NET Framework 2.0 setup was failing.  Then, I used the list of .NET Framework 3.0 setup log files to request additional information from the customer - specifically, the log file named %temp%\dd_netfx_retMSI*.txt.

    When the customer sent me this log file, I found the following error that was causing the .NET Framework 2.0 setup to fail:

    Error 25015.Failed to install assembly 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.VisualBasic.Vsa.dll' because of system error: The process cannot access the file because it is being used by another process.

    In addition, the customer sent me a log file created by Filemon that indicated that setup failed when attempting to open this file with an access denied error.

    How to workaround this error

    Based on the above information, I made an educated guess that there was something wrong with the folder and file permissions on the customer's system.  Fortunately, he was able to use the following steps to resolve this issue and successfully install the .NET Framework 3.0:

    1. Use the SubInAcl tool described at http://blogs.msdn.com/astebner/archive/2006/09/04/739820.aspx to make sure that the Administrators group and the SYSTEM account both have permissions to folders under %windir% and registry hives under HKLM
    2. Run the cleanup tool described at http://blogs.msdn.com/astebner/archive/2006/05/30/611355.aspx to make sure any remnants of the .NET Framework 2.0 have been removed from the system
    3. Try again to install the .NET Framework 2.0 (or in this case, try again to install the .NET Framework 3.0, which will try to install the .NET Framework 2.0 behind the scenes)

    Important caveats about error code 25015

    Please note - error code 25015 during .NET Framework 2.0 setup is a catch-all for many types of errors.  Therefore, the solution described in this post will likely only work if you see error code 25015 and the system error message states that the file is being used by another process and/or access is denied.  Not all instances of the 25015 error code will be resolvable with these steps.

    In coding terms, error code 25015 is the else block at the end of a big if statement.  As a result, it ends up being the error code displayed after .NET Framework 2.0 setup verifies that the error is not caused by any other known fusion return code (which are defined in the file corerror.h that ships in the .NET Framework 2.0 SDK).

    The customer who encountered this problem also posted this item on his blog describing this troubleshooting experience in case you are interested in reading that as well.  Hopefully this will be useful if you run into this type of error while installing the .NET Framework 2.0 on your system.

  • Aaron Stebner's WebLog

    Mailbag: More information about Workflow extensions for VS 2005 setup

    • 0 Comments

    Question:

    I would like to automate the installation of the Visual Studio 2005 extensions for .NET Framework 3.0 (Windows Workflow Foundation) setup package.  How can I install this package in silent mode?  Also, if this package fails to install, where can I find log files to troubleshoot installation problems?

    Answer:

    Silent install command lines:

    To run the Visual Studio 2005 extensioins for .NET Framework 3.0 (Windows Workflow Foundation) setup package in silent mode, you can use steps similar to the following:

    1. Download the self-extracting executable setup package from this location
    2. Extract the contents using a compression tool such as WinZip
    3. From the extracted directory, run setup.exe /quiet

    The setup.exe in the extracted directory also supports the following command line switches that might be useful depending on your installation scenario:

    • /passive - run setup in unattended mode, which displays a progress dialog but requires no user interaction
    • /norestart - suppress any reboots that are requested during installation so you can defer them until later
    • /log <file name> - specify a path for the setup log files (if you do not want to use the default log file names listed below)

    Log files:

    The Visual Studio 2005 extensioins for .NET Framework 3.0 (Windows Workflow Foundation) setup package creates the following log files:

    • %temp%\Setup(<timestamp>).htm - a summary log file that describes high level actions taken during setup
    • %temp%\Setup(<timestamp>).log - the verbose MSI log file created during setup; a link to this log file is also placed at the bottom of the summary HTML log file

    For both log files, the <timestamp> value is dynamically generated based on the system clock time when setup is launched.  It takes the form of MMDDYY HHMMSS (month, day, year, hours in 24 hour clock time, minutes, seconds).

  • Aaron Stebner's WebLog

    New Windows Media Center development blog by Niall Ginsbourg

    • 0 Comments

    Niall Ginsbourg, the developer behind several Windows Media Center applications, including Big Screen Headlines, Big Screen Contacts, and several others, has started a blog about Windows Media Center development.  The blog is called Big Screen Blog and you can find it at this location - http://mobilewares.spaces.live.com/.

    Niall has already written some really interesting posts about Media Center Markup Language (MCML) development for Windows Media Center in Windows Vista:

    I've also added a link to the Big Screen Blog to my list of Windows Media Center blogs on the lower left side of my main blog page.  I encourage you to check out this blog and keep an eye on it for future posts about Windows Media Center development as well.

  • Aaron Stebner's WebLog

    Complete list of keyboard shortcuts that can be used in Windows Media Center

    • 1 Comments

    The Windows Media Center user interface is optimized for television displays and remote control-based navigation.  However, there are a lot of computers running Windows Media Center that are configured as standard desktop systems or laptops.  I find myself trying to navigate through the Windows Media Center UI using the keyboard very often on my systems, particularly while working on Windows Media Center application development using the Windows Media Center SDK.

    I recently found a couple of lists that contain all of the keyboard shortcuts that can be used in Windows Media Center.  These shortcuts can be particularly useful when testing applications on a system that you do not have a remote control receiver plugged in to, or if you are like me and find keyboard navigation faster and more convenient than mouse or remote control navigation.

    Here are the lists of keyboard shortcuts that are supported for various editions of Windows Media Center:

  • Aaron Stebner's WebLog

    White paper with UAC development information for Windows Vista

    • 3 Comments

    Recently, a friend of mine asked me a question about an installer that his team was working on.  They have an MSI that is launched by a lightweight bootstrapper that is named something like ProductSetup.exe.  When running this installer on Windows Vista, they noticed that Windows was automatically prompting for permission to elevate when the EXE was first launched.

    After asking around a little bit about this scenario, I received a pointer to a really good white paper that has been published for public download - Windows Vista Application Development Requirements for User Account Control Compatibility.

    This white paper includes details many aspects of designing and building applications that will work well with User Account Control (UAC) on Windows Vista.

    At a high level, it describes the following steps to use when designing applications for Windows Vista:

    1. Test Your Application for Application Compatibility
    2. Classify Your Application as a Standard User, Administrator, or Mixed User Application
    3. Redesign Your Application's Functionality for UAC Compatibility
    4. Redesign Your Application's User Interface for UAC Compatibility
    5. Redesign Your Application's Installer
    6. Create and Embed an Application Manifest with Your Application
    7. Test Your Application
    8. Authenticode Sign Your Application
    9. Participate in the Windows Vista Logo Program

    In addition, it describes some interesting setup-specific considerations.  Windows Vista includes some logic to automatically prompt for elevations for processes that it believes are likely to be installer processes.  For example, it will check for strings like setup, install, update and others in the name and file properties of a file.

    In some cases, this automatic prompting can be annoying and undesirable.  Fortunately, step 6 of the list above describes how you can override this behavior for your application - by creating and embedding an application manifest that specifies the requested execution level.  In the case of an installer process that you do not want to prompt for elevation, you can specify the asInvoker execution level to prevent Windows Vista from automatically prompting because the word setup appears in the name of your application (as was the case with my friend's scenario).

    In other cases I have seen, an application may want to request elevation when it is first launched to avoid possible file or registry permission problems later on.  In those cases, you can mark your application with the highestAvailable or requireAdministrator execution level, and Windows Vista will prompt the user for elevation when launching the application.

    If you are developing an application and/or an installer for Windows Vista, or have an existing application and/or installer that you plan to support on Windows Vista, I highly encourage reading the UAC white paper linked above and understanding the new scenarios that are introduced with UAC in Windows Vista.

  • Aaron Stebner's WebLog

    More details about how .NET Framework 2.0 setup reduces system reboots

    • 2 Comments

    A while back, Quan To posted an item on his blog that briefly described a project he worked on to help reduce the number of reboots in the .NET Framework 2.0 setup.  Recently, I learned more details about how this feature works, and I wanted to post them here in case anyone is curious.

    .NET Framework 2.0 setup carries an updated copy of the file mscoree.dll.  This file is shared between all versions of the .NET Framework and installs to %windir%\system32, which means that if the file is in use because there is a .NET Framework 1.0 or 1.1 application running on the system, it could potentially cause a reboot at the end of .NET Framework 2.0 setup.

    The reboot reduction algorithm for the .NET Framework 2.0 looks like the following:

    Windows Installer uses the MoveFileEx API behind the scenes to copy the new version of mscoree.dll.  If mscoree.dll is in use, Windows Installer will report back return code 3010 (which means success with a reboot required).

    The external UI handler for the .NET Framework 2.0 intercepts the 3010 return code and performs the following additional checks:

    • Is the reboot request caused by mscoree.dll (and only by mscoree.dll)?
    • Is mscoree.dll soft-locked?  If it is soft-locked (as opposed to hard-locked), then this means that MoveFileEx was able to rename mscoree.dll and copy the new version to %windir%\system32.  If it is hard-locked, MoveFileEx would not be able to rename mscoree.dll and a reboot would be necessary to enable copying the new version to %windir%\system32.

    Note that in my experiences with hard-locking tests, Windows Installer will fail to copy the file and prompt you to abort, retry or cancel and there isn't a way to get a successful installation when a file that needs to be updated is hard-locked.  As an example of this type of scenario, you can install the .NET Framework 1.1, open mscoree.dll in Microsoft Word then try to install the .NET Framework 2.0.

    If both of the above conditions are true, the external UI handler changes the 3010 return code to 0 and does not prompt the user to reboot.  In this scenario, any applications that were previously running will have the old version of mscoree.dll loaded into their process and continue to work correctly.  Any new applications that run after installing the .NET Framework 2.0 will be able to use the updated version of mscoree.dll now located in %windir%\system32.

    An interesting point to keep in mind here is that this logic to intercept and override the 3010 reboot return code is located within the external UI handler for the .NET Framework 2.0 setup.  This means that you will not get this feature when deploying the .NET Framework 2.0 using the MSI directly.  In that scenario, Windows Installer will return 3010 whenever setup completes in cases where mscoree.dll is in use during installation, and the code that modifies this return code does not ever get run.  However, applications that include the .NET Framework 2.0 as a prerequisite can safely defer the reboot until the end of the overall application installation process (as opposed to requesting a reboot in the middle of installation).

  • Aaron Stebner's WebLog

    Clarification about .NET Framework 3.0 detection registry key on a 64-bit OS

    • 1 Comments

    There is information in the Microsoft .NET Framework 3.0 deployment guide that describes how to read registry values to detect whether or not the .NET Framework 3.0 is installed on a system.  I just noticed a subtle point that I wanted to clarify in case anyone else runs into it as well.  We document the following registry value to use to detect the presense of the .NET Framework 3.0:

    • Registry root: HKEY_LOCAL_MACHINE
    • Key name: SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.0\Setup
    • Value name: InstallSuccess
    • Value data type: REG_DWORD
    • Value data: 1

    However, if you go and look for this value in regedit.exe on a 64-bit OS that has the .NET Framework 3.0 installed, you will not see it.  On a 64-bit OS, this detection registry value is automatically reflected by WOW64 registry redirection.  This means, you will see the value under the key HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\NET Framework Setup\NDP\v3.0\Setup.

    If you run a 32-bit application on a 64-bit OS, you can query the non-reflected registry value (without the Wow6432Node in the key name) and Windows will automatically redirect the registry query for you.  However, if you run a native 64-bit application on a 64-bit OS, or have a 32-bit process that is hosted within a 64-bit process, you will need to use an additional flag (KEY_WOW64_32KEY) when calling registry APIs to ensure that the 64-bit process can access the 32-bit registry view so that it will be able to find this .NET Framework 3.0 detection registry value.

    More information about Windows registry APIs for WOW64 scenarios can be found in the following topics on the MSDN web site:

  • Aaron Stebner's WebLog

    How to fix Application Data folder error when launching Visual Studio 2005 on Windows Vista

    • 19 Comments

    I have heard of a few instances recently where customers have installed Visual Studio 2005 on Windows Vista, and then every time they tried to launch Visual Studio, they received an error dialog with the following text:

    The Application Data folder for Visual Studio could not be created.

    This error dialog only has an OK button and clicking OK closes Visual Studio and the IDE cannot be used.

    I previously posted a description of an application compatibility warning that appears when launching Visual Studio 2005 on Windows Vista.  This warning dialog appears when attempting to launch Visual Studio 2005 on Windows Vista.

    Unfortunately, the same dialog also appears during Visual Studio 2005 setup.  If you press cancel on this dialog when it appears during setup, it can cause some of the necessary registration steps to be skipped.

    If you see this Application Data folder error dialog when launching Visual Studio 2005 on Windows Vista, there is a chance that you inadvertantly pressed cancel on this application compatibility dialog when it appeared during Visual Studio 2005 setup.  You can use the following steps to repair the Visual Studio registration on your system and resolve this error:

    1. Click on the Start menu, choose All Programs, then Accessories
    2. Right-click on the item named Command Prompt and choose Run as administrator
    3. Click continue to launch an elevated command prompt
    4. Run "%programfiles%\Microsoft Visual Studio 8\Common7\IDE\devenv.exe" /setup

    Note: the command line in step 4 assumes that you have installed Visual Studio 2005 to the default path on an x86 system.  You will need to update the command line if your system is not an x86 system or if you installed Visual Studio 2005 to a non-default path.

  • Aaron Stebner's WebLog

    Windows SDK for Windows Vista has been released

    • 2 Comments

    Today has been an exciting day for developers.  First, the final version of the .NET Framework 3.0 was released, and I just recently found out that the final version of the Windows SDK for Windows Vista has been released today as well.  Here are the download locations:

    The Windows SDK includes documentation, samples, header files, libraries and tools that can be used to develop applications using APIs that are a part of Windows Vista, including the following .NET Framework 3.0 technologies:

    • .NET Framework 2.0
    • Windows Presentation Foundation
    • Windows Communication Foundation
    • Windows Workflow Foundation
    • Windows CardSpace

    You can also read the release notes for the Windows SDK for Windows Vista by going to this location.

  • Aaron Stebner's WebLog

    The final version of the .NET Framework 3.0 is now available for download

    • 1 Comments

    I'm sure this is already old news by now, but the final version of the .NET Framework 3.0 has been released to the web and can be downloaded and installed now.  Here are the download locations:

    The web download bootstrapper is around 3 megabytes in size, and it will inventory your system and only download the components that it detects are relevant for your operating system.  This is particularly useful for systems that already have the .NET Framework 2.0 because that package comprises nearly half of the overall size of the full versions.

    The full version for x86 is 50 megabytes and the full version for x64 is 90 megabytes.  These versions are most useful for network deployment scenarios or for including on installation media for .NET Framework 3.0 applications that don't want to depend on internet access in order to deliver the components that make up the .NET Framework 3.0.

    You must make sure that you install the build of the Visual Studio 2005 extensions that is listed above.  Previous builds will not recognize that you have the final release of the .NET Framework 3.0 installed and will block you from installing.

    Important note:  If you have installed any previous beta version of the .NET Framework 3.0, you must uninstall these versions by using the entry in the Add/Remove Programs control panel before installing the final release version.

    <update date="11/7/2006"> Added a link to the Visual Studio development tools that match the final build of the .NET Framework 3.0 </update>

     

  • Aaron Stebner's WebLog

    Download Visual Studio 2005 hotfixes without contacting Microsoft Developer Support

    • 0 Comments

    I just heard about a pilot project that was introduced this past week and I wanted to let folks know about.  The Visual Studio team is making the top 10 most requested hotfixes for Visual Studio 2005 available for download on the Microsoft Connect site.  The eventual goal is to make a much larger set of hotfixes available on the Connect site, but having the top 10 hotfixes posted is a great step in that direction and I'm excited to see that we're trying to make hotfixes easier to find.

    Previously, customers who wanted to get a hotfix had to find the knowledge base article describing the fix and then contact Microsoft Developer Support.  Josh Ledgard previously wrote about an experiment his team performed to figure out how frustrating it could be to obtain Visual Studio hotfixes from Microsoft.

    You can read more background about this hotfix policy change on Brian Harry's blog.

  • Aaron Stebner's WebLog

    Why to not use gacutil.exe in an application setup

    • 32 Comments

    I read the article titled Using the .NET fusion API to manipulate the GAC yesterday.  That article describes how to call fusion APIs from C++ code to programatically add assemblies to the global assembly cache (GAC) instead of using the .NET configuration utility or gacutil.exe.

    In general, installing an assembly to the GAC is an application deployment activity, and is most often done during application setup.  The article I read does not specifically say that C++ code should be used to install assemblies during application setup, but it does not say not to either.  Therefore, I wanted to make sure that anyone reading this blog knows that you should not use C++ code or gacutil.exe to install assemblies during setup of your application.

    You should use Windows Installer to install your application.  Starting with version 2.0, Windows Installer has built-in functionality to install assemblies to the GAC - the MsiAssembly and MsiAssemblyName tables in particular.  You can refer to this MSDN document for an overview of how to add assemblies to an MSI package and this MSDN document for a description of how to add Win32 assemblies to an MSI package.  Therefore you should use this built-in functionality to handle GAC installation and uninstallation for you.

    I would also like to point out that the Windows Vista Logo Program requirements document contains the following statement:

    Gacutil must not be called from a custom action. Gacutil is not designed to be used during installation.

    This means that if you want to obtain Windows Vista Logo certification for your application, you should use Windows Installer and the built-in GAC installation functionality for your setup.

Page 1 of 2 (28 items) 12