.NET：针对运行时
我开始深入阅读 .NET 框架及其公共语言运行时。我正在阅读 Microsoft 的 .NET 概述，我不知道这个声明是什么意思。
针对运行时的代码已知 作为托管代码，而代码则 不针对运行时被称为 非托管代码。
您如何定位公共语言运行时？我知道在 Visual Studio 中开发时它是默认的，但是您将如何专门针对 CLR？
开发 .NET 应用程序时哪些代码不会以 CLR 为目标，从而被称为非托管代码？
I'm starting to read in-depth on the .NET framework, and its Common Language Runtime. I'm reading a .NET overview by Microsoft and I'm not sure what is meant by this statement.
Code that targets the runtime is known
as managed code, while code that does
not target the runtime is known as
unmanaged code.
How do you target the Common Language Runtime? I know its defaulted when developing in Visual Studio, but how would you specifically target the CLR?
What code when developing a .NET application wouldn't target the CLR, and thereby be called unmanaged code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
以运行时为目标意味着针对运行时进行编译，即输出 CIL 又名 MSIL（而不是 x86/x64/等机器代码）。
说任何不针对运行时的东西都是“非托管代码”，这有点错误的二分法。例如，在 JVM 上运行的代码可以说是受管理的，但我认为我们可以在这种情况下将这句话理解为“不受管理的[由 CLR]”。
可以编写一个 C# 编译器，它可以输出本机代码而不是针对运行时（尽管您可能至少需要一些 GC 运行时），并且同样可以编写 C编译器抛出 CIL。在此示例中，假设的 C# 编译器不会以运行时为目标，但假设的 C 编译器会以运行时为目标。这里重要的区别是将语言与其目标分开。
不针对运行时的 .NET 应用程序将是一个矛盾。如果它不以运行时为目标，那么它就不是一个 .NET 应用程序。
不过，使用
unsafe和P/Invoke可能会变得更加模糊。当您使用 P/Invoke 或 COM 互操作等功能时，您最终会瞄准运行时以及另外一些其他东西。但这并不意味着您已经停止以运行时为目标，而只是意味着您在运行时之外还有其他依赖项。跟踪此类内容就是为什么会出现CLSCompliantAttribute存在。Targetting the runtime means compiling for the runtime, that is, among other things, outputting CIL aka MSIL (as opposed to x86/x64/etc. machine code).
Saying that anything that doesn't target the runtime is "unmanaged code", is a bit of a false dichotomy. Code running on the JVM for example is arguably managed, but I think we can take in this context the sentence to mean "unamanged [by the CLR]".
It would be possible to write a C# compiler that could spit out native code and not target the runtime (albeit you'd probably need some runtime for GC at least), and it is equally possible to write C compiler that spat out CIL. In this example the hypothetical C# compiler wouldn't be targetting the runtime but the hypothetical C compiler would be. The important distinction here is separating the language from its target.
A .NET application that didn't target the runtime would be a contradiction. If it didn't target the runtime it wouldn't be a .NET application.
It can get fuzzier though, with
unsafeandP/Invoke. When you use functionality likeP/Invokeor COM interop, you end up targeting the runtime and additionally some other stuff. This doesn't mean you've stopped targeting the runtime though, it just means you have additional dependencies beyond the runtime. Keeping track of this sort of stuff is why things like theCLSCompliantAttributeexist.在 .NET 框架上运行的所有代码都是托管代码。非托管代码的一个示例是 C++，它称为非托管代码或本机代码。
All code that runs on the .NET framework is managed code. An example of unmanaged code is C++ it's called unmanaged or native code.
这是一个模糊的术语，它的意思是“配置构建工具以生成与托管运行时兼容的二进制映像”。可以运行托管代码的可执行文件遵循标准 PE32 文件格式。您所熟悉的 EXE 和 DLL 文件。这样的二进制图像在 .NET 中称为“程序集”。其格式在 Ecma 标准文档中有详细记录。
大多数常用的构建工具都非常特定于创建托管程序集。就像 csc.exe 和 vbc.exe 一样，分别是 C# 和 VB.NET 编译器。某些工具可以生成其中任何一个，并且必须使用正确的命令行选项运行才能获得所需的最终结果。与 cl.exe 和 link.exe 一样，C/C++ 编译器和链接器具有对 C++/CLI 语言的内置支持。他们还可以创建包含托管 IL 和机器代码混合的程序集。
尤其是后两个工具不太容易用于针对托管运行时。这是 IDE 和与 Visual Studio 集成的构建系统的工作，以使其变得简单。
It is a fuzzy term, it means "configuring the build tools to generate a binary image that's compatible with the managed runtime". An executable that can run managed code follows the standard PE32 file format. Familiar to you as EXE and DLL files. Such a binary image is called "assembly" in .NET speak. Its format is well documented in this Ecma standard document.
Most build tools in common use are very specific to creating managed assemblies. Like csc.exe and vbc.exe, respectively the C# and VB.NET compilers. Some tools can generate either and must be run with the right command line options to get the desired end result. Like cl.exe and link.exe, the compiler and linker for C/C++ with built-in support for the C++/CLI language. They can also create assemblies that contain a mix of managed IL and machine code.
Especially the latter two tools are not that easy to use to target the managed runtime. It is the job of the IDE and the build system incorporated with Visual Studio to make it easy.