Abrufen von Ziel-Framework-Version-und Ziel-Rahmen-Profil aus .Net-Assembly

Gibt es irgendeine Möglichkeit, dass ich Zugriff auf die Werte, die verwendet wurden, für TargetFrameworkVersion und/oder TargetFrameworkProfile wenn ein .Net-assembly kompiliert wurde?

Die Werte, die ich spreche, sind diejenigen, die enthalten die Projekt-Datei

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <OtherStuff>
    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
    <TargetFrameworkProfile>Client</TargetFrameworkProfile>
    <OtherStuff>
  </PropertyGroup>
  <OtherStuff>
  </OtherStuff>
</Project>

Im Grunde möchte ich herausfinden, was das Ziel Version des Frameworks wurde, wenn die assembly kompiliert wurde und wenn möglich den Ziel-Rahmen-Profil als gut.

- Und ich spreche nicht über die aktuell geladene version der CLR, Umwelt.Version nicht das, was ich bin nach.

Idealerweise die Lösung wäre die Verwendung von System.Reflexion aber wenn ich Zuflucht zu anderen Methoden, die ich will.

Ich glaube, die TargetFrameworkProfile betrifft nur die Verweise in Visual Studio können Sie aus dem Projekt. Ich glaube nicht, dass etwas kompiliert wird in der output-Baugruppe.
Damien ich denke, Sie sind richtig. Ich sehe es nicht als ein verfügbaren Projekt-level-Eigenschaft, die übergeben werden kann, um MSBuild. Wenn es nicht zu MSBuild, dann ist es sicherlich nicht gehen, um in die Assembly eingebettet. Ich kann immer noch Leben in der Hoffnung, dass TargetFrameworkVersion ist eingebettet in dort irgendwo obwohl.
public string TargetFrameworkProfile { get; set; } Microsoft.Bauen.Aufgaben

InformationsquelleAutor Scott | 2011-07-28

12

Wenn du zufrieden mit der version der CLR, dass die kompilierte assembly, die Sie verwenden können, die Assembly.ImageRuntimeVersion Eigenschaft. Laut MSDN ist, wird die Eigenschaft:

vertreten die version der common language runtime (CLR) gespeichert in der Datei mit dem manifest.

und

Standardmäßig ImageRuntimeVersion eingestellt ist, um die version der CLR verwendet, um erstellen Sie die assembly. Es kann sich jedoch gesetzt wurden, auf einen anderen Wert zur compile-Zeit.

Natürlich, dass doesn ' T geben Sie die spezifische version des .NET-Framework (zum Beispiel: .NET Frameworks 2, 3.0 und 3.5 sind alle auf der CLR 2.0).

Wenn die CLR-version ist nicht ausreichend, Sie könnten versuchen, zu "schätzen" (Vermutung intelligent), welche version es basiert auf den Versammlungen, auf den es verweist. Für .NET 1 und 4, die CLR-version sollte genug sein. Allerdings, wenn die CLR-version 2.0 hat, würde man nicht wissen, ob das bedeutete, 2.0, 3.0, oder 3.5, so dass Sie versuchen könnte, etwas mehr Logik. Zum Beispiel, wenn Sie sah, dass die Assembly verwiesen wird System.Core (mit Assembly.GetReferencedAssemblies()), dann würden Sie wissen, dass die version 3.5 seit System.Core war neu in 3.5. Das ist nicht gerade "rock solid", da die Versammlung in Frage stellen könnten, nicht zu verwenden, alle Typen aus der Assembly, so dass Sie wäre nicht in der Lage zu fangen, die. Versuchen, Sie zu fangen mehr Fällen könnten Sie eine Schleife durch alle die referenzierten Assemblys und überprüfen Sie Ihre version zahlen - vielleicht filtern, um nur Baugruppen, die mit beginnen System, Fehlalarme zu vermeiden mit anderen Bibliotheken. Wenn Sie sehen, alle System.* Assemblys verwiesen wird, dass eine version von 3.5.x.x, dann kann man auch ziemlich sicher sein, gebaut wurde es für 3.5.

