Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS with no warranties, and confer no rights. Additionally, views expressed herein are my own and not those of my employer, Microsoft.
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:
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:
http://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:
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:
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.
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:
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>
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
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.
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?
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?
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.
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.
Details about the .NET Framework 2.0 setup packaging Available command line switches for .NET Framework
Regarding how you could check the integrity of the files: could you verify the digital signature? I suppose hotfixes keep that up to date.
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.
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
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.
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?
こんにちは！ フォーラム オペレーターの服部 清次です 昨日、郵便局に荷物を取りに行ったら、年賀状の案内ポスターが貼ってありました。 約 60 年の歴史を持つお年玉付き年賀はがきも、最近では時代の波を反映して、当選商品にデジカメなどが用意されていますが、今年は一体どんな商品が当たるのでしょうか？
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...
Jörg
Hi Jschlager - There is information about how to run the verification tool in silent mode in the user's guide at http://blogs.msdn.com/astebner/pages/8999004.aspx. I have tried the following command line and it works fine:
netfx_setupverifier.exe /q:a /c:"setupverifier.exe /p .NET Framework 1.1"
You need to make sure the EXE is in the exact path that you're using for your command line. Also, in silent mode, the program doesn't display any progress UI during verification, so you need to look at the log files it produces to determine exactly what it is doing.
I'm not sure what the ./ syntax is that you listed before the names of the EXEs that you're running, but that could be the problem here. It gives me an error if I try to do that on my system, but that isn't being caused by the verification tool - I can't run any command with syntax like that.