. NET Core Series: 2, Project.json what kind of medicine is this gourd selling?

.NET Core series: 1, Getting started with. NET core environment build and command line CLI describes the. NET core environment, which describes the most important configuration file Project.json in. NET Core. We can use the. NET Core dotnet Command-line interface (CLI) dotnet New command to create an app, or you can create an app with Visual Studio Update 3. They all have a project.json, which is the project configuration file, similar to the previous *.csrpoj file. Project.json is a new project file that overlaps most of its functions with *.*proj files. It identifies items such as project references, version options (such as version numbers), and identifies the platform to be compiled, for example,. NET Core or the. NET Framework. Cautious you may have found that the contents of the Project.json file they created are quite different. We'll take a look at the contents of this file, Project.json's official documentation Https://docs.microsoft.com/en-us/dotnet/articles/core/tools/project-json. Project.json

First, from the project we created through Visual Studio, Xproj project.json:

{
"Version": "1.0.0-*",
"Buildoptions": {
"Emitentrypoint": True
},

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

"Frameworks": {
"netcoreapp1.0": {
"Imports": "Dnxcore50"
}
}
}

dotnet the new command to create 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 structurally similar, but there are big differences in the content, and they all have 4 top-level properties: Version, Buildoptions, dependencies, and framework. The most important files in the. NET Core project structure may be Project.json. This file is intended to:

Replaces the NuGet File Manager package.config file, which identifies a nuget reference to the project.
Specifies the framework that the project supports, as well as configuration details about how to build a project for a specific framework.
Identifies the target platform for a standalone application, which contains all of its dependencies, including the platform-specific. NET Core runtime required by the corresponding platform. Or, if the project is a portable app, Project.json can identify the framework that the project will install on the target computer on which the Assembly will run.
These three tasks are distributed in the four main parts of Project.json (based on the project type, I merge frameworks and dependencies into functional overlap):

Version

Version This property is the smallest metadata for the component you are building, other metadata including name,title,description, copyright, and so on, the name option by default is the parent folder, which you can use by name This property gives it a name you want.

Buildoptions

The Buildoptions node defines which files to compile and compile, and so on, which is the compile option. The compilation Options section contains some useful properties. The first is Emitentrypoint, which is used to determine whether an executable binary file or EXE is generated. By default, the call Program.main () method is called to run your app.

I found an interesting attribute is "Debugtype": "Portable". The Visual Studio code debugger must set this property to work. But it also means that your application will be published in different ways, depending on your settings here. A brief look at the dotnet Publish section of the previous article, more on the introduction of the application later.

Frameworks and Dependencies

Dependencies This section lists the individual NuGet packages on which your project depends, including the version number of the dependencies described. You can use wildcards to specify the version number so that you can allow the NuGet Package Manager restore to automatically download the "latest version" that matches the wildcard character. The empty quotation marks for the version number indicate "use latest available items." The projects we create can be targeted at one or more frameworks (for example, what we want to create can run simultaneously on the. NET Framework and. NET core), and the supported framework is defined under the Frameworks node. If more than one framework is added, it does not mean that the resulting application can run in these frameworks at the same time, but rather that the source files generate corresponding assemblies for those frameworks at compile time. For the traditional. NET project, if we need to invoke an API, we need to add a reference to the assembly in which it is located. For. NET core, all the assemblies that are used are packaged as a nuget package, so the direct dependency on the assembly turns into a dependency on a nuget package. There are two main types of dependencies for NuGet, one for all frameworks, they are defined directly under the Dependencies node, and the other for a specific framework, Defined as the Dependencies child node under the current framework node. For standalone applications, the runtime section specifies which OS will be supported, so you can specify the run-time library to bind to the application.

From the above 2 Project.json files you can see that frameworks and dependencies have dependencies. They can be nested, at the highest level of dependency, will be dependent on all frameworks, or can build its dependencies on a specific framework, and different frameworks use different versions of dependencies. Looking at the example above, we see that the Visual Studio and dotnet CLI versions define the same results, just two different expressions.

Microsoft.NETCore.App

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

