. NET Core series: 2. What medicines are sold in project. json? coreproject. json

. NET Core series: 2. What medicines are sold in project. json? coreproject. json
. NET Core series: 1 ,. NET Core Environment setup and command line CLI introduction. NET Core environment, this article introduces.. NET Core is the most important configuration file project. json. We can use. NET Core dotnet command line interface (CLI) dotnet new command to create an application, you can also use Visual Studio 2015 update 3 to create an application, each of which has a project. json, which is the configuration file of the project, similar to the previous *. csrpoj file. Project. json is a new Project file. Most of its functions overlap with *. * PROJ files. It identifies project references, Version options (such as version numbers), and platforms to be compiled, such as. NET Core or. NET Framework. You may have discovered many different contents in the project. json file they created. Next let's take a look at the content of this file, the official document https://docs.microsoft.com/en-us/dotnet/articles/core/tools/project-json of project. json. Project. json

First, the project. json of the project xproj created through Visual Studio ︰

 

{
"Version": "1.0.0 -*",
"BuildOptions ":{
"EmitEntryPoint": true
},

"Dependencies ":{
"Microsoft. NETCore. App ":{
"Type": "platform ",
"Version": "1.0.0"
}
},

"Frameworks ":{
"Netcoreapp1.0 ":{
"Imports": "dnxcore50"
}
}
}

 

The dotnet new command creates the project. json of the project:

 

{
"Version": "1.0.0 -*",
"BuildOptions ":{
"DebugType": "portable ",
"EmitEntryPoint": true
},
"Dependencies ":{},
"Frameworks ":{
"Netcoreapp1.0 ":{
"Dependencies ":{
"Microsoft. NETCore. App ":{
"Type": "platform ",
"Version": "1.0.0"
}
},
"Imports": "dnxcore50"
}
}
}

They are similar in structure, but the specific content is quite different. They all have four top-level attributes: version, buildOptions, dependencies, and framework .. The most important file in the NET Core project structure may be project. json. This file is intended:

Replace the package. config file of the NuGet File Manager to identify the NuGet reference of the project.
Specify the framework supported by the project and the configuration details about how to build the project for the specific framework.
Identifies the target platform of an independent application. It contains all its dependencies, including the platform-specific. NET Core runtime required by the corresponding platform. Alternatively, if the project is portable, project. json identifies the framework on which the project will be installed on the target computer (on which the Assembly will be run.
These three tasks are distributed in four main parts of project. json (based on the project type, I merge Frameworks and dependencies into overlapping functions ):

Version

The version attribute is the smallest metadata of the component you want to build. Other metadata includes name, title, description, and copyright. By default, the name option uses the parent folder name, you can use the name attribute to give it the name you want.

 

BuildOptions

The buildOptions node defines how to compile and compile which files, that is, the compilation option. The compilation options section contains some useful attributes. The first is emitEntryPoint, which is used to determine whether to generate an executable binary file or exe. By default, calling the Program. Main () method will be called to run your application.

An interesting property I found is "debugType": "portable ". The Visual Studio code debugger must set this attribute to work. However, this means that your application will be released in different ways. The specific value depends on your settings here. For a brief introduction, see the dotnet publish section in the previous article. For more information, see the following section about application release.

Frameworks and dependencies

Dependencies this section lists the various NuGet packages that your project depends on, including the version number of the dependency. You can use wildcards to specify the version number, so that you can allow the NuGet Package Manager to automatically download the "latest version" that matches the wildcard ". An empty quotation mark ("use the latest available items") indicates the version number ". The project we create can be targeted at one or more frameworks (for example, the project we want to create can run on. NET Framework and. NET Core at the same time), and the supported frameworks are defined under the frameworks node. If multiple frameworks are added, it does not mean that the final generated application can run in these frameworks at the same time, but that the source file will generate the corresponding assembly for these frameworks during compilation. For traditional. NET projects, if we need to call an API, we need to add references to the Assembly. For. NET Core, all the used assembly is packaged into an NuGet package, so the direct dependency on the assembly is converted into the dependency on a NuGet package. There are two main types of dependencies for NuGet. One is for all frameworks, which are directly defined under the dependencies node and the other is for a specific Framework, it is defined as the dependencies subnode under the current Framework node. For independent applications, the runtime part specifies the OS that will be supported, so you can specify the Runtime Library to bind to the application.

From the above two project. json files, we can see that there is a dependency between Frameworks and dependencies. They can be nested. dependencies at the highest level will be dependent on all Frameworks, and dependencies can be built for a specific Framework, different frameworks use different versions of dependencies. Looking at the example above, we can see that the Visual Studio and dotnet CLI versions define the same results, but there are two different expressions.

 

Microsoft. NETCore. App

Let's take a closer look at Microsoft.NETCore.App:

"Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0"
   }
This is a dependency, a platform dependency, and it is also a Nuget package, which contains a bunch of system library NuGet packages, including .netcore's basic runtime and basic class libraries. Article
Running .NET Core apps on multiple frameworks and What the Target Framework Monikers (TFMs) are about detailed content.

  netcoreapp1.0
Let's take a closer look at netcoreapp1.0:

"frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }
  }
The framework netcoreapp1.0 is a multi-target framework object name (TFM) value. In addition to the classic net45 and net46, there are now some new ones like netcoreapp1.0
Running .NET Core apps on multiple frameworks and What the Target Framework Monikers (TFMs) are about have more detailed instructions.

  NETStandard.Library
The project we created above is an application. When we return to the class library, we will find a NETStandard.Library in the dependencies:

