Aaron Stebner's WebLog

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

September, 2005

  • Aaron Stebner's WebLog

    Set Program Access and Defaults and Windows Media Center


    I got a comment from a customer asking about the availability of some Windows features such as Internet Explorer and Windows Media Player on a Windows XP Media Center 2005 computer that they purchased from an OEM.  This comment made me realize that it is likely that not everyone out there is aware of a control panel applet called Set Program Access and Defaults (or SPAD for short) that can be used in Windows 2000 and Windows XP to control the default behavior of the OS for certain types of middleware applications such as email clients, web browsers, media players, instant messaging clients, etc.  The SPAD applet also has specific items that can be used to show or hide individual Media Center experiences (DVDs, music, radio, TV, videos and Online Spotlight).

    If you are interested in taking a look at the SPAD applet, you can get to it by opening the Add or Remove Programs control panel on a Windows 2000 Professional, Windows XP, Media Center or Tablet PC OS.  There should be an item on the left side of the Add or Remove Programs control panel called Set Program Access and Defaults.  Clicking this will open the configuration window for SPAD.  You can use this to specify default programs to use for various activities and also enable or disable access to programs.  A common usage of SPAD is to hide all entry points to Internet Explorer or Windows Media Player for example.

    If you look at the Custom settings for the SPAD configuration control panel on a Windows XP Media Center 2005 machine, it looks like the following:

    Set Program Access and Defaults

    Applications that fit into the categories in the SPAD configuration control panel can install registry keys that will cause their applications to appear in this control panel if they want to.  The registry values that control what appears in the SPAD control panel are located at HKEY_LOCAL_MACHINE\Software\Clients, and there is some good documentation regarding how to register an application to work correctly with the SPAD control panel in this MSDN article if you are interested.

    There is also some more in-depth information about the SPAD control panel in this article.


  • Aaron Stebner's WebLog

    New tool that will be integrated into the VS 2005 cleanup tool - your feedback requested


    We have seen some cases where the new VS 2005 cleanup tool fails to fully remove previous VS 2005 beta products.  Behind the scenes, the cleanup tool searches for a list of known previous beta product codes, and if it is found, it will try to run msiexec /x for each product code that is found to be installed on the machine.  However, there are some cases where msiexec /x fails to uninstall the product and additional steps need to be taken.

    In order to address this set of scenarios, I have been working on a standalone tool that can be run as an action by the cleanup tool or as a standalone tool.  There is a version of this tool, called smartmsizap, that can be downloaded from this location.  In order to use the tool, you can run smartmsizap.exe /p {product_code}.  It uses msiexec /x and msizap behind the scenes.

    I'm interested in getting feedback from anyone reading this regarding the logic behind the scenes for this tool.  Here is a rough outline of what it does behind the scenes:

    1. Takes the product code passed in with the /p switch and call MsiQueryProductState
    2. If MsiQueryProductState is equal to INSTALLSTATE_UNKNOWN or equal to INSTALLSTATE_INVALIDARG, then return without doing anything
    3. Call MsiGetProductInfo with the INSTALLPROPERTY_LOCALPACKAGE parameter to retrieve the locally cached MSI package
    4. Check to see if the locally cached MSI package exists in the expected location
    5. If it does not exist, run msizap TP {product_code} and then return
    6. If it does exist, try to run msiexec /x {product_code} /qn REBOOT=REALLYSUPPRESS and check the return code
    7. If msiexec /x returns success, then return
    8. If msiexec /x fails, run msizap TP {product_code} and then return

    I'm still testing this out in various scenarios as I run into weird dirty machine states.  But I'm curious if there are any holes in this logics that I've missed so far.  Let me know what you think by posting comments or contacting me.

    Once we get some additional testing, we'll get this exe integrated into a later version of the cleanup tool to make it able to cleanup additional scenarios that it currently can't resolve because it does not run msizap.exe currently.

    <update date="4/1/2009"> Fixed broken link to smartmsizap tool. </update>


  • Aaron Stebner's WebLog

    Undocumented unattended install switch for .NET Framework 1.1


    I was helping a customer last week who wanted to push the .NET Framework 1.1 to a series of computers in a corporate network, but wanted to show some kind of progress UI on the client computers.  I realized that we added an unattended switch to the setup wrapper for .NET Framework 1.1 based on some customer feedback from 1.0.

    You can run .NET Framework 1.1 setup with the following command line switches to install using MSI basic UI:

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

    This command line will cause the .NET Framework 1.1 to install with no user interaction required, but a small MSI progress bar will appear during installation so the user knows that something is happening on their machine.  Note that as stated above, this /qb switch was added in .NET Framework 1.1, so this switch will not work in 1.0 setup.

    Those of you with some knowledge of MSI command line parameters might ask why not just have customers extract the contents of dotnetfx.exe and then install netfx.msi directly.  Or better yet, why not have them run dotnetfx.exe /q:a /c:"msiexec /i netfx.msi /qb /l*v" or something like that to achieve the same effect without needing to write new code to support the /qb switch for install.exe.

    The answer to this is that we want customers who install the .NET Framework 1.0 and 1.1 to use install.exe to do so.  There are several reason for this:

    • We shipped .NET Framework 1.0 with some bugs that caused problems if you install using netfx.msi directly instead of going through install.exe.  Fortunately, these bugs are fixed in .NET 1.1 and beyond, but they can potentially cause servicing and uninstall problems if .NET 1.0 is installed using the MSI directly.
    • Install.exe will bootstrap and install Windows Installer 2.0 if it is not already installed on the computer.  If the .NET Framework is installed by running the MSI directly, it becomes the responsibility of the 3rd party application or administrator who is deploying the .NET Framework to ensure that Windows Installer 2.0 or higher is already installed on the machine.
    • (most importantly and most complicated to explain) Install.exe stops the Windows Installer service (named msiserver) before starting installation of the .NET Framework and after completing installation.  This helps eliminate 1935 errors that might otherwise happen while installing the .NET Framework.  Windows Installer added support for installing assemblies via native tables (MsiAssembly and MsiAssemblyName) beginning in Windows Installer version 2.0, but it requires the .NET Framework to be present becauses it uses a .NET Framework feature (called fusion) to install assemblies.  That logic works fine for "normal" applications but becomes tricky for the .NET Framework itself (which is also an MSI package and needs to install assemblies as part of its own setup).  This is what we call a "chicken and egg" problem - one has to come first but which one?  The solution we use for .NET 1.0 and 1.1 setup is to copy the the minimal pieces of the .NET Framework needed to install assemblies, and then if Windows Installer detects that the .NET Framework is not present it will use these minimal pieces to install assemblies instead of the normal mechanism.  At a really high level, the Windows Installer service will check to see if mscoree.dll exists in %windir%\system32, and if it does not, it will use the minimal pieces (located in the %windir%\system32\urttemp folder) to install assemblies.  The complicating factor here is that the Windows Installer service continues to run in the background for 10 minutes after completing any installation activity.  If Windows Installer has loaded the minimal pieces of the .NET Framework from %windir%\system32\urttemp, it will still have this version loaded in memory and if another setup needs to install assemblies within the next 10 minutes before the Windows Installer service shuts down, it will skip searching for mscoree.dll and instead use the minimal .NET Framework already loaded into memory.  If that version of the .NET Framework in memory is not compatible with the assemblies in the next setup package, Windows Installer will not know this and will try to install the new assemblies with the incompatible .NET Framework in memory, which will fail with a 1935 and/or 2908 error.  This problem is not very likely because the .NET Framework is generally designed to be backwards compatible and because it requires 2 setups to be run within 10 minutes.  A couple examples of problematic scenarios are the following:  Install .NET 1.0 and then try to install .NET 1.1 within 10 minutes by installing netfx.msi directly; and install and uninstall .NET 1.1 and then try to install .NET 1.0 within 10 minutes by installing netfx.msi directly.

    As a side note, in the .NET Framework 2.0, we implemented a custom action to install assemblies using fusion APIs directly, in part to eliminate the "chicken and egg" problem.  As a result, we see nearly no 1935 errors while installing .NET Framework 2.0.  The install.exe setup wrapper still stops the Windows Installer service before and after installation because of possible interactions with other versions of .NET Framework setup due to copies of other versions of fusion being loaded into memory during the 10 minute window that the service would otherwise stay running after installation.  Also, .NET 2.0 does not carry Windows Installer 2.0 because of the high market penetration of Windows Installer and because Windows Installer 3.1 has been posted as a mandatory update on Windows Update.  That makes bullet #2 above much less of an issue for administrators and 3rd party developers.  However, we still recommend installing .NET Framework 2.0 using the install.exe wrapper even though we've improved the scenario of installing using netfx.msi directly.

    Even though we recommend using install.exe to install the .NET Framework 1.1 and 2.0, setup will work in most cases when running the MSI directly.  It requires more care on the part of administrators or 3rd party setup developers who redistribute the .NET Framework.  In controlled environments (such as OEM pre-installations of the .NET Framework), it is much easier to control cases where the Windows Installer service might be running and shut it down separately by running net stop msiserver for example.


  • Aaron Stebner's WebLog

    Microsoft Max setup and troubleshooting links


    I wrote a post earlier this week about software that was given out to attendees at PDC 2005 and some of the setup issues I have seen or heard of related to that software.  One of the topics I touched on was Microsoft codename Max (photo sharing software built on WinFX).  A customer posted a comment to that previous post with some useful links that I also wanted to post on my main blog page in case others have problems installing or using Microsoft Max.  Here they are:


  • Aaron Stebner's WebLog

    Kids Programming Language


    I stumbled on an interesting project designed to make it easier to teach kids how to program.  It is called Kids Programming Language.  My nephew turns 2 on October 6, I wonder how much longer I'll have to wait until I can get him started with a learning system like this or like the Visual Studio 2005 express edition starter kits to turn him into a geek like his uncle?  :-)

    <update 9/29/2005>

    I found a couple of additional links talking about KPL:

    </update 9/29/2005>

  • Aaron Stebner's WebLog

    Install issues with various products given out at PDC (Vista, WinFX September CTP, .NET Framework 2.0, VS 2005, Max)


    Starting approximately this past weekend, I've started hearing from a few folks who have had questions or problems installing some of the various versions of the products given out to attendees at PDC 2005 last week.  Rob Relyea did a really nice job of outlining how to configure a WinFX development machine using the DVDs given out at PDC or using bits available for download from the web.

    I wanted to emphasize the key points that I've gathered by looking at the various packages given out at PDC, reading Rob's notes, and talking to some customers who have run into problems so far:

    • The build of Windows Vista given out at PDC (build 5219) contains a beta 2 build of the .NET Framework 2.0 (version 2.0.50215.xxx) as part of the OS.
    • The build of Visual Studio 2005 given out at PDC is a release candidate and has version 8.0.50727.26, and it requires the .NET Framework 2.0 release candidate (version 2.0.50727.26).  This can cause problems when trying to install on top of the build of Vista given out at PDC because it has an older build of the .NET Framework integrated into the OS.  I have heard of cases where installing this build of VS on Vista 5219 works and other cases where problems are encountered and setup fails.  Some VS installs may also fail due to the issue I describe here but that failure can be worked around using the workaround also listed in that post.  I need to try a more detailed repro and see the exact behavior for myself when I get more time.
    • The build of the WinFX runtime and SDK given out at PDC (the September CTP, also available for download here) includes a beta 2 build of the .NET Framework 2.0 (version 2.0.50215.xxx).  It should install and work fine on the build of Vista given out at PDC, and setup will be smart enough to skip installing the .NET Framework 2.0 because it is already a part of the OS and the version matches.
    • The build of WinFX given out at PDC will not work correctly with the build of VS 2005 given out at PDC.  As Rob describes in his blog, you need a beta 2 version of VS 2005 to use for WinFX development with the September CTP of the WinFX runtime and SDK.  VS 2005 beta 2 is still available for download here and you can opt to install the VB Express or VC# Express SKUs rather than the full version of VS 2005 beta 2.

    Another problem I have heard of that is related to the development tools passed out at PDC involves the beta version of Microsoft codename Max.  This Max beta is built on top of WinFX and it requires the September CTP of the WinFX runtime, which was given out at PDC and is available on the web.  The Max setup package will attempt to download and install the WinFX runtime if it is not already installed, but it does so by trying to download the entire 40+ megabyte package instead of using the web download bootstrapper that the standalone WinFX setup package uses.  If you encounter failures during download of Max, I suggest downloading and installing the WinFX runtime directly from the WinFX download page because the link on that page points to the WinFX setup bootstrapper.  The WinFX bootstrapper is more resilient to network hiccups (it has logic to retry the download several times before giving up), offers richer progress UI, and will skip downloading the .NET Framework 2.0 beta 2 to minimize bandwidth if it is already present (which it will be on Vista build 5219 from PDC).  I have heard of a few Max setup failures that were simply the result of a download hiccup during that 40+ megabyte download of the WinFX runtime and a lack of retries within the Max bootstrapper.  I have heard of a few others that were the result of a lack of progress feedback during Max download and user cancellations as a result.  Hopefully future versions of these setup packages will work a little smoother together in the future.  :-)

    Please feel free to contact me or post comments if you have any questions or run into any issues with any of the PDC software (or any non-PDC versions for that matter...) and I'll try my best to help out.


  • Aaron Stebner's WebLog

    How to modify the default install path in an MSI-based setup based on a registry value


    I got a question from a customer this week asking how they could modify the default installation path in their MSI-based setup package based on a value they wanted to retrieve from the registry.  Typically this kind of modification is desired if your setup shares files/components with another MSI, and that other MSI can be installed to non-default locations by another setup package.  The steps to accomplish this are roughly the following.  Please note that I am basing this algorithm on how we accomplish this inside of Visual Studio setup (I also described what happens behind the scenes in VS setup in more detail here).  There may be alternative ways to accomplish the same result.

    1. Create a new entry in the AppSearch table that contains the Signature_ you want to search for and a specific Property name that will store the data you retrieve
    2. Create an entry in the RegLocator table that has a Signature_ column name that matches the Signature_ column name you added to the AppSearch table in step 1 above and that contains the key/value you want to retrieve and use if it exists on the user's system
    3. Create an entry in the CustomAction table that has a Target value that matches the Property column name you added to the AppSearch table in step 1 above (and is in square brackets since this is an MSI property and it needs to be referenced in square brackets to resolve correctly here), and has a Source name that matches the name of the directory in the Directory table that you want to change the default installation path for
    4. Add an entry to the InstallExecuteSequence table that has an Action column name that matches the name of the custom action added in step 3 above and has a Condition column name that matches the Property column name you added to the AppSearch table in step 1 above.  This will ensure that you will only try to change the installation directory if the registry value you are searching for exists on the user's system, and your MSI will use the default installation directory if the registry value is missing.


  • Aaron Stebner's WebLog

    Cool! A Visual Studio and .NET Framework Setup dev has a blog...


    I just found out that Peter Marcu has established a blog.  He is a developer who works on setup for Visual Studio and the .NET Framework, and based on my most recent Google and MSN searches, it appears that he is the only developer on the setup team who has their own blog....


  • Aaron Stebner's WebLog

    How to fix .NET Framework install errors that ask for tmpXXXX.tmp


    I have heard from several customers who have had problems trying to repair the .NET Framework or install a .NET Framework service pack and saw an error dialog asking for the source location for tmpXXXX.tmp.  I wanted to try to explain why this can happen and also describe a way that I normally recommend to fix this issue.

    Why does this happen?

    The .NET Framework hotfix setup wrapper creates patch files on the fly in the %temp% directory that are named tmpXXXX.tmp (where XXXX is a randomly generated ending), and then deletes the file after applying the patch.  When attempting to install any .NET Framework hotfix or repair the .NET Framework, Windows Installer will perform a component health check.  If any of the components installed as part of the patch have been damaged/deleted, Windows Installer will trigger a repair and search for the files in the original install location.  In this case, the original install location does not exist because it was deleted from %temp%.

    How can I workaround this?

    I posted a complete set of steps that you can use to clean up your system and reinstall the .NET Framework at http://blogs.msdn.com/b/astebner/archive/2008/03/07/8108332.aspx. 

    <update date="5/6/2011"> Removing the old instructions in this post and pointing to updated steps. </update>


  • Aaron Stebner's WebLog

    Media Center 2005 end-to-end installation and configuration instructions


    After I posted these instructions for how to correctly install Media Center from CD, I got a mail from Charlie Owen with a link to a blog item he posted back in February that I hadn't seen at the time I wrote my post.  His post provides links to several really nice articles he wrote about how to configure a Media Center PC from scratch.  Here is a list of the topics he wrote about:

    Interestingly enough, his setup document instructs you to boot directly from Windows XP Media Center Edition 2005 CD1 to start OS setup and doesn't cover the command line switches I wrote about in my blog post.  I'd recommend using those instructions instead of trying to launch OS setup yourself unless there is some reason you need to launch OS setup directly because it is less error-prone that way.

    I strongly encourage anyone looking at building a Media Center PC to take a look at these docs if you haven't already....


  • Aaron Stebner's WebLog

    Updated VS 2005 uninstall tool is now available on MSDN


    The officially supported uninstall tool for previous beta versions of VS 2005 has been posted on MSDN.  You can download it at this location.  This uninstall tool automates the instructions located hereHong has previously posted an interim version of this tool on her blog.  Please note that this version of the cleanup tool will only work correctly if you currently have VS 2005 beta 2 or a post beta 2 CTP installed and you haven't started the uninstall process to prepare for upgrading to a later build.

    If you have already started uninstalling VS 2005 components and did not use the officially recommended uninstall order, you can try out the "find it - fix it" tool that is designed to resolve known issues that can be caused by orphaned files that we know will be left behind if VS 2005 components are uninstalled in the incorrect order.  I have heard of a few cases where this tool has crashed when people have tried to run it.  If you encounter this, please choose to send the crash report back to Microsoft.  This will allow us to debug the failure and fix the tool for future versions.


  • Aaron Stebner's WebLog

    How to manually uninstall SQL Express if uninstalling from Add/Remove Programs fails


    I have heard from a few customers (inside and outside of Microsoft) who have had problems uninstalling previous beta versions of SQL Express via Add/Remove Programs or via the cleanup tools we have released (located here and here).  These customers have seen unexpected errors in the datastore related to the actions named RestoreSetupParams and/or Write_CommitFlag.  The exact error message states that setup is unable to write property into the cache: IsClustered and unable to write property into the cache: flagCommit.

    I haven't narrowed down the exact sequence, but these uninstall errors are caused by uninstalling beta versions of SQL 2005 and/or VS 2005 in specific orders.  The officially recommended uninstall order for these products can be found at this location.  However, this order is not enforced via the Add/Remove Programs control panel and it is pretty easy to overlook the readme and uninstall in alphabetical order or some other random order and get into this state.

    If you encounter either or both of the above error dialogs, you can use the following steps to resolve the errors:

    1. Download and run msiinv.exe using the instructions in this previous blog post
    2. Look at the output from msiinv.exe in a text editor such as notepad and locate each of the products that are installed that have SQL 2005 in the name
    3. Click on the Start menu, choose Run and type cmd
    4. For each of the SQL 2005 product codes found in the msiinv.exe output, run msiexec /x {Product Code} from the cmd prompt - this command will likely generate the same errors shown above but it is good to run it just in case
    5. Download the smartmsizap tool
    6. For each of the SQL 2005 product codes found in the msiinv.exe output, run smartmsizap.exe /p {Product Code} from the cmd prompt

    After running smartmsizap to cleanup each of the SQL 2005 products left behind on your machine, you should be able to successfully install later builds of SQL Express and/or VS 2005.

    <update date="11/26/2005"> Added text descriptions of the error messages to make it more likely that this blog post will be found from internet search engines because I have heard from a lot of customers who have run into this error but not found this blog post. Also modified the uninstall instructions to use the smartmsizap tool that I had not yet written at the time that I originally wrote this blog post. </update>

    <update date="4/14/2009"> Fixed broken link to the smartmsizap tool and removed broken image links. </update>

    <update date="8/27/2010"> Fixed broken link to the VS 2005 uninstall instructions and the TTool.zip tool. </update>


  • Aaron Stebner's WebLog

    How to install Media Center from CDs


    I have seen questions from fellow Microsoft employees regarding how to install Windows XP Media Center edition on a brand new computer using the OS installation CDs.  This question has very rarely been asked by customers outside of Microsoft because Media Center is typically only available via an OEM reseller and comes pre-installed on the computer.  There are some cases where customers can buy machines with the installation CDs but do not have the OS installed, or the OEM provides recovery media on CD instead of on DVD.  This process is a little bit tricky so I decided to list the steps to install Media Center on a clean partition from CD.

    The process to install Media Center is different from the process to install XP Home/Pro because Media Center spans 2 CDs whereas the standard Windows XP Home/Pro product fits on a single CD.  It requires the following 2 steps that are different from standard XP Home/Pro OS setup:

    Launch OS setup with a special command line switch

    The following command lines can be used to launch Media Center setup from CD:

    • If you are launching OS setup from within Windows: <cd drive>\i386\winnt32.exe /makelocalsource:all
    • If you are launching OS setup from a boot floppy: <cd drive>\i386\winnt.exe /2

    The /makelocalsource:all and /2 command line parameters cause winnt32.exe and winnt.exe to copy the contents of CD1 and CD2 to the local hard drive at the beginning of OS setup.  If you fail to do this you will receive disk swap prompts during Media Center (or Tablet PC) OS installation.

    Enter a valid product key that matches the OS type you want to install

    After launching setup with one of the above command line parameters, the other step required to install Media Center instead of the standard XP Home/Pro OS is to enter a valid Media Center product key when prompted during OS setup.  Doing so will cause OS setup to install the .NET Framework 1.0 and Media Center components in addition to the standard XP Home/Pro components.  It will also cause your OS to be branded appropriately (for example - the left side of the start menu if you have your desktop configured for Windows Classic view will display "Media Center" instead of "Windows XP").

    Also, if you enter a Home/Pro product key, OS setup will not end up installing the .NET Framework 1.0 or the Media Center components, and you cannot use Media Center on the Home/Pro OS that you have just installed.

    Why the extra steps?!?

    Media Center setup ships with the core OS components on CD1 and the Media Center-specific OS components on CD2.  If you take a look at Media Center CD1 and compare it to XP Home/Pro CD1, you will see that the contents are nearly identical (with the exception of the EULA file and a couple other small things).  CD2 contains Media Center, Tablet PC and .NET Framework bits.  The decision about which bits to actually install happens at OS setup time and is controlled by the product key that you enter during OS setup.

    Note that even though I only mentioned Media Center, the above OS setup behaviors apply equally to Tablet PC.  Both Media Center and Tablet PC share the same underlying OS setup design and both require the extra command line switches and specific product key to be entered during setup to install the correct bits.


  • Aaron Stebner's WebLog

    How to fix Common IDE package load failure in VS 2005 July or August CTP


    Important note - the steps in this blog post have typically only proven useful in cases where a previous beta of Visual Studio 2005 was installed on the system prior to installing the final release of VS 2005.  If you have never had a beta of VS 2005 on your system and are encountering package load failure errors, these steps will most likely not help.  In that type of scenario, I recommend running devenv.exe with the /log switch (described in this MSDN topic) to create a log file of the packages it tries to load and then search in that log file for errors and warnings to help narrow this issue down further.  

    A few customers have contacted me because they have seen the following package load failure error message after uninstalling VS 2005 beta 1 and upgrading to the VS 2005 July or August Community Tech Preview (CTP):

    Visual Studio Common IDE Package load error

    They have all tried running the VS 2005 beta cleanup tool (located here) but did not have any success.  One of the fixes that the VS 2005 cleanup tool makes is to delete some native images, and the directory that it uses to delete the native images from is specific to VS 2005 beta 2.  However, I recently figured out that this fix needs to be modified to work correctly for post beta 2 CTP builds.  That means the current version of the cleanup tool will fix this package load error if you upgrade from beta 1 to beta 2, but not if you upgrade from beta 1 to a post beta 2 build such as the July or August CTP.

    There are a couple of options for how to fix this issue:

    1.  You can use these manual steps:

    1. Open a cmd prompt
    2. Run del %windir%\Assembly\NativeImages_v2.0.XXXXX_32\Microsoft.VisualStu# (where XXXXX is the build number of the .NET Framework 2.0 that you have installed - you can figure that out by looking at the name of the folder at %windir%\Microsoft.NET\Framework\v2.0.XXXXX)
    3. Run %windir%\Microsoft.NET\Framework\v2.0.XXXXX\ngen.exe update /queue

    The above steps will remove an incorrect native image from the native image cache and then re-run NGEN.exe to generate a new set of correct native images.

    2.  You can download a work-in-progress version of the updated VS 2005 cleanup tool

    This new version of the cleanup tool will automatically fix this issue on both VS 2005 beta 2 and post-beta 2 builds.  Please note that the cleanup tool is still being enhanced to handle additional known issues and should be used at your own risk.  Please provide feedback about this tool at this link (my contact page) and/or at this link (Hong's contact page).

    <update date="4/11/2008"> Added a caveat to the top of this post indicating that it is typically only useful on systems that had a previous beta version of Visual Studio 2005 installed. </update>


  • Aaron Stebner's WebLog

    Additional info about installing an assembly to the GAC and the local file system


    I wrote this post a couple of months ago describing how to install an assembly to both the GAC and the local file system in the same MSI.  Since then, I've been asked a couple of follow-up questions by folks who read my blog post and also by internal Microsoft setup developers.  Here is an interesting question that I wanted to share.  I helped out a developer who is using WiX to create their MSI.  They initially created a single component with 2 copies of the file but the MSI could not be created.  This is because Windows Installer does not allow you to install multiple assemblies in the same component (except in the rare case that you have a multi-module assembly).  The developer then followed the guidelines of creating 2 separate components to install the file - one for the local file system and one for the GAC.  The snippet of their WiX XML looks like this:

    <Component Id="foo.dll" Guid="23C421A5-B2AA-415b-9359-B3CC2F46D155" DiskId="1">
        Id="foo.dll" KeyPath="yes"
        Name="foo.DLL" LongName="foo.dll"
    <Component Id="foo_GAC.dll" Guid="73205F15-F5D9-4EAE-A442-025B06B1ECBF" DiskId="1">
        Id="foo_GAC.dll" KeyPath="yes" Assembly=".net" ProcessorArchitecture="msil"
        Name="foo.dll" LongName="foo.dll"

    However, when the developer ran ICE validation on the resultant MSI, it came up with the following errors:

    ICE30   ERROR The target file 'foo.dll|foo.dll' is installed in '[ProgramFilesFolder]My Folder\' by two different components on an LFN system: 'foo_GAC.dll.77A12173_4086_4E29_AEFF_562F22878D9A' and 'foo.dll.77A12173_4086_4E29_AEFF_562F22878D9A'. This breaks component reference counting.
    ICE30   ERROR The target file 'foo.dll|foo.dll' is installed in '[ProgramFilesFolder]My Folder\' by two different components on an LFN system: 'foo_GAC.dll.77A12173_4086_4E29_AEFF_562F22878D9A' and 'foo.dll.77A12173_4086_4E29_AEFF_562F22878D9A'. This breaks component reference counting.

    The problem ended up being that both components were authored to install to the same directory, which is a little misleading since the copy of the file that gets installed to the GAC does not actually get installed to the directory listed in the Component table of the MSI.  The way that the Visual Studio MSI package handles this is to create a dummy directory named \GAC underneath the local directory that each duplicated assembly is installed to on the local file system.  Then the GAC version of the component can be marked to "install" to that dummy directory, which will allow the ICE30 test to pass.


  • Aaron Stebner's WebLog

    Updated sample code that detects .NET Framework 2.0


    A while back I posted some sample code in C++ that can be used to detect whether or not the .NET Framework 1.0 or 1.1 is installed, and if so, what service pack is installed.  I've been meaning to update the code to detect 2.0.  Now that the final version number for the .NET Framework 2.0 has been locked to v2.0.50727, I don't have any excuse to put this work off any longer.  Plus I got an email from a customer asking about this detection, and that finally provided the motivation I needed to do this.  :-)  You can find updated detection code for the .NET Framework that includes 2.0 at this location.  Hope this helps!


  • Aaron Stebner's WebLog

    How to repair the .NET Framework 1.0 that ships as part of the OS on Media Center and Tablet PC


    A couple of months ago I posted some instructions about how to repair the OCM version of the .NET Framework 1.1 that ships as part of the OS on Windows Server 2003 (at this location).  When I wrote that post, I knew that there would eventually be questions about how to perform a similar repair for the version of the .NET Framework 1.0 that ships as part of the OS on Windows XP Media Center Edition and Tablet PC Edition, but I skipped those instructions at the time because they are more complicated.  Yesterday, I came to work and found a comment on one of my blog posts asking that very question, so now it is time to list these steps as well.  I apologize in advance for the complicated nature of these steps - I promise that if we knew then what we know now we would have engineered our OCM setup to make this easier.

    Here are the steps required to manually repair the .NET Framework 1.0 on Media Center and Tablet PC:

    1. Delete the registry value netfx under HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\OC Manager\Subcomponents
    2. Rename the registry values ServicePackSourcePath and SourcePath located at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup to ServicePackSourcePath2 and SourcePath2
    3. Rename the file netfxocm.dll located at %windir%\system32\dllcache
    4. Download the file netfxocm.dll (located in the zip file here) and copy it to %windir%\system32\setup.  A Windows File Protection error will likely appear shortly after doing this, and for now you can press cancel and ignore it.
    5. Create a file named netfx_repair.inf that contains the following text (or download it from here):
      Signature = "$Windows NT$"
    6. Open a cmd prompt and run the following command: sysocmgr /i:<full path to netfx_repair.inf>.  This will bring up the Windows optional component installer wizard.  Press next and installation/repair of the .NET Framework 1.0 component will begin.  You will be told that you need your original OS installation disc.  Press OK on that dialog.
    7. After pressing OK, you will be prompted to browse to the location of your OS installation disc.  In the browse dialog, you will need to browse to the folder \cmpnents\netfx\i386 on your OS installation disc or network share.  Windows XP Tablet PC Edition and Windows XP Media Center Edition include a file named netfx.cab on their installation discs in the \cmpnents\netfx\ sub-folder, and that cab file contains the files needed for the .NET Framework 1.0.
    8. After optional component setup finishes, rename the registry values ServicePackSourcePath2 and SourcePath2 located at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup to ServicePackSourcePath and SourcePath

    Note, you can verify that the .NET Framework 1.0 component was repaired by looking at the contents of the log file named %windir%\netfxocm.log.  You should see entries towards the end indicating that several files were installed to the GAC, type libraries were re-registered, performance counters were re-registered, etc.

    <update date="8/19/2007"> Added more specific details about where to browse for .NET Framework 1.0 source files </update>

    <update date="6/24/2009"> Fixed broken download links. </update>


Page 1 of 1 (17 items)