是否可以事后确定 .NET 程序集是用哪种语言编写的？
这最初是一种查找 C++/CLI 和托管 C++ 程序集的方法，以便可以测试它们内部的所有类，以确保重新实现所有继承的方法。 我想将其添加为构建过程步骤，以确保它不再发生。
思考这个问题也让我有点好奇，因为能够确定所使用的任何 .NET 语言会很有趣。 因此，我进一步比较了所有 .NET 语言的程序集。 到目前为止，这是我通过我编写的一个小程序发现的，该程序通过反射比较任何 .NET 程序集集合中的类型和属性数据：
- C# - Has AssemblyConfigurationAttribute、Has GuidAttribute
- VB - 有许多额外的“我的”类型（例如.MyApplication、MySettings)，具有 GuidAttibute
- F# - 具有 FSharpInterfaceDataVersionAttribute，它还指定所使用的编译器的版本。
- C++（除 /clr:safe 之外的所有类型） - 有一堆额外类型（FrameInfo、type_info）
- C++ /clr:safe - 似乎没有独特的反射功能。
按以下顺序解析可能是合理的：
- 如果它具有 FSharpInterfaceDataVersionAttribute，则它是 F#；
- 如果它具有我发现的大量额外类型中的任何类型，则它是 C++。
- 如果它具有“My*”类型，则它是 VB。
- 如果它具有 AssemblyConfigurationAttribute 或 GuidAttribute，则它是 C#
- 它很可能是 C++ /clr:Safe
但是，由于这是一个可怕的 hack，我想在这里检查以确保没有其他可用选项。
This started as a way to find C++/CLI and Managed C++ assemblies so that all classes internal to them could be tested to ensure all inherited methods were being reimplemented. I would like to add this as a build process step to ensure that it never happens again.
Thinking about this problem also made me a bit curious as it would be interesting to be able to determine any .NET language used. Because of this, I went a bit further and compared assemblies from all of the .NET languages. So far here is what I've found through a small program I wrote which compares the type and attribute data from any set of .NET assemblies via reflection:
- C# - Has AssemblyConfigurationAttribute, Has GuidAttribute
- VB - Has many extra "My" type (ex. MyApplication, MySettings), Has GuidAttibute
- F# - Has a FSharpInterfaceDataVersionAttribute which also specifies the version of the compiler used.
- C++ (all but /clr:safe) - Has a bunch of extra types (FrameInfo, type_info)
- C++ /clr:safe - Seems to have no unique reflection features.
It might be reasonable to parse in this order:
- It's F# if it has the FSharpInterfaceDataVersionAttribute
- It's C++ if it has any in the huge set of extra types I found.
- It's VB if it has the "My*" Types.
- It's C# if it has AssemblyConfigurationAttribute or GuidAttribute
- It's likely to be C++ /clr:Safe
However, as this is a horrible hack, I wanted to check in here to make sure that there wasn't another option available.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
检查 VB 或 F# 类库之类的引用似乎是最不可靠的方法，但正如其他人提到的，这是一种启发式方法 - 就像没有明确的方法来判断本机二进制文件是用哪种语言编写的一样（但是通过启发法你几乎可以 100% 确定）
Checking the references for things like the VB or F# class libraries seems to be the least shaky way to do this, but as others mention, it's a heuristic - just like there's no definitive way to tell which language a native binary is written in (but you can be almost 100% sure by heuristics)
当.NET语言被编译时，你得到的只是IL。 我不知道确定哪种特定语言创建程序集的标准方法。 您可以采用现有程序集并将其 ildasm（反汇编）到 IL 中，然后将其 ilasm（汇编）回几乎相同的程序集。
您使用的启发式方法是识别用于创建程序集的语言的合理而巧妙的方法。 但是，请记住，这些细节可能会因语言的编译器版本而异。
When a .NET language is compiled, all you get is IL. I am not aware of a standard way of determining which specific language created the assembly. You can take an existing assembly and ildasm (disassemble) it into IL and them ilasm (assemble) it back into a virtually identical assembly.
The heuristics you use is a reasonable and clever way to identify the language used to create the assembly. However, bear in mind that these details might change between compiler versions of the languages.