{
  "version": "1.0.0- *",
  "buildOptions": {
    "debugType": "portable"
  },
  "dependencies": {},
  "frameworks": {
    "netstandard1.6": {
      "dependencies": {
        "NETStandard.Library": "1.6.0"
      }
    }
  }
}

This is also a NuGet package: https://www.nuget.org/packages/NETStandard.Library/, which contains multiple target versions, similar to the old PCL method. In the future, NETStandard.Library will be used instead of PCL. There is a more unified version control strategy.

Essentially, NETStandard.Library is a target minimum support base class library, so that it can have better forward compatibility, and there is no need to re-release when a new version of the existing platform appears (such as .net core 1.1 or even 2.0) New changes.

 

More information about project.json
The .NET Core project relies on the use of NuGet all, requires NuGet 3.0 version, and uses nuget.org as the source by default. When installing VS2015 Update3, the official dependency packages required by .NET Core have been installed (installed by default) in C: \ Program Files (x86) \ Microsoft SDKs \ NuGetPackages directory. You can also see that this is in nuget management. The default offline package directory, what kind of package do we need? Just copy it to this directory, and select the offline source for the package source in nuget management. After executing the dotnet restore command, the project will restore the project dependent packages according to the project.json file configuration, and at the same time, a new project.json.lock file will be generated.

 

project.lock.json
 

Project.lock.json stores a list of files required for compilation (usually NuGet references). Unlike the project.json file, it includes a specific package version number and can support wildcards. If there is no project.lock.json, the package will be completely restored. Project.lock.json includes package pictures and other package-related data downloaded locally (restored). It works very similar to npm and RubyGems. You can check this file into the repository or not, but when this file doesn't exist, you will run NuGet restore to recreate it. This file is listed as a subkey of project.json in Visual Studio.

 

HellodotnetCore.xproj
<? xml version = "1.0" encoding = "utf-8"?>
<Project ToolsVersion = "14.0" DefaultTargets = "Build" xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <VisualStudioVersion Condition = "'$ (VisualStudioVersion)' == ''"> 14.0 </ VisualStudioVersion>
    <VSToolsPath Condition = "'$ (VSToolsPath)' == ''"> $ (MSBuildExtensionsPath32) \ Microsoft \ VisualStudio \ v $ (VisualStudioVersion) </ VSToolsPath>
  </ PropertyGroup>

  <Import Project = "$ (VSToolsPath) \ DotNet \ Microsoft.DotNet.Props" Condition = "'$ (VSToolsPath)'! = ''" />
  <PropertyGroup Label = "Globals">
    <ProjectGuid> 34ee435f-9fda-4fb2-b4fb-a3203939f0c5 </ ProjectGuid>
    <RootNamespace> HellodotnetCore </ RootNamespace>
    <BaseIntermediateOutputPath Condition = "'$ (BaseIntermediateOutputPath)' == ''">. \ Obj </ BaseIntermediateOutputPath>
    <OutputPath Condition = "'$ (OutputPath)' == ''">. \ Bin \ </ OutputPath>
    <TargetFrameworkVersion> v4.5.2 </ TargetFrameworkVersion>
  </ PropertyGroup>

  <PropertyGroup>
    <SchemaVersion> 2.0 </ SchemaVersion>
  </ PropertyGroup>
  <Import Project = "$ (VSToolsPath) \ DotNet \ Microsoft.DotNet.targets" Condition = "'$ (VSToolsPath)'! = ''" />
</ Project>

 
Like the previous csproj file, this file bridges the communication between Visual Studio and MSBuild. HellodotnetCore.xproj defines what will happen when building the project. The latest version can be imported into Microsoft.DotNet.targets, which defines build tasks using the new DotNet.exe command. Unlike the MSBuild proj file in the past, the xproj file is very small because most of the information has been (temporarily) moved to project.json. However, the follow-up file will be replaced by csproj, which may become csproj in Visual Studio 2016 in the near future.

  global.json
global.json is a magical configuration file to be explored. One of my favorite features is new support for debugging and single-step execution, and you can even modify the source code of the package in real time. Suppose you have a company-wide "framework" assembly that can be shared among many teams. but,

However, the framework package is actually open source, so anyone within the company (or, even better, outside the company) can make improvements and changes. Now, imagine if you reference the NuGet package for this framework, but sometimes suspect that there may be a bug that needs to be fixed or there may be an approved enhancement. Typically, this requires processing the source code in the component independently of the project / solution. Conversely, what if you could download the source code and develop it at any time to update it to an integrated experience-even single-step debugging, without relying on the availability of the symbol server or PDB file? Fortunately, Visual Studio 2015 supports this critical scenario.

For example, imagine you want to debug the Microsoft.Extensions.Logging package available on GitHub. To add and debug it in the project, you need to download (possibly using the git clone or git submodule command) source code. Next, in order to let Visual Studio know where to find the source code, you need to edit the global.json project node, such as adding "submodules \ Logging" to the list of directories viewed:

{
  "projects": ["src", "test", "submodules \ Logging"],
  "sdk": {
    "version": "1.0.0- *"
  }
}
Of course, you can provide the full path (for example, you did not clone the code to a subdirectory). However, please note that the directory separator is two backslashes (\\) or a single forward slash (such as c: / users / geffzhang / documents / visual studio2015 / Projects / Microsoft.Extensions.Logging).

After updating and saving global.json, once Visual Studio successfully finds the source code, it will automatically add the project to your solution, allowing you to debug to the source code.

A very good algorithm is used here to determine the source code directory to be loaded:

 

 

This article briefly introduces the content of the most important configuration file project.json in the .NET Core project and related basic information such as tools and class libraries. In the next article, let's talk about how to build solutions for multiple projects.