Determinare la versione di .NET Framework per dll


137

Ho una vecchia dll che è stata compilata contro il framework .NET e distribuita. Non sono sicuro su quale versione di .NET framework sia stata compilata. Mi chiedo come posso determinare su quale versione del framework .NET è stata compilata questa dll? Non posso fidarmi del codice sorgente perché credo che sia stato aggiornato a Visual Studio 2008 e modificato in .NET Framework versione 3.5.


Risposte:


49

Caricalo in Reflector e vedi a cosa fa riferimento?

per esempio:

inserisci qui la descrizione dell'immagine


1
Anche la mia idea, ma conoscendo il riflettore, probabilmente si lamenterà e gli darà una bella icona di errore non descrittiva.
leppie,

@leppie Non dovrebbe essere un problema, anche se è .NET 1.1. Basta cambiare l'elenco di assiemi predefinito.
ParmesanCodice

La tua risposta è molto utile, ma ti consiglio di non fare affidamento su di essa alla cieca: ieri ho trascorso troppo tempo sul mio progetto che era stato preso di mira per .Net 4.0, segnalato da Reflector per l'uso di .Net 4.0.3 e richiesto .Net 4.5 da Windows :-) non so alcun metodo per verificare questo su progetto diverso da quello con le fonti - si veda qui: stackoverflow.com/questions/13214503/...
greenoldman

3
Puoi anche usare l'alternativa gratuita e open source ILSpy come notato da Kat Lim Ruiz.
Marcus Mangelsdorf,

Questa risposta ha funzionato per me: stackoverflow.com/a/3461027/2961177 .
ckkkitty,

128

In PowerShell è possibile utilizzare quanto segue per ottenere il runtime di destinazione:

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

L'ho adattato a PowerShell dalla risposta di Ben Griswold .

Se si desidera conoscere la versione del framework di destinazione specificata in Visual Studio, utilizzare:

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

Dovresti ottenere qualcosa del genere

.NETFramework, Version = v4.5.2


4
Questa risposta è la più utile. Tutti i sistemi operativi Windows dopo il 2003 supportano Powershell. Una shell che fornisce un feedback immediato, senza richiedere alcun supporto applicativo aggiuntivo, come suggeriscono molte altre risposte. Ottimo per un controllo "una tantum" di una dll. sei l'uomo @swoogan.
Nathan McCoy,

1
L'ho fatto per una DLL che ho creato con TargetFrameworkVersion di v3.5 e ha restituito v2.0.50727. Cosa mi sto perdendo?
BHSPitMonkey l'

4
@BHSPitMonkey ci sono state solo 4 versioni di runtime: 1.0, 1.1, 2.0 e 4.0. .NET 3.0 e 3.5 vengono compilati in CLR versione 2.0. msdn.microsoft.com/en-us/library/bb822049(v=vs.110).aspx
Swoogan

1
Questo script fornisce solo RuntimeVersion, la domanda riguarda TargetFrameworkversion. In modo efficace per tutti gli assembly compilati con 2.0.3.0,3.5 questo script mostra la versione Runtime come 2.0.0.0
Kiran Vedula

3
Per me ReflectionOnlyLoadFrom restituisce ImageRuntimeVersion ma zero CustomAttributes. L'uso di LoadFrom invece di ReflectionOnlyLoadFrom fornisce il risultato previsto. Qualche ragione? PSVersion 5.1.16299.251 CLRVersion 4.0.30319.42000
Bernard Vander Beken

69

dotPeek è un ottimo strumento (gratuito) per mostrare queste informazioni.

Se stai riscontrando alcuni problemi per ottenere Reflector, questa è una buona alternativa.

inserisci qui la descrizione dell'immagine


4
Cordiali saluti, sono passato da DotPeek a JustDecompile a causa di un problema: se si seleziona "versione specifica = falso", DotPeek ha mostrato una versione vuota e JustDecompile mostra la versione corretta. Mi è valsa la pena cambiare per me.
ashes999,

Fantastico: ha fatto esattamente quello che volevo senza installare una versione di prova per Reflector.
Bernhardrusch,

49

Puoi usare ILDASM ...

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

e controlla la sezione "Metadata" nell'output. Sarebbe qualcosa del genere:

Sezione metadati: 0x424a5342, versione: 1.1, extra: 0, versione len: 12, versione: v4.0.30319

Il tag 'version' ti dirà la versione di .NET Framework. Nell'esempio sopra è 4.0.30319


