Targeting multiple .NET frameworks in a single binary?

Question

The Background:

I have an application that needs to run on clients whose installed .NET frameworks range all the way from 2.0 up to 4.5. This application has to be able to enumerate and perform operations on large numbers of files (in excess of 200k discrete files, in select cases).

To build the index of files, the application currently uses System.IO.DirectoryInfo.GetFiles(). This comes at a performance hit, as the processing component has to wait for the entirety of the Path tree to be indexed before it can start work. Due to some archaic tape multiloaders and some poorly written firmware, traversing some directories can trigger reads from tapes - jacking the processing time from tens of seconds to tens of minutes.

.NET 4.0 provides the System.IO.Directory.EnumerateFiles(Path) method, which alleviates this problem. However, only a few of the datter consoles have been upgraded to 4.0+, and our pleas to modernize have been met with hostility.

The Question:

Is it possible to implement methods for both GetFiles and EnumerateFiles in a single binary? Effectively, this would be a single binary targeted to .NET 2.0, with the ability to call a .NET 4.0 method if it was determined at runtime that the 4.0 framework was available.

Before it's mentioned: changing out the datters is not an option to our client. I've tried. Have I ever tried.

Answer 1

You won't be able to (easily) make a single binary that works on .NET 2.0 and uses the .NET 4.0 methods. There are all kinds of roundabout ways - reflection etc., but those seem like a bad idea in your case.

However, there's no reason why you can't make your own implementation for EnumerateFiles in a .NET 2.0 library. For this you'd make P/Invoke calls to the WIN32 functions FindFirstFile and FindNextFile. Two CodeProject projects look like they cover this area, and should have the right bits in the source:

• http://www.codeproject.com/Articles/12782/File-System-Enumerator-using-lazy-matching
• http://www.codeproject.com/Articles/38959/A-Faster-Directory-Enumerator