packages, meta-packages and frameworks in. Net Core (Packages, metapackages and Frameworks)

package, meta-package and framework

This article is translated from Packages, Metapackages and Frameworks.

. Net Core is a platform made up of NuGet Packages. Some product experiences benefit from fine-grained definitions of code packages, while others benefit from coarse-grained definitions, both of which are useful and cannot be absolutely good or bad. therefore, in order to adapt to these two differences, a good product should be split into a group of fine-grained code packages, which are independent of each other, the formal name of a single code package is called "meta-package" (metapackage).

Each. NET Core package supports running in a variety of. net runtimes, which are referred to as the Framework. Some of these frameworks are traditional frameworks, such as net46, while others are new frameworks that can be thought of as "package-based frameworks", another new definition model of the Framework. These package-based frameworks are all made up of packages, which themselves are also defined as packages, which form a relatively close relationship between the framework and the Package.

Package

. Net core is split into a set of packages that provide primitive types, as well as higher-level data types, application combination types, and common class Libraries. Each package represents a separate assembly of the same name, for example, system.runtime This package, which contains the System.Runtime.dll assembly.

Defining these packages as fine-grained structural styles has the following benefits:

• A fine-grained package can be delivered within its own development cycle, with only the other limited packages associated with it being tested.
• Fine-grained packages can provide different OS and CPU Support.
• A fine-grained package can depend on a class library Alone.
• Applications can become smaller because packages that are not referenced do not become part of the final release.

These benefits apply only to specific situations. For example, all packages of Net Core provide support for the same platform during the same release cycle, in which case patches and updates are released in a small, separate package. Because of this small range of changes, patch validation and related work can be limited to the requirements of a single platform and class library, so that work can be minimized.

The following is a list of. Net Core packages based on the NuGet library:

• Sytem.runtime-the most basic. Net Core package that contains object,string,array, Action, and ilist<t>.
• System.collections-a set of primitive generic collections containing list<t> and dictionary<k,v>.
• System.Net.Http-a set of types for Http network traffic, including HttpClient and Httpresponsemessage.
• System.IO.FileSystem-a set of types used to read and write local or network disk storage, including the File and Dictory Classes.
• System.linq-a set of object query types that contain Enumerable and ilookup<tkey, telement>.
• System.reflection-a set of types for loading, checking and activating the type, including Assembly, typeinfo, and MethodInfo

The package reference is defined in the Project.json file, and in the following example, the System.Runtime package is used:

{"dependencies": {    "system.runtime": "4.1.0"  },  "frameworks": {    "netstandard1.5": {}}  }

　　

In most cases, you may not need to refer directly to the Underlying. Net Core package, because too many of the referenced packages can make you MAD. So you just need to quote the Meta-package.

Meta Package

Wenbao is a NuGet package that conveniently describes a set of meaning-related Packages. The development team uses dependencies to describe a set of packages that describe a framework (the framework) through this set of packages and then selectively publish Them.

Referencing a meta-package, This operation actually adds a reference dependency to each individual package in the package, which means that all the class libraries (refs or Libs) in these packages are available in IntelliSense (intellisense) and are also published (in the Lib Directory) to your Application.

Note: Lib and ref refer to the corresponding folder in the NuGet package, which describes the common API package represented by the meta-assembly, which contains the implementation of this public API in different frameworks.

Using a meta-package has the following benefits:

• Provides a convenient user experience for referencing a large number of fine-grained packages.
• Defines a set of fully tested and well-worked packages (including the various versions specified).

. Net Standard Class Library Meta-package:

• Netstandard.library-describes part of the ". Net standard class library". All. net implementations, such as The. net framework,. net Core, Mono, support The. net Standard class library, which is the ' Netstandard ' Framework.

The following is The. Net Core meta-package:

• Microsoft.NETCore.App-describes a partial class library of The. Net Core release, that is. Netcoreapp Frame. It relies on netstandard.library this smaller meta-package.
• Microsoft.NETCore.Portable.Compatibility-a set of compatible proxies that enable the Mscorlib-based Portable class Library (PCL) to run On. Net core.

