Determinar la versión de .NET Framework para dll


137

Tengo un viejo dll que se compiló contra .NET Framework y se implementó. No estoy seguro de con qué versión de .NET Framework se compiló. Me pregunto cómo puedo determinar con qué versión del .NET Framework se compiló este dll. No puedo confiar en el código fuente porque creo que se ha actualizado a Visual Studio 2008 y se ha cambiado a .NET Framework versión 3.5.


Respuestas:


49

¿Cargarlo en Reflector y ver a qué hace referencia?

por ejemplo:

ingrese la descripción de la imagen aquí


1
Mi idea también, pero conociendo el reflector, probablemente se quejará y le dará un buen ícono de error no descriptivo.
leppie

@leppie No debería ser un problema, incluso si es .NET 1.1. Simplemente cambie su lista de ensamblaje predeterminada.
ParmesanCodice

Su respuesta es muy útil, pero le aconsejo que no confíe en ella a ciegas: ayer pasé demasiado tiempo en mi propio proyecto que estaba dirigido a .Net 4.0, que Reflector informó que usaba .Net 4.0.3, y requería usarlo. .Net 4.5 por Windows :-) No conozco ningún método para verificar esto en el proyecto que no sea con las fuentes - ver aquí: stackoverflow.com/questions/13214503/…
greenoldman

3
También puede utilizar la alternativa gratuita de código abierto ILSpy como lo señala Kat Lim Ruiz.
Marcus Mangelsdorf

Esta respuesta funcionó para mí: stackoverflow.com/a/3461027/2961177 .
ckkkitty 01 de

128

En PowerShell puede usar lo siguiente para obtener el tiempo de ejecución de destino:

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

Adapte esto a PowerShell de la respuesta de Ben Griswold .

Si desea conocer la versión del marco de destino especificada en 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

Deberías obtener algo como

.NETFramework, Versión = v4.5.2


44
Esta respuesta es la más útil. Todos los sistemas operativos Windows posteriores a 2003 son compatibles con Powershell. Un shell que proporciona retroalimentación inmediata, que no requiere ningún soporte de aplicación adicional como sugieren muchas de las otras respuestas. Genial para un "único" chequeo de un dll. eres el hombre @swoogan.
Nathan McCoy

1
Hice esto para una DLL que construí con una TargetFrameworkVersion de v3.5, y devolvió v2.0.50727. ¿Qué me estoy perdiendo?
BHSPitMonkey

44
@BHSPitMonkey solo ha habido 4 versiones de tiempo de ejecución: 1.0, 1.1, 2.0 y 4.0. .NET 3.0 y 3.5 compilan a CLR versión 2.0. msdn.microsoft.com/en-us/library/bb822049(v=vs.110).aspx
Swoogan

1
Este script solo proporciona RuntimeVersion, la pregunta es sobre TargetFrameworkversion. Efectivamente para todos los ensamblados compilados contra 2.0,3.0,3.5, este script muestra la versión Runtime como 2.0.0.0
Kiran Vedula

3
Para mí, ReflectionOnlyLoadFrom devuelve ImageRuntimeVersion pero cero CustomAttributes. Usar LoadFrom en lugar de ReflectionOnlyLoadFrom da el resultado esperado. ¿Cualquier razón? PSVersion 5.1.16299.251 CLRVersion 4.0.30319.42000
Bernard Vander Beken

69

dotPeek es una gran herramienta (gratuita) para mostrar esta información.

Si tiene algunos problemas para obtener Reflector, esta es una buena alternativa.

ingrese la descripción de la imagen aquí


44
Para su información, cambié de DotPeek a JustDecompile debido a un problema: si selecciona "versión específica = falso", DotPeek muestra una versión vacía y JustDecompile muestra la versión correcta. Hizo que valiera la pena cambiarme.
cenizas999

Genial: hice exactamente lo que quería sin instalar una versión de prueba para Reflector.
bernhardrusch

49

Puedes usar ILDASM ...

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

y verifique la sección 'Metadata' en la salida. Sería algo como esto:

Sección de metadatos: 0x424a5342, versión: 1.1, extra: 0, versión len: 12, versión: v4.0.30319

La etiqueta 'versión' le indicará la versión de .NET Framework. En el ejemplo anterior es 4.0.30319


