Have you ever had a client who claims that your application is constantly failing on one of his machines, only to later find he has no .NET Framework installed there? How do you test if the (right version of the) Framework exists if all your code is .NET based? This is the sort of chicken-and-egg question that requires thinking outside the box...
I manage the Professional Services team for my company. We're in charge of installation, integration and customization of our products. Every once in a while, we would have to write a small utility, wrapper, or sample code for a client. We usually use Visual Studio (2003 or 2005 - based on the client's environment) and create a .NET utility quite easily. Once the tool becomes widely used, we wrap it up in a nice MSI (created in Visual Studio as a Setup Project - no time/money for InstallShield).
An installer-deployed tool can rely on its installer to check for the existence and even provide an installation of the .NET Framework. But the greatest annoyance for us are clients who don't have the Framework installed at all, or have it on some machines. If they use our standalone (installer-less) tools, there's no way to test that the right Framework is installed. When a .NET application is run on a Framework-less machine, the results are unpredictable: the application will either not work, crash, or be frozen as an open window that does nothing...
At first, someone suggested a short VB 6 app - but that was ruled out - who's to say that our client would have VB runtime installed? This called for plain-old Win32, console application (and let's admit it, I wanted to flex those unused muscles myself).
After starting at the usual place for Microsoft related hassles (Google Microsoft Search), I got to this support article. It contains a long piece of code that checks some registry keys. The catch - it's compiled in C++ .NET. Search a little more, and you find this article, by Junfeng Zhang, which explains that you need to look at a single registry key to get the info you need:
And so, I wrote a short piece of C++ code in Visual Studio 6.0, called
dotNetTester, that does 3 simple things:
- Checks whether that key exists.
- Checks for the latest Framework version subkey underneath that key and compares it to the required FW version.
- Upon success of the first 2, launches an application (the real .NET application).
Using the application
Compile the code in Visual Studio 6.0, or just use the compiled version (unoptimized, release) like this:
dotNetTester.exe <FW version formatted major.minor>
[<path of app to run>]
For example (test for a minimum of FW 1.1 and launch an application):
dotNetTester.exe 1.1 C:\Temp\Myapp.exe
Or (test for the existence of FW 2.0, and do nothing, just report):
Now, of course, comes the packaging: we use a self-extracting, self-executing ZIP file (created with WinZip or WinRar), to launch
dotNetTester, and through it, the real app.
Luckily, they'll both be automatically extracted into the same folder, so getting the path is a non-issue.
Here's the code of the
int main(int argc, char* argv)
if(argc < 2 || argc > 3)
printf("Usage: dotNetTester <minimum FW version (x.y)>
[<path of app to run>]\n");
if(3 == argc)
printf("Minimum required .NET Framework version is %s,
you have version %s installed. Please install the
proper .NET Framework\n", argv, fwVersion);
printf("Please install the latest .NET Framework -
it can be downloaded from Microsoft\n", argv, fwVersion);
And here's the version comparison "algorithm":
bool CompareFWVersions(TCHAR *existing, TCHAR *required)
int existingMajor = atoi(existing);
int existingMinor = atoi(existing+2);
int requiredMajor = atoi(required);
int requiredMinor = atoi(required+2);
bool result = false;
if(requiredMajor < existingMajor)
result = true;
else if(requiredMajor == existingMajor && requiredMinor <= existingMinor)
result = true;
result = false;
The application will be launched using
WinExec - the shortest and easiest function I found.
Points of Interest
This is a QAD (Quick and Dirty) development, done in one seating, with plenty of music and teeth-rotting soda.
There's plenty to fix here:
- Use proper string manipulation functions.
- There's probably an easier way to read from the registry
WinExec function is probably obsolete, but it still works.
- Add support (and test) complex application paths...
In the future, I'd like to explore better ways of repackaging this tiny application.
One last point of interest: Windows Vista comes with FW 2.0 pre-installed, so my application is not needed there. Same for Windows 2003 R2.
- Version 1.0 - if people would ask for fixes, features, etc., there might be more...