Fixed links (#628)
This commit is contained in:
Petr Onderka
Bill Wagner
Родитель
708f7b7942
Коммит
7452b3eabf
|
|
@ -23,7 +23,7 @@ There is great diversity across these languages, in philosophy and syntax, but a
|
|||
|
||||
Multiple [.NET implementations and products](products.md) are available, based on open [.NET Standards](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/dotnet-standards.md) that specify the fundamentals of the platform. They are separately optimized for different application types (e.g. desktop, mobile, gaming, cloud) and support many chips (e.g. x86/x64, ARM) and operating systems (e.g. Windows, Linux, iOS, Android, macOS). Open source is also an important part of the .NET ecosystem, with multiple .NET implementations and many libraries available under OSI-approved licenses.
|
||||
|
||||
- Learn about [.NET](../standard/)
|
||||
- Learn about [C#](../csharp/)
|
||||
- Learn about [F#](../fsharp/)
|
||||
- Learn about [.NET](../standard/index.md)
|
||||
- Learn about [C#](../languages/csharp/index.md)
|
||||
- Learn about [F#](../languages/fsharp/index.md)
|
||||
- Browse the [.NET API Library](../api)
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ Major commercial and open source .NET implementations are listed below, in alpha
|
|||
|
||||
.NET Core is used to build device, web, cloud and embedded/IoT apps. It is [open source](https://github.com/dotnet/core) and cross-platform, supporting Windows, macOS and Linux. [ASP.NET Core](http://docs.asp.net/) is the most popular workload for .NET Core. You can use it to build web apps and services, for on-premises and cloud deployment. You can also use .NET Core to build tools, utilities and cloud worker apps.
|
||||
|
||||
- Learn about [.NET Core](../core)
|
||||
- Learn about [.NET Core](../core/index.md)
|
||||
- Learn about [ASP.NET Core](http://docs.asp.net/)
|
||||
- [Download .NET Core](http://dot.net/core)
|
||||
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ will restore the needed runtime for all the RIDs specifies. Then, when you want
|
|||
you publish it using the `--runtime <RID>` argument to `dotnet publish`. The RID specified in the
|
||||
command invocation **has to be** an RID that is specified in your `project.json`; otherwise, an error is thrown.
|
||||
|
||||
If you want to publish for the RID that represents the operating system you are using the [.NET Core SDK](sdk/index.md)
|
||||
If you want to publish for the RID that represents the operating system you are using the [.NET Core SDK](sdk.md)
|
||||
on, you don't have to specify anything to `dotnet publish`. However, you still have to specify that RID in your
|
||||
`project.json` in order to get a standalone application.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,11 +16,11 @@
|
|||
|
||||
You can deploy your .NET Core app in either of two ways:
|
||||
|
||||
- As a portable app. A portable app relies on a shared system-wide version of the .NET Core framework that is present on a system. Portable applications are .dll files that can be launched by using the [dotnet utility](./core-sdk/cli/dotnet.md) from the command line. For example, `dotnet app.dll` runs a portable application named `app`.
|
||||
- As a portable app. A portable app relies on a shared system-wide version of the .NET Core framework that is present on a system. Portable applications are .dll files that can be launched by using the [dotnet utility](../tools/dotnet.md) from the command line. For example, `dotnet app.dll` runs a portable application named `app`.
|
||||
|
||||
- As a self-contained application. All components, including .NET Core itself, are included with the application and are isolated from other .NET Core applications. Self-contained applications include an executable (such as `app.exe` on Windows platforms for a self-contained application named `app`), which is a renamed version of the platform-specific .NET Core host, and a .dll file (such as `app.dll`), which is the actual application.
|
||||
|
||||
For more information on .NET Core application types, see [.NET Core App Types](./app-types.md).
|
||||
For more information on .NET Core application types, see [.NET Core App Types](../app-types.md).
|
||||
|
||||
## Portable Applications ##
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ For a portable app, you deploy only your app and any third-party dependencies. Y
|
|||
|
||||
Deploying a portable app has a number of advantages:
|
||||
|
||||
- You do not have to define the target operating systems that your .NET Core app will run on in advance. Because .NET Core uses a common PE file format for executables and libraries regardless of operating system, .NET Core can execute your app regardless of the underlying operating system. For more information on the PE file format, see [.NET Assembly File Format](../concepts/assembly-format.md).
|
||||
- You do not have to define the target operating systems that your .NET Core app will run on in advance. Because .NET Core uses a common PE file format for executables and libraries regardless of operating system, .NET Core can execute your app regardless of the underlying operating system. For more information on the PE file format, see [.NET Assembly File Format](../../standard/assembly-format.md).
|
||||
|
||||
- The size of your deployment package is small. You only have to deploy your app and its dependencies, not .NET Core itself.
|
||||
|
||||
|
|
@ -44,9 +44,9 @@ There are also a few disadvantages:
|
|||
|
||||
### Deploying a Simple Portable App ###
|
||||
|
||||
Deploying a portable app with no third-party dependencies simply involves building, testing, and publishing the app. A simple example written in C# illustrates the process. The example uses the [dotnet utility](./core-sdk/cli/dotnet.md) from the command line; however, you can also use a development environment, such as Visual Studio or Visual Studio Code, to compile, test, and publish the example.
|
||||
Deploying a portable app with no third-party dependencies simply involves building, testing, and publishing the app. A simple example written in C# illustrates the process. The example uses the [dotnet utility](../tools/dotnet.md) from the command line; however, you can also use a development environment, such as Visual Studio or Visual Studio Code, to compile, test, and publish the example.
|
||||
|
||||
1. Create a directory for your project, and from the command line, type [dotnet new](./core-sdk/cli/dotnet-new.md) to create a new C# console project.
|
||||
1. Create a directory for your project, and from the command line, type [dotnet new](../tools/dotnet-new.md) to create a new C# console project.
|
||||
|
||||
2. Open the `Program.cs` file in an editor, and replace the auto-generated code with the following code. It prompts the user to enter text, and then displays the individual words entered by the user. It uses the regular expression `\w+` to separate the words in the input text.
|
||||
|
||||
|
|
@ -85,9 +85,9 @@ Deploying a portable app with no third-party dependencies simply involves buildi
|
|||
}
|
||||
```
|
||||
|
||||
3. Run the [dotnet restore](./core-sdk/cli/dotnet-restore.md) command to restore the dependencies specified in your project.
|
||||
3. Run the [dotnet restore](../tools/dotnet-restore.md) command to restore the dependencies specified in your project.
|
||||
|
||||
4. Create a debug build of your app by using the [dotnet build](./core-sdk/cli/dotnet-build.md) command.
|
||||
4. Create a debug build of your app by using the [dotnet build](../tools/dotnet-build.md) command.
|
||||
|
||||
5. After you've debugged and tested the program, you can create the files to be deployed with your app by using the `dotnet publish -f netcoreapp1.0 -c release` command. This creates a release (rather than a debug) version of your app.
|
||||
|
||||
|
|
@ -208,7 +208,7 @@ Deploying a self-contained app with no third-party dependencies involves creatin
|
|||
```
|
||||
This change removes the `"type": "platform"` attribute, which identifies `Microsoft.NETCore.App` as a platform package that is provided by the system. It also replaces the `Microsoft.NETCore.App` package, which includes a number of system components that are not used by self-contained apps, with `NETStandard.Library`, the .NET Core runtime, and the .NET Core host. This produces a self-contained app with a smaller footprint than if you had simply modified your `dependencies` section to include the `Microsoft.NETCore.App` package.
|
||||
|
||||
5. Create a `runtimes` section in your `project.json` file that defines the platforms your app targets and specify the runtime identifier of each platform that you target. See [Runtime IDentifier catalog](./rid-catalog.md) for a list of runtime identifiers. For example, the following `runtimes` section indicates that the app runs on 64-bit Windows 10 operating systems and the 64-bit OS X Version 10.10 operating system.
|
||||
5. Create a `runtimes` section in your `project.json` file that defines the platforms your app targets and specify the runtime identifier of each platform that you target. See [Runtime IDentifier catalog](../rid-catalog.md) for a list of runtime identifiers. For example, the following `runtimes` section indicates that the app runs on 64-bit Windows 10 operating systems and the 64-bit OS X Version 10.10 operating system.
|
||||
|
||||
```json
|
||||
"runtimes": {
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Additionally, if you wish to support older targets, you will need to install tar
|
|||
|
||||
## How to target the .NET Standard
|
||||
|
||||
If you're not quite familiar with the .NET Standard, please refer to [the .NET Standard Library](../../concepts/dotnet-standard-library.md) to learn more.
|
||||
If you're not quite familiar with the .NET Standard, please refer to [the .NET Standard Library](../../standard/library.md) to learn more.
|
||||
|
||||
In that article, there is a table which maps .NET Standard versions to various implementations:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,25 +0,0 @@
|
|||
---
|
||||
title: Developing with .NET Core
|
||||
description: Developing with .NET Core
|
||||
keywords: .NET, .NET Core
|
||||
author: blackdwarf
|
||||
manager: wpickett
|
||||
ms.date: 06/20/2016
|
||||
ms.topic: article
|
||||
ms.prod: .net-core
|
||||
ms.technology: .net-core-technologies
|
||||
ms.devlang: dotnet
|
||||
ms.assetid: e5b91a47-f3fd-43c4-9e95-254a6efac947
|
||||
---
|
||||
|
||||
# Developing with .NET Core
|
||||
|
||||
* [Web applications](web-apps/index.md)
|
||||
* [Console applications](console/index.md)
|
||||
* [🔧 Overview](console/overview.md)
|
||||
* [🔧 Writing Console Apps: An advanced step-by-step guide](console/cli-console-app-tutorial-advanced.md)
|
||||
* [Libraries](libraries/index.md)
|
||||
* [Writing Libraries with Cross Platform Tools](libraries/libraries-with-cli.md)
|
||||
* [🔧 Creating a class library in Visual Studio](libraries/libraries-with-vs.md)
|
||||
* [Testing](testing/unit-testing.md)
|
||||
* [Unit Testing in .NET Core using dotnet test](testing/unit-testing-with-dotnet-test.md)
|
||||
|
|
@ -21,7 +21,7 @@ The following characteristics best define .NET Core:
|
|||
|
||||
- **Flexible deployment:** app-local or side-by-side user- or machine-wide installation.
|
||||
- **Cross-platform:** Runs on Windows, macOS and Linux; can be ported to other OSes.
|
||||
- **Compatibility:** .NET Core is compatible with .NET Framework and Xamarin platforms, via the [.NET Standard Library](../concepts/dotnet-standard-library.md).
|
||||
- **Compatibility:** .NET Core is compatible with .NET Framework and Xamarin platforms, via the [.NET Standard Library](../standard/library.md).
|
||||
- **Open source:** The .NET Core platform is open source, using MIT and Apache 2 licenses. Documentation is licensed under [CC-BY](http://creativecommons.org/licenses/by/4.0/). .NET Core is a [.NET Foundation](http://www.dotnetfoundation.org/) project.
|
||||
|
||||
Composition
|
||||
|
|
@ -32,7 +32,7 @@ Composition
|
|||
- A [.NET runtime](https://github.com/dotnet/coreclr), which provides a type system, assembly loading, a garbage collector, native interop and other basic services.
|
||||
- A set of [framework libraries](https://github.com/dotnet/corefx), which provide primitive data types, app composition types and fundamental utilities.
|
||||
- The 'dotnet' app host, which is used to launch .NET Core apps. It selects the runtime and hosts the runtime, provides an assembly loading policy and launches the app. The same host is also used to launch SDK tools in much the same way.
|
||||
- A [set of SDK tools](https://github.com/dotnet/cli) and language compilers that enable the base developer experience, available in the [.NET Core SDK](core-sdk/index.md).
|
||||
- A [set of SDK tools](https://github.com/dotnet/cli) and language compilers that enable the base developer experience, available in the [.NET Core SDK](sdk.md).
|
||||
|
||||
Languages
|
||||
---------
|
||||
|
|
@ -44,14 +44,14 @@ The C# Roslyn compiler and the .NET Core tools are or can be integrated into sev
|
|||
.NET APIs and Compatibility
|
||||
---------------------------
|
||||
|
||||
.NET Core can be thought of as a cross-platform version of the .NET Framework, at the layer of the .NET Framework Base Class Libraries (BCL). It implements the [.NET Standard Library](../concepts/dotnet-standard-library.md) specification. .NET Core provides a subset of the APIs that are available in the .NET Framework or Mono/Xamarin. In some cases, types are not fully implemented (some members are not available or have been moved).
|
||||
.NET Core can be thought of as a cross-platform version of the .NET Framework, at the layer of the .NET Framework Base Class Libraries (BCL). It implements the [.NET Standard Library](../standard/library.md) specification. .NET Core provides a subset of the APIs that are available in the .NET Framework or Mono/Xamarin. In some cases, types are not fully implemented (some members are not available or have been moved).
|
||||
|
||||
Look at the [.NET Core roadmap](https://github.com/dotnet/core/blob/master/roadmap.md) to learn more about the .NET Core API roadmap.
|
||||
|
||||
Relationship to the .NET Standard Library
|
||||
-----------------------------------------
|
||||
|
||||
The [.NET Standard Library](../concepts/dotnet-standard-library.md) is an API spec that describes the consistent set of .NET APIs that developers can expect in each .NET implementation. .NET implementations need to implement this spec in order to be considered .NET Standard Library compliant and to support libraries that target the .NET Standard Library.
|
||||
The [.NET Standard Library](../standard/library.md) is an API spec that describes the consistent set of .NET APIs that developers can expect in each .NET implementation. .NET implementations need to implement this spec in order to be considered .NET Standard Library compliant and to support libraries that target the .NET Standard Library.
|
||||
|
||||
.NET Core implements the .NET Standard Library, and therefore supports .NET Standard Libraries.
|
||||
|
||||
|
|
@ -141,7 +141,7 @@ The .NET platform was first announced by Microsoft in 2000 and then evolved from
|
|||
The major differences between .NET Core and the .NET Framework:
|
||||
|
||||
- **App-models** -- .NET Core does not support all the .NET Framework app-models, in part because many of them are built on Windows technologies, such as WPF (built on top of DirectX). The console and ASP.NET Core app-models are supported by both .NET Core and .NET Framework.
|
||||
- **APIs** -- .NET Core contains many of the same, but fewer, APIs as the .NET Framework, and with a different factoring (assembly names are different; type shape differs in key cases). These differences currently typically require changes to port source to .NET Core. .NET Core implements the [.NET Standard Library](../concepts/dotnet-standard-library.md) API, which will grow to include more of the .NET Framework BCL API over time.
|
||||
- **APIs** -- .NET Core contains many of the same, but fewer, APIs as the .NET Framework, and with a different factoring (assembly names are different; type shape differs in key cases). These differences currently typically require changes to port source to .NET Core. .NET Core implements the [.NET Standard Library](../standard/library.md) API, which will grow to include more of the .NET Framework BCL API over time.
|
||||
- **Subsystems** -- .NET Core implements a subset of the subsystems in the .NET Framework, with the goal of a simpler implementation and programming model. For example, Code Access Security (CAS) is not supported, while reflection is supported.
|
||||
- **Platforms** -- The .NET Framework supports Windows and Windows Server while .NET Core also supports macOS and Linux.
|
||||
- **Open Source** -- .NET Core is open source, while a [read-only subset of the .NET Framework](https://github.com/microsoft/referencesource) is open source.
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ would put it on the $PATH for the given session. This would allow you to use the
|
|||
|
||||
DNVM was discontinued because its feature set was made redundant by changes coming in the .NET Core CLI tools.
|
||||
|
||||
The CLI tools come packaged in two main ways, as was explained in the [overview document](core-sdk/cli/overview.md#installation):
|
||||
The CLI tools come packaged in two main ways, as was explained in the [overview document](tools/index.md#installation):
|
||||
|
||||
1. Native installers for a given platform
|
||||
2. Install script for other situations (like CI servers)
|
||||
|
|
@ -84,7 +84,7 @@ packages with a shell script that would invoke the DNX you specified to run the
|
|||
|
||||
The CLI does not support this concept. It does, however, support the concept of adding per-project commands that can be
|
||||
invoked using the familiar `dotnet <command>` syntax. More about this can be found in the
|
||||
[extensibility overview](core-sdk/cli/overview.md#extensibility).
|
||||
[extensibility overview](tools/index.md#extensibility).
|
||||
|
||||
### Installing dependencies
|
||||
As of v1, the .NET Core CLI tools don't have an `install` command for installing dependencies. In order to install a
|
||||
|
|
@ -124,7 +124,7 @@ tools that you wish to use, in this case **1.0.0-preview2-003118**:
|
|||
The CLI and DNX both use the same basic project system based on `project.json` file. The syntax and the semantics of the
|
||||
project file are pretty much the same, with small differences based on the scenarios. There are also some changes to
|
||||
the schema which you can see in the [schema file](http://json.schemastore.org/project) or in a more friendly
|
||||
[project.json reference](../project-model/project-json-reference.md).
|
||||
[project.json reference](tools/project-json.md).
|
||||
|
||||
If you are building a console application, you need to add the following snippet to your project file:
|
||||
|
||||
|
|
@ -144,7 +144,7 @@ DNU commands, such as Entity Framework CLI commands, are being ported to be
|
|||
per-project extensions to the CLI. If you built your own commands that you are using in your projects, you need to
|
||||
replace them with CLI extensions. In this case, the `commands` node in `project.json` needs to be replaced by the
|
||||
`tools` node and it needs to list the tools dependencies as explained in the
|
||||
[CLI extensibility section](core-sdk/cli/overview.md#extensibility).
|
||||
[CLI extensibility section](tools/index.md#extensibility).
|
||||
|
||||
After these things are done, you need to decide which type of portability you wish for you app. With .NET Core, we have
|
||||
invested into providing a spectrum of portability options that you can choose from. For instance, you may want to have
|
||||
|
|
|
|||
|
|
@ -148,11 +148,11 @@ The two primary package-based frameworks used with .NET Core are:
|
|||
.NET Standard
|
||||
-------------
|
||||
|
||||
The .NET Standard (TFM: `netstandard`) framework represents the APIs defined by and built on top of the [.NET Standard Library](../concepts/dotnet-standard-library.md). Libraries that are intended to run on multiple runtimes should target this framework. They will be supported on any .NET Standard compliant runtime, such as .NET Core, .NET Framework and Mono/Xamarin. Each of these runtimes supports a set of .NET Standard versions, depending on which APIs they implement.
|
||||
The .NET Standard (TFM: `netstandard`) framework represents the APIs defined by and built on top of the [.NET Standard Library](../standard/library.md). Libraries that are intended to run on multiple runtimes should target this framework. They will be supported on any .NET Standard compliant runtime, such as .NET Core, .NET Framework and Mono/Xamarin. Each of these runtimes supports a set of .NET Standard versions, depending on which APIs they implement.
|
||||
|
||||
The `NETStandard.Library` metapackage targets the `netstandard` framework. The most common way to target `netstandard` is by referencing this metapackage. It describes and provides access to the ~40 .NET libraries and associated APIs that define the .NET Standard Library. You can reference additional packages that target `netstandard` to get access to additional APIs.
|
||||
|
||||
A given [NETStandard.Library version](versioning.md) matches the highest `netstandard` version it exposed (via its closure). The framework reference in project.json is used to select the correct assets from the underlying packages. In this case, `netstandard1.5` assets are required, as opposed to `netstandard1.4` or `net46`, for example.
|
||||
A given [NETStandard.Library version](versions/index.md) matches the highest `netstandard` version it exposed (via its closure). The framework reference in project.json is used to select the correct assets from the underlying packages. In this case, `netstandard1.5` assets are required, as opposed to `netstandard1.4` or `net46`, for example.
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
|||
|
|
@ -38,8 +38,8 @@ require administrative privileges on the machine. You can view the installation
|
|||
Install scripts, on the other hand, do not require administrative privileges. However, they will also not install any
|
||||
prerequisites on the machine; you need to install all of the prerequisites manually. The scripts are meant mostly for
|
||||
setting up build servers or when you wish to install the tools without admin privileges (do note the prerequisites
|
||||
caveat above). You can find more information on the [install script reference topic](cli/dotnet-install-script.md). If you are
|
||||
interested in how to set up SDK on your CI build server you can take a look at the [SDK with CI servers](cli/using-ci-with-cli.md)
|
||||
caveat above). You can find more information on the [install script reference topic](tools/dotnet-install-script.md). If you are
|
||||
interested in how to set up SDK on your CI build server you can take a look at the [SDK with CI servers](tools/using-ci-with-cli.md)
|
||||
document.
|
||||
|
||||
By default, the SDK will install in a "side-by-side" (SxS) manner. This means that multiple versions of the CLI tools
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Depending on the type of portable app, the resulting directory will contain the
|
|||
dependency.
|
||||
2. **Self-contained application** - same as above plus the entire runtime for the targeted platform.
|
||||
|
||||
The above types are covered in more details in the [types of portable applications](../../app-types.md) topic.
|
||||
The above types are covered in more details in the [types of portable applications](../app-types.md) topic.
|
||||
|
||||
## OPTIONS
|
||||
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ The `dotnet run` command must be used in the context of projects, not built asse
|
|||
|
||||
`dotnet myapp.dll`
|
||||
|
||||
For more information about the `dotnet` driver, see the [.NET Core Command Line Tools (CLI)](overview.md) topic.
|
||||
For more information about the `dotnet` driver, see the [.NET Core Command Line Tools (CLI)](index.md) topic.
|
||||
|
||||
|
||||
## OPTIONS
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ The following sample project.json shows the properties needed:
|
|||
`dotnet test` supports two running modes:
|
||||
|
||||
1. Console: In console mode, `dotnet test` simply executes fully any command gets passed to it and outputs the results. Anytime you invoke `dotnet test` without passing --port, it runs in console mode, which in turn will cause the runner to run in console mode.
|
||||
2. Design time: used in the context of other tools, such as editors or Integrated Development Environments (IDEs). You can find out more about this mode in the [dotnet-test protocol](dotnet-test-protocol.md) document.
|
||||
2. Design time: used in the context of other tools, such as editors or Integrated Development Environments (IDEs). You can find out more about this mode in the [dotnet-test protocol](test-protocol.md) document.
|
||||
|
||||
## OPTIONS
|
||||
|
||||
|
|
@ -122,4 +122,4 @@ Runs the tests in the test1 project.
|
|||
|
||||
## SEE ALSO
|
||||
|
||||
* [dotnet-test communication protocol](dotnet-test-protocol.md)
|
||||
* [dotnet-test communication protocol](test-protocol.md)
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ The two extensibility mechanisms outlined above are not exclusive; you can use b
|
|||
depends largely on what is the goal you are trying to achieve with your extension.
|
||||
|
||||
## Per-project based extensibility
|
||||
Per-project tools are [portable console applications](../../app-types.md) that are distributed as NuGet packages. Tools are
|
||||
Per-project tools are [portable console applications](../app-types.md) that are distributed as NuGet packages. Tools are
|
||||
only available in the context of the project that references them and for which they are restored; invocation outside
|
||||
of the context of the project (for example, outside of the directory that contains the project) will fail as the command will
|
||||
not be able to be found.
|
||||
|
|
@ -92,7 +92,7 @@ The `tools` node is structured in a similar way as the `dependencies` node. It n
|
|||
containing the tool and its version at the very least. In the example above, we can see that there is another statement,
|
||||
the `imports` one. This influences the tool's restore process and specifies that the tool is also compatible, in
|
||||
addition to any targeted frameworks the tools has, with `dnxcore50` target. For more information you can
|
||||
consult the [project.json reference](../../../project-model/project-json-reference.md).
|
||||
consult the [project.json reference](project-json.md).
|
||||
|
||||
### Building tools
|
||||
As mentioned, tools are just portable console applications. You would build one as you would build any console application.
|
||||
|
|
@ -148,7 +148,7 @@ PATH-based extensibility is usually used for development machines where you need
|
|||
than a single project. The main drawback of this extensions mechanism is that it is tied to the machine where the
|
||||
tool exists. If you need it on another machine, you would have to deploy it.
|
||||
|
||||
This pattern of CLI toolset extensibility is very simple. As covered in the [.NET Core CLI overview](overview.md), `dotnet` driver
|
||||
This pattern of CLI toolset extensibility is very simple. As covered in the [.NET Core CLI overview](index.md), `dotnet` driver
|
||||
can run any command that is named after the `dotnet <command>` convention. The default resolution logic will first
|
||||
probe several locations and will finally fall to the system PATH. If the requested command exists in the system PATH
|
||||
and is a binary that can be invoked, `dotnet` driver will invoke it.
|
||||
|
|
|
|||
|
|
@ -113,13 +113,13 @@ CLI enables applications to be portable in two main ways:
|
|||
1. Completely portable application that can run anywhere .NET Core is installed
|
||||
2. Self-contained applications
|
||||
|
||||
You can learn more about both of these in the [application types overview](../../app-types.md) topic.
|
||||
You can learn more about both of these in the [application types overview](../app-types.md) topic.
|
||||
|
||||
## Migration from DNX
|
||||
If you used DNX in RC1 of .NET Core, you may be wondering what happened to it and how do these new tools
|
||||
relate to the DNX tools. In short, the DNX tools have been replaced with the .NET Core CLI tools.
|
||||
If you have existing projects or are just wondering how the commands map, you
|
||||
can use the [DNX to CLI migration document](../../dnx-migration.md) to get all of the details.
|
||||
can use the [DNX to CLI migration document](../migrating-from-dnx.md) to get all of the details.
|
||||
|
||||
## Extensibility
|
||||
Of course, not every tool that you could use in your workflow will be a part of the core CLI tools. However, .NET Core
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Visual Studio 2015 provides a full-featured development environment for developi
|
|||
|
||||
* .NET Core Tooling Preview 1 for Visual Studio 2015. This installs templates and other tools as well as .NET Core itself.
|
||||
|
||||
* A supported version of the Windows client or server operating system. For a list of supported versions, see [.NET Core System Requirements](../system-reqs.md).
|
||||
* A supported version of the Windows client or server operating system. For a list of supported versions, see [.NET Core Release Notes](https://github.com/dotnet/core/blob/master/release-notes/1.0/Release-Notes-1.0.0.md).
|
||||
|
||||
## Getting Started
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ ms.assetid: be988f09-7349-43b0-97fb-3a703d4587ce
|
|||
|
||||
This guide will show you how to use the .NET Core CLI tooling to build cross-platform console apps. It will start with the most basic console app and eventually span multiple projects, including testing. You'll add these features step-by-step, building on what you've already seen and built.
|
||||
|
||||
If you're unfamiliar with the .NET Core CLI toolset, read [the .NET Core SDK overview](../core-concepts/core-sdk/sdk-overview.md). It's also helpful to have an understanding of the [console app paradigm](../core-concepts/console/overview.md).
|
||||
If you're unfamiliar with the .NET Core CLI toolset, read [the .NET Core SDK overview](../sdk.md). It's also helpful to have an understanding of the [console app paradigm](../console/overview.md).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ Let's do a quick walkthrough:
|
|||
|
||||
1. `$ dotnet new`
|
||||
|
||||
[`dotnet new`](../core-concepts/core-sdk/cli/dotnet-new.md) creates an up-to-date `project.json` file with NuGet dependencies necessary to build a console app. It also creates a `Program.cs`, a basic file containing the entry point for the application.
|
||||
[`dotnet new`](../tools/dotnet-new.md) creates an up-to-date `project.json` file with NuGet dependencies necessary to build a console app. It also creates a `Program.cs`, a basic file containing the entry point for the application.
|
||||
|
||||
`project.json`:
|
||||
```javascript
|
||||
|
|
@ -78,24 +78,24 @@ Let's do a quick walkthrough:
|
|||
|
||||
2. `$ dotnet restore`
|
||||
|
||||
[`dotnet restore`](../core-concepts/core-sdk/cli/dotnet-restore.md) calls into NuGet to restore the tree of dependencies. NuGet analyzes the `project.json` file, downloads the dependencies stated in the file (or grabs them from a cache on your machine), and writes the `project.lock.json` file. The `project.lock.json` file is necessary to be able to compile and run.
|
||||
[`dotnet restore`](../tools/dotnet-restore.md) calls into NuGet to restore the tree of dependencies. NuGet analyzes the `project.json` file, downloads the dependencies stated in the file (or grabs them from a cache on your machine), and writes the `project.lock.json` file. The `project.lock.json` file is necessary to be able to compile and run.
|
||||
|
||||
The `project.lock.json` file is a persisted and complete set of the graph of NuGet dependencies and other information describing an app. This file is read by other tools, such as `dotnet build` and `dotnet run`, enabling them to process the source code with a correct set of NuGet dependencies and binding resolutions.
|
||||
|
||||
3. `$ dotnet run`
|
||||
|
||||
[`dotnet run`](../core-concepts/core-sdk/cli/dotnet-run.md) calls `dotnet build` to ensure that the build targets have been built, and then calls `dotnet <assembly.dll>` to run the target application.
|
||||
[`dotnet run`](../tools/dotnet-run.md) calls `dotnet build` to ensure that the build targets have been built, and then calls `dotnet <assembly.dll>` to run the target application.
|
||||
|
||||
```
|
||||
$ dotnet run
|
||||
Hello, World!
|
||||
```
|
||||
|
||||
You can also execute [`dotnet build`](../core-concepts/core-sdk/cli/dotnet-build.md) to compile and the code without running the build console applications.
|
||||
You can also execute [`dotnet build`](../tools/dotnet-build.md) to compile and the code without running the build console applications.
|
||||
|
||||
### Building a self-contained application
|
||||
|
||||
Let's try compiling a self-contained application instead of a portable application. You can read more about the [types of portability in .NET Core](../core-concepts/app-types.md) to learn about the different application types, and how they are deployed.
|
||||
Let's try compiling a self-contained application instead of a portable application. You can read more about the [types of portability in .NET Core](../app-types.md) to learn about the different application types, and how they are deployed.
|
||||
|
||||
You need to make some changes to your `project.json`
|
||||
file to direct the tools to build a self-contained application. You can see these in the
|
||||
|
|
@ -125,7 +125,7 @@ you'll build a Windows executable. If you are following these steps on a Mac, yo
|
|||
}
|
||||
```
|
||||
|
||||
See the full list of supported runtimes in the [RID catalog](../core-concepts/rid-catalog.md).
|
||||
See the full list of supported runtimes in the [RID catalog](../rid-catalog.md).
|
||||
|
||||
After making those two changes you execute `dotnet restore`, followed by `dotnet build` to create the native executable. Then, you can run the generated
|
||||
native executable.
|
||||
|
|
@ -635,7 +635,7 @@ public class PetTests
|
|||
}
|
||||
```
|
||||
|
||||
Now you can run tests! The [`dotnet test`](../core-concepts/core-sdk/cli/dotnet-test.md) command runs the test runner you have specified in your project. Make sure you start at the top-level directory.
|
||||
Now you can run tests! The [`dotnet test`](../tools/dotnet-test.md) command runs the test runner you have specified in your project. Make sure you start at the top-level directory.
|
||||
|
||||
```
|
||||
$ dotnet restore
|
||||
|
|
@ -660,6 +660,6 @@ SUMMARY: Total: 1 targets, Passed: 1, Failed: 0.
|
|||
|
||||
Hopefully this guide has helped you learn how to create a .NET Core console app, from the basics all the way up to a multi-project system with unit tests. The next step is to create awesome console apps of your own!
|
||||
|
||||
If a more advanced example of a console app interests you, check out the next tutorial: [Using the CLI tools to write console apps: An advanced step-by-step guide](../core-concepts/console/cli-console-app-tutorial-advanced.md).
|
||||
If a more advanced example of a console app interests you, check out the next tutorial: [Using the CLI tools to write console apps: An advanced step-by-step guide](../console/cli-console-app-tutorial-advanced.md).
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ ms.assetid: f6f684b1-1d2c-4105-8376-7c1959e23803
|
|||
.NET Core Versioning
|
||||
====================
|
||||
|
||||
.NET Core is a platform of [NuGet packages](packages.md), of frameworks and distributed as a unit. Each of these platform layers can be versioned separately for product agility and to accurately describe product changes. While there is significant versioning flexibility, there is a desire to version the platform as a unit to make the product easier to understand.
|
||||
.NET Core is a platform of [NuGet packages](../packages.md), of frameworks and distributed as a unit. Each of these platform layers can be versioned separately for product agility and to accurately describe product changes. While there is significant versioning flexibility, there is a desire to version the platform as a unit to make the product easier to understand.
|
||||
|
||||
The product is somewhat unique, being described and delivered via a package manager (NuGet) as packages. While you typically acquire .NET Core as a standalone SDK, the SDK is largely a convenience experience over NuGet packages and therefore not distinct from packages. As a result, versioning is first and foremost in terms of packages and other versioning experiences follow from there.
|
||||
|
||||
|
|
@ -85,7 +85,7 @@ There are two primary metapackages for .NET Core.
|
|||
|
||||
- v1.6 as of .NET Core 1.0 (these versions won't typically or intentionally match).
|
||||
- Maps to the `netstandard` framework.
|
||||
- Describes the packages that are considered required for modern app development and that .NET platforms must implement to be considered a [.NET Standard](../concepts/dotnet-standard-library.md) platform.
|
||||
- Describes the packages that are considered required for modern app development and that .NET platforms must implement to be considered a [.NET Standard](../../standard/library.md) platform.
|
||||
|
||||
**Microsoft.NETCore.App**
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ types that you can reuse whenever you need delegate types. These are
|
|||
[generic](generics.md) definitions so you can declare customizations
|
||||
when you need new method declarations.
|
||||
|
||||
The first of these types is the [`Action`](https:// docs.microsoft.com/dotnet/core/api/System.Action) type, and several variations:
|
||||
The first of these types is the [`Action`](https://docs.microsoft.com/dotnet/core/api/System.Action) type, and several variations:
|
||||
|
||||
```cs
|
||||
public delegate void Action();
|
||||
|
|
@ -47,7 +47,7 @@ The `in` modifier on the generic type argument is covered in the article
|
|||
on covariance.
|
||||
|
||||
There are variations of the `Action` delegate that contain up to
|
||||
[16 arguments](https:// docs.microsoft.com/dotnet/core/api/System.Action%6016).
|
||||
[16 arguments](https://docs.microsoft.com/dotnet/core/api/System.Action%6016).
|
||||
It's important that these definitions use different generic arguments for each of the
|
||||
delegate arguments: That gives you maximum flexibility. The method arguments need not be, but may be, the same type.
|
||||
|
||||
|
|
@ -67,14 +67,14 @@ The `out` modifier on the result generic type argument is covered in the
|
|||
article on covariance.
|
||||
|
||||
There are variations of the `Func` delegate with up to
|
||||
[16 input arguments](https:// docs.microsoft.com/dotnet/core/api/System.Func%6017).
|
||||
[16 input arguments](https://docs.microsoft.com/dotnet/core/api/System.Func%6017).
|
||||
The type of the result is always the last type parameter in all the `Func`
|
||||
declarations, by convention.
|
||||
|
||||
Use one of the `Func` types for any delegate type that returns a value.
|
||||
|
||||
There's also a specialized
|
||||
[`Predicate`](https:// docs.microsoft.com/dotnet/core/api/System.Predicate%601)
|
||||
[`Predicate`](https://docs.microsoft.com/dotnet/core/api/System.Predicate%601)
|
||||
type for a delegate that returns a test on a single value:
|
||||
|
||||
```cs
|
||||
|
|
|
|||
|
|
@ -572,7 +572,7 @@ capabilities.
|
|||
Even the last example recognizes a subset of the possible node types.
|
||||
You can still feed it many expressions that will cause it to fail.
|
||||
A full implementation is included in the .NET Standard Library
|
||||
under the name [ExpressionVisitor](https:// docs.microsoft.com/dotnet/core/api/System.Linq.Expressions.ExpressionVisitor)
|
||||
under the name [ExpressionVisitor](https://docs.microsoft.com/dotnet/core/api/System.Linq.Expressions.ExpressionVisitor)
|
||||
and can handle all the possible node types.
|
||||
|
||||
Finally, the library I used in this article was built for demonstration
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ ms.assetid: 42c7ea39-8da5-499c-9a02-c1d27b37fc40
|
|||
* [Building simple C# solutions with Visual Studio](solution-authoring/vs-golden-path.md)
|
||||
* [Building simple C# solutions with the .NET CLI](solution-authoring/cli-golden-path.md)
|
||||
* [Building simple F# solutions with the .NET CLI](solution-authoring/f-golden-path.md)
|
||||
* [Building simple C# solutions with Visual Studio and MSBuild](target-dotnetcore-with-msbuild.md)
|
||||
* [Building simple C# solutions with Visual Studio and MSBuild](solution-authoring/target-dotnetcore-with-msbuild.md)
|
||||
|
||||
* [Packaging and deploying applications](deployment/index.md)
|
||||
* [🔧 Deploying applications overview](deployment/overview.md)
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ The version number of the .NET Framework doesn't necessarily correspond to the v
|
|||
|
||||
## See Also
|
||||
|
||||
[Automatic Memory Management](../concepts/gc-overview.md)
|
||||
[Automatic Memory Management](gc-overview.md)
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ The .NET ecosystem has a concept of frameworks. Frameworks define the API that y
|
|||
Framework Versions
|
||||
==================
|
||||
|
||||
The table below defines the set of frameworks that you can use, how they are referred to and which version of the [.NET Standard Library](dotnet-standard-library.md) that they implement.
|
||||
The table below defines the set of frameworks that you can use, how they are referred to and which version of the [.NET Standard Library](library.md) that they implement.
|
||||
|
||||
| Framework | Latest Version | Target Framework Moniker (TFM) | Compact Target Framework Moniker (TFM) | .NET Standard Version | Metapackage |
|
||||
|:--------: | :--: | :--: | :--: | :--: | :--: | :--: |
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ ms.assetid: bbfe6465-329d-4982-869d-472e7ef85d93
|
|||
|
||||
Multiple implementations of .NET are available, based on open [.NET Standards](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/dotnet-standards.md) that specify the fundamentals of the platform. They are separately optimized for different application types (e.g. desktop, mobile, gaming, cloud) and support many chips (e.g. x86/x64, ARM) and operating systems (e.g. Windows, Linux, iOS, Android, macOS). Open source is also an important part of the .NET ecosystem, with multiple .NET implementations and many libraries available under OSI-approved licenses.
|
||||
|
||||
You can take a look at the [Overview of .NET implementations](editions-overview.md) document to figure out all of the different editions of the .NET Framework that are available, both Microsoft's and others.
|
||||
You can take a look at the [Overview of .NET implementations](../about/products.md) document to figure out all of the different editions of the .NET Framework that are available, both Microsoft's and others.
|
||||
|
||||
This Primer will help you understand some of the key concepts in the .NET Platform and point you to more resources
|
||||
for each given topic. By the end of it, you should have enough information to be able to recognize significant terms and
|
||||
|
|
@ -188,7 +188,7 @@ To learn more about async programming in .NET, start with the [Async Overview](.
|
|||
|
||||
LINQ is a powerful set of features for C# and VB that allow you to write simple, declarative code for operating on data. The data can be in many forms (such as in-memory objects, in a SQL database, or an XML document), but the LINQ code you write typically won't look different for each data source!
|
||||
|
||||
To learn more and see some samples, check out [LINQ (Language Integrated Query)](linq.md).
|
||||
To learn more and see some samples, check out [LINQ (Language Integrated Query)](using-linq.md).
|
||||
|
||||
### Native Interoperability
|
||||
|
||||
|
|
|
|||
|
|
@ -78,14 +78,14 @@ A given component, like System.Runtime, describes:
|
|||
Derivative artifacts are provided to enable more convenient reading and to enable certain developer scenarios (for example, using a compiler).
|
||||
|
||||
- API list in markdown (TBD)
|
||||
- Reference assemblies, distributed as [NuGet packages](../core-concepts/packages.md) and referenced by the [NETStandard.Library](https://www.nuget.org/packages/NETStandard.Library/) metapackage.
|
||||
- Reference assemblies, distributed as [NuGet packages](../core/packages.md) and referenced by the [NETStandard.Library](https://www.nuget.org/packages/NETStandard.Library/) metapackage.
|
||||
|
||||
Package Representation
|
||||
----------------------
|
||||
|
||||
The primary distribution vehicle for the .NET Standard Library reference assemblies is [NuGet packages](../core-concepts/packages.md). Implementations will be delivered in a variety of ways, appropriate for each .NET runtime.
|
||||
The primary distribution vehicle for the .NET Standard Library reference assemblies is [NuGet packages](../core/packages.md). Implementations will be delivered in a variety of ways, appropriate for each .NET runtime.
|
||||
|
||||
NuGet packages target one of more [frameworks](frameworks.md). The .NET Standard Library packages target the ".NET Standard" framework. You can target the .NET Standard Framework using the `netstandard` [compact TFM](../concepts/frameworks.md) (for example, `netstandard1.4`). Libraries that are intended to run on multiple runtimes should target this framework.
|
||||
NuGet packages target one of more [frameworks](frameworks.md). The .NET Standard Library packages target the ".NET Standard" framework. You can target the .NET Standard Framework using the `netstandard` [compact TFM](frameworks.md) (for example, `netstandard1.4`). Libraries that are intended to run on multiple runtimes should target this framework.
|
||||
|
||||
The `NETStandard.Library` metapackage references the complete set of NuGet packages that define the .NET Standard Library. The most common way to target `netstandard` is by referencing this metapackage. It describes and provides access to the ~40 .NET libraries and associated APIs that define the .NET Standard Library. You can reference additional packages that target `netstandard` to get access to additional APIs.
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ The spec is not singular, but an incrementally growing and linearly versioned se
|
|||
|
||||
The .NET Standard Library is not specific to any one .NET runtime, nor does it match the versioning scheme of any of those runtimes.
|
||||
|
||||
APIs added to any of the runtimes (such as, .NET Framework, .NET Core and Mono) can be considered as candidates to add to the specification, particularly if they are thought to be fundamental in nature. New [versions of the .NET Standard Library](https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#list-of-net-corefx-apis-and-their-associated-net-platform-standard-version) are created based on .NET runtime releases, enabling you to target new APIs from a .NET Standard PCL. The versioning mechanics are described in more detail in [.NET Core Versioning](../core-concepts/versioning.md).
|
||||
APIs added to any of the runtimes (such as, .NET Framework, .NET Core and Mono) can be considered as candidates to add to the specification, particularly if they are thought to be fundamental in nature. New [versions of the .NET Standard Library](https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#list-of-net-corefx-apis-and-their-associated-net-platform-standard-version) are created based on .NET runtime releases, enabling you to target new APIs from a .NET Standard PCL. The versioning mechanics are described in more detail in [.NET Core Versioning](../core/versions/index.md).
|
||||
|
||||
.NET Standard Library versioning is important for usage. Given a .NET Standard Library version, you can use libraries that target that same or lower version. The following approach describes the workflow for using .NET Standard Library PCLs, specific to .NET Standard Library targeting.
|
||||
|
||||
|
|
@ -135,4 +135,4 @@ You can see the set of PCL profiles that are compatible with the .NET Standard:
|
|||
Targeting .NET Standard Library
|
||||
===============================
|
||||
|
||||
You can [build .NET Standard Libraries](../core-concepts/libraries/libraries-with-cli.md) using a combination of the `netstandard` framework and the NETStandard.Library metapackage. You can see examples of [targeting the .NET Standard Library with .NET Core tools](../core-concepts/packages.md).
|
||||
You can [build .NET Standard Libraries](../core/deploying/libraries.md) using a combination of the `netstandard` framework and the NETStandard.Library metapackage. You can see examples of [targeting the .NET Standard Library with .NET Core tools](../core/packages.md).
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
C# Microservices Sample
|
||||
================
|
||||
|
||||
This sample is created during the [Creating Microservices hosted in Docker](../microservices.html)
|
||||
This sample is created during the [Creating Microservices hosted in Docker](../microservices.md)
|
||||
tutorial. Please see that topic for detailed steps on the code
|
||||
for this sample.
|
||||
|
||||
|
|
@ -24,4 +24,4 @@ To build and run the sample locally, type the following three commands:
|
|||
`dotnet build` creates the output assembly (or assemblies).
|
||||
`dotnet run` runs the output assembly.
|
||||
|
||||
To install and run the sample in Docker, consult the [full tutorial](../microservices.html).
|
||||
To install and run the sample in Docker, consult the [full tutorial](../microservices.md).
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
C# LINQ Sample
|
||||
================
|
||||
|
||||
This sample is created during the [Working with LINQ tutorial](../working-with-linq.html)
|
||||
This sample is created during the [Working with LINQ tutorial](../working-with-linq.md)
|
||||
for learning C# features. Please see that topic for detailed steps on the code
|
||||
for this sample.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
C# Console Application Sample
|
||||
================
|
||||
|
||||
This sample is created during the [Console Application Tutorial](../console-teleprompter.html)
|
||||
This sample is created during the [Console Application Tutorial](../console-teleprompter.md)
|
||||
for learning C# features. Please see that topic for detailed steps on the code
|
||||
for this sample.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
C# REST Client Sample
|
||||
================
|
||||
|
||||
This sample is created during the [REST client tutorial](../console-webapiclient.html)
|
||||
This sample is created during the [REST client tutorial](../console-webapiclient.md)
|
||||
for learning C# features. Please see that topic for detailed steps on the code
|
||||
for this sample.
|
||||
|
||||
|
|
|
|||
|
|
@ -33,10 +33,10 @@ Documentation
|
|||
|
||||
This documentation will show you how to build an app from scratch or finish one that you are already working on. Key sections you should check out:
|
||||
|
||||
- [C# Guide](csharp/)
|
||||
- [C# Guide](languages/csharp/index.md)
|
||||
- [.NET Core API](core/api)
|
||||
- [.NET Core Guide](core/)
|
||||
- [.NET Standard Guide](standard/)
|
||||
- [.NET Core Guide](core/index.md)
|
||||
- [.NET Standard Guide](standard/index.md)
|
||||
|
||||
Open Source
|
||||
-----------
|
||||
|
|
|
|||
6
index.md
6
index.md
|
|
@ -31,7 +31,7 @@ ms.assetid:
|
|||
<h2 class="section-heading"><span class="icon icon-lightbulb-checked"></span> Featured Content</h2>
|
||||
<div class="features row">
|
||||
<ul class="column-half">
|
||||
<li><a href="core/core/index">Get started with .NET Core</a></li>
|
||||
<li><a href="docs/core/index.md">Get started with .NET Core</a></li>
|
||||
</ul>
|
||||
<ul class="column-half">
|
||||
<li><a href="https://docs.asp.net">Get started with ASP.NET Core</a></li>
|
||||
|
|
@ -54,7 +54,7 @@ ms.assetid:
|
|||
<section class="journey-step-elements content">
|
||||
<ul class="row">
|
||||
<li class="column column-third">
|
||||
<a href="core/welcome">
|
||||
<a href="docs/welcome.md">
|
||||
<h3>.NET Documentation</h3>
|
||||
<p>Learn .NET concepts and language syntax.</p>
|
||||
</a>
|
||||
|
|
@ -66,7 +66,7 @@ ms.assetid:
|
|||
</a>
|
||||
</li>
|
||||
<li class="column column-third">
|
||||
<a href="core/core/index">
|
||||
<a href="docs/core/index.md">
|
||||
<h3>Getting Started with .NET Core</h3>
|
||||
<p>Learn how to build .NET Core console apps at the command-line or in Visual Studio.</p>
|
||||
</a>
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче