Updated .NET Framework setup verification tool that addresses application compatibility issues
A little while ago, I posted an updated version of the .NET Framework setup verification tool that enabled support for the .NET Framework 4.5 and Windows 8. I used the Windows 8 Release Preview to test that version of the tool, and an application compatibility shim was added to the final version of Windows 8 that causes the .NET Framework setup verification tool to silently exit and return success. This was done to address application compatibility issues such as this.
This week, I’ve posted an updated version of the .NET Framework setup verification tool that has a couple of key changes to react to the application compatibility issues that led to this shim being added to Windows 8. Here is a brief summary of the changes:
Updated pass/fail logic
The logic for determining success and failure for .NET Framework setup verification has been updated. Previously, the tool would report errors if any file that was supposed to be installed by a given version of the .NET Framework was not found on the computer. Now, missing files are logged as warnings instead of errors because many of the files installed by the .NET Framework are not critical to the functionality of the .NET Framework. The only things that will cause the verification tool to report an error are the following:
- Missing registry keys that are used by applications to detect whether or not the .NET Framework is installed (as documented in the deployment guide for each version of the .NET Framework).
- Failure to run a sample application that verifies that the .NET Framework runtime can be started correctly.
Silent mode has been removed
The .NET Framework setup verification tool no longer supports running in silent mode. While it was never officially supported to do so, some applications have redistributed older versions of the .NET Framework setup verification tool in their installers. They would run the verification tool in silent mode, and in some cases they would prevent the user from installing their application if the verification tool reported any failures. This has caused application compatibility issues (such as this) as new versions of Windows and the .NET Framework have been released.
You can download the latest version of the .NET Framework setup verification tool by using the links in the User’s Guide. As always, if you run into any issues or have any feedback about the .NET Framework setup verification tool, please let me know by posting a comment on one of my blog posts or by using the contact form.
Comments
Anonymous
September 29, 2012
<i>The only things that will cause the verification tool to report an error are the following: •Missing registry keys that are used by applications to detect whether or not the .NET Framework is installed (as documented in the deployment guide for each version of the .NET Framework). •Failure to run a sample application that verifies that the .NET Framework runtime can be started correctly.</i> Aaron, my layman's interpretation of this is that requiring apps to check registry keys to detect .Net Framework installations is too brittle a method. Registry keys and values might be okay for not-quite-critical stuff like ARP, but functionality checks should be more robust, especially if the functionality is part of the OS setup. Why can't app installers include or utilize an inbox dNF verifier? More generally - it would be handy for image builders (like me) to be able to run apps in a verify-only mode, like this; > winword.exe /verify /close This would open the app, bypassing any runonce or open file dialog logic, and then when all critical dlls have loaded, close the app and return an appropriate errorlevel. If the return code is zero, i can be confident the app will work once the image is deployed, plus the secondary benefit of building Prefetch data. Non-zero return codes could be detected in aggregating log; > findstr :[1-9] %temp%appAudit.log Put another way, if it's appropriate for the OS to have an audit mode, why not apps?Anonymous
September 30, 2012
Hi Drewfus - I don't know of any inbox .NET Framework verifiers like the one you describe for Microsoft Office. The registry keys that are checked by my .NET Framework verification tool are the same keys that are publicly documented in the .NET Framework deployment guides. These keys are the recommended way for application developers to detect whether or not they should install the .NET Framework as a part of their setup process. Because of their recommended usage, I think those registry keys are important enough to need to be verified by this tool. I agree with you that using registry keys to detect the install state of the .NET Framework is not foolproof, but it is the way that is publically documented.Anonymous
October 17, 2012
Thanks Aaron. "I don't know of any inbox .NET Framework verifiers like the one you describe for Microsoft Office." Ok. I meant more that Office apps should have these "audit mode" switches, natively. "The registry keys that are checked by my .NET Framework verification tool are the same keys that are publicly documented in the .NET Framework deployment guides. These keys are the recommended way for application developers to detect whether or not they should install the .NET Framework as a part of their setup process. Because of their recommended usage, I think those registry keys are important enough to need to be verified by this tool." Understood and point taken. However, as you describe, your verification tool also "run[s] a sample application that verifies that the .NET Framework runtime can be started correctly." That's great, so i suppose i'm just wondering out loud; why can't the dotNetFramework include a small, GUI-less app that tests dotNet functionality, rather than just having to have faith in the correctnesss of registry keys? But you have already answered that. :-) Lets see if i can't ask something less hypothetical... Suppose a user wants to install an app that has a dependency on a dotNetFramework version not currently installed. The user installs the required dotNet version successfully, but the installer indicates a reboot is required. Ok, so can the user go ahead and install the app anyway, and reboot after that installation, or should they reboot immediately after the dotNet install? I know its a simple question, but i'm not sure if there is a general answer. Another example; in another post we were recently talking about Media Center, and i mentioned about building an MCE2005 master image, in case i came across a machine still running this. So when i did this, i kept wondering things like; Okay, i've just installed Update Rollup 2, and Windows wants to reboot, but can i install October 2006 Update Rollup first ( which is dependent on Update Rollup 2), or should i reboot and then reboot again? This is an old OS, so i'm just using this as an example. So does 'reboot required' mean:
- Reboot before you do anything else. Or just
- A reboot is required to complete the installation, but postpone this if necessary, including to install other software that is dependent on the software that requires the reboot. ?
Anonymous
October 17, 2012
Hi Drewfus - There isn't a one-size-fits-all answer to the reboot required question. It depends on the program that asks for the reboot. When a setup asks for a reboot, it is nearly always because a file that the setup needs to install/update is in use by another program on the computer, so the file can't be replaced until after the next reboot. The behavior that you'll see when skipping a reboot depends on what file was in use. The safest thing to do in this type of scenario would be to reboot if a setup indicates that one is needed just in case. In the case of the .NET Framework, it can be chained in with other setup programs, and if it requests a reboot, it is safe to defer that reboot until the end of the overall installation process. However, it is not safe to defer the reboot indefinitely and proceed to try to use the application after the overall setup process completes.Anonymous
October 22, 2012
Thanks Aaron.