The reference method of a meta-package is defined in project.json, just like an ordinary nuget package.

In the following example, the netstandard.library is referenced to create a portable class library that is based on The. Net Runtime.

{"  dependencies": {    "netstandard.library": "1.5.0"  },  "frameworks": {    "netstandard1.5": {}}  }

　　

In the following example, the MICROSOFT.NETCORE.APP is referenced to create an application or class library, run On. net core, and use all of the. net core Features. It provides a greater range of access than netstandard.library.

{"  dependencies": {    "Microsoft.NETCore.App": "1.0.0"  },  "frameworks": {    "netcoreapp1.0": {}}  }

Frame

Each. Net Core Package supports a set of frameworks that are declared in the Framework folder (in the preceding Lib and ref directories). The framework describes a set of available APIs (and potentially other features), so you can get those features when you specify a target Framework. When the new API joins, it goes into the version management Process.

For example, System.IO.FileSystem supports the following frameworks:

• . netframework, version 4.6
• . netstandard, version 1.3
• 6 Xamarin Platforms (e.g., Xamarinios10)

It is necessary to compare the first two frameworks, as they each represent a different way of defining the Framework.

. netframework,version=4.6 This framework represents the APIs available in The. Net framework 4.6, which you can use to produce your own class libraries, reference the assemblies in them, and publish your class library in the same party as the NuGet Package. After they are published, they are located in a folder named Net46 under the Lib Folder. In this way, your

Class libraries are used by applications that are based on or compatible with. Net Framework 4.6. This is how the traditional class library works.

And. netstandard,version=1.3 This framework is a package-based Framework. The framework is made up of packages that target this framework, defined and implemented Apis.

The difference is visible: the traditional framework is defined as a whole, and the package-based framework allows for the free combination of different packages.

package-based Framework

The relationship between the framework and the package is Bidirectional.

The first is to define a set of APIs for a given framework, such as netstandard1.3. A package that targets netstandard1.3 (or a compatible framework, such as NETSTANDARD1.0) defines which APIs are available and sounds like a circular definition, but Not. From the perspective of the word "package-based" itself, the Framework's API definition comes from the package, and the framework itself does not define any Apis.

second, the choice of assets in this two-way relationship. The inside of a package can contain assets of different frameworks, and for a set of packages or packages, the framework needs to decide which assets it should choose, for example, net46 or netstandard1.3. This is important for cross-asset, for example, an net46 asset may not be compatible with The. NET Framework 4.0 or. net Core 1.0.

You can see this relationship in the API selection framework as the target, and the API defines the framework, and the framework is used for asset selection, and the asset implements the API.

Here's an interesting question: where the end of the framework definition is, where consumption begins. The framework can be thought of as a function definition given by the Project.json file, and what you rely on creates a framework that is independent of the dependencies of the full framework that has been published. (the translator Notes: so to understand,

The actual implementation of the framework depends on what you refer to in project.json, and you may not be referencing all the packages, so the package you depend on is a subset of all the packages of the official Framework. ）

On the foundation Of. Net core, There are two packages-based frameworks:

• Netstandard
• Netcoreapp

. NET standard

The. NET Standard framework (netstandard) means the APIs defined and built based on THE. net Standard class Library. If you build a class library that will be used in a variety of running platforms, it should be built based on netstandard, so that the class library will support any runtime that is compatible With. net standards, such as. net Core,. net framework, and Mono/xamarin. Each of these runtimes supports one or several. Net standards, depending on the implementation, as to which version is Supported.

The target frame of Wenbao netstandard.library is Netstandard. The most common way to target a netstandard frame is to refer to the Meta-package. It is defined with a provision of about 40. NET class library and is associated with the API defined by The. NET Standard class Library. You can reference Third-party packages developed based on Netstandard to use Third-party Apis.

