Dies begann als eine Möglichkeit, C++/CLI- und verwaltete C++ - Assemblys zu finden, sodass alle internen Klassen getestet werden konnten, um sicherzustellen, dass alle geerbten Methoden erneut implementiert wurden. Ich möchte dies als Build-Prozess-Schritt hinzufügen, um sicherzustellen, dass es nie wieder passiert.Kann festgestellt werden, in welcher Sprache eine .NET Assembly nachträglich geschrieben wurde?
Das Nachdenken über dieses Problem machte mich auch ein bisschen neugierig, da es interessant wäre, jede verwendete .NET Sprache zu bestimmen. Aus diesem Grund ging ich ein bisschen weiter und verglich Baugruppen aus allen .NET-Sprachen. Bis jetzt hier ist, was ich durch ein kleines Programm gefunden habe ich geschrieben, die die Art und Attributdaten aus jedem Satz von .NET-Assemblies über Reflexion vergleicht:
- C# - Hat AssemblyConfigurationAttribute hat GuidAttribute
- VB - Hat viele zusätzliche "My" -Typ (z. B. MyApplication, MySettings), hat GuidAttibute
- F # - Hat eine FSharpInterfaceDataVersionAttribute, die auch die Version des verwendeten Compilers angibt.
- C++ (alle außer/clr: sicher) - Hat eine Reihe von zusätzlichen Typen (FrameInfo, type_info)
- C++/clr: sicher - Scheint keine einzigartigen Reflexionsmerkmale zu haben.
Es könnte sinnvoll sein, in dieser Reihenfolge zu analysieren:
- Es ist F #, wenn sie die FSharpInterfaceDataVersionAttribute
- Es ist C++ hat, wenn es ein in der riesigen Menge von zusätzlichen Typen habe ich gefunden.
- Es ist VB, wenn es die "My *" Typen hat.
- Es ist C#, wenn sie AssemblyConfigurationAttribute hat oder GuidAttribute
- Es ist wahrscheinlich, C++/clr sein: Sicher
Da dies jedoch eine schreckliche Hack ist, wollte ich hier einchecken, um sicherzustellen, dass es wasn Es ist keine andere Option verfügbar.
Interessante Frage, aber warum die Verwendung von Latein? Retrospektiver wäre einfacher zu verstehen. Nicht jeder hier ist ein englischer Muttersprachler. – danio
@danio: Weil Latein ist großartig? – bcat