Determine .NET Framework version for dll

Question

I have an old dll that was compiled against the .NET framework and deployed. I am not sure which version of the .NET framework it was compiled against. I am wondering how I can determine which version of the .NET framework this dll was compiled against? I cannot trust the source code because I believe it has been upgraded to Visual Studio 2008 and changed to .NET framework version 3.5.

Answer 1

In PowerShell you can use the following to get the target runtime:

$path = "C:\Some.dll"
[Reflection.Assembly]::ReflectionOnlyLoadFrom($path).ImageRuntimeVersion

I adapted this to PowerShell from Ben Griswold's answer.

If you want to know the target framework version specified in Visual Studio, use:

$path = "C:\Some.dll"
[Reflection.Assembly]::ReflectionOnlyLoadFrom($path).CustomAttributes |
Where-Object {$_.AttributeType.Name -eq "TargetFrameworkAttribute" } | 
Select-Object -ExpandProperty ConstructorArguments | 
Select-Object -ExpandProperty value

You should get something like

.NETFramework,Version=v4.5.2

Answer 2

dotPeek is a great (free) tool to show this information.

If you are having a few issues getting hold of Reflector then this is a good alternative.

Answer 3

You can use ILDASM...

ildasm.exe C:\foo.dll /metadata[=MDHEADER] /text /noil

and check for the 'Metadata section' in the output. It would be something like this:

Metadata section: 0x424a5342, version: 1.1, extra: 0, version len: 12, version: v4.0.30319

The 'version' tag will tell you the .NET Framework version. In the above example it is 4.0.30319

Answer 4

Load it into Reflector and see what it references?

for example:

Answer 5

You have a few options: To get it programmatically, from managed code, use Assembly.ImageRuntimeVersion:

Dim a As Assembly = Reflection.Assembly.ReflectionOnlyLoadFrom("C:\path\assembly.dll")
Dim s As String = a.ImageRuntimeVersion

From the command line, starting in v2.0, ildasm.exe will show it if you double-click on "MANIFEST" and look for "Metadata version". Determining an Image’s CLR Version

Answer 6

Use ILSpy http://ilspy.net/

open source, free, definitely an option since now reflector is paid.

Answer 7

Just simply

var tar = (TargetFrameworkAttribute)Assembly
          .LoadFrom("yoursAssembly.dll")
          .GetCustomAttributes(typeof(TargetFrameworkAttribute)).First();

Answer 8

Yet another option via Visual Studio, add a reference to the DLL to any project, then right-clicking on the new reference and click Properties, you can see what you are looking for in Runtime version:

Answer 9

The simplest way: just open the .dll in any text editor. Look at one of the last lines:

Answer 10

Decompile it with ILDASM, and look at the version of mscorlib that is being referenced (should be pretty much right at the top).

Answer 11

If you have dotPeek from JetBrains, you can see it in Assembly Explorer.

Answer 12

I quickly wrote this C# console app to do this:

https://github.com/stuartjsmith/binarydetailer

Simply pass a directory as a parameter and it will do its best to tell you the net framework for each dll and exe in there

Answer 13

"Detect It Easy" also known as DiE is a program for determining types of files. Works with .dll files or other (.exe) files. Absolute free for commercial and non-commercial use.

Answer 14

Using the "read the text contents of the dll" approach:

private static readonly Regex CompiledNetCoreRegex = new Regex(@".NETCoreApp,Version=v[0-9\.]+", RegexOptions.Compiled);
private static readonly Regex CompiledNetFrameworkRegex = new Regex(@".NETFramework,Version=v[0-9\.]+", RegexOptions.Compiled);

// You can define other methods, fields, classes and namespaces here
public string GetTargetFramework(FileInfo dll)
{
    string contents = File.ReadAllText(dll.FullName);
 
    Match match = CompiledNetCoreRegex.Match(contents);
    if (match.Success)
    {
        return match.Value;
    }

    match = CompiledNetFrameworkRegex.Match(contents);
    if (match.Success)
    {
        return match.Value;
    }

    return "unable to compute target framework";
}

Answer 15

Expanding on the answers here, this can blow up if there is a dependent assembly. If you're lucky and you know where the dependent is (or even luckier, it's in the GAC) then this may help ...

using System.Reflection;
using System.Runtime.Versioning;
// ...
{
    AppDomain.CurrentDomain.ReflectionOnlyAssemblyResolve += new ResolveEventHandler(CurrentDomain_ReflectionOnlyAssemblyResolve);
    var asm = System.Reflection.Assembly.LoadFrom(@"C:\Codez\My.dll");
    var targetFrameAttribute = asm.GetCustomAttributes(true).OfType<TargetFrameworkAttribute>().FirstOrDefault();
    targetFrameAttribute.Dump();
}

Assembly CurrentDomain_ReflectionOnlyAssemblyResolve(object sender, ResolveEventArgs args)
{
    var name = args.Name;

    if (name.StartsWith("Depends"))
        return System.Reflection.Assembly.ReflectionOnlyLoadFrom(@"C:\Codez\Depends.dll");

    return System.Reflection.Assembly.ReflectionOnlyLoad(args.Name);
}

Reference: https://weblog.west-wind.com/posts/2006/Dec/22/Reflection-on-Problem-Assemblies