diff --git a/docs/standard/assembly/create-public-private-key-pair.md b/docs/standard/assembly/create-public-private-key-pair.md index b8a849fd70bed..ea48ab3c383cd 100644 --- a/docs/standard/assembly/create-public-private-key-pair.md +++ b/docs/standard/assembly/create-public-private-key-pair.md @@ -5,7 +5,7 @@ ms.date: "08/20/2019" helpviewer_keywords: - "key pairs for strong-named assemblies" - "signing assemblies" - - "assemblies [.NET Framework], signing" + - "assemblies [.NET], signing" - "cryptographic key pairs" - "snk files (key pair files)" - "public-private key pairs" diff --git a/docs/standard/assembly/create-use-strong-named.md b/docs/standard/assembly/create-use-strong-named.md index ed4dd392354d6..d5528c984b604 100644 --- a/docs/standard/assembly/create-use-strong-named.md +++ b/docs/standard/assembly/create-use-strong-named.md @@ -7,9 +7,9 @@ helpviewer_keywords: - "strong-named assemblies, about strong-named assemblies" - "strong-named assemblies" - "signing assemblies" - - "assemblies [.NET Framework], signing" + - "assemblies [.NET], signing" - "strong-named assemblies, scenarios" - - "assemblies [.NET Framework], strong-named" + - "assemblies [.NET], strong-named" - "strong-named assemblies, loading into trusted application domains" - "assembly binding, strong-named" ms.assetid: ffbf6d9e-4a88-4a8a-9645-4ce0ee1ee5f9 @@ -40,7 +40,7 @@ The following scenario outlines the process of signing an assembly with a strong 3. Assembly B is a consumer of Assembly A. The reference section of Assembly B's manifest includes a token that represents Assembly A's public key. A token is a portion of the full public key and is used rather than the key itself to save space. -4. The common language runtime verifies the strong name signature when the assembly is placed in the global assembly cache. When binding by strong name at run time, the common language runtime compares the key stored in Assembly B's manifest with the key used to generate the strong name for Assembly A. If the .NET Framework security checks pass and the bind succeeds, Assembly B has a guarantee that Assembly A's bits have not been tampered with and that these bits actually come from the developers of Assembly A. +4. The common language runtime verifies the strong name signature when the assembly is placed in the global assembly cache. When binding by strong name at run time, the common language runtime compares the key stored in Assembly B's manifest with the key used to generate the strong name for Assembly A. If the .NET security checks pass and the bind succeeds, Assembly B has a guarantee that Assembly A's bits have not been tampered with and that these bits actually come from the developers of Assembly A. > [!NOTE] > This scenario doesn't address trust issues. Assemblies can carry full Microsoft Authenticode signatures in addition to a strong name. Authenticode signatures include a certificate that establishes trust. It's important to note that strong names don't require code to be signed in this way. Strong names only provide a unique identity. diff --git a/docs/standard/assembly/create.md b/docs/standard/assembly/create.md index 04191193414d7..6a123a3c0e74e 100644 --- a/docs/standard/assembly/create.md +++ b/docs/standard/assembly/create.md @@ -3,9 +3,9 @@ title: "Create assemblies" description: Learn about creating single-file or multifile assemblies using an IDE, such as Visual Studio, or the compilers and tools provided by the Windows SDK. ms.date: "08/19/2019" helpviewer_keywords: - - "assemblies [.NET Framework], multifile" + - "assemblies [.NET], multifile" - "single-file assemblies" - - "assemblies [.NET Framework], creating" + - "assemblies [.NET], creating" - "multifile assemblies" ms.assetid: 54832ee9-dca8-4c8b-913c-c0b9d265e9a4 --- diff --git a/docs/standard/assembly/delay-sign.md b/docs/standard/assembly/delay-sign.md index 01f347f2af404..22c68d7ffb00c 100644 --- a/docs/standard/assembly/delay-sign.md +++ b/docs/standard/assembly/delay-sign.md @@ -5,7 +5,7 @@ ms.date: "08/19/2019" helpviewer_keywords: - "deferring assembly signing" - "signing assemblies" - - "assemblies [.NET Framework], signing" + - "assemblies [.NET], signing" - "strong-named assemblies, delaying assembly signing" - "partial assembly signing" ms.assetid: 9d300e17-5bf1-4360-97da-2aa55efd9070 @@ -57,7 +57,7 @@ To delay-sign an assembly: sn –Vr myAssembly.dll ``` - To turn off verification on platforms where you can’t run the Strong Name tool, such as Advanced RISC Machine (ARM) microprocessors, use the **–Vk** option to create a registry file. Import the registry file into the registry on the computer where you want to turn off verification. The following example creates a registry file for `myAssembly.dll`. + To turn off verification on platforms where you can't run the Strong Name tool, such as Advanced RISC Machine (ARM) microprocessors, use the **–Vk** option to create a registry file. Import the registry file into the registry on the computer where you want to turn off verification. The following example creates a registry file for `myAssembly.dll`. ```console sn –Vk myRegFile.reg myAssembly.dll diff --git a/docs/standard/attributes/applying-attributes.md b/docs/standard/attributes/applying-attributes.md index a9ca09b7519e5..4e30a15800521 100644 --- a/docs/standard/attributes/applying-attributes.md +++ b/docs/standard/attributes/applying-attributes.md @@ -2,48 +2,51 @@ title: "Applying Attributes" ms.date: "03/30/2017" ms.technology: dotnet-standard -dev_langs: +dev_langs: - "csharp" - "vb" - "cpp" -helpviewer_keywords: +helpviewer_keywords: - "assemblies [.NET Framework], attributes" - "attributes [.NET Framework], applying" ms.assetid: dd7604eb-9fa3-4b60-b2dd-b47739fa3148 --- -# Applying Attributes -Use the following process to apply an attribute to an element of your code. - -1. Define a new attribute or use an existing attribute by importing its namespace from the .NET Framework. - -2. Apply the attribute to the code element by placing it immediately before the element. - +# Apply attributes + +Use the following process to apply an attribute to an element of your code. + +1. Define a new attribute or use an existing .NET attribute. + +2. Apply the attribute to the code element by placing it immediately before the element. + Each language has its own attribute syntax. In C++ and C#, the attribute is surrounded by square brackets and separated from the element by white space, which can include a line break. In Visual Basic, the attribute is surrounded by angle brackets and must be on the same logical line; the line continuation character can be used if a line break is desired. - -3. Specify positional parameters and named parameters for the attribute. - - Positional parameters are required and must come before any named parameters; they correspond to the parameters of one of the attribute's constructors. Named parameters are optional and correspond to read/write properties of the attribute. In C++, and C#, specify `name`=`value` for each optional parameter, where `name` is the name of the property. In Visual Basic, specify `name`:=`value`. - - The attribute is emitted into metadata when you compile your code and is available to the common language runtime and any custom tool or application through the runtime reflection services. - - By convention, all attribute names end with Attribute. However, several languages that target the runtime, such as Visual Basic and C#, do not require you to specify the full name of an attribute. For example, if you want to initialize , you only need to reference it as **Obsolete**. - -## Applying an Attribute to a Method - The following code example shows how to declare **System.ObsoleteAttribute**, which marks code as obsolete. The string `"Will be removed in next version"` is passed to the attribute. This attribute causes a compiler warning that displays the passed string when code that the attribute describes is called. - + +3. Specify positional parameters and named parameters for the attribute. + + *Positional* parameters are required and must come before any named parameters; they correspond to the parameters of one of the attribute's constructors. *Named* parameters are optional and correspond to read/write properties of the attribute. In C++, and C#, specify `name=value` for each optional parameter, where `name` is the name of the property. In Visual Basic, specify `name:=value`. + + The attribute is emitted into metadata when you compile your code and is available to the common language runtime and any custom tool or application through the runtime reflection services. + + By convention, all attribute names end with "Attribute". However, several languages that target the runtime, such as Visual Basic and C#, do not require you to specify the full name of an attribute. For example, if you want to initialize , you only need to reference it as **Obsolete**. + +## Apply an attribute to a method + + The following code example shows how to use **System.ObsoleteAttribute**, which marks code as obsolete. The string `"Will be removed in next version"` is passed to the attribute. This attribute causes a compiler warning that displays the passed string when code that the attribute describes is called. + [!code-cpp[Conceptual.Attributes.Usage#3](../../../samples/snippets/cpp/VS_Snippets_CLR/conceptual.attributes.usage/cpp/source1.cpp#3)] [!code-csharp[Conceptual.Attributes.Usage#3](../../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.attributes.usage/cs/source1.cs#3)] - [!code-vb[Conceptual.Attributes.Usage#3](../../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.attributes.usage/vb/source1.vb#3)] - -## Applying Attributes at the Assembly Level - If you want to apply an attribute at the assembly level, use the **assembly** (`Assembly` in Visual Basic) keyword. The following code shows the **AssemblyTitleAttribute** applied at the assembly level. - + [!code-vb[Conceptual.Attributes.Usage#3](../../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.attributes.usage/vb/source1.vb#3)] + +## Apply attributes at the assembly level + + If you want to apply an attribute at the assembly level, use the `assembly` (`Assembly` in Visual Basic) keyword. The following code shows the **AssemblyTitleAttribute** applied at the assembly level. + [!code-cpp[Conceptual.Attributes.Usage#2](../../../samples/snippets/cpp/VS_Snippets_CLR/conceptual.attributes.usage/cpp/source1.cpp#2)] [!code-csharp[Conceptual.Attributes.Usage#2](../../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.attributes.usage/cs/source1.cs#2)] - [!code-vb[Conceptual.Attributes.Usage#2](../../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.attributes.usage/vb/source1.vb#2)] - - When this attribute is applied, the string `"My Assembly"` is placed in the assembly manifest in the metadata portion of the file. You can view the attribute either by using the [MSIL Disassembler (Ildasm.exe)](../../framework/tools/ildasm-exe-il-disassembler.md) or by creating a custom program to retrieve the attribute. - + [!code-vb[Conceptual.Attributes.Usage#2](../../../samples/snippets/visualbasic/VS_Snippets_CLR/conceptual.attributes.usage/vb/source1.vb#2)] + + When this attribute is applied, the string `"My Assembly"` is placed in the assembly manifest in the metadata portion of the file. You can view the attribute either by using the [MSIL Disassembler (Ildasm.exe)](../../framework/tools/ildasm-exe-il-disassembler.md) or by creating a custom program to retrieve the attribute. + ## See also - [Attributes](index.md) diff --git a/docs/standard/attributes/index.md b/docs/standard/attributes/index.md index e98367e80be2b..1a6108b6b815c 100644 --- a/docs/standard/attributes/index.md +++ b/docs/standard/attributes/index.md @@ -1,12 +1,12 @@ --- title: "Extending Metadata Using Attributes" description: Learn how to extend metadata using attributes in .NET. Attributes are keyword-like descriptive declarations to annotate programming elements, like types and fields. -ms.date: "03/30/2017" +ms.date: 10/14/2020 ms.technology: dotnet-standard -helpviewer_keywords: +helpviewer_keywords: - "metadata, extending" - - "attributes [.NET Framework], metadata" - - "elements [.NET Framework], attributes" + - "attributes [.NET], metadata" + - "elements [.NET], attributes" - "common language runtime, attributes" - "annotating programming elements" - "keyword-like descriptive declarations" @@ -14,20 +14,22 @@ helpviewer_keywords: - "extending metadata" ms.assetid: 30386922-1e00-4602-9ebf-526b271a8b87 --- -# Extending Metadata Using Attributes -The common language runtime allows you to add keyword-like descriptive declarations, called attributes, to annotate programming elements such as types, fields, methods, and properties. When you compile your code for the runtime, it is converted into Microsoft intermediate language (MSIL) and placed inside a portable executable (PE) file along with metadata generated by the compiler. Attributes allow you to place extra descriptive information into metadata that can be extracted using runtime reflection services. The compiler creates attributes when you declare instances of special classes that derive from . - - The .NET Framework uses attributes for a variety of reasons and to address a number of issues. Attributes describe how to serialize data, specify characteristics that are used to enforce security, and limit optimizations by the just-in-time (JIT) compiler so the code remains easy to debug. Attributes can also record the name of a file or the author of code, or control the visibility of controls and members during forms development. - -## Related Topics - -|Title|Description| -|-----------|-----------------| -|[Applying Attributes](applying-attributes.md)|Describes how to apply an attribute to an element of your code.| -|[Writing Custom Attributes](writing-custom-attributes.md)|Describes how to design custom attribute classes.| -|[Retrieving Information Stored in Attributes](retrieving-information-stored-in-attributes.md)|Describes how to retrieve custom attributes for code that is loaded into the execution context.| -|[Metadata and Self-Describing Components](../metadata-and-self-describing-components.md)|Provides an overview of metadata and describes how it is implemented in a .NET Framework portable executable (PE) file.| -|[How to: Load Assemblies into the Reflection-Only Context](../../framework/reflection-and-codedom/how-to-load-assemblies-into-the-reflection-only-context.md)|Explains how to retrieve custom attribute information in the reflection-only context.| - -## Reference - +# Extend metadata using attributes + +The common language runtime allows you to add keyword-like descriptive declarations, called attributes, to annotate programming elements such as types, fields, methods, and properties. When you compile your code for the runtime, it is converted into Microsoft intermediate language (MSIL) and placed inside a portable executable (PE) file along with metadata generated by the compiler. Attributes allow you to place extra descriptive information into metadata that can be extracted using runtime reflection services. The compiler creates attributes when you declare instances of special classes that derive from . + +.NET uses attributes for a variety of reasons and to address a number of issues. Attributes describe how to serialize data, specify characteristics that are used to enforce security, and limit optimizations by the just-in-time (JIT) compiler so the code remains easy to debug. Attributes can also record the name of a file or the author of code, or control the visibility of controls and members during forms development. + +## Related articles + +|Title|Description| +|-----------|-----------------| +|[Applying Attributes](applying-attributes.md)|Describes how to apply an attribute to an element of your code.| +|[Writing Custom Attributes](writing-custom-attributes.md)|Describes how to design custom attribute classes.| +|[Retrieving Information Stored in Attributes](retrieving-information-stored-in-attributes.md)|Describes how to retrieve custom attributes for code that is loaded into the execution context.| +|[Metadata and Self-Describing Components](../metadata-and-self-describing-components.md)|Provides an overview of metadata and describes how it is implemented in a .NET Framework portable executable (PE) file.| +|[How to: Load Assemblies into the Reflection-Only Context](../../framework/reflection-and-codedom/how-to-load-assemblies-into-the-reflection-only-context.md)|Explains how to retrieve custom attribute information in the reflection-only context.| + +## Reference + +- diff --git a/docs/standard/base-types/best-practices.md b/docs/standard/base-types/best-practices.md index 03f761750f9af..cfdc7a1e7c3e4 100644 --- a/docs/standard/base-types/best-practices.md +++ b/docs/standard/base-types/best-practices.md @@ -7,7 +7,7 @@ dev_langs: - "csharp" - "vb" helpviewer_keywords: - - ".NET Framework regular expressions, best practices" + - ".NET regular expressions, best practices" - "regular expressions, best practices" ms.assetid: 618e5afb-3a97-440d-831a-70e4c526a51c --- @@ -55,7 +55,7 @@ To solve this problem, you can do the following: ## Handle object instantiation appropriately -At the heart of .NET’s regular expression object model is the class, which represents the regular expression engine. Often, the single greatest factor that affects regular expression performance is the way in which the engine is used. Defining a regular expression involves tightly coupling the regular expression engine with a regular expression pattern. That coupling process, whether it involves instantiating a object by passing its constructor a regular expression pattern or calling a static method by passing it the regular expression pattern along with the string to be analyzed, is by necessity an expensive one. +At the heart of .NET's regular expression object model is the class, which represents the regular expression engine. Often, the single greatest factor that affects regular expression performance is the way in which the engine is used. Defining a regular expression involves tightly coupling the regular expression engine with a regular expression pattern. That coupling process, whether it involves instantiating a object by passing its constructor a regular expression pattern or calling a static method by passing it the regular expression pattern along with the string to be analyzed, is by necessity an expensive one. > [!NOTE] > For a more detailed discussion of the performance implications of using interpreted and compiled regular expressions, see [Optimizing Regular Expression Performance, Part II: Taking Charge of Backtracking](/archive/blogs/bclteam/optimizing-regular-expression-performance-part-ii-taking-charge-of-backtracking-ron-petrusha) in the BCL Team blog. @@ -130,7 +130,7 @@ The regular expression pattern used in the example, `\b(\w+((\r?\n)|,?\s))*\w+[. ### Regular expressions: Compiled to an assembly -.NET also enables you to create an assembly that contains compiled regular expressions. This moves the performance hit of regular expression compilation from run time to design time. However, it also involves some additional work: You must define the regular expressions in advance and compile them to an assembly. The compiler can then reference this assembly when compiling source code that uses the assembly’s regular expressions. Each compiled regular expression in the assembly is represented by a class that derives from . +.NET also enables you to create an assembly that contains compiled regular expressions. This moves the performance hit of regular expression compilation from run time to design time. However, it also involves some additional work: You must define the regular expressions in advance and compile them to an assembly. The compiler can then reference this assembly when compiling source code that uses the assembly's regular expressions. Each compiled regular expression in the assembly is represented by a class that derives from . To compile regular expressions to an assembly, you call the method and pass it an array of objects that represent the regular expressions to be compiled, and an object that contains information about the assembly to be created. diff --git a/docs/standard/building-console-apps.md b/docs/standard/building-console-apps.md index 2c9f086203387..fdf0eec2393aa 100644 --- a/docs/standard/building-console-apps.md +++ b/docs/standard/building-console-apps.md @@ -1,29 +1,30 @@ --- -title: "Building Console Applications in the .NET Framework" +title: "Building Console Applications in .NET" ms.date: "03/30/2017" ms.technology: dotnet-standard -helpviewer_keywords: - - ".NET Framework, building console applications" - - "application development [.NET Framework], console" +helpviewer_keywords: + - ".NET, building console applications" + - "application development [.NET], console" - "console applications" ms.assetid: c21fb997-9f0e-40a5-8741-f73bba376bd8 --- -# Building Console Applications in the .NET Framework -Applications in the .NET Framework can use the class to read characters from and write characters to the console. Data from the console is read from the standard input stream, data to the console is written to the standard output stream, and error data to the console is written to the standard error output stream. These streams are automatically associated with the console when the application starts and are presented as the , , and properties, respectively. - - The value of the property is a object, whereas the values of the and properties are objects. You can associate these properties with streams that do not represent the console, making it possible for you to point the stream to a different location for input or output. For example, you can redirect the output to a file by setting the property to a , which encapsulates a by means of the method. The and properties do not need to refer to the same stream. - +# Building Console Applications in .NET + +.NET applications can use the class to read characters from and write characters to the console. Data from the console is read from the standard input stream, data to the console is written to the standard output stream, and error data to the console is written to the standard error output stream. These streams are automatically associated with the console when the application starts and are presented as the , , and properties, respectively. + + The value of the property is a object, whereas the values of the and properties are objects. You can associate these properties with streams that do not represent the console, making it possible for you to point the stream to a different location for input or output. For example, you can redirect the output to a file by setting the property to a , which encapsulates a by means of the method. The and properties do not need to refer to the same stream. + > [!NOTE] -> For more information about building console applications, including examples in C#, Visual Basic, and C++, see the documentation for the class. - - If the console does not exist, as in a Windows-based application, output written to the standard output stream will not be visible, because there is no console to write the information to. Writing information to an inaccessible console does not cause an exception to be raised. - - Alternately, to enable the console for reading and writing within a Windows-based application that is developed using Visual Studio, open the project's **Properties** dialog box, click the **Application** tab, and set the **Application type** to **Console Application**. - - Console applications lack a message pump that starts by default. Therefore, console calls to Microsoft Win32 timers might fail. - - The **System.Console** class has methods that can read individual characters or entire lines from the console. Other methods convert data and format strings, and then write the formatted strings to the console. For more information on formatting strings, see [Formatting Types](base-types/formatting-types.md). - +> For more information about building console applications, including examples in C#, Visual Basic, and C++, see the documentation for the class. + + If the console does not exist, as in a Windows-based application, output written to the standard output stream will not be visible, because there is no console to write the information to. Writing information to an inaccessible console does not cause an exception to be raised. + + Alternately, to enable the console for reading and writing within a Windows-based application that is developed using Visual Studio, open the project's **Properties** dialog box, click the **Application** tab, and set the **Application type** to **Console Application**. + + Console applications lack a message pump that starts by default. Therefore, console calls to Microsoft Win32 timers might fail. + + The **System.Console** class has methods that can read individual characters or entire lines from the console. Other methods convert data and format strings, and then write the formatted strings to the console. For more information on formatting strings, see [Formatting Types](base-types/formatting-types.md). + ## See also - diff --git a/docs/standard/language-independence-and-language-independent-components.md b/docs/standard/language-independence-and-language-independent-components.md index d219eb97c7713..a41ea3c49dd18 100644 --- a/docs/standard/language-independence-and-language-independent-components.md +++ b/docs/standard/language-independence-and-language-independent-components.md @@ -16,7 +16,7 @@ ms.assetid: 4f0b77d0-4844-464f-af73-6e06bedeafc6 --- # Language Independence and Language-Independent Components -.NET Framework is language independent. This means that, as a developer, you can develop in one of the many languages that target .NET Framework, such as C#, C++/CLI, Eiffel, F#, IronPython, IronRuby, PowerBuilder, Visual Basic, Visual COBOL, and Windows PowerShell. You can access the types and members of class libraries developed for the .NET Framework without having to know the language in which they were originally written and without having to follow any of the original language's conventions. If you are a component developer, your component can be accessed by any .NET Framework app regardless of its language. +.NET is language independent. This means that, as a developer, you can develop in one of the many languages that target .NET, such as C#, C++/CLI, Eiffel, F#, IronPython, IronRuby, PowerBuilder, Visual Basic, Visual COBOL, and Windows PowerShell. You can access the types and members of class libraries developed for .NET without having to know the language in which they were originally written and without having to follow any of the original language's conventions. If you are a component developer, your component can be accessed by any .NET app, regardless of its language. > [!NOTE] > This first part of this article discusses creating language-independent components—that is, components that can be consumed by apps that are written in any language. You can also create a single component or app from source code written in multiple languages; see [Cross-Language Interoperability](#CrossLang) in the second part of this article. @@ -151,7 +151,7 @@ The rules for CLS compliance are listed in the following table. The text of the ### Types and type member signatures -The type is CLS-compliant and is the base type of all object types in the .NET Framework type system. Inheritance in the .NET Framework is either implicit (for example, the class implicitly inherits from the class) or explicit (for example, the class explicitly inherits from the class, which explicitly inherits from the class, which explicitly inherits from the class). For a derived type to be CLS compliant, its base type must also be CLS-compliant. +The type is CLS-compliant and is the base type of all object types in the .NET type system. Inheritance in .NET is either implicit (for example, the class implicitly inherits from the class) or explicit (for example, the class explicitly inherits from the class, which explicitly inherits from the class, which explicitly inherits from the class). For a derived type to be CLS compliant, its base type must also be CLS-compliant. The following example shows a derived type whose base type is not CLS-compliant. It defines a base `Counter` class that uses an unsigned 32-bit integer as a counter. Because the class provides counter functionality by wrapping an unsigned integer, the class is marked as non-CLS-compliant. As a result, a derived class, `NonZeroCounter`, is also not CLS-compliant. @@ -164,7 +164,7 @@ All types that appear in member signatures, including a method's return type or - All types used as constraints on generic parameters must be CLS-compliant. -The .NET Framework [common type system](base-types/common-type-system.md) includes a number of built-in types that are supported directly by the common language runtime and are specially encoded in an assembly's metadata. Of these intrinsic types, the types listed in the following table are CLS-compliant. +The .NET [common type system](base-types/common-type-system.md) includes a number of built-in types that are supported directly by the common language runtime and are specially encoded in an assembly's metadata. Of these intrinsic types, the types listed in the following table are CLS-compliant. |CLS-compliant type|Description| |-------------------------|-----------------| @@ -191,13 +191,13 @@ The intrinsic types listed in the following table are not CLS-Compliant. ||64-bit unsigned integer| (may overflow), , or | ||Unsigned pointer or handle|| -The .NET Framework Class Library or any other class library may include other types that aren't CLS-compliant; for example: +The .NET Class Library or any other class library may include other types that aren't CLS-compliant; for example: - Boxed value types. The following C# example creates a class that has a public property of type `int*` named `Value`. Because an `int*` is a boxed value type, the compiler flags it as non-CLS-compliant. [!code-csharp[Conceptual.CLSCompliant#26](../../samples/snippets/csharp/VS_Snippets_CLR/conceptual.clscompliant/cs/box2.cs#26)] -- Typed references, which are special constructs that contain a reference to an object and a reference to a type. Typed references are represented in the .NET Framework by the class. +- Typed references, which are special constructs that contain a reference to an object and a reference to a type. Typed references are represented in .NET by the class. If a type is not CLS-compliant, you should apply the attribute with an `isCompliant` value of `false` to it. For more information, see [The CLSCompliantAttribute attribute](#CLSAttribute) section. @@ -481,7 +481,7 @@ To correct this error, the `ErrorClass` class must inherit from or from a type derived from . +In .NET assemblies, custom attributes provide an extensible mechanism for storing custom attributes and retrieving metadata about programming objects, such as assemblies, types, members, and method parameters. Custom attributes must derive from or from a type derived from . The following example violates this rule. It defines a `NumericAttribute` class that does not derive from . Note that a compiler error results only when the non-CLS-compliant attribute is applied, not when the class is defined. @@ -527,7 +527,7 @@ At compile time, the compiler detects non-compliant elements that are presumed t Component developers can use the attribute in two ways: -- To define the parts of the public interface exposed by a component that are CLS-compliant and the parts that are not CLS-compliant. When the attribute is used to mark particular program elements as CLS-compliant, its use guarantees that those elements are accessible from all languages and tools that target the .NET Framework. +- To define the parts of the public interface exposed by a component that are CLS-compliant and the parts that are not CLS-compliant. When the attribute is used to mark particular program elements as CLS-compliant, its use guarantees that those elements are accessible from all languages and tools that target .NET. - To ensure that the component library's public interface exposes only program elements that are CLS-compliant. If elements are not CLS-compliant, compilers will generally issue a warning. @@ -565,7 +565,7 @@ If you are developing an app rather than a library (that is, if you aren't expos ## Cross-Language Interoperability -Language independence has a number of possible meanings. One meaning, which is discussed in the article [Language Independence and Language-Independent Components](language-independence-and-language-independent-components.md), involves seamlessly consuming types written in one language from an app written in another language. A second meaning, which is the focus of this article, involves combining code written in multiple languages into a single .NET Framework assembly. +Language independence has a number of possible meanings. One meaning, which is discussed in the article [Language Independence and Language-Independent Components](language-independence-and-language-independent-components.md), involves seamlessly consuming types written in one language from an app written in another language. A second meaning, which is the focus of this article, involves combining code written in multiple languages into a single .NET assembly. The following example illustrates cross-language interoperability by creating a class library named Utilities.dll that includes two classes, `NumericLib` and `StringLib`. The `NumericLib` class is written in C#, and the `StringLib` class is written in Visual Basic. Here's the source code for StringUtil.vb, which includes a single member, `ToTitleCase`, in its `StringLib` class. diff --git a/docs/standard/language-independence.md b/docs/standard/language-independence.md index eebb9c3bf92d3..23410c23ecef7 100644 --- a/docs/standard/language-independence.md +++ b/docs/standard/language-independence.md @@ -179,7 +179,7 @@ Index to subsections: ### Types and type member signatures -The [System.Object](xref:System.Object) type is CLS-compliant and is the base type of all object types in the .NET Framework type system. Inheritance in the .NET Framework is either implicit (for example, the [String](xref:System.String) class implicitly inherits from the `Object` class) or explicit (for example, the [CultureNotFoundException](xref:System.Globalization.CultureNotFoundException) class explicitly inherits from the [ArgumentException](xref:System.ArgumentException) class, which explicitly inherits from the [Exception](xref:System.Exception) class. For a derived type to be CLS compliant, its base type must also be CLS-compliant. +The [System.Object](xref:System.Object) type is CLS-compliant and is the base type of all object types in the .NET type system. Inheritance in .NET is either implicit (for example, the [String](xref:System.String) class implicitly inherits from the `Object` class) or explicit (for example, the [CultureNotFoundException](xref:System.Globalization.CultureNotFoundException) class explicitly inherits from the [ArgumentException](xref:System.ArgumentException) class, which explicitly inherits from the [Exception](xref:System.Exception) class. For a derived type to be CLS compliant, its base type must also be CLS-compliant. The following example shows a derived type whose base type is not CLS-compliant. It defines a base `Counter` class that uses an unsigned 32-bit integer as a counter. Because the class provides counter functionality by wrapping an unsigned integer, the class is marked as non-CLS-compliant. As a result, a derived class, `NonZeroCounter`, is also not CLS-compliant. @@ -314,7 +314,7 @@ Non-compliant type | Description | CLS-compliant alternative [UInt64](xref:System.UInt64) | 64-bit unsigned integer | [Int64](xref:System.Int64) (may overflow), [BigInteger](xref:System.Numerics.BigInteger), or [Double](xref:System.Double) [UIntPtr](xref:System.UIntPtr) | Unsigned pointer or handle | [IntPtr](xref:System.IntPtr) -The .NET Framework Class Library or any other class library may include other types that aren't CLS-compliant; for example: +The .NET Class Library or any other class library may include other types that aren't CLS-compliant; for example: * Boxed value types. The following C# example creates a class that has a public property of type `int*` named `Value`. Because an `int*` is a boxed value type, the compiler flags it as non-CLS-compliant. @@ -2474,7 +2474,7 @@ End Module ### Attributes -In.NET Framework assemblies, custom attributes provide an extensible mechanism for storing custom attributes and retrieving metadata about programming objects, such as assemblies, types, members, and method parameters. Custom attributes must derive from [System.Attribute](xref:System.Attribute) or from a type derived from `System.Attribute`. +In .NET assemblies, custom attributes provide an extensible mechanism for storing custom attributes and retrieving metadata about programming objects, such as assemblies, types, members, and method parameters. Custom attributes must derive from [System.Attribute](xref:System.Attribute) or from a type derived from `System.Attribute`. The following example violates this rule. It defines a `NumericAttribute` class that does not derive from `System.Attribute`. A compiler error results only when the non-CLS-compliant attribute is applied, not when the class is defined. @@ -2631,7 +2631,7 @@ At compile time, the compiler detects non-compliant elements that are presumed t Component developers can use the `CLSCompliantAttribute` attribute in two ways: -* To define the parts of the public interface exposed by a component that are CLS-compliant and the parts that are not CLS-compliant. When the attribute is used to mark particular program elements as CLS-compliant, its use guarantees that those elements are accessible from all languages and tools that target the .NET Framework. +* To define the parts of the public interface exposed by a component that are CLS-compliant and the parts that are not CLS-compliant. When the attribute is used to mark particular program elements as CLS-compliant, its use guarantees that those elements are accessible from all languages and tools that target .NET. * To ensure that the component library's public interface exposes only program elements that are CLS-compliant. If elements are not CLS-compliant, compilers will generally issue a warning. @@ -2783,7 +2783,7 @@ If you are developing an app rather than a library (that is, if you aren't expos ## Cross-language interoperability -Language independence has a number of possible meanings. One meaning involves seamlessly consuming types written in one language from an app written in another language. A second meaning, which is the focus of this article, involves combining code written in multiple languages into a single .NET Framework assembly. +Language independence has a number of possible meanings. One meaning involves seamlessly consuming types written in one language from an app written in another language. A second meaning, which is the focus of this article, involves combining code written in multiple languages into a single .NET assembly. The following example illustrates cross-language interoperability by creating a class library named Utilities.dll that includes two classes, `NumericLib` and `StringLib`. The `NumericLib` class is written in C#, and the `StringLib` class is written in Visual Basic. Here's the source code for `StringUtil.vb`, which includes a single member, `ToTitleCase`, in its `StringLib` class. diff --git a/docs/standard/managed-code.md b/docs/standard/managed-code.md index 4a22c2cb26416..eb365d8186564 100644 --- a/docs/standard/managed-code.md +++ b/docs/standard/managed-code.md @@ -7,17 +7,17 @@ ms.assetid: 20bb7ea8-192e-4a96-8ef3-e10e1950fd3d --- # What is "managed code"? -When working with .NET Framework, you will often encounter the term "managed code". This document will explain what this term means and additional information around it. +When working with .NET, you will often encounter the term "managed code". This document will explain what this term means and additional information around it. -To put it very simply, managed code is just that: code whose execution is managed by a runtime. In this case, the runtime in question is called the **Common Language Runtime** or CLR, regardless of the implementation ([Mono](https://www.mono-project.com/) or .NET Framework or .NET Core). CLR is in charge of taking the managed code, compiling it into machine code and then executing it. On top of that, runtime provides several important services such as automatic memory management, security boundaries, type safety etc. +To put it very simply, managed code is just that: code whose execution is managed by a runtime. In this case, the runtime in question is called the **Common Language Runtime** or CLR, regardless of the implementation (for example, [Mono](https://www.mono-project.com/), .NET Framework, or .NET Core/.NET 5+). CLR is in charge of taking the managed code, compiling it into machine code and then executing it. On top of that, runtime provides several important services such as automatic memory management, security boundaries, type safety etc. Contrast this to the way you would run a C/C++ program, also called "unmanaged code". In the unmanaged world, the programmer is in charge of pretty much everything. The actual program is, essentially, a binary that the operating system (OS) loads into memory and starts. Everything else, from memory management to security considerations are a burden of the programmer. -Managed code is written in one of the high-level languages that can be run on top of .NET, such as C#, Visual Basic, F# and others. When you compile code written in those languages with their respective compiler, you don’t get machine code. You get **Intermediate Language** code which the runtime then compiles and executes. C++ is the one exception to this rule, as it can also produce native, unmanaged binaries that run on Windows. +Managed code is written in one of the high-level languages that can be run on top of .NET, such as C#, Visual Basic, F# and others. When you compile code written in those languages with their respective compiler, you don't get machine code. You get **Intermediate Language** code which the runtime then compiles and executes. C++ is the one exception to this rule, as it can also produce native, unmanaged binaries that run on Windows. ## Intermediate Language & execution -What is "Intermediate Language" (or IL for short)? It is a product of compilation of code written in high-level .NET languages. Once you compile your code written in one of these languages, you will get a binary that is made out of IL. It is important to note that the IL is independent from any specific language that runs on top of the runtime; there is even a separate specification for it that you can read if you’re so inclined. +What is "Intermediate Language" (or IL for short)? It is a product of compilation of code written in high-level .NET languages. Once you compile your code written in one of these languages, you will get a binary that is made out of IL. It is important to note that the IL is independent from any specific language that runs on top of the runtime; there is even a separate specification for it that you can read if you're so inclined. Once you produce IL from your high-level code, you will most likely want to run it. This is where the CLR takes over and starts the process of **Just-In-Time** compiling, or **JIT-ing** your code from IL to machine code that can actually be run on a CPU. In this way, the CLR knows exactly what your code is doing and can effectively _manage_ it. @@ -31,6 +31,6 @@ Similar to this, C# is one language that allows you to use unmanaged constructs ## More resources -* [Overview of the .NET Framework](../framework/get-started/overview.md) +* [Overview of .NET Framework](../framework/get-started/overview.md) * [Unsafe Code and Pointers](../csharp/programming-guide/unsafe-code-pointers/index.md) * [Native interoperability](./native-interop/index.md) diff --git a/docs/standard/managed-execution-process.md b/docs/standard/managed-execution-process.md index 80af3bad6f9d6..7f77980bb2e47 100644 --- a/docs/standard/managed-execution-process.md +++ b/docs/standard/managed-execution-process.md @@ -2,7 +2,7 @@ title: "Managed Execution Process" ms.date: "03/30/2017" ms.technology: dotnet-standard -helpviewer_keywords: +helpviewer_keywords: - "source code language" - "code, managed execution process" - "runtime, managed execution process" @@ -12,93 +12,93 @@ helpviewer_keywords: ms.assetid: 476b03dc-2b12-49a7-b067-41caeaa2f533 --- # Managed Execution Process - The managed execution process includes the following steps, which are discussed in detail later in this topic: - -1. [Choosing a compiler](#choosing_a_compiler). - - To obtain the benefits provided by the common language runtime, you must use one or more language compilers that target the runtime. - -2. [Compiling your code to MSIL](#compiling_to_msil). - - Compiling translates your source code into Microsoft intermediate language (MSIL) and generates the required metadata. - -3. [Compiling MSIL to native code](#compiling_msil_to_native_code). - - At execution time, a just-in-time (JIT) compiler translates the MSIL into native code. During this compilation, code must pass a verification process that examines the MSIL and metadata to find out whether the code can be determined to be type safe. - -4. [Running code](#running_code). - - The common language runtime provides the infrastructure that enables execution to take place and services that can be used during execution. - + The managed execution process includes the following steps, which are discussed in detail later in this topic: + +1. [Choosing a compiler](#choosing_a_compiler). + + To obtain the benefits provided by the common language runtime, you must use one or more language compilers that target the runtime. + +2. [Compiling your code to MSIL](#compiling_to_msil). + + Compiling translates your source code into Microsoft intermediate language (MSIL) and generates the required metadata. + +3. [Compiling MSIL to native code](#compiling_msil_to_native_code). + + At execution time, a just-in-time (JIT) compiler translates the MSIL into native code. During this compilation, code must pass a verification process that examines the MSIL and metadata to find out whether the code can be determined to be type safe. + +4. [Running code](#running_code). + + The common language runtime provides the infrastructure that enables execution to take place and services that can be used during execution. + -## Choosing a Compiler - To obtain the benefits provided by the common language runtime (CLR), you must use one or more language compilers that target the runtime, such as Visual Basic, C#, Visual C++, F#, or one of many third-party compilers such as an Eiffel, Perl, or COBOL compiler. - - Because it is a multilanguage execution environment, the runtime supports a wide variety of data types and language features. The language compiler you use determines which runtime features are available, and you design your code using those features. Your compiler, not the runtime, establishes the syntax your code must use. If your component must be completely usable by components written in other languages, your component's exported types must expose only language features that are included in the [Language Independence and Language-Independent Components](language-independence-and-language-independent-components.md) (CLS). You can use the attribute to ensure that your code is CLS-compliant. For more information, see [Language Independence and Language-Independent Components](language-independence-and-language-independent-components.md). - - [Back to top](#introduction) - +## Choosing a Compiler + To obtain the benefits provided by the common language runtime (CLR), you must use one or more language compilers that target the runtime, such as Visual Basic, C#, Visual C++, F#, or one of many third-party compilers such as an Eiffel, Perl, or COBOL compiler. + + Because it is a multilanguage execution environment, the runtime supports a wide variety of data types and language features. The language compiler you use determines which runtime features are available, and you design your code using those features. Your compiler, not the runtime, establishes the syntax your code must use. If your component must be completely usable by components written in other languages, your component's exported types must expose only language features that are included in the [Language Independence and Language-Independent Components](language-independence-and-language-independent-components.md) (CLS). You can use the attribute to ensure that your code is CLS-compliant. For more information, see [Language Independence and Language-Independent Components](language-independence-and-language-independent-components.md). + + [Back to top](#introduction) + -## Compiling to MSIL - When compiling to managed code, the compiler translates your source code into Microsoft intermediate language (MSIL), which is a CPU-independent set of instructions that can be efficiently converted to native code. MSIL includes instructions for loading, storing, initializing, and calling methods on objects, as well as instructions for arithmetic and logical operations, control flow, direct memory access, exception handling, and other operations. Before code can be run, MSIL must be converted to CPU-specific code, usually by a [just-in-time (JIT) compiler](#compiling_msil_to_native_code). Because the common language runtime supplies one or more JIT compilers for each computer architecture it supports, the same set of MSIL can be JIT-compiled and run on any supported architecture. - - When a compiler produces MSIL, it also produces metadata. Metadata describes the types in your code, including the definition of each type, the signatures of each type's members, the members that your code references, and other data that the runtime uses at execution time. The MSIL and metadata are contained in a portable executable (PE) file that is based on and that extends the published Microsoft PE and common object file format (COFF) used historically for executable content. This file format, which accommodates MSIL or native code as well as metadata, enables the operating system to recognize common language runtime images. The presence of metadata in the file together with MSIL enables your code to describe itself, which means that there is no need for type libraries or Interface Definition Language (IDL). The runtime locates and extracts the metadata from the file as needed during execution. - - [Back to top](#introduction) - +## Compiling to MSIL + When compiling to managed code, the compiler translates your source code into Microsoft intermediate language (MSIL), which is a CPU-independent set of instructions that can be efficiently converted to native code. MSIL includes instructions for loading, storing, initializing, and calling methods on objects, as well as instructions for arithmetic and logical operations, control flow, direct memory access, exception handling, and other operations. Before code can be run, MSIL must be converted to CPU-specific code, usually by a [just-in-time (JIT) compiler](#compiling_msil_to_native_code). Because the common language runtime supplies one or more JIT compilers for each computer architecture it supports, the same set of MSIL can be JIT-compiled and run on any supported architecture. + + When a compiler produces MSIL, it also produces metadata. Metadata describes the types in your code, including the definition of each type, the signatures of each type's members, the members that your code references, and other data that the runtime uses at execution time. The MSIL and metadata are contained in a portable executable (PE) file that is based on and that extends the published Microsoft PE and common object file format (COFF) used historically for executable content. This file format, which accommodates MSIL or native code as well as metadata, enables the operating system to recognize common language runtime images. The presence of metadata in the file together with MSIL enables your code to describe itself, which means that there is no need for type libraries or Interface Definition Language (IDL). The runtime locates and extracts the metadata from the file as needed during execution. + + [Back to top](#introduction) + -## Compiling MSIL to Native Code - Before you can run Microsoft intermediate language (MSIL), it must be compiled against the common language runtime to native code for the target machine architecture. The .NET Framework provides two ways to perform this conversion: - -- A .NET Framework just-in-time (JIT) compiler. - -- The .NET Framework [Ngen.exe (Native Image Generator)](../framework/tools/ngen-exe-native-image-generator.md). - -### Compilation by the JIT Compiler - JIT compilation converts MSIL to native code on demand at application run time, when the contents of an assembly are loaded and executed. Because the common language runtime supplies a JIT compiler for each supported CPU architecture, developers can build a set of MSIL assemblies that can be JIT-compiled and run on different computers with different machine architectures. However, if your managed code calls platform-specific native APIs or a platform-specific class library, it will run only on that operating system. - - JIT compilation takes into account the possibility that some code might never be called during execution. Instead of using time and memory to convert all the MSIL in a PE file to native code, it converts the MSIL as needed during execution and stores the resulting native code in memory so that it is accessible for subsequent calls in the context of that process. The loader creates and attaches a stub to each method in a type when the type is loaded and initialized. When a method is called for the first time, the stub passes control to the JIT compiler, which converts the MSIL for that method into native code and modifies the stub to point directly to the generated native code. Therefore, subsequent calls to the JIT-compiled method go directly to the native code. - -### Install-Time Code Generation Using NGen.exe - Because the JIT compiler converts an assembly's MSIL to native code when individual methods defined in that assembly are called, it affects performance adversely at run time. In most cases, that diminished performance is acceptable. More importantly, the code generated by the JIT compiler is bound to the process that triggered the compilation. It cannot be shared across multiple processes. To allow the generated code to be shared across multiple invocations of an application or across multiple processes that share a set of assemblies, the common language runtime supports an ahead-of-time compilation mode. This ahead-of-time compilation mode uses the [Ngen.exe (Native Image Generator)](../framework/tools/ngen-exe-native-image-generator.md) to convert MSIL assemblies to native code much like the JIT compiler does. However, the operation of Ngen.exe differs from that of the JIT compiler in three ways: - -- It performs the conversion from MSIL to native code before running the application instead of while the application is running. - -- It compiles an entire assembly at a time, instead of one method at a time. - -- It persists the generated code in the Native Image Cache as a file on disk. - -### Code Verification - As part of its compilation to native code, the MSIL code must pass a verification process unless an administrator has established a security policy that allows the code to bypass verification. Verification examines MSIL and metadata to find out whether the code is type safe, which means that it accesses only the memory locations it is authorized to access. Type safety helps isolate objects from each other and helps protect them from inadvertent or malicious corruption. It also provides assurance that security restrictions on code can be reliably enforced. - - The runtime relies on the fact that the following statements are true for code that is verifiably type safe: - -- A reference to a type is strictly compatible with the type being referenced. - -- Only appropriately defined operations are invoked on an object. - -- Identities are what they claim to be. - - During the verification process, MSIL code is examined in an attempt to confirm that the code can access memory locations and call methods only through properly defined types. For example, code cannot allow an object's fields to be accessed in a manner that allows memory locations to be overrun. Additionally, verification inspects code to determine whether the MSIL has been correctly generated, because incorrect MSIL can lead to a violation of the type safety rules. The verification process passes a well-defined set of type-safe code, and it passes only code that is type safe. However, some type-safe code might not pass verification because of some limitations of the verification process, and some languages, by design, do not produce verifiably type-safe code. If type-safe code is required by the security policy but the code does not pass verification, an exception is thrown when the code is run. - - [Back to top](#introduction) - +## Compiling MSIL to Native Code + Before you can run Microsoft intermediate language (MSIL), it must be compiled against the common language runtime to native code for the target machine architecture. .NET provides two ways to perform this conversion: + +- A .NET just-in-time (JIT) compiler. + +- [Ngen.exe (Native Image Generator)](../framework/tools/ngen-exe-native-image-generator.md). + +### Compilation by the JIT Compiler + JIT compilation converts MSIL to native code on demand at application run time, when the contents of an assembly are loaded and executed. Because the common language runtime supplies a JIT compiler for each supported CPU architecture, developers can build a set of MSIL assemblies that can be JIT-compiled and run on different computers with different machine architectures. However, if your managed code calls platform-specific native APIs or a platform-specific class library, it will run only on that operating system. + + JIT compilation takes into account the possibility that some code might never be called during execution. Instead of using time and memory to convert all the MSIL in a PE file to native code, it converts the MSIL as needed during execution and stores the resulting native code in memory so that it is accessible for subsequent calls in the context of that process. The loader creates and attaches a stub to each method in a type when the type is loaded and initialized. When a method is called for the first time, the stub passes control to the JIT compiler, which converts the MSIL for that method into native code and modifies the stub to point directly to the generated native code. Therefore, subsequent calls to the JIT-compiled method go directly to the native code. + +### Install-Time Code Generation Using NGen.exe + Because the JIT compiler converts an assembly's MSIL to native code when individual methods defined in that assembly are called, it affects performance adversely at run time. In most cases, that diminished performance is acceptable. More importantly, the code generated by the JIT compiler is bound to the process that triggered the compilation. It cannot be shared across multiple processes. To allow the generated code to be shared across multiple invocations of an application or across multiple processes that share a set of assemblies, the common language runtime supports an ahead-of-time compilation mode. This ahead-of-time compilation mode uses the [Ngen.exe (Native Image Generator)](../framework/tools/ngen-exe-native-image-generator.md) to convert MSIL assemblies to native code much like the JIT compiler does. However, the operation of Ngen.exe differs from that of the JIT compiler in three ways: + +- It performs the conversion from MSIL to native code before running the application instead of while the application is running. + +- It compiles an entire assembly at a time, instead of one method at a time. + +- It persists the generated code in the Native Image Cache as a file on disk. + +### Code Verification + As part of its compilation to native code, the MSIL code must pass a verification process unless an administrator has established a security policy that allows the code to bypass verification. Verification examines MSIL and metadata to find out whether the code is type safe, which means that it accesses only the memory locations it is authorized to access. Type safety helps isolate objects from each other and helps protect them from inadvertent or malicious corruption. It also provides assurance that security restrictions on code can be reliably enforced. + + The runtime relies on the fact that the following statements are true for code that is verifiably type safe: + +- A reference to a type is strictly compatible with the type being referenced. + +- Only appropriately defined operations are invoked on an object. + +- Identities are what they claim to be. + + During the verification process, MSIL code is examined in an attempt to confirm that the code can access memory locations and call methods only through properly defined types. For example, code cannot allow an object's fields to be accessed in a manner that allows memory locations to be overrun. Additionally, verification inspects code to determine whether the MSIL has been correctly generated, because incorrect MSIL can lead to a violation of the type safety rules. The verification process passes a well-defined set of type-safe code, and it passes only code that is type safe. However, some type-safe code might not pass verification because of some limitations of the verification process, and some languages, by design, do not produce verifiably type-safe code. If type-safe code is required by the security policy but the code does not pass verification, an exception is thrown when the code is run. + + [Back to top](#introduction) + -## Running Code - The common language runtime provides the infrastructure that enables managed execution to take place and services that can be used during execution. Before a method can be run, it must be compiled to processor-specific code. Each method for which MSIL has been generated is JIT-compiled when it is called for the first time, and then run. The next time the method is run, the existing JIT-compiled native code is run. The process of JIT-compiling and then running the code is repeated until execution is complete. - - During execution, managed code receives services such as garbage collection, security, interoperability with unmanaged code, cross-language debugging support, and enhanced deployment and versioning support. - - In Microsoft Windows Vista, the operating system loader checks for managed modules by examining a bit in the COFF header. The bit being set denotes a managed module. If the loader detects managed modules, it loads mscoree.dll, and `_CorValidateImage` and `_CorImageUnloading` notify the loader when the managed module images are loaded and unloaded. `_CorValidateImage` performs the following actions: - -1. Ensures that the code is valid managed code. - -2. Changes the entry point in the image to an entry point in the runtime. - - On 64-bit Windows, `_CorValidateImage` modifies the image that is in memory by transforming it from PE32 to PE32+ format. - - [Back to top](#introduction) - +## Running Code + The common language runtime provides the infrastructure that enables managed execution to take place and services that can be used during execution. Before a method can be run, it must be compiled to processor-specific code. Each method for which MSIL has been generated is JIT-compiled when it is called for the first time, and then run. The next time the method is run, the existing JIT-compiled native code is run. The process of JIT-compiling and then running the code is repeated until execution is complete. + + During execution, managed code receives services such as garbage collection, security, interoperability with unmanaged code, cross-language debugging support, and enhanced deployment and versioning support. + + In Microsoft Windows Vista, the operating system loader checks for managed modules by examining a bit in the COFF header. The bit being set denotes a managed module. If the loader detects managed modules, it loads mscoree.dll, and `_CorValidateImage` and `_CorImageUnloading` notify the loader when the managed module images are loaded and unloaded. `_CorValidateImage` performs the following actions: + +1. Ensures that the code is valid managed code. + +2. Changes the entry point in the image to an entry point in the runtime. + + On 64-bit Windows, `_CorValidateImage` modifies the image that is in memory by transforming it from PE32 to PE32+ format. + + [Back to top](#introduction) + ## See also - [Overview](../framework/get-started/overview.md) diff --git a/docs/standard/metadata-and-self-describing-components.md b/docs/standard/metadata-and-self-describing-components.md index 84b355dc62a3b..390803c9af0d8 100644 --- a/docs/standard/metadata-and-self-describing-components.md +++ b/docs/standard/metadata-and-self-describing-components.md @@ -13,12 +13,12 @@ helpviewer_keywords: - "metadata, about metadata" - "common language runtime, metadata" - "PE files, metadata" - - "components [.NET Framework], metadata" + - "components [.NET], metadata" ms.assetid: 3dd13c5d-a508-455b-8dce-0a852882a5a7 --- # Metadata and Self-Describing Components -In the past, a software component (.exe or .dll) that was written in one language could not easily use a software component that was written in another language. COM provided a step towards solving this problem. The .NET Framework makes component interoperation even easier by allowing compilers to emit additional declarative information into all modules and assemblies. This information, called metadata, helps components to interact seamlessly. +In the past, a software component (.exe or .dll) that was written in one language could not easily use a software component that was written in another language. COM provided a step towards solving this problem. .NET makes component interoperation even easier by allowing compilers to emit additional declarative information into all modules and assemblies. This information, called metadata, helps components to interact seamlessly. Metadata is binary information describing your program that is stored either in a common language runtime portable executable (PE) file or in memory. When you compile your code into a PE file, metadata is inserted into one portion of the file, and your code is converted to Microsoft intermediate language (MSIL) and inserted into another portion of the file. Every type and member that is defined and referenced in a module or assembly is described within metadata. When code is executed, the runtime loads metadata into memory and references it to discover information about your code's classes, members, inheritance, and so on. @@ -46,7 +46,7 @@ In the past, a software component (.exe or .dll) that was written in one languag ## Benefits of Metadata -Metadata is the key to a simpler programming model, and eliminates the need for Interface Definition Language (IDL) files, header files, or any external method of component reference. Metadata enables .NET Framework languages to describe themselves automatically in a language-neutral manner, unseen by both the developer and the user. Additionally, metadata is extensible through the use of attributes. Metadata provides the following major benefits: +Metadata is the key to a simpler programming model, and eliminates the need for Interface Definition Language (IDL) files, header files, or any external method of component reference. Metadata enables .NET languages to describe themselves automatically in a language-neutral manner, unseen by both the developer and the user. Additionally, metadata is extensible through the use of attributes. Metadata provides the following major benefits: - Self-describing files. @@ -58,11 +58,11 @@ Metadata is the key to a simpler programming model, and eliminates the need for - Attributes. - The .NET Framework lets you declare specific kinds of metadata, called attributes, in your compiled file. Attributes can be found throughout the .NET Framework and are used to control in more detail how your program behaves at run time. Additionally, you can emit your own custom metadata into .NET Framework files through user-defined custom attributes. For more information, see [Attributes](attributes/index.md). + .NET lets you declare specific kinds of metadata, called attributes, in your compiled file. Attributes can be found throughout .NET and are used to control in more detail how your program behaves at run time. Additionally, you can emit your own custom metadata into .NET files through user-defined custom attributes. For more information, see [Attributes](attributes/index.md). ## Metadata and the PE File Structure -Metadata is stored in one section of a .NET Framework portable executable (PE) file, while Microsoft intermediate language (MSIL) is stored in another section of the PE file. The metadata portion of the file contains a series of table and heap data structures. The MSIL portion contains MSIL and metadata tokens that reference the metadata portion of the PE file. You might encounter metadata tokens when you use tools such as the [MSIL Disassembler (Ildasm.exe)](../framework/tools/ildasm-exe-il-disassembler.md) to view your code's MSIL, for example. +Metadata is stored in one section of a .NET portable executable (PE) file, while Microsoft intermediate language (MSIL) is stored in another section of the PE file. The metadata portion of the file contains a series of table and heap data structures. The MSIL portion contains MSIL and metadata tokens that reference the metadata portion of the PE file. You might encounter metadata tokens when you use tools such as the [MSIL Disassembler (Ildasm.exe)](../framework/tools/ildasm-exe-il-disassembler.md) to view your code's MSIL, for example. ### Metadata Tables and Heaps @@ -128,7 +128,7 @@ public class MyApp When the code runs, the runtime loads the module into memory and consults the metadata for this class. Once loaded, the runtime performs extensive analysis of the method's Microsoft intermediate language (MSIL) stream to convert it to fast native machine instructions. The runtime uses a just-in-time (JIT) compiler to convert the MSIL instructions to native machine code one method at a time as needed. -The following example shows part of the MSIL produced from the previous code's `Main` function. You can view the MSIL and metadata from any .NET Framework application using the [MSIL Disassembler (Ildasm.exe)](../framework/tools/ildasm-exe-il-disassembler.md). +The following example shows part of the MSIL produced from the previous code's `Main` function. You can view the MSIL and metadata from any .NET application using the [MSIL Disassembler (Ildasm.exe)](../framework/tools/ildasm-exe-il-disassembler.md). ```console .entrypoint