1. NET Core command line interface (CLI) tool Deprecated project.json and replaced it with a .csproj file, which was project.json used as a project configuration file in the early .NET core, and it is estimated that Microsoft deprecated it after discovering some problems, and MSBuild was still used as a .net compilation tool.
MSBuild introduces:https://docs.microsoft.com/zh-cn ... sbuild?view=vs-2017
When we perform VS compilation and generation, VS just helps us call the MSBuild tool, which means that when we compile the .NET project, we don't need to install the VS tool at all.
The .NET Core CLI tool command is as follows:
.NET Command Line Tools (2.1.301) Usage: dotnet [runtime-options] [path-to-application] Usage: dotnet [sdk-options] [command] [arguments] [command-options]
path-to-application: The path to the application .dll file to be executed.
SDK commands: new initializes the .NET project. restore the dependencies specified in the .NET project. run and execute the .NET project immediately. build .NET project. publish publishes a .NET project for deployment (including the runtime). test runs unit tests using the test runner specified in the project. pack to create a NuGet package. migrate project.json-based projects to MSBuild-based projects. clean clean generated output. SLN Modification Solution (SLN) file. add to the reference. remove from the project. list the tools that the project references or installs. NuGet provides additional NuGet commands. msbuild runs the Microsoft Build Engine (MSBuild). vstest runs the Microsoft Test Execution command-line tool. store stores the specified assembly in the runtime store. tool to install or use tools that extend the .NET experience. build-server interacts with the server that is launched by the build version. help shows help.
Common Options: -v|--verbosity sets the level of detail of the command. The allowed values are Q[UIET], M[inimal], N[Ormal], D[etailed], and diag[nostic]. -h|--help shows help.
Run the dotnet command --help to get more information about the command.
sdk-options: --version shows the version of the .NET Core SDK in use. --info displays .NET Core information. --list-sdks to display the installed SDK. --list-runtimes shows the installed runtime. -d|--diagnostics enables diagnostic output.
runtime-options: --additionalprobingpath <path> The path containing the probe policy and assembly to probe. --fx-version <version> version of the installed version of the shared framework to be used to run the application. --roll-forward-on-no-candidate-fx "No Roll Forward to Candidate Shared Framework" is enabled. --additional-deps <path> to the path to other deps.json files.
Additional tools ('dotnet [tool-name] --help' for more information): dev-certs Create and manage development certificates. ef Entity Framework Core command-line tools. sql-cache SQL Server cache command-line tools. user-secrets Manage development user secrets. watch Start a file watcher that runs a command when files change.
2. Compilation and release
Publish a .NET project for deployment (including the runtime). dotnet publish
C:\project\dotnet\test1>dotnet publish --help Usage: dotnet publish [options]
Options: -h, --help displays help information. -o, --output <OUTPUT_DIR> is used to place the output directory of the published item. -f, --framework <FRAMEWORK> The target framework to be published. The target framework must be specified in the project document. -r, --runtime <RUNTIME_IDENTIFIER> publish the project for a given runtime. Use this when creating self-contained deployments. The default action is to publish an app that depends on the framework. -c, --configuration <CONFIGURATION> is used to generate the project's configuration. The default value for most projects is "Debug". --version-suffix <VERSION_SUFFIX> defines the value of the $(VersionSuffix) property in your project. --manifest <manifest.xml> Path to the target manifest file containing a list of packages to be executed through the publish step. --no-build do not build the project before publishing. Implies --no-restore. --self-contained accompanying applications publish .NET Core runtimes, eliminating the need to install the runtime on the target machine. If a runtime identifier is specified, it defaults to "true". --no-restore Do not perform an implicit restore while executing the command. -v, --verbosity sets the level of detail of the command. The allowed values are Q[UIET], M[inimal], N[Ormal], D[etailed], and diag[nostic]. --no-dependencies sets this flag to ignore project-to-project references and only restore the root project. --force to force all dependencies to be resolved, even if the last restore has been successful. This is equivalent to deleting project.assets.json. From an execution perspective, CLI commands take their parameters and construct a call to the "original" MSBuild to set the desired properties and the desired target to run. To better illustrate this, refer to the following command:
This command publishes the application to the pub folder using the Publish configuration. Internally, this command translates to the following MSBuild call:
Define the target platform for your application
Create a tag in the section of the csproj file (which is used to define the target platform for your app), <PropertyGroup> <RuntimeIdentifiers> and then specify the runtime identifier (RID) for each target platform. Note that semicolons are also required to separate RIDs. Check the Runtime Identifier Catalog for a list of runtime identifiers. For example, the following <PropertyGroup> section indicates that the app runs on a 64-bit Windows 10 operating system and a 64-bit OS X version 10.11 version of the operating system.
If we only want to generate a distribution below the win10 x64 platform, we can execute the following command:
Output folder: C:\project\dotnet\test1\bin\release\netcoreapp2.1\win10-x64\publish, the whole folder has 66M, which is quite large, as shown in the figure below:
Generate the release package under the centos.7-x64 platform, there is 70M, which is also quite large, let's try to publish it on centos 7 to execute it (The .NET Core SDK is not installed on CentOS 7 systems)。
The system information is as follows:
[root@master ~]# uname -a Linux master 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux [root@master ~]# cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core) We upload the file to the temp directory and try to execute the test1 file, which can be output normally, as follows:
[root@master ~]# mkdir temp [root@master ~]# cd temp/ [root@master temp]# ./test1 -bash: ./test1: Not enough permissions [root@master temp]# cd .. [root@master ~]# chmod -R 777 temp/ [root@master ~]# cd temp/ [root@master temp]# ./test1 Hello World! [root@master temp]# echo "http://www.itsvse.com"
http://www.itsvse.com [root@master temp] #
3、. NET Core Run Identifier
.NET Core RID, RID is short for Runtime Identifier. RID values are used to identify the target platform on which the application runs. .NET packages use them to represent platform-specific assets in NuGet packages. The following values are examples of RID: linux-x64, ubuntu.14.04-x64, win7-x64, or osx.10.12-x64. For packages with native dependencies, the RID specifies the platform on which the package can be restored.
<RuntimeIdentifier> You can set a RID in the element of the project file. Multiple RIDs can be defined as a <RuntimeIdentifiers> list (separated by semicolons) in the elements of a project file.
RIDs that represent a specific operating system typically follow the following pattern: [os]. [version]-[architecture]-[additional qualifiers], where:
- [os] is the operating system/platform system name. For example, ubuntu.
- [version] is the OS version, which is formatted by a dot (.) version number. For example, 15.10. Versions should not be marketing releases, as they typically represent multiple discrete versions of the operating system with different platform API peripherals.
- [architecture] is the processor architecture. For example: x86, x64, arm, or arm64.
- [additional qualifiers] further differentiate between different platforms. For example AOT or Corert.
Specific introduction:https://docs.microsoft.com/zh-cn/dotnet/core/rid-catalog
4、. NET Core creates NuGet packages
For .NET Standard and .NET Core, all libraries should be released as NuGet packages. In fact, this is how all .NET standard libraries are published and used. This can be easily achieved using the dotnet pack command.
(End)
|