A given version of netstandard.library, always matching the highest version exposed by Netstandard. The reference to the framework in the Project.json file is primarily used to select the right asset from this Framework. therefore, If you define netstandard1.5, you need the DLL assets, not netstandard1.4, or net46.

{"dependencies": {   "netstandard.library": "1.5.0"}, "frameworks": {   "netstandard1.5": {}}}

　　

The framework referenced in this Project.json file does not require strict matching with the meta-package, for example, the following Project.json is also correct:

{"dependencies": {   "netstandard.library": "1.5.0"}, "frameworks": {   "netstandard1.3": {}}}

　　

It seems a bit strange to set the build target to netstandard1.3 but use the version 1.5 of Netstandard.library. however, This is a legitimate use case because the meta package supports older Netstandard versions. It may happen that you are using the 1.5.0 version of the meta-package to develop all of your class libraries and then run them in multiple versions of netstandard, in which case you just need to reload netstandard.library 1.5.0, and you don't need to load an earlier Version.

The opposite is not true: netstandard1.5 as a running target, but using the Netstandard.library 1.3.0 version to develop your class library: you cannot use a later version of the framework as a development goal, but you are using a lower version of the Meta-package. The version management mechanism of the Meta-package asset, which matches the definition of the highest version of the Framework. With the release Management mechanism, the first version of Netstandard.library is v1.5.0, which contains the assets of netstandard1.5. The v1.3.0 version in the above example is just for the sake of convenience and does not actually exist.

The translator notes: the various nouns of this paragraph around each other, will be around the person dizzy. For example, It is understood that because the class library is always backwards compatible, the 1.5 implementation necessarily contains all definitions of 1.3, and the 1.5 version of the Meta-package can be run on the 1.3 version of the Framework.

however, This is inconsistent with our intuitive experience, so the author says it looks strange because the program you developed on Win7 (dependent on the high-version Meta-package) is probably not supported on the XP system (the low version framework).

But why is this happening in the magical world Of. Net Core?

This is determined by the version management mechanism Of. Net Core. The article does not give a specific explanation. For version management, There is another article that will be introduced and translated Later.

. NET Core Application

The. NET core application framework (netcoreapp) means that the package-related APIs are based on The. NET core specific release version and the console program model that it provides. the. NET core application must use this framework, Because the console program model must be Used. This model should also be used for class libraries that run only on The. Net Core platform. With this framework, applications (exe) and class libraries (dlls) will only be able to run on The. Net core Platform. (foreigner is very wordy ah) the target frame of Microsoft.NETCore.App is netcoreapp. This meta-package provides about 60 class libraries, of which about 40 are provided by netstandard.library, and 20 are implemented by MICROSOFT.NETCORE.APP themselves (addition). If the target framework for the class library you are developing is NETCOREAPP or its compatible framework (such as netstandard), you can use these 20 additional class libraries (addition) of MICROSOFT.NETCORE.APP to invoke these additional Apis.

addition, refers to the additional implementation by MICROSOFT.NETCORE.APP on the basis of netstandard.library, about 20 class Libraries. In the code migrated from the traditional framework, if you use netstandard.library, there may be cases where classes or methods are not recognized, most likely because these unrecognized parts are implemented in these 20 addition, instead of referencing MICROSOFT.NETCORE.APP may resolve the Issue.

Most of the additional class libraries implemented by MICROSOFT.NETCORE.APP can also be run on other Netstandard frameworks, if they meet the runtime environment of the class library on which they depend. This means that the class library running on the Netstandard framework also references these additional packages as Dependencies.

This passage is also more obscure, and then give Examples. For example, Microsoft.NETCore.App 1.5 (abbreviated App1.5) is an additional 20 packages (Add20), App1.5 = Lib1.5 + Add20, on top of netstandard.library 1.5 (abbreviated Lib1.5). It says that Lib1.5 can run on frame netstandard 1.5 (abbreviated Std1.5), and Std1.3, and if the ADD20 can also run on Lib1.3, then App1.5 can be run on Lib1.3.

packages, meta-packages and frameworks in. Net Core (Packages, metapackages and Frameworks)