Introduction

When you want to know which .NET Framework a DLL targets, you are really trying to identify the assembly's target framework metadata, not just the CLR version. Those are related, but they are not the same thing, and using the wrong signal can lead to incorrect compatibility assumptions.

Look for TargetFrameworkAttribute

The most direct clue is usually the assembly's TargetFrameworkAttribute. You can read it with reflection:

1using System;
2using System.Linq;
3using System.Reflection;
4using System.Runtime.Versioning;
5
6class Program
7{
8    static void Main()
9    {
10        var assembly = Assembly.LoadFrom("MyLibrary.dll");
11        var tfm = assembly.GetCustomAttributes(typeof(TargetFrameworkAttribute), false)
12                          .Cast<TargetFrameworkAttribute>()
13                          .FirstOrDefault();
14
15        Console.WriteLine(tfm?.FrameworkName ?? "No TargetFrameworkAttribute found");
16    }
17}

Typical output looks like .NETFramework,Version=v4.7.2. That is usually the answer people actually need.

CLR Metadata Is Not the Whole Story

Tools such as ILDASM or decompilers can also show the metadata runtime version, for example something like v4.0.30319. That is useful, but it does not uniquely identify the exact target framework version.

For example, many different .NET Framework versions use the CLR 4 runtime family. So:

• CLR version tells you the runtime generation,
• target framework tells you the intended framework contract.

If you need compatibility or deployment guidance, prefer the target framework value.

Use ILDASM or a Decompiler

If you do not want to write code, tools can show the same information. Open the DLL in ILDASM, ILSpy, dotPeek, or a similar decompiler and inspect the assembly metadata.

In many tools you will find either:

• the target framework attribute,
• the runtime metadata version,
• or both.

That makes GUI tools useful for one-off inspections when you are debugging a deployment issue or reviewing third-party binaries.

PowerShell Example

PowerShell can also inspect the target framework attribute:

1$asm = [Reflection.Assembly]::LoadFrom("MyLibrary.dll")
2$attr = $asm.GetCustomAttributesData() |
3    Where-Object { $_.AttributeType.FullName -eq "System.Runtime.Versioning.TargetFrameworkAttribute" }
4
5$attr.ConstructorArguments[0].Value

This is handy in build scripts, deployment checks, or quick local diagnostics on Windows systems.

If you prefer a GUI path, ILSpy and similar tools often expose the same target framework information in the assembly metadata view, which is convenient when you are investigating a third-party DLL and do not want to write a helper script.

Be Careful With Modern .NET

Not every DLL targets classic .NET Framework. Some target .NET Core, .NET 5 and later, or .NET Standard. The same inspection technique still helps, but the output may look different, for example .NETStandard,Version=v2.0.

That is why the question should usually be framed as "what target framework does this assembly declare?" rather than "what .NET Framework version is this DLL?"

That wording is more precise and avoids false certainty in cases where the assembly can run in more than one compatible environment.

Common Pitfalls

• Using only the CLR metadata version and assuming it uniquely identifies the framework version.
• Confusing .NET Framework with .NET Standard or modern .NET.
• Assuming every DLL will contain the same metadata pattern, especially older or unusual assemblies.
• Using file version or product version instead of target framework metadata.
• Treating the target framework as a guarantee that every runtime dependency is available on the destination machine.

Summary

• The best signal is usually the assembly's TargetFrameworkAttribute.
• CLR metadata version is informative, but it is not the same as the exact target framework.
• Reflection, PowerShell, ILDASM, and decompilers can all reveal the relevant metadata.
• Modern assemblies may target .NET Standard or newer .NET, not classic .NET Framework.
• Use target framework data for compatibility checks, not file version numbers.