3
Cosa sto cercando qui? Questo significa .NET 4.0? // Metadata section: 0x424a5342, version: 1.1, extra: 0, version len: 12, versio n: v4.0.30319
PeterX,

Sì, per .NET 2 ottengo quanto segue: // Sezione metadati: 0x424a5342, versione: 1.1, extra: 0, versione len: 12, versione: v2.0.50727
Simon

17

Hai alcune opzioni: Per ottenerlo a livello di codice, dal codice gestito, usa Assembly.ImageRuntimeVersion:

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

Dalla riga di comando, a partire dalla v2.0, ildasm.exe lo mostrerà se si fa doppio clic su "MANIFEST" e si cerca "Versione metadati". Determinazione della versione CLR di un'immagine


Come ottenere ImageRuntimeVersion per CurrentAppDomain?
Kiquenet,


15

Semplicemente

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

1
Non so perché questo sia stato sottoposto a downgrade, ma posso eseguire lo snippet (è necessario un riferimento a System.Runtime.Versioning) e ottenere correttamente l'output (questo è da LINQPad): TypeId typeof (TargetFrameworkAttribute) FrameworkName .NETFramework, Versione = v4.0 FrameworkDisplayName .NET Framework 4
Sudhanshu Mishra

Questo codice non recupera la versione completa del framework. "4.0" è utile, ma "v4.0.30319" sarebbe più utile se, ad esempio, cercassi di accedere a RegAsm.exe. Le informazioni sulla versione più completa sono disponibili in: string tar = Assembly.LoadFrom (@ "myAssembly.dll"). ImageRuntimeVersion;
Martin,

Questo sembra l'approccio giusto, ci sono circostanze in cui un assembly potrebbe non avere questo attributo applicato? L'ho provato con un assembly .NET Core e riporta correttamente netcore e il numero di versione.
Adam Naylor,

Questo non funziona per me. Il GetCustomAttributesnon ha un TargetFrameworkAttribute. Ma ImageRuntimeVersion funziona benissimo, ma recupera il CLR giusto per cui è stato creato il binario. Ho bisogno della versione del framework di destinazione per cui è stata creata.
Shameel Mohamed,

13

Ancora un'altra opzione tramite Visual Studio, aggiungi un riferimento alla DLL a qualsiasi progetto, quindi fai clic con il tasto destro del mouse sul nuovo riferimento e fai clic su Proprietà, puoi vedere cosa stai cercando nella versione Runtime:

inserisci qui la descrizione dell'immagine


Penso che questa domanda non si ponga quando si fa riferimento a una DLL in Visual Studio, ma a qualsiasi altra DLL .NET che trovi in ​​giro sul tuo PC.
ashes999,

7
Questa risposta indica che è possibile aggiungere un riferimento a qualsiasi vecchia DLL .NET che si trova in giro sul PC e una delle proprietà dell'elemento in Riferimenti corrispondenti a quella DLL è la "Versione runtime".
ALEXintlsos,

8

Decompilalo con ILDASM e osserva la versione di mscorlib a cui viene fatto riferimento (dovrebbe essere praticamente in alto).


4

Il modo più semplice: basta aprire il DLL in qualsiasi editor di testo. Guarda una delle ultime righe: inserisci qui la descrizione dell'immagine


L'opzione migliore tra tutte
Sisir

2
Tuttavia, questo non funziona per le dll create prima .Net 3.0
Sisir

2

Ho scritto rapidamente questa app console C # per fare questo:

https://github.com/stuartjsmith/binarydetailer

Passa semplicemente una directory come parametro e farà del suo meglio per dirti il ​​framework di rete per ogni dll ed exe presente


Fornisce buone informazioni dettagliate; è un'app da riga di comando; devi passare il nome della directory dalla riga di comando.
philu

2

" Detect It Easy " noto anche come DiE è un programma per determinare i tipi di file. Funziona con file .dll o altri file (.exe). Assolutamente gratuito per uso commerciale e non commerciale.

inserisci qui la descrizione dell'immagine


0

Se avete DotPeekda JetBrains, si può vedere in Assembly Explorer.

Riesci a vedere questo screenshot?  non sono:(


0

Espandendo le risposte qui, questo può esplodere se c'è un gruppo dipendente. Se sei fortunato e sai dove si trova la persona a carico (o anche più fortunata, è nel GAC), questo può aiutare ...

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

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

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.