开发者

.NET : Targeting the runtime

开发者 https://www.devze.com 2023-01-01 06:25 出处:网络
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.

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开发者_JAVA百科 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?


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 unsafe and P/Invoke. When you use functionality like P/Invoke or 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 the CLSCompliantAttribute exist.


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.


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消