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:
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):
dotNetTester.exe 2.0
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 main() function::
// Main function
int main(int argc, char* argv[])
{
TCHAR fwVersion[VERSION];
// Ensure correct number of parameters
if(argc < 2 || argc > 3)
{
printf("Usage: dotNetTester <minimum FW version (x.y)>
[<path of app to run>]\n");
exit(-1);
}
// Check if Framework key exists and get the FW version if yes
if(CheckRegistryKeyExistance(fwVersion))
{
// Compare versions
if(CompareFWVersions(fwVersion, argv[1]))
{
// Launch an application, if the user requested it
if(3 == argc)
RunApplication(argv[2]);
}
else
{
// Minimum FW requirement not met
printf("Minimum required .NET Framework version is %s,
you have version %s installed. Please install the
proper .NET Framework\n", argv[1], fwVersion);
exit(-2);
}
}
else
{
// No FW exists
printf("Please install the latest .NET Framework -
it can be downloaded from Microsoft\n", argv[1], fwVersion);
exit(-3);
}
return 0;
}
And here's the version comparison "algorithm":
//Compare the existing and required FW version numbers
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;
// very simple comparison algorithm, really
if(requiredMajor < existingMajor)
result = true;
else if(requiredMajor == existingMajor && requiredMinor <= existingMinor)
result = true;
else
result = false;
return result;
}
The application will be launched using WinExec - the shortest and easiest function I found.
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:
WinExec function is probably obsolete, but it still works. 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.
