Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Languages / C++

Is .NET Framework installed on this machine???

4.22/5 (13 votes)
26 Apr 20073 min read 1   3.2K  
Find out if .NET Framework is installed on the machine, before running your .NET code-based program.
Screenshot - dotNetTester.gif

Introduction

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

Background

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:

Registry key and subkeys we're looking for

And so, I wrote a short piece of C++ code in Visual Studio 6.0, called dotNetTester, that does 3 simple things:

  1. Checks whether that key exists.
  2. Checks for the latest Framework version subkey underneath that key and compares it to the required FW version.
  3. 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):

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.

The code

Here's the code of the main() function::

C++
// 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":

C++
//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.

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
  • The 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.

History

  • Version 1.0 - if people would ask for fixes, features, etc., there might be more...

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here