Shulou(Shulou.com)06/03 Report--

Net Core application types Portableapps and Self-containedapps how to use, for this problem, this article describes in detail the corresponding analysis and solutions, hoping to help more partners who want to solve this problem to find a more simple and easy way.

There are many ways to consider the type of application to be built, which is usually used to describe a specific execution model or an application based on it. For example: console application (Console Application), Web application (Web Application), and so on. All of these types of applications can be created using the .NET Core. The .NET Core itself is a general development platform. But to give .NET Core cross-platform features,. NET Core still needs a corner to discover the type of application, which is called: application portability (application's portablility). Portability essentially means where to run your application and what prerequisites need to be met to run it on a particular machine.

Portable applications

Portable applications are the default application type for .NET Core. This requires that the .NET Core be pre-installed on the target machine on which the program is running. This means that as a developer, your program is portable between different .NET Core devices. This type of application only needs to carry and deploy its own code and dependencies (outside the. NET Core library). To create a portable application, all you need to do is set the current .NET Core class library in project.json, and then change the frameworks to look like this:

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

[Microsoft.NETCore.App] is a "meta-package" that shows you your target .NET Core class library. The [type:platform] attribute in the dependency means that when released, the publishing tool will omit publishing these dependent .NET Core class library files because these dependent class library files have been installed on the target server with the .NET Core.

Portable applications using native dependencies

Portable applications that use native dependencies are a subset of the above portable applications. These portable applications have some native dependencies specified in specific places on the dependency chain, so that these native dependencies can run directly on the target platform, and our portable programs can also run directly on these platforms. The most typical example is our Kestrel server (ASP.NET cross-platform Web server), which is built on libuv (native dependency). When you release a portable application with native dependencies, all the release output is the same as above, and for native dependencies, the release output generates a folder for each RID (Runtime Identifier). The following project.json file shows a portable application using native dependencies:

"dependencies": {"Microsoft.NETCore.App": {"version": "1.0.0", "type": "platform"}, "Microsoft.AspNetCore.Server.Kestrel": "1.0.0 copyright *"}, "frameworks": {"netcoreapp1.0": {}}

Self-contained applications

Unlike portable applications, stand-alone applications do not rely on any shared components on the target machine where you are going to deploy the program. As its name implies, it means that the entire dependency is closed-loop and the runtime will be released with the entire program. This makes the entire release larger, but it also allows the program to run on any platform supported by the .NET Core with the correct native dependencies (regardless of whether the. NET Core has been installed on the target server beforehand). This makes it easier to deploy your application to the target server. Because the launch of the application now comes with its own runtime, you must specify in advance which platforms your program will run on. For example, if you want to release a stand-alone program to Windows 10 but are not going to run it to macOS and Linux, you will have to add or remove some platforms (platforms) during development. Completing a stand-alone program takes a lot of steps, but the first step is to delete any "type": "platform"

Property. The second step is to keep the dependency on Microsoft.NETCore.App, which pulls in some of the rest of the things we need. Finally, we need to add a runtimes node to project.json to indicate which platforms our program will run on.

"dependencies": {"Microsoft.NETCore.App": "1.0.0"}, "frameworks": {"netcoreapp1.0": {}, "runtimes": {"win10-x64": {}, "osx.10.11-x64": {}}

When we restore a project, if the project.json contains a runtimes node, NuGet will restore all specified runtimes. Next, when we need to publish an application for a given platform, we use the following command line:

Dotnet publish-runtime

RID must be the RID specified in project.json, such as win10-x64 or osx.10.11-x64, otherwise an error will be reported. If the operating system you are about to release to is your current operating system. NET Core is running, you can directly use the following command:

Dotnet publish

But you still need to specify the corresponding RID in the project.json.

It is important to note, however, that within the time frame of .NET Core Tools Preview 2, stand-alone applications are released from the native NuGet cache, which means that all application dependencies, including the .NET Core runtime and class libraries, are not run-optimized. As a result, stand-alone applications have lower overall performance than portable applications because the .NET Core runtime and class libraries that portable applications rely on are ready-to-run-ready.

This is the answer to the question about how to use the .NET Core application type Portableapps and Self-containedapps. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.