Als Sie bemerkt haben, ich glaube nicht, dass die TargetFrameworkProfile entweicht Vergangenheit Visual Studio. Jedoch, wenn es geschieht, um eine app.config-Datei für die Anwendung, Visual Studio kann das Ziel-framework in es. Zum Beispiel, wenn Sie Projekt zu verwenden, den 4.0 Client Profile, erstellt Visual Studio eine app.config wie hier:
```
<?xml version="1.0"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0,Profile=Client"/>
  </startup>
</configuration>
```
- Ich habe R1.dll mit Ziel-Framework 4.5 und R2.dll mit Ziel-Framework 4.0. CLR 4.0 für beide dll. dann habe ich P1.dll compiliert mit Ziel-Framework 4.0. Kann P1.dll Referenzen R1.dll in der Ausführungszeit ?
- Dies scheint, wie etwas nicht Frage. Sie möchten möglicherweise überprüfen Sie heraus andere Fragen, die sind genauer mit deiner Frage. Zum Beispiel: Ist es möglich, die Referenz auf eine assembly, die Ziele .net 4.5 in einem Projekt, die Ziele 4.0? oder Upgrade auf .Net 4.5 Ursachen der Montage zu scheitern?
- Dank Stephen McDaniel - ich hatte gehofft, dass jemand kommen würde, zusammen mit einer besseren Antwort, aber ich glaube nicht, dass das passieren wird. Es scheint, dass die korrekte Antwort "Nein", aber ich nehme Ihre Antwort, denn es enthält einige nützliche Infos sowieso.
- Sehr interessante Antwort. Ich bin überrascht, zu finden, die das unterstützt .NET-runtime ist so obskur, zu finden aus einer assembly, die noch gute Arbeit mit der "Vermutung intelligent" - Ansatz. Haben Sie eine Idee haben, oder einen Verweis auf mich zu, wie Mono-Griffe diesem? Ich kenne die version von mono ist irrelevant für die unterstützt .NET-runtime mono-kompilierte assembly unterstützen können. Immer noch Frage ich mich, würde Ihr trick funktionieren in der gleichen Weise für Assemblys kompiliert mit mono?
- Ich würde erwarten, dass meine raten Logik zu arbeiten, auch im Rahmen von mono. Ich warf einen Blick auf eine zufällige Klasse, dass ich weiß, existiert nur in .net 3.5 ( "System".Linq -.Zählbare) und die mono-version, die ist auch erklärt in der System.Core.dll - Datei. Ich würde erwarten, dass die meisten Arten, so zu sein als gut. Aber wahrscheinlich der beste Weg, sicher zu wissen, wäre, um es zu testen und sehen. 🙂
InformationsquelleAutor Stephen McDaniel

Wenn die assembly kompiliert wurde, mit dem TargetFrameworkAttribute (assembly scoped), können Sie einfach und einheitlich bestimmen Sie die Rahmen-Profil Ziel.

Probieren Sie dieses Beispiel aus, und verweisen Sie Ihre eigenen benutzerdefinierten Assemblys mit verschiedenen Zielen.

class Program
{
    static void Main(string[] args)
    {


        //Lets examine all assemblies loaded into the current application domain.
        var assems = AppDomain.CurrentDomain.GetAssemblies();

        //The target framework attribute used when the assemby was compiled.
        var filteredType = typeof(TargetFrameworkAttribute);

        //Get all assemblies that have the TargetFrameworkAttribute applied.
        var assemblyMatches = assems.Select(x => new { Assembly = x, TargetAttribute = (TargetFrameworkAttribute)x.GetCustomAttribute(filteredType) })
                                    .Where(x => x.TargetAttribute != null);

        //Report assemblies framework target
        foreach (var assem in assemblyMatches)
        {
            var framework = new System.Runtime.Versioning.FrameworkName(assem.TargetAttribute.FrameworkName);
            Console.WriteLine("Assembly: '{0}' targets .NET version: '{1}'.",
                                assem.Assembly.FullName,
                                framework.Version);
        }

        Console.ReadLine();
    }
}

TargetFrameworkAttribute....dies funktioniert nur in Version 4

InformationsquelleAutor njappboy

Versuchen auch in diesem Beispiel abzurufen, die Ziel-und die aktuellen Versionen .NET framework zur Laufzeit (funktioniert für .NET V4.X) :

    Dim ca As Object() = System.Reflection.Assembly.GetEntryAssembly().GetCustomAttributes(False)

    For Each c In ca.Where(Function(x) x.TypeId.Name = "TargetFrameworkAttribute")
        Console.WriteLine("Target .NET framework for " & Application.ProductName & " : " & c.FrameworkDisplayName)
    Next

    Console.WriteLine("Current .NET framework for " & Application.ProductName & " : " & System.Diagnostics.FileVersionInfo.GetVersionInfo(GetType(Integer).Assembly.Location).ProductVersion)

InformationsquelleAutor Didier L

njappboy die Lösung funktioniert Super. Ich brauchte VB.Net version, hier also der Umwandlung.

Dim assems = AppDomain.CurrentDomain.GetAssemblies()
Dim filteredType = GetType(Runtime.Versioning.TargetFrameworkAttribute)
Dim assemblyMatches = assems.[Select](Function(x) New With {Key .Assembly = x,
            Key .TargetAttribute = CType(x.GetCustomAttribute(filteredType),
            Runtime.Versioning.TargetFrameworkAttribute)}).Where(
            Function(x) x.TargetAttribute IsNot Nothing)
For Each assem In assemblyMatches
    Dim framework = New System.Runtime.Versioning.FrameworkName(
        assem.TargetAttribute.FrameworkName)

    Console.WriteLine("Assembly: '{0}' targets .NET version: '{1}'.",
                      assem.Assembly.FullName, framework.Version)
Next

InformationsquelleAutor Greg Bologna

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.