"Microsoft.NETCore.App": {      "type": "platform",      "version": "1.0.0"   }

Running. NET Core apps on multiple frameworks and what the Target Framework monikers (TFMS) is about to detail the specifics.

netcoreapp1.0

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

"frameworks": {    "netcoreapp1.0": {      "imports": "dnxcore50"    }  }

Running. NET Core apps on multiple frameworks and what the Target Framework monikers (TFMS) is about to have a more detailed description.

Netstandard.library

The project we created above is an application, and when we go back to the class library, we 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, Later, using netstandard.library instead of PCL, we have a more unified version control strategy.

Essentially, Netstandard.library is a goal-minimum support base Class library, which allows for better forward compatibility when new versions of existing platforms appear (such as. NET core 1.1 or even 2.0) without having to republish new changes.

More information about the Project.json

The. NET core project relies on the use of NuGet, which requires the use of NuGet version 3.0, which uses nuget.org as the source by default. When installing VS2015 Update3, the official dependency packages required for. NET core are already installed (the default installation) C:\Program Files (x86) \microsoft Sdks\nugetpackages Directory, In NuGet management You can also see that this is the default offline package directory, what kind of package we need as long as it is copied to this directory, in the NuGet management of the source of the program to select offline sources. After the dotnet restore command is executed, the project recovers the project dependency package based on the Project.json file configuration, and a new Project.json.lock file is generated.

Project.lock.json

Project.lock.json stores a list of files required for compilation (typically NuGet references). Unlike the Project.json file, it includes a specific package version number, which can support wildcard characters. If there is no Project.lock.json, the package will be fully restored. Project.lock.json includes package pictures and other package-related data that is downloaded locally (restored). It works very much like NPM and RubyGems, you can check the file into the repository, or you can not check it in, but this file does not exist and will run the NuGet restore restoration to recreate it. This file is listed as a child 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 previous csproj files, this file is a bridge between visual Studio and MSBuild. Hellodotnetcore.xproj defines what happens when a project is built. The latest version can be imported into Microsoft.DotNet.targets, which defines the build task that leverages the new DotNet.exe command. Unlike the previous MSBuild proj files, the Xproj file is very small because most of the information has been (temporarily) moved to Project.json. However, the subsequent document will be replaced by csproj, perhaps in the near future of Visual Studio 2016 will become csproj.

Global.json

Global.json is a magical profile to explore, and one of my favorite features is new support for debugging and stepping, and even the ability to modify the source code of a 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 any person within the company (or, even better, outside the company) can make improvements and changes. Now, imagine if you reference a NUGET package for this framework, but sometimes you suspect that there may be a flaw that needs to be fixed or there might be an approved enhancement. Typically, this requires a separate source code from the project/solution processing component. Conversely, what if you were able to download the source code and develop it at any time to update it to an integrated experience-even one-step debugging, regardless of whether the symbol server or PDB file is available? Fortunately, Visual Studio 2015 supports this critical scenario.

For example, imagine that you want to debug a Microsoft.Extensions.Logging package available on GitHub. To add and debug it in your project, you need to download (possibly using the git clone or git submodule command) source code. Next, in order for Visual Studio to 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 viewed directories:

{
"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). Note, however, that the directory delimiter is two backslashes (\ \) or a single forward slash (such as C:/users/geffzhang/documents/visual studio2015/projects/ Microsoft.Extensions.Logging).

Once the Global.json is updated and saved, once Visual Studio successfully finds the source code, it automatically adds the project to your solution so that you can debug to the source code.

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

1. If any source code location specified in Global.json contains a folder with the same name as the package (for example, Microsoft.Extensions.Logging), and this folder contains a file named Project.json, The debugger will use this folder and its internal source files.
2. Otherwise, the compiled binaries in the package folder are loaded.

This article provides a brief overview of the most important configuration file in the. NET core project, the content of the Project.json and related tools, class libraries, and other basic information, and next article we'll talk about how to build the content of multiple project solutions.

. NET Core Series: 2, Project.json what kind of medicine is this gourd selling?