回答:
それをReflectorにロードして、それが何を参照しているかを確認してください
例えば:
PowerShellでは、次を使用してターゲットランタイムを取得できます。
$path = "C:\Some.dll"
[Reflection.Assembly]::ReflectionOnlyLoadFrom($path).ImageRuntimeVersion
これを、Ben Griswoldの回答からPowerShellに適合させました。
Visual Studioで指定されたターゲットフレームワークのバージョンを知りたい場合は、以下を使用します。
$path = "C:\Some.dll"
[Reflection.Assembly]::ReflectionOnlyLoadFrom($path).CustomAttributes |
Where-Object {$_.AttributeType.Name -eq "TargetFrameworkAttribute" } |
Select-Object -ExpandProperty ConstructorArguments |
Select-Object -ExpandProperty value
あなたは次のようなものを取得する必要があります
.NETFramework、Version = v4.5.2
dotPeekは、この情報を表示するための優れた(無料の)ツールです。
Reflectorを取得する際にいくつかの問題が発生している場合、これは良い代替手段です。
ILDASMを使用できます...
ildasm.exe C:\foo.dll /metadata[=MDHEADER] /text /noil
出力の「メタデータセクション」を確認します。これは次のようなものです。
メタデータセクション:0x424a5342、バージョン:1.1、追加:0、バージョンlen:12、バージョン:v4.0.30319
'version'タグは、.NET Frameworkのバージョンを通知します。上記の例では4.0.30319です。
// Metadata section: 0x424a5342, version: 1.1, extra: 0, version len: 12, versio n: v4.0.30319
いくつかのオプションがあります。マネージコードからプログラムで取得するには、Assembly.ImageRuntimeVersionを使用します。
Dim a As Assembly = Reflection.Assembly.ReflectionOnlyLoadFrom("C:\path\assembly.dll")
Dim s As String = a.ImageRuntimeVersion
コマンドラインから、v2.0以降、「マニフェスト」をダブルクリックして「メタデータバージョン」を探すと、ildasm.exeに表示されます。画像のCLRバージョンの確認
ILSpy http://ilspy.net/を使用してください
オープンソース、無料、間違いなくオプションになりました。
ただ単に
var tar = (TargetFrameworkAttribute)Assembly
.LoadFrom("yoursAssembly.dll")
.GetCustomAttributes(typeof(TargetFrameworkAttribute)).First();
GetCustomAttributes
ませんTargetFrameworkAttribute
。ただし、ImageRuntimeVersionは正常に機能し、バイナリがビルドされた正しいCLRを取得します。それが構築された対象のフレームワークバージョンが必要です。
Visual Studioを介したさらに別のオプションとして、DLLへの参照を任意のプロジェクトに追加し、新しい参照を右クリックして[プロパティ]をクリックすると、ランタイムバージョンで探しているものが表示されます。
これを行うために、このC#コンソールアプリをすぐに作成しました。
https://github.com/stuartjsmith/binarydetailer
ディレクトリをパラメータとして渡すだけで、そこにある各dllとexeのネットフレームワークがわかるように最善を尽くします
ここでの答えを拡張すると、依存するアセンブリがある場合、これは爆発する可能性があります。あなたが幸運で、扶養家族がいる場所がわかっている場合(または幸運なことに、GACにある)、これが役立つ場合があります...
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);
}
リファレンス:https : //weblog.west-wind.com/posts/2006/Dec/22/Reflection-on-Problem-Assemblies