3
¿Qué estoy buscando aquí? ¿Esto significa .NET 4.0? // Metadata section: 0x424a5342, version: 1.1, extra: 0, version len: 12, versio n: v4.0.30319
PeterX

Sí, para .NET 2 obtengo lo siguiente: // Sección de metadatos: 0x424a5342, versión: 1.1, extra: 0, versión len: 12, versión: v2.0.50727
Simon

17

Tiene algunas opciones: para obtenerlo mediante programación, desde el código administrado, use Assembly.ImageRuntimeVersion:

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

Desde la línea de comandos, comenzando en v2.0, ildasm.exe lo mostrará si hace doble clic en "MANIFEST" y busca "Versión de metadatos". Determinación de la versión CLR de una imagen


¿Cómo obtener ImageRuntimeVersion para CurrentAppDomain?
Kiquenet


15

Así de simple

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

1
No sé por qué se ha rechazado esto, pero puedo ejecutar el fragmento (se necesita una referencia a System.Runtime.Versioning) y obtener con éxito la salida (esto es de LINQPad): TypeId typeof (TargetFrameworkAttribute) FrameworkName .NETFramework, Versión = v4.0 FrameworkDisplayName .NET Framework 4
Sudhanshu Mishra

Este código no recupera la versión completa del marco. Es bueno saber "4.0", pero "v4.0.30319" sería más útil si, por ejemplo, intentara acceder a RegAsm.exe. La información más completa sobre la versión se puede encontrar en: string tar = Assembly.LoadFrom (@ "myAssembly.dll"). ImageRuntimeVersion;
Martin

Este parece ser el enfoque correcto, ¿hay alguna circunstancia en la que un ensamblado no tenga este atributo aplicado? Lo probé con un ensamblado .NET Core e informa correctamente netcore y el número de versión.
Adam Naylor

Esto no funciona para mi. El GetCustomAttributesno tiene un TargetFrameworkAttribute. Pero ImageRuntimeVersion funciona bien, recupera el CLR correcto para el que se creó el binario. Necesito la versión de framework de destino para la cual fue construida.
Shameel Mohamed

13

Otra opción más a través de Visual Studio, agrega una referencia a la DLL a cualquier proyecto, luego haz clic derecho en la nueva referencia y haz clic en Propiedades, puedes ver lo que estás buscando en la versión Runtime:

ingrese la descripción de la imagen aquí


Creo que esta pregunta no es acerca de cuándo se hace referencia a una DLL en Visual Studio, sino sobre cualquier DLL .NET antigua que encuentre en su PC.
cenizas999

77
Esta respuesta indica que puede agregar una referencia a cualquier DLL .NET antiguo que encuentre en su PC, y una de las propiedades del elemento en las Referencias correspondientes a esa DLL es la "Versión de tiempo de ejecución".
ALEXintlsos

8

Descompílelo con ILDASM y mire la versión de mscorlib a la que se hace referencia (debería estar más o menos en la parte superior).


4

La forma más simple: simplemente abra el archivo .dll en cualquier editor de texto. Mira una de las últimas líneas: ingrese la descripción de la imagen aquí


La mejor opción entre todas
Sisir

2
Sin embargo, esto no funciona para dlls construidos antes de .Net 3.0
Sisir

2

Rápidamente escribí esta aplicación de consola C # para hacer esto:

https://github.com/stuartjsmith/binarydetailer

Simplemente pase un directorio como parámetro y hará todo lo posible para decirle el marco de red para cada dll y exe allí


Da buena información detallada; es una aplicación de línea de comandos; tienes que pasarle el nombre del directorio en la línea de comandos.
philu

2

" Detect It Easy ", también conocido como DiE, es un programa para determinar tipos de archivos. Funciona con archivos .dll u otros archivos (.exe). Absoluto libre para uso comercial y no comercial.

ingrese la descripción de la imagen aquí


0

Si tienes DotPeekde JetBrains, puedes verlo en Assembly Explorer.

¿Puedes ver esta captura de pantalla?  no soy:(


0

Ampliando las respuestas aquí, esto puede explotar si hay un ensamblaje dependiente. Si tiene suerte y sabe dónde está el dependiente (o incluso más afortunado, está en el GAC), entonces esto puede ayudar ...

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);
}

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.