Partager via

Draft version of a new .NET Framework setup verification tool available for download

  • Article

A while ago, I published a .NET Framework setup verification tool that can be run to provide a sanity check of the install state of the .NET Framework 1.0, 1.1 and 2.0 on a system.  However, there are some limitations in that tool:

  • It does not support validating the .NET Framework 2.0 on Windows Vista
  • It does not support the .NET Framework 2.0 SP1, the .NET Framework 3.0, the .NET Framework 3.0 SP1 or the .NET Framework 3.5
  • It only checks file version information and does not check registry values created by setup
  • It depends on the setup technology used to install the product in the first place (Windows Installer or OS install technologies) and requires you to select an OS-specific version of the product in the UI in order to get accurate verification results
  • It reports misleading warnings if hotfixes for the .NET Framework are installed on the system

As a result, I decided to create a new verification tool, and I have an initial version that I think is ready for more people to use.  I wanted to post some information about the tool so that folks can try it out to verify the installation state of the various versions of the .NET Framework on their systems.

Where to download the new verification tool

I have a draft version of a new verification tool that can be used to verify all versions of the .NET Framework (1.0, 1.1, 2.0, 2.0 SP1, 3.0, 3.0 SP1 and 3.5) on any supported OS and processor architecture.  You can find information about the tool and download it from this location:

https://blogs.msdn.com/astebner/pages/8999004.aspx

The UI for the tool is straightforward - it contains a drop-down list box that lets you choose the version of the .NET Framework that you would like to verify and a Verify Now button to initiate the verification process for the chosen product.  After verification completes, it will display results for the chosen product and allow you to select additional products to verify.

I have been testing this new version on several systems that I have access to, but there are likely to still be issues where the tool falsely reports errors or misses some error cases.  Please let me know if you see any issues while using this tool by posting comments on this blog post or by contacting me directly.  If possible, please include information about your scenario and copies of the log files that I describe below so I can continue to make this tool better in the future.

How to run the tool in silent mode

This verification tool supports running in silent mode if you would like to automate the verification process.  To run in silent mode, you need to download the verification tool .zip file, extract the file netfx_setupverifier.exe from the .zip file, and then run it using syntax like the following:

netfx_setupverifier.exe /q:a /c:"setupverifier.exe /p <name of product to verify>"

The value that you pass with the /p switch to replace <name of product to verify> in this example must exactly match one of the products listed in the file setupverifier.ini that is included in the self-extracting package for the verification tool.

Currently, the verification tool includes the following product names that can be passed in using the /p switch:

  • .NET Framework 1.0
  • .NET Framework 1.1
  • .NET Framework 2.0
  • .NET Framework 2.0 SP1
  • .NET Framework 2.0 SP2
  • .NET Framework 3.0
  • .NET Framework 3.0 SP1
  • .NET Framework 3.0 SP2
  • .NET Framework 3.5
  • .NET Framework 3.5 SP1

For example, if you would like to run the tool in silent mode and verify the install state of the .NET Framework 2.0, you would use a command line like the following:

netfx_setupverifier.exe /q:a /c:"setupverifier.exe /p .NET Framework 2.0"

The verification tool returns the following exit codes:

  • 0 - cleanup completed successfully for the specified product
  • 1 - the required file setupverifier.ini was not found in the same path as setupverifier.exe
  • 2 - a product name was passed in that cannot be verified because it does not support installing on the OS that the tool is running on
  • 3 - a product name was passed in that does not exist in setupverifier.ini
  • 100 - verification failed for the specified product
  • 1602 - verification was canceled

Logging

This verification tool creates 2 log files by default that can be used to determine what actions the tool is taking and what errors it encounters while verifying a product.  The 2 log files are listed below, and they are created in the %temp% directory by default.  Note that you can find the %temp% directory by clicking on the Windows start menu, choosing Run, typing %temp% and clicking OK to open the directory in Windows Explorer.

  • %temp%\setupverifier_main_*.txt - this log contains information about all actions taken during a verification tool session; it will include information about each resource that the tool attempts to verify for a chosen product and whether or not that resource was found on the system; this log tends to be fairly long, so errors will be logged with the prefix ****ERROR**** to make it easy to search and find them
  • %temp%\setupverifier_errors_*.txt - this log only contains information about any errors found during verification of a chosen product

A new pair of log files will be created each time the verification tool is launched.  The date and time the tool is launched will be appended to the end of the log file names by default in place of the * in the names listed above.  If you want to control the exact names used for the log files, you can use the following command line parameters:

  • /l <filename> - specifies a name to replace the default value of setupverifier_main_*.txt for the main activity log for the verification tool
  • /e <filename> - specifies a name to replace the default value of setupverifier_errors_*.txt for the error log for the verification tool

