Determinar a versão do .NET Framework para dll


137

Eu tenho uma dll antiga que foi compilada na estrutura .NET e implantada. Não tenho certeza em qual versão do .NET framework foi compilada. Gostaria de saber como posso determinar em qual versão do .NET framework essa dll foi compilada? Não posso confiar no código-fonte porque acredito que ele foi atualizado para o Visual Studio 2008 e alterado para o .NET framework versão 3.5.


Respostas:


49

Carregue-o no Reflector e veja o que ele faz referência?

por exemplo:

insira a descrição da imagem aqui


1
Minha idéia também, mas conhecendo o refletor, provavelmente ele irá reclamar e fornecer um bom ícone de erro não descritivo.
Leppie

@ leppie Não deve ser um problema, mesmo que seja o .NET 1.1. Apenas mude sua lista de montagem padrão.
ParmesanCodice

Sua resposta é muito útil, mas aconselho a não confiar nela cegamente - ontem passei muito tempo em meu próprio projeto, direcionado ao .Net 4.0, relatado pelo Reflector para usar o .Net 4.0.3, e necessário o uso .Net 4.5 pelo Windows :-) Eu não sei qualquer método para verificar isso no projeto diferente com fontes - veja aqui: stackoverflow.com/questions/13214503/...
greenoldman

3
Você também pode usar a alternativa gratuita de código aberto ILSpy, conforme observado por Kat Lim Ruiz.
Marcus Mangelsdorf 02/02

Esta resposta funcionou para mim: stackoverflow.com/a/3461027/2961177 .
Ckkitty

128

No PowerShell, você pode usar o seguinte para obter o tempo de execução de destino:

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

Adaptei isso ao PowerShell a partir da resposta de Ben Griswold .

Se você deseja conhecer a versão da estrutura de destino especificada no 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

Você deve obter algo como

.NETFramework, Versão = v4.5.2


4
Esta resposta é a mais útil. Todos os sistemas operacionais Windows após 2003 oferecem suporte ao Powershell. Um shell que fornece feedback imediato, não exigindo nenhum suporte adicional a aplicativos, como muitas das outras respostas sugerem. Ótimo para uma verificação "única" de uma dll. você é o homem @swoogan.
Nathan McCoy

1
Fiz isso para uma DLL que construí com uma TargetFrameworkVersion da v3.5 e ela retornou a v2.0.50727. o que estou perdendo?
BHSPitMonkey

4
@BHSPitMonkey, na verdade, existem apenas 4 versões de tempo de execução: 1.0, 1.1, 2.0 e 4.0. .NET 3.0 e 3.5 compilam para CLR versão 2.0. msdn.microsoft.com/pt-br/library/bb822049(v=vs.110).aspx
Swoogan

1
Este script fornece apenas RuntimeVersion, a pergunta é sobre TargetFrameworkversion. Eficazmente para todos os conjuntos compilados contra 2.0,3.0,3.5 este script mostra a versão Runtime como 2.0.0.0
Kiran Vedula

3
Para mim, o ReflectionOnlyLoadFrom retorna o ImageRuntimeVersion, mas zero CustomAttributes. Usar LoadFrom em vez de ReflectionOnlyLoadFrom fornece o resultado esperado. Qualquer razão? PSVersion 5.1.16299.251 CLRVERSION 4.0.30319.42000
Bernard Vander Beken

69

O dotPeek é uma ótima ferramenta (gratuita) para mostrar essas informações.

Se você está tendo alguns problemas para se apossar do Reflector, essa é uma boa alternativa.

insira a descrição da imagem aqui


4
Para sua informação, mudei do DotPeek para o JustDecompile por causa de um problema: se você selecionar "versão específica = false", o DotPeek exibia uma versão vazia e o JustDecompile exibia a versão correta. Valeu a pena mudar para mim.
ashes999

Ótimo - fiz exatamente o que eu queria sem instalar um teste para o Reflector.
precisa saber é o seguinte

49

Você pode usar o ILDASM ...

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

e verifique a seção "Metadados" na saída. Seria algo como isto:

Seção de metadados: 0x424a5342, versão: 1.1, extra: 0, versão len: 12, versão: v4.0.30319

A tag 'version' informará a versão do .NET Framework. No exemplo acima, é 4.0.30319


