Aaron Stebner's WebLog

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

January, 2010

  • Aaron Stebner's WebLog

    TurboTax 2009 can fail to install because it thinks the .NET Framework is not installed, even when it is

    • 109 Comments

    I’ve heard from a few customers over the past few days who have had trouble installing the new 2009 version of TurboTax.  In the cases I’ve heard about so far, the installer for TurboTax reports that the .NET Framework 3.5 SP1 is not correctly installed and instructs the user to re-install it.  Unfortunately, attempts to uninstall and re-install the .NET Framework did not help in some of these cases.

    Behind the scenes, it appears that TurboTax setup is running a verification process that is similar to the .NET Framework setup verification tool.  This verification process checks that files and registry keys that should be installed by the .NET Framework 2.0, 3.0 and 3.5 setup packages are correctly installed on the computer.  It is possible for the .NET Framework to be installed but for some of the files and/or registry values to have been removed by some other program (such as a registry cleaner tool, a disk cleanup tool, or even manual deletion by the user).

    If TurboTax reports a problem with the .NET Framework 3.5, it suggests that you try to uninstall and re-install the .NET Framework 3.5.  However, the exact steps needed to do this depend on what version of Windows you are running, and this has ended up causing confusion for the users I’ve heard from so far because the different steps aren’t very well documented in general.

    For Windows XP and Windows Server 2003

    If you are running a version of Windows before Windows Vista (such as Windows XP or Windows Server 2003), then in most cases, you can use the entry in Add/Remove Programs to repair the .NET Framework 3.5 or 3.5 SP1.  If that doesn’t help, then you can use the steps in this blog post to remove and then re-install the .NET Framework 3.5 SP1.

    For Windows Vista or Windows Server 2008

    If you are running Windows Vista or Windows Server 2008, then the .NET Framework 2.0 and 3.0 are installed as OS components.  As a result, the repair steps are more complicated.  You will need to try the following:

    1. Try to repair the .NET Framework 3.5 or 3.5 SP1 using the entry in the Programs and Features control panel.
    2. If that doesn’t help, try to use the steps in this blog post to remove and re-install the .NET Framework 3.5 SP1.
    3. If the above steps do not help, run sfc.exe /scannow to attempt to repair the files that are a part of your OS (which will also repair some parts of the .NET Framework).

    For Windows 7

    If you are running Windows 7, then the .NET Framework 2.0, 3.0 and 3.5 are all installed as OS components, and you cannot remove or re-install these versions using the Programs and Features control panel.  On Windows 7, this is your only built-in repair option:

    Run sfc.exe /scannow to attempt to repair the files that are a part of your OS (which will also repair some parts of the .NET Framework).

    What to do if the above doesn’t help

    Unfortunately, sfc.exe will only repair files that are protected by Windows Resource Protection.  For the .NET Framework, only binary files that can be repaired using sfc.exe.  Non-binary files (such as .config files) and registry keys cannot be repaired using sfc.exe.  For non-binary files, the only options are to manually replace them with files from other computers or to repair your OS.  For registry keys, the only options are to manually re-create them in regedit.exe or to repair your OS.

    Here are some steps I’ve been able to use to narrow down the exact missing files and/or registry keys that cause TurboTax setup to think that the .NET Framework 3.5 SP1 is not correctly installed:

    1. Download and run the TurboTax verification utility from http://turbotax.intuit.com/support/kb/installing/errors/7659.html
    2. When the utility finishes, click the button named Save Logs on Desktop
    3. Go to your desktop and open the zip file named TurboTax2009UtilityLogFiles*.zip
    4. Find the file named *_TurboTax 2009 Utility – *.log (where the first * is a date-time stamp and the 2nd * is a version number)
    5. Search for the string ****ERROR**** in this log file and take note of the files and/or registry keys that it reports are missing

    From the information in this log file, it is usually possible to figure out what files and/or registry keys need to be manually repaired on the computer.  So far, the cases I’ve seen reported missing .config files and we have been able to get TurboTax setup to run correctly after copying the .config files from another computer or downloading them from here and putting them in the locations reported in this log file.

    If you run into problems getting TurboTax 2009 setup to run correctly due to errors related to the .NET Framework 3.5, I encourage you to try the steps above.  If they don’t help, please don’t hesitate to leave a comment on my blog and/or contact me and I’ll try to help as best as I can.

    <update date="2/3/2010"> Added a link to a zip file that I posted with the .config files that have been causing the majority of the issues with TurboTax setup that I've seen so far. </update>

     

  • Aaron Stebner's WebLog

    A simpler way to add Windows Installer major upgrade functionality to your MSI in WiX v3.5

    • 5 Comments

    Bob Arnson has been working on some simplifications to the WiX language in WiX v3.5, and he has posted some introductory information about a couple of these changes on his blog.  I wanted to link to them here to hopefully help raise visibility for these simplifications:

    I have found the major upgrade simplifications to be particularly useful.  A while back, I wrote a step-by-step guide for authoring, building and testing major upgrades using WiX, and that guide later got added to the WiX documentation.

    As you can see in Bob’s blog post and in the WiX MajorUpgrade element documentation, Bob’s simplifications will allow WiX v3.5 to handle creating the Upgrade table elements, scheduling the RemoveExistingProducts action, and optionally blocking downgrades if a user tries to install an older version of the MSI after installing a newer version.  You only need to make sure that you include UpgradeCode and Version attributes in your Product element, and then you can use the new MajorUpgrade element in your WiX v3.5 authoring.

    If you choose to, you can continue to use the more verbose syntax described in my previous blog post or the WiX documentation for authoring a major upgrade, but you could instead convert to the new MajorUpgrade element in order to more clearly express the behavior you intend for your MSI and to simplify your setup authoring.

    The major upgrade and component authoring functionality described in the above blog posts is available in WiX v3.5 builds starting with the v3.5.1315.0 build on SourceForge, and I encourage you to check them out.

Page 1 of 1 (2 items)