You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/framework/data/adonet/connection-string-syntax.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -133,9 +133,9 @@ You can also set the <xref:System.Data.SqlClient.SqlConnectionStringBuilder.Data
133
133
The <xref:System.Data.OleDb.OleDbConnection.ConnectionString%2A> property of a <xref:System.Data.OleDb.OleDbConnection> allows you to get or set a connection string for an OLE DB data source, such as Microsoft Access. You can also create an `OleDb` connection string at run time by using the <xref:System.Data.OleDb.OleDbConnectionStringBuilder> class.
134
134
135
135
### OleDb Connection String Syntax
136
-
You must specify a provider name for an <xref:System.Data.OleDb.OleDbConnection> connection string. The following connection string connects to a Microsoft Access database using the Jet provider. Note that the `UserID` and `Password` keywords are optional if the database is unsecured (the default).
136
+
You must specify a provider name for an <xref:System.Data.OleDb.OleDbConnection> connection string. The following connection string connects to a Microsoft Access database using the Jet provider. Note that the `User ID` and `Password` keywords are optional if the database is unsecured (the default).
137
137
138
-
```
138
+
```
139
139
Provider=Microsoft.Jet.OLEDB.4.0; Data Source=d:\Northwind.mdb;User ID=Admin;Password=;
The .NET Framework provides a run-time environment called the common language runtime, which runs the code and provides services that make the development process easier.
30
-
31
-
Compilers and tools expose the common language runtime's functionality and enable you to write code that benefits from this managed execution environment. Code that you develop with a language compiler that targets the runtime is called managed code; it benefits from features such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services.
32
-
28
+
# Common Language Runtime (CLR) overview
29
+
30
+
The .NET Framework provides a run-time environment called the common language runtime, which runs the code and provides services that make the development process easier.
31
+
32
+
Compilers and tools expose the common language runtime's functionality and enable you to write code that benefits from this managed execution environment. Code that you develop with a language compiler that targets the runtime is called managed code; it benefits from features such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services.
33
+
33
34
> [!NOTE]
34
-
> Compilers and tools are able to produce output that the common language runtime can consume because the type system, the format of metadata, and the runtime environment (the virtual execution system) are all defined by a public standard, the ECMA Common Language Infrastructure specification. For more information, see [ECMA C# and Common Language Infrastructure Specifications](https://www.visualstudio.com/license-terms/ecma-c-common-language-infrastructure-standards/).
35
-
36
-
To enable the runtime to provide services to managed code, language compilers must emit metadata that describes the types, members, and references in your code. Metadata is stored with the code; every loadable common language runtime portable executable (PE) file contains metadata. The runtime uses metadata to locate and load classes, lay out instances in memory, resolve method invocations, generate native code, enforce security, and set run-time context boundaries.
37
-
38
-
The runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used. Objects whose lifetimes are managed in this way are called managed data. Garbage collection eliminates memory leaks as well as some other common programming errors. If your code is managed, you can use managed data, unmanaged data, or both managed and unmanaged data in your .NET Framework application. Because language compilers supply their own types, such as primitive types, you might not always know (or need to know) whether your data is being managed.
39
-
40
-
The common language runtime makes it easy to design components and applications whose objects interact across languages. Objects written in different languages can communicate with each other, and their behaviors can be tightly integrated. For example, you can define a class and then use a different language to derive a class from your original class or call a method on the original class. You can also pass an instance of a class to a method of a class written in a different language. This cross-language integration is possible because language compilers and tools that target the runtime use a common type system defined by the runtime, and they follow the runtime's rules for defining new types, as well as for creating, using, persisting, and binding to types.
41
-
42
-
As part of their metadata, all managed components carry information about the components and resources they were built against. The runtime uses this information to ensure that your component or application has the specified versions of everything it needs, which makes your code less likely to break because of some unmet dependency. Registration information and state data are no longer stored in the registry where they can be difficult to establish and maintain. Instead, information about the types you define (and their dependencies) is stored with the code as metadata, making the tasks of component replication and removal much less complicated.
43
-
44
-
Language compilers and tools expose the runtime's functionality in ways that are intended to be useful and intuitive to developers. This means that some features of the runtime might be more noticeable in one environment than in another. How you experience the runtime depends on which language compilers or tools you use. For example, if you are a Visual Basic developer, you might notice that with the common language runtime, the Visual Basic language has more object-oriented features than before. The runtime provides the following benefits:
45
-
46
-
- Performance improvements.
47
-
48
-
- The ability to easily use components developed in other languages.
49
-
50
-
- Extensible types provided by a class library.
51
-
52
-
- Language features such as inheritance, interfaces, and overloading for object-oriented programming.
53
-
54
-
- Support for explicit free threading that allows creation of multithreaded, scalable applications.
55
-
56
-
- Support for structured exception handling.
57
-
58
-
- Support for custom attributes.
59
-
60
-
- Garbage collection.
61
-
62
-
- Use of delegates instead of function pointers for increased type safety and security. For more information about delegates, see [Common Type System](../../docs/standard/base-types/common-type-system.md).
63
-
64
-
## Versions of the Common Language Runtime
65
-
The version number of the .NET Framework doesn't necessarily correspond to the version number of the CLR it includes. The following table shows how the two version numbers correlate.
> Compilers and tools are able to produce output that the common language runtime can consume because the type system, the format of metadata, and the runtime environment (the virtual execution system) are all defined by a public standard, the ECMA Common Language Infrastructure specification. For more information, see [ECMA C# and Common Language Infrastructure Specifications](https://www.visualstudio.com/license-terms/ecma-c-common-language-infrastructure-standards/).
36
+
37
+
To enable the runtime to provide services to managed code, language compilers must emit metadata that describes the types, members, and references in your code. Metadata is stored with the code; every loadable common language runtime portable executable (PE) file contains metadata. The runtime uses metadata to locate and load classes, lay out instances in memory, resolve method invocations, generate native code, enforce security, and set run-time context boundaries.
38
+
39
+
The runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used. Objects whose lifetimes are managed in this way are called managed data. Garbage collection eliminates memory leaks as well as some other common programming errors. If your code is managed, you can use managed data, unmanaged data, or both managed and unmanaged data in your .NET Framework application. Because language compilers supply their own types, such as primitive types, you might not always know (or need to know) whether your data is being managed.
40
+
41
+
The common language runtime makes it easy to design components and applications whose objects interact across languages. Objects written in different languages can communicate with each other, and their behaviors can be tightly integrated. For example, you can define a class and then use a different language to derive a class from your original class or call a method on the original class. You can also pass an instance of a class to a method of a class written in a different language. This cross-language integration is possible because language compilers and tools that target the runtime use a common type system defined by the runtime, and they follow the runtime's rules for defining new types, as well as for creating, using, persisting, and binding to types.
42
+
43
+
As part of their metadata, all managed components carry information about the components and resources they were built against. The runtime uses this information to ensure that your component or application has the specified versions of everything it needs, which makes your code less likely to break because of some unmet dependency. Registration information and state data are no longer stored in the registry where they can be difficult to establish and maintain. Instead, information about the types you define (and their dependencies) is stored with the code as metadata, making the tasks of component replication and removal much less complicated.
44
+
45
+
Language compilers and tools expose the runtime's functionality in ways that are intended to be useful and intuitive to developers. This means that some features of the runtime might be more noticeable in one environment than in another. How you experience the runtime depends on which language compilers or tools you use. For example, if you are a Visual Basic developer, you might notice that with the common language runtime, the Visual Basic language has more object-oriented features than before. The runtime provides the following benefits:
46
+
47
+
- Performance improvements.
48
+
49
+
- The ability to easily use components developed in other languages.
50
+
51
+
- Extensible types provided by a class library.
52
+
53
+
- Language features such as inheritance, interfaces, and overloading for object-oriented programming.
54
+
55
+
- Support for explicit free threading that allows creation of multithreaded, scalable applications.
56
+
57
+
- Support for structured exception handling.
58
+
59
+
- Support for custom attributes.
60
+
61
+
- Garbage collection.
62
+
63
+
- Use of delegates instead of function pointers for increased type safety and security. For more information about delegates, see [Common Type System](../../docs/standard/base-types/common-type-system.md).
64
+
65
+
## CLR versions
66
+
67
+
The version number of the .NET Framework doesn't necessarily correspond to the version number of the CLR it includes. The following table shows how the two version numbers correlate.
|[Managed Execution Process](../../docs/standard/managed-execution-process.md)|Describes the steps required to take advantage of the common language runtime.|
84
-
|[Automatic Memory Management](../../docs/standard/automatic-memory-management.md)|Describes how the garbage collector allocates and releases memory.|
85
-
|[NIB: Overview of the .NET Framework](https://msdn.microsoft.com/library/ea38ac1e-92af-4d1b-8db1-e8a5ea10ed85)|Describes key .NET Framework concepts such as the common type system, cross-language interoperability, managed execution, application domains, and assemblies.|
86
-
|[Common Type System](../../docs/standard/base-types/common-type-system.md)|Describes how types are declared, used, and managed in the runtime in support of cross-language integration.|
87
-
88
-
## See Also
89
-
[Versions and Dependencies](../../docs/framework/migration-guide/versions-and-dependencies.md)
79
+
|4.7 (including 4.7.1 and 4.7.2)|4|
80
+
81
+
## Related topics
82
+
83
+
|Title|Description|
84
+
|-----------|-----------------|
85
+
|[Managed Execution Process](managed-execution-process.md)|Describes the steps required to take advantage of the common language runtime.|
86
+
|[Automatic Memory Management](automatic-memory-management.md)|Describes how the garbage collector allocates and releases memory.|
87
+
|[Overview of the .NET Framework](../framework/get-started/overview.md)|Describes key .NET Framework concepts such as the common type system, cross-language interoperability, managed execution, application domains, and assemblies.|
88
+
|[Common Type System](./base-types/common-type-system.md)|Describes how types are declared, used, and managed in the runtime in support of cross-language integration.|
89
+
90
+
## See also
91
+
92
+
[Versions and Dependencies](../framework/migration-guide/versions-and-dependencies.md)
Copy file name to clipboardExpand all lines: docs/standard/frameworks.md
+13-13Lines changed: 13 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title: Target frameworks
3
3
description: Learn about target frameworks for .NET Core apps and libraries.
4
4
author: richlander
5
5
ms.author: mairaw
6
-
ms.date: 09/22/2017
6
+
ms.date: 04/16/2018
7
7
ms.topic: article
8
8
ms.custom: "updateeachrelease"
9
9
ms.prod: .net
@@ -26,13 +26,13 @@ For package-based target frameworks (for example, .NET Standard and .NET Core),
26
26
27
27
## Latest target framework versions
28
28
29
-
The following table defines the most common target frameworks, how they're referenced, and which version of the [.NET Standard](~/docs/standard/net-standard.md) they implement. These target framework versions are the latest stable versions. Pre-release versions aren't shown. A Target Framework Moniker (TFM) is a standardized token format for specifying the target framework of a .NET app or library.
29
+
The following table defines the most common target frameworks, how they're referenced, and which version of the [.NET Standard](~/docs/standard/net-standard.md) they implement. These target framework versions are the latest stable versions. Pre-release versions aren't shown. A Target Framework Moniker (TFM) is a standardized token format for specifying the target framework of a .NET app or library.
30
30
31
-
| Target Framework | Latest Version | Target Framework Moniker (TFM) | Implemented <br/> .NET Standard Version |
0 commit comments