3
O que estou procurando aqui? Isso significa .NET 4.0? // Metadata section: 0x424a5342, version: 1.1, extra: 0, version len: 12, versio n: v4.0.30319
PeterX

Sim, para o .NET 2, recebo o seguinte: // Seção de metadados: 0x424a5342, versão: 1.1, extra: 0, versão len: 12, versão: v2.0.50727
Simon

17

Você tem algumas opções: para obtê-lo programaticamente, a partir do código gerenciado, use Assembly.ImageRuntimeVersion:

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

Na linha de comando, começando na v2.0, o ildasm.exe o mostrará se você clicar duas vezes em "MANIFEST" e procurar "Versão dos metadados". Determinando a versão CLR de uma imagem


Como obter ImageRuntimeVersion para CurrentAppDomain?
Kiquenet


15

Simplesmente

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

1
Não sei por que isso foi recusado, mas posso executar o snippet (é necessária uma referência ao System.Runtime.Versioning) e obter a saída com êxito (do LINQPad): TypeId typeof (TargetFrameworkAttribute) FrameworkName .NETFramework, Versão = v4.0 FrameworkDisplayName .NET Framework 4
Sudhanshu Mishra

Este código não recupera a versão completa da estrutura. "4.0" é bom saber, mas a "v4.0.30319" seria mais útil se você estivesse, digamos, tentando acessar o RegAsm.exe. As informações da versão mais completa podem ser encontradas em: string tar = Assembly.LoadFrom (@ "myAssembly.dll"). ImageRuntimeVersion;
Martin Martin

Essa parece ser a abordagem correta. Existem circunstâncias em que um assembly pode não ter esse atributo aplicado? Testei-o com um assembly .NET Core e ele relata corretamente o netcore e o número da versão.
Adam Naylor

Isso não funciona para mim. O GetCustomAttributesnão tem a TargetFrameworkAttribute. Porém, o ImageRuntimeVersion funciona bem, ele recupera o CLR correto para o qual o binário foi criado. Eu preciso da versão da estrutura de destino para a qual ela foi criada.
Shameel Mohamed

13

Ainda outra opção via Visual Studio, adicione uma referência à DLL a qualquer projeto, clique com o botão direito do mouse na nova referência e clique em Propriedades, para ver o que você está procurando na versão Runtime:

insira a descrição da imagem aqui


Eu acho que essa pergunta não está perguntando sobre quando uma DLL é referenciada no Visual Studio, mas qualquer DLL do .NET antiga que você encontra por aí no seu PC.
ashes999

7
Esta resposta indica que você pode adicionar uma referência a qualquer DLL do .NET antiga encontrada no seu PC e uma das propriedades do item nas Referências correspondentes a essa DLL é a "Versão de Tempo de Execução".
ALEXintlsos

8

Descompile-o com o ILDASM e observe a versão do mscorlib que está sendo referenciada (deve estar praticamente no topo).


4

A maneira mais simples: basta abrir o .dll em qualquer editor de texto. Veja uma das últimas linhas: insira a descrição da imagem aqui


A melhor opção entre todos
Sisir 13/01

2
No entanto, isso não funciona para DLLs construídas antes .Net 3.0
Sisir

2

Eu rapidamente escrevi este aplicativo de console em C # para fazer isso:

https://github.com/stuartjsmith/binarydetailer

Basta passar um diretório como parâmetro e ele fará o possível para informar a estrutura da rede para cada dll e exe lá


Dá boas informações detalhadas; é um aplicativo de linha de comando; você precisa passar o nome do diretório na linha de comando.
philu 24/06

2

" Detect It Easy ", também conhecido como DiE, é um programa para determinar tipos de arquivos. Funciona com arquivos .dll ou outros arquivos (.exe). Absolutamente livre para uso comercial e não comercial.

insira a descrição da imagem aqui


0

Se tiver DotPeekde JetBrains, você pode vê-lo em Assembly Explorer.

Você consegue ver esta captura de tela?  Eu não estou:(


0

Expandindo as respostas aqui, isso pode explodir se houver uma montagem dependente. Se você tiver sorte e souber onde está o dependente (ou ainda mais, está no GAC), isso pode ajudar ...

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

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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.