Updated .NET Framework setup verification tool that addresses application compatibility issues

re: Updated .NET Framework setup verification tool that addresses application compatibility issues

Drewfus — Tue, 23 Oct 2012 01:06:28 GMT

Thanks Aaron.

re: Updated .NET Framework setup verification tool that addresses application compatibility issues

Aaron Stebner — Thu, 18 Oct 2012 14:02:00 GMT

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.

re: Updated .NET Framework setup verification tool that addresses application compatibility issues

Drewfus — Thu, 18 Oct 2012 07:43:20 GMT

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:

1. Reboot before you do anything else.

Or just

2. 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.

re: Updated .NET Framework setup verification tool that addresses application compatibility issues

Aaron Stebner — Mon, 01 Oct 2012 13:49:28 GMT

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.

re: Updated .NET Framework setup verification tool that addresses application compatibility issues

Drewfus — Sun, 30 Sep 2012 07:04:36 GMT

<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?