How check if an executable is compatible to the installed .NET version

Question

I'm a software tester. I was given an executable to test on a given machine. In the test the executable behaved strangly which could not be explained by anybody.

After a lot of research and debugging I found the cause: The executable that was built for .NET target framework 4.6, but the machine was equipped with .NET 4.5. This produced some "MissingMethodExeception" for even trivial methods like "string.Format()". Some try-catch caught these exceptions, but treated them in wrong way because nobody had expected them to occur.

A likewise issue has been described here:

Method not found: 'System.String System.String.Format(System.IFormatProvider, System.String, System.Object)

My questions:

1. Isn't Windows meant to warn me when I'm trying to run an executable that cannot be run properly since the necessary .NET version is not available?
2. What is the best practise to deal with this problem in general?

(I would have expected something like a checkbox "Dont execute if target network is not available" in VisualStudio?!)

Answer 1

Isn't Windows meant to warn me ...

You'll certainly should get a warning, not from Windows but from the CLR. The dialog looks like this, clicking Yes automatically gets the required framework version deployed and installed on the machine. The CLR performs this check by looking for the [TargetFramework] attribute embedded in the assembly. As noted, run ildasm.exe to verify this attribute. With the expectation that it is either missing or has a low enough value so the dialog does not trigger.

What is the best practice to deal with this problem in general?

It is procedural mistake, the assembly was built wrong. You know with high confidence that the compiler used reference assemblies that are only appropriate for .NET version 4.6. That has to be traced back to the machine that built it, most likely to be a build server. It was not setup correctly, the kind of mishap that is so common when the build engineer cut corners by avoiding using a licensed copy of Visual Studio. Or by favoring freeware tooling, Jenkins is a common scourge.

Beyond getting the [TargetFramework] attribute wrong or missing, this particular mishap is particularly easy to induce. All it takes is using the assemblies in c:\windows\microsoft.net\framework as reference assemblies instead of the proper ones that require a targeting pack and are installed in the c:\program files (x86)\reference assemblies directory. This Q+A has more leads.

Fixing a build server tends to have lots of resistance points, best thing to do as a tester is to file a bug report. You also want to write one for the broken catch-em-all exception handling that made the problem so difficult to diagnose.