For example, the following command line will allow you to specify non-default names for both log files:

netfx_setupverifier.exe /q:a /c:"setupverifier.exe /l %temp%\my_main_log.txt /e %temp%\my_error_log.txt"

<update date="9/2/2009"> Fixed broken link to the verification tool. </update>

Comments

  • Anonymous
    March 03, 2008
    I've used this tool before to check if a certain version of .NET was installed on my system: http://www.asoft.be/prod_netver.html It is very easy for users to find out if they have a particular version, and if even provides links to the download site of the particular version if it's needed to install. For the .NET developers they allow you to distribute it along with their tools. My 2cts

  • Anonymous
    March 04, 2008
    Hi JeroenV - Thanks for sending the link to this utility.  I can't tell how in-depth this tool goes in checking the install state of the .NET Framework though. I have run into cases in the past where the registry value that is officially documented as the way to detect the .NET Framework install state exists, yet something is wrong with the install and it doesn't work correctly.  That is the type of scenario I was targeting when I created the verification tool described in this blog post.

  • Anonymous
    March 06, 2008
    Does this verification tool check the integrity of the .NET files (check to see if any files might be corrupted), or does it only check if the files are installed?

  • Anonymous
    March 06, 2008
    Hi Lrios80 - Currently, the tool only checks for the existence of files in specified locations.  I am open to suggestions regarding checking for corruption.  The previous version of the tool contained some checksum information that it would compute and compare against, but that logic doesn't work if any service packs or hotfixes are installed for the .NET Framework.  Do you know of any other ways to check for file corruption from a tool like this? Also, have you run into cases where files have gotten corrupted for the .NET Framework?  If so, do you have any more information about how that happened and how you figured out the root cause?

  • Anonymous
    March 07, 2008
    I've run into some cases where programs would not load, so .NET had to be uninstalled then reinstalled or repaired before it would work. The only time I've been able to find a specific cause for it was when SP1 for .NET 2.0 was downloaded and installed and the installation failed. (I'm not sure if this would be file corruption or if some files were removed when SP1 tried to install and then were not restored when the installation failed.) .NET 2.0 had to be completely uninstalled then reinstalled.

  • Anonymous
    March 07, 2008
    Hi Lrios80 - Thanks for providing more details about this scenario.  I'll keep an eye out and see if I run into any similar .NET Framework 2.0 SP1 failures and check out the exact state of the files that are a part of the .NET Framework in that case.  If you run into this again, can you also try out the new verification tool and see if it reports any errors that might help narrow this down further? It would also help if you could send me any log files you have from one of these failures - the .NET Framework 2.0 SP1 creates a verbose log named %temp%dd_net_framework*.txt during installation.  You can send the log to Aaron.Stebner (at) microsoft (dot) com.

  • Anonymous
    March 28, 2008
    The comment has been removed

  • Anonymous
    April 16, 2008
    Regarding how you could check the integrity of the files: could you verify the digital signature? I suppose hotfixes keep that up to date.

  • Anonymous
    April 17, 2008
    Hi Szilvaa - Yes, I think that would help for files that are digitally signed.  I'm not sure it fully guarantees that the files are not corrupt, but it would be a step in the right direction.  The trick there is that not all files in the .NET Framework are digitally signed, so the tool would need to keep track of which ones are and which ones aren't.  I'll look into options for doing something like this in the future.

  • Anonymous
    September 30, 2008
    Hi Aaron Is there a nice way to use your tool to scan dotnet installs across a LAN (assuming authentication requirement has been met)? Currently the best we have is the prospect of rclienting and running against network share and collating on network share. Your thoughts would be most welcome. Cheers, G

  • Anonymous
    September 30, 2008
    Hi Elguido - This verification tool is designed to run on the local computer and return results from that computer.  It doesn't support running remotely across a network.  What I'd suggest doing here is scheduling some kind of job/task to run the tool on the machines on your network, and then collect the logs it creates and upload them to a network share for centralized analysis.  Hopefully this will be feasible in your scenario.

  • Anonymous
    September 30, 2008
    That could work for us, thanks Aaron. The only reason I asked is your method involves loads of signoffs and the like, the approach I'm heading from is something that the frontline support staff (of which I am a member) can organize on their own users. If there is any scope to handle UNCs that'd be excellent? Cheers, G

  • Anonymous
    October 14, 2008
    こんにちは！ フォーラム オペレーターの服部 清次です 昨日、郵便局に荷物を取りに行ったら、年賀状の案内ポスターが貼ってありました。 約 60 年の歴史を持つお年玉付き年賀はがきも、最近では時代の波を反映して、当選商品にデジカメなどが用意されていますが、今年は一体どんな商品が当たるのでしょうか？

  • Anonymous
    November 03, 2008
    Hi Aaron, I'm trying to use the draft version of your tool in silent mode on my local machine. The interactive version is working fine, but I had no success using the /p switch so far. I've used the syntax from the included readme.txt and after a call to ./netfx_setupverifier.exe /q:a /c:"setupverifier.exe /p .NET Framework 1.1" the program quits without any noticeable action and without setting the exit code. Even if I extract the files from the archive and call ./setupverifier /e "d:error.txt" /l "d:log.txt" /p ".NET Framework 1.1" nothing happens. I've tried both with and without quotes, using cmd32 and the windows power shell and would appreciate any hints... Cheers, Jörg

  • Anonymous
    November 04, 2008
    The comment has been removed

  • Anonymous
    November 04, 2008
    Hi, the syntax I've posted is for calling the executable from the windows power shell. I've tried with cmd32 and without the "./" part, but had no success. The setupverifier does not do anything on my system when started in silent mode. There is no logfile or errorfile, the executable just returns immediately without setting the exit code. BTW, I'm using a modified MUI version of Windows XP SP2, currently with the German language packs. Again, the interactive version is working fine.

  • Anonymous
    November 05, 2008
    The comment has been removed

  • Anonymous
    December 02, 2008
    PingBack from http://wickedw.wordpress.com/2008/12/02/visual-studio-2008-sp-and-net-framework-35-sp1-has-not-installed-but-says-it-has/

  • Anonymous
    December 27, 2008
    The comment has been removed

  • Anonymous
    January 03, 2009
    Hi Jamieleecho - The .NET Framework setup verification tool is a Windows application, not a console application.  This means that it returns the appropriate error code to the calling process in this type of scenario, but it does not update the %errorlevel% environment veriable that it sounds like you're checking in your scenario.  You'll need to have your calling process check the return code and/or manually set the errorlevel to the return code of the verification tool if you need it to work the way you're describing.

  • Anonymous
    February 10, 2009
    PingBack from http://hlcit.wordpress.com/2009/02/10/failure-of-net-framework-update/

  • Anonymous
    February 27, 2009
    Hi, I used your program to check if .net framework was correctly installed on a win98 machine - it reported me several missing dll files and following errors: Error: GetProcAdress failed for SHGetFolderPath with error code 127 Error: Unable to ind an ExecutablePath value for custom action 'Custom Action - .NET framework 2.0 test application', exiting now I guess these two are connected somehow, but I dont know how to fix it. There is already the shfolder.dll in windowssystem what else do I need to do?

  • Anonymous
    February 28, 2009
    Hi Spaceship - To fix the missing files, I'd suggest uninstalling and re-installing the version(s) of the .NET Framework that you have installed on your system.  The steps at http://blogs.msdn.com/astebner/archive/2008/03/07/8108332.aspx might be helpful too if you run into any uninstall issues. For those 2 errors in the verification tool, could you please upload your verification tool log files to a file server (such as http://skydrive.live.com) and then reply back with a link to the server location so I can take a look and see if I can figure out why the tool is reporting those errors on your system?

  • Anonymous
    July 12, 2011
    Hi Aaron,   can we use this tool to determine whether .Net 3.5 Language Pack SP1 (for different languages) is installed? If not, do you know any tool or utility or documentation that help us to determine this? Thanks in advance. -Vinay

  • Anonymous
    July 12, 2011
    Hi Vinay - No, the verification tool does not support verifying the .NET Framework language packs.  I haven't run into enough installation problems with the language packs to justify the work needed to update the tool to support the language packs.  Are you seeing specific problems that you're trying to diagnose?  If so, I could look into adding some verification logic to the tool for you or something like that.  I'd like to understand more about the issues you're seeing first though if possible.

  • Anonymous
    December 29, 2011
    Ich hoffe du kannst es übersetzen ^^ Ich versuch schon länger das programm zu installieren, aber jedes mal stürzt es ohne Grund ab. Und ich habe nichts gefunden was helfen könnte... Bitte um Rückmeldung Leon

  • Anonymous
    December 29, 2011
    Hi Leon - Are you seeing this crash when you try to install the .NET Framework, or when you try to run the verification tool?  If it is when running the verification tool, please download the new version that I posted today - I have made a couple of fixes that should solve these issues. If you try with the latest version of the tool from today and it still crashes, please let me know which exact version of the .NET Framework you are trying to verify, which version of Windows you have on your computer, and if possible, please upload your verification tool log file to a file server (such as http://skydrive.live.com) and reply back here and provide a link that I can use to download your log file and take a closer look.