Add a build from source section #2014

bleroy · 2017-04-25T19:27:24Z

Build .NET Core from source

Summary

Instructions for building .NET Core from source, and for packaging and shipping it.

Details

The main topic reproduces a summary of build instructions from the relevant repos (CLR and CLI). This will eventually be replaced with a new set of instructions.
Another topic gives specific guidance for package maintainers about versioning and packaging .NET Core (addresses #1912).

Suggested Reviewers

@mairaw, @ellismg

…ing recommendations

… optional packages.

…otnet/build-from-source

dnfclas · 2017-05-01T23:11:09Z

@bleroy, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request.

Thanks, .NET Foundation Pull Request Bot

svick · 2017-05-02T01:10:40Z

docs/core/building/index.md

+
+The build currently depends on Git, CMake, Python and a C++ compiler.
+Once these prerequisites are installed, the CLR is built by invoking the 'build' script (`build.cmd` or `build.sh`) at the base of the 
+repository.


What repository? Shouldn't there be a link to https://github.com/dotnet/coreclr/ somewhere at the start of this section?

svick · 2017-05-02T01:20:23Z

docs/core/building/index.md

+In addition, by default the build will not only create the runtime executables, but it will also 
+build all the tests.   There are quite a few tests so this does take a significant amount of time
+that is not necessary if you want to experiment with changes.
+You can submit the building of the tests with the 'skiptests' argument to the build script.


Maybe it's me not being a native speaker, but I don't understand how does "submit" make sense here.

svick · 2017-05-02T01:22:30Z

docs/core/building/index.md

+that is not necessary if you want to experiment with changes.
+You can submit the building of the tests with the 'skiptests' argument to the build script.
+
+In order to get a build as quickly as possible type the following (using `\` as the directory separator, use `/` on Unix machines)


Just replacing \ with / is not enough. ./build won't work on Unix, ./build.sh is needed.

svick · 2017-05-07T18:13:49Z

docs/core/building/index.md

+
+### Building the CLI
+
+## Prerequisites


This heading has the wrong level, it should be ####, not ##.

Also, the actual build instructions don't have their own heading, so it looks like they are part of Prerequisites, which is wrong.

svick · 2017-05-07T18:15:56Z

docs/core/building/index.md

+    This is the technique that all the tests in the repo use, and is useful for quick local 'edit-compile-debug' loop (e.g. preliminary unit testing).
+    See [Executing .NET Core Apps with CoreRun.exe](https://github.com/dotnet/coreclr/blob/master/Documentation/workflow/UsingCoreRun.md) for details on using this technique.
+
+### Building the CLI


Similarly to CLR above, I think there should be a link to the cli repo here.

mairaw

first set of comments. more coming later if needed...

mairaw · 2017-05-09T19:08:41Z

docs/core/building/distribution-packaging.md

+ms.assetid: 71b9d722-c5a8-4271-9ce1-d87e7ae2494d
+---
+
+.NET Core distribution packaging


we use # for all headings

mairaw · 2017-05-09T19:12:21Z

docs/core/building/distribution-packaging.md

+.NET Core distribution packaging
+================================
+
+As .NET Core becomes available on more and more platforms, thanks to the efforts of dedicated contributors, it is useful to provide guidelines on how to package, name, and version it, in order to ensure a consistency of experience no matter where you choose to run .NET.


thanks to the efforts of dedicated contributors seems like content that would be in a blog post not on official docs

Suggested rewriting:
As .NET Core becomes available on more and more platforms, it's useful to learn how to package, name, and version it, in order to ensure a consistent experience no matter where you choose to run .NET.

You mean just that one paragraph, right?

mairaw · 2017-05-09T19:12:35Z

docs/core/building/distribution-packaging.md

+================================
+
+As .NET Core becomes available on more and more platforms, thanks to the efforts of dedicated contributors, it is useful to provide guidelines on how to package, name, and version it, in order to ensure a consistency of experience no matter where you choose to run .NET.
+This document provides such guidelines.


Remove this.

mairaw · 2017-05-09T19:14:26Z

docs/core/building/distribution-packaging.md

+As .NET Core becomes available on more and more platforms, thanks to the efforts of dedicated contributors, it is useful to provide guidelines on how to package, name, and version it, in order to ensure a consistency of experience no matter where you choose to run .NET.
+This document provides such guidelines.
+
+What .NET Core is made of


This title is a bit strange. How about .NET Core components?

mairaw · 2017-05-09T19:16:50Z

docs/core/building/distribution-packaging.md

+
+.NET Core is made of three major parts that need to be packaged:
+
+1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that is not a strict requirement.


is muxer a common word? for me, it just adds confusion here to add that aka but it could just be me

we style paths with italic and use contractions:
that is not -> that isn't

It's used in some contexts, so it's useful to mention that it is the same thing. This was originally added based on feedback.

mairaw · 2017-05-09T19:18:26Z

docs/core/building/distribution-packaging.md

+.NET Core is made of three major parts that need to be packaged:
+
+1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that is not a strict requirement.
+2. **The framework** is made of a runtime and supporting managed libraries. A framework may be installed as part of an application, or as a shared framework in a central location that can be re-used by multiple applications. There may be any number of shared frameworks installed on a given machine. Shared frameworks live under `shared/Microsoft.NETCore.App/<version>`. The host will roll forward across patch versions, so if an application targets `Microsoft.NETCore.App` 1.0.0, and only 1.0.4 is present, it will be launched against 1.0.4.


A framework may -> The framework may

avoid future tense. For example:
The host will roll forward -> The host rolls forward
and probably better to break this sentence in two as well.

mairaw · 2017-05-09T19:20:33Z

docs/core/building/distribution-packaging.md

+
+1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that is not a strict requirement.
+2. **The framework** is made of a runtime and supporting managed libraries. A framework may be installed as part of an application, or as a shared framework in a central location that can be re-used by multiple applications. There may be any number of shared frameworks installed on a given machine. Shared frameworks live under `shared/Microsoft.NETCore.App/<version>`. The host will roll forward across patch versions, so if an application targets `Microsoft.NETCore.App` 1.0.0, and only 1.0.4 is present, it will be launched against 1.0.4.
+3. **The SDK** (also sometimes referred to as "the tooling") is a set of managed tools that can be used to write and build .NET Core libraries and applications. This includes the CLI, MS Build and associated build tasks and targets, NuGet, new project templates, etc. It is possible to have multiple SDKs on a machine (in order, for example, to allow for building projects that explicitly require an older version), but the recommendation is to use the latest available tools whenever possible.


also sometimes referred to as -> also known as

MS Build -> MSBuild

It is possible -> It's possible

use the latest available tools whenever possible: wouldn't the support come into play here? LTS and Current?

use the latest available tools whenever possible: wouldn't the support come into play here? LTS and Current?

Only for the runtime. I don't think that would apply to the SDK.

mairaw · 2017-05-09T19:25:29Z

docs/core/building/distribution-packaging.md

+Recommended package names
+-------------------------
+
+These are recommendations, and a specific package maintainer may choose to diverge from it, for example based on different tradition of the specific distro they're targeting.


Suggested rewriting:
The following is our recommendation for package names. A package maintainer may choose to diverge from it based on various reasons, such as, a different tradition of the specific distribution they're targeting.

mairaw · 2017-05-09T19:31:09Z

docs/core/building/distribution-packaging.md

@@ -0,0 +1,69 @@
+---


avoid ing on file and folder names for SEO purposes (we were not following guidelines earlier). probably packaging is ok in this scenario but building should be build

mairaw

The topics look good but I still have some more comments. If you prefer, I can make some of the changes I'm requesting on your behalf. Not sure if I can rename the building folder to remove the ing though. It's an SEO recommendation. If you'd like me to make the changes on your behalf, just let me know if you disagree with any of my comments. A lot of my comments are trying to make the topic more concise, to have a better flow or to follow style guide rules.

mairaw · 2017-05-24T22:47:51Z

docs/core/building/distribution-packaging.md

@@ -0,0 +1,63 @@
+---
+title: .NET Core distribution packaging
+description: .NET Core distribution packaging


needs to be different than title. It's what the search engine will display in search results. For example:
Learn how to package, name, and version .NET Core for ...

mairaw · 2017-05-24T22:48:01Z

docs/core/building/distribution-packaging.md

+title: .NET Core distribution packaging
+description: .NET Core distribution packaging
+keywords: .NET, .NET Core, source, build
+author: beleroy


bleroy is your GH alias

mairaw · 2017-05-24T22:49:18Z

docs/core/building/distribution-packaging.md

+
+# .NET Core distribution packaging
+
+As .NET Core becomes available on more and more platforms, it's useful to learn how to package, name, and version it, in order to ensure a consistent experience no matter where you choose to run .NET.


consider breaking the first sentence in two.

also the article should make clear who is your target audience and what's the goal of learning this. who this article is useful for? I think it should be stated in this paragraph.

mairaw · 2017-05-24T22:56:14Z

docs/core/building/distribution-packaging.md

+.NET Core is made of three major parts that need to be packaged:
+
+1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that isn't a strict requirement.
+2. **The framework** is made of a runtime and supporting managed libraries. The framework may be installed as part of an application, or as a shared framework in a central location that can be re-used by multiple applications. There may be any number of shared frameworks installed on a given machine. Shared frameworks live under `shared/Microsoft.NETCore.App/<version>`. The host rolls forward across patch versions. If an application targets `Microsoft.NETCore.App` 1.0.0, and only 1.0.4 is present, it's launched against 1.0.4.


re-used -> reused

mairaw · 2017-05-24T23:00:00Z

docs/core/building/distribution-packaging.md

+
+1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that isn't a strict requirement.
+2. **The framework** is made of a runtime and supporting managed libraries. The framework may be installed as part of an application, or as a shared framework in a central location that can be re-used by multiple applications. There may be any number of shared frameworks installed on a given machine. Shared frameworks live under `shared/Microsoft.NETCore.App/<version>`. The host rolls forward across patch versions. If an application targets `Microsoft.NETCore.App` 1.0.0, and only 1.0.4 is present, it's launched against 1.0.4.
+3. **The SDK** (also known as "the tooling") is a set of managed tools that can be used to write and build .NET Core libraries and applications. This includes the CLI, MSBuild and associated build tasks and targets, NuGet, new project templates, etc. It's possible to have multiple SDKs on a machine (in order, for example, to allow for building projects that explicitly require an older version), but the recommendation is to use the latest available tools whenever possible.


in order, for example, to allow for building -> for example, to build

do we also need to make it clear that you should use the latest version of the released tools (vs. preview)?

mairaw · 2017-05-24T23:51:02Z

docs/core/building/index.md

+
+#### Prerequisites
+
+In order to build .NET Command Line Interface, you need the following installed on you machine.


Command Line Interface -> CLI

mairaw · 2017-05-24T23:51:50Z

docs/core/building/index.md

+
+The source code for the .NET Core CLI can be found in [the `dotnet/cli` repository on GitHub](https://github.com/dotnet/cli/).
+
+#### Prerequisites


you didn't add a section to the previous one. I think you can just list them without a heading.

mairaw · 2017-05-24T23:52:13Z

docs/core/building/index.md

+    - Xcode
+    - OpenSSL
+
+#### building the CLI


then you can remove this

mairaw · 2017-05-24T23:53:04Z

docs/core/building/index.md

+
+#### building the CLI
+
+In order to build, run `build.cmd` or `build.sh` from the root depending on your OS. If you don't want to execute tests, run `build.cmd /t:Compile` or `./build.sh /t:Compile`. To build the CLI in macOS Sierra, you need to set the DOTNET_RUNTIME_ID environment variable by running `export DOTNET_RUNTIME_ID=osx.10.11-x64`.


depending on your OS: I'd actually say which one you use in Windows vs. Linux/macOS

mairaw · 2017-05-24T23:53:55Z

docs/core/building/index.md

+
+#### Using your build
+
+Use `artifacts/{RID}/stage2/dotnet` to try out the `dotnet` command. You can also add `artifacts/{os}-{arch}/stage2` to the PATH if you want to use the build output when invoking `dotnet` from the current console.


Use artifacts/{RID}/stage2/dotnet -> what does this mean?

AFAIK, this is the actual path to the dotnet executable, except {RID} is a placeholder depends on your OS (including the specific version of a specific Linux distro) and architecture.

bleroy · 2017-05-25T22:56:16Z

Thanks for the great feedback. Hopefully I addressed it all.

bleroy · 2017-06-21T00:46:05Z

@mairaw are there any remaining issues on this PR?

mairaw · 2017-06-26T23:08:51Z

I'll start the review now but I already see that the folder hasn't been changed from building to just build. We're following SEO best practices to our new content. We might have to change old content that has folders ending in ing.

mairaw

Looks good. Ran our terminology tool on these articles. I'm calling out the main suggestions.

mairaw · 2017-06-26T23:10:40Z

docs/core/building/distribution-packaging.md

@@ -0,0 +1,63 @@
+---
+title: .NET Core distribution packaging
+description: Learn how to package, name, and version .NET Core distribution packages


add period in the end

mairaw · 2017-06-27T01:14:54Z

docs/core/building/distribution-packaging.md

+* `dotnet-sdk-[major].[minor]`: new patch versions update the package, but new minor or major versions are separate packages.
+* `dotnet-lts`: `update` rolls forward major, minor, and patch versions.
+
+Those are recommendations, and each distro is free to choose what versions to offer, and when. For example, a distro that values stability more than being up to date may choose to release only versions that snap with the LTS release train.


up to date -> up-to-date

Those are recommendations -> This topic has presented our recommendations for ... however each distro is free to choose what versions to offer and when.

mairaw · 2017-06-27T01:15:43Z

docs/core/building/distribution-packaging.md

+
+Some maintainers may choose to provide additional packages such as:
+
+* `dotnet-lts`: the latest "Long-Term Support" version of the shared framework. [LTS and Current release trains](~/docs/core/versions/lts-current.md) correspond to different cadences at which .NET Core gets released. Users have a choice of adopting one or the other train, based on how often they are willing to update. This is a concept that is also tied to support levels, so it may or may not make sense depending on the distro being considered.


latest "Long-Term Support" -> latest Long-Term Support (LTS)

mairaw · 2017-06-27T01:18:08Z

docs/core/building/distribution-packaging.md

+.NET Core is made of three major parts that need to be packaged:
+
+1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that isn't a strict requirement.
+2. **The framework** is made of a runtime and supporting managed libraries. The framework may be installed as part of an application, or as a shared framework in a central location that can be reused by multiple applications. There may be any number of shared frameworks installed on a given machine. Shared frameworks live under `shared/Microsoft.NETCore.App/<version>`. The host rolls forward across patch versions. If an application targets `Microsoft.NETCore.App` 1.0.0, and only 1.0.4 is present, it's launched against 1.0.4.


it's launched -> the app is

mairaw · 2017-06-27T01:19:25Z

docs/core/building/distribution-packaging.md

+
+1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that isn't a strict requirement.
+2. **The framework** is made of a runtime and supporting managed libraries. The framework may be installed as part of an application, or as a shared framework in a central location that can be reused by multiple applications. There may be any number of shared frameworks installed on a given machine. Shared frameworks live under `shared/Microsoft.NETCore.App/<version>`. The host rolls forward across patch versions. If an application targets `Microsoft.NETCore.App` 1.0.0, and only 1.0.4 is present, it's launched against 1.0.4.
+3. **The SDK** (also known as "the tooling") is a set of managed tools that can be used to write and build .NET Core libraries and applications. This includes the CLI, MSBuild and associated build tasks and targets, NuGet, new project templates, etc. It's possible to have multiple SDKs on a machine (for example, to build projects that explicitly require an older version), but the recommendation is to use the latest released tools.


This includes the CLI, MSBuild and -> The SDK includes the CLI, MSBuild, and

https://microsoft-ce-csi.acrolinx.cloud/htmldata/en/rules/help/use_this_that_these_those_with_noun.html
https://microsoft-ce-csi.acrolinx.cloud/htmldata/en/rules/help/use_serial_comma.html

mairaw · 2017-06-27T01:36:23Z

docs/core/building/index.md

+
+ 2. **Use corerun.exe to run an application using unpackaged Dlls**.
+    This repository also defines a simple host called corerun.exe that does NOT take any dependency on NuGet.
+    This host has to be told where to get the necessary DLLs you actually use, and you have to manually gather them together.


Can you simplify this sentence? Maybe "You need to tell the host where to get the required DLLs..."

mairaw · 2017-06-27T01:38:10Z

docs/core/building/index.md

+ 2. **Use corerun.exe to run an application using unpackaged Dlls**.
+    This repository also defines a simple host called corerun.exe that does NOT take any dependency on NuGet.
+    This host has to be told where to get the necessary DLLs you actually use, and you have to manually gather them together.
+    This is the technique that all the tests in the repo use, and is useful for quick local 'edit-compile-debug' loop (for example preliminary unit testing).


This is the technique that all the tests in the repo use -> This technique is used by all tests in the repo
also which repo? CoreCLR? I suggest naming it and linking to it

(for example preliminary unit testing) -> such as, preliminary unit testing

mairaw · 2017-06-27T01:39:36Z

docs/core/building/index.md

+
+The source code for the .NET Core CLI can be found in [the `dotnet/cli` repository on GitHub](https://github.com/dotnet/cli/).
+
+In order to build .NET CLI, you need the following installed on you machine.


.NET CLI -> the .NET CLI

your machine

mairaw · 2017-06-27T01:40:58Z

docs/core/building/index.md

+
+### Using your build
+
+Use the `dotnet` executable from *artifacts/{os}-{arch}/stage2* to try out the newly built CLI. You can also add *artifacts/{os}-{arch}/stage2* to the PATH if you want to use the build output when invoking `dotnet` from the current console.


Mention if first in the second sentence?

I don't understand that one.

I think it's about moving the "if" clause before the "then" clause :)

"You can also add artifacts/{os}-{arch}/stage2 to the PATH if you want to use the build output when invoking dotnet from the current console."

->

"If you want to use the build output when invoking dotnet from the current console, you can add artifacts/{os}-{arch}/stage2 to PATH"

Ah, yes, that makes sense. Thanks Omair!

mairaw · 2017-06-27T01:42:41Z

docs/toc.md

@@ -77,6 +77,8 @@
 ### [Analyzing third-party dependencies](core/porting/third-party-deps.md)
 ### [Porting libraries](core/porting/libraries.md)
 <!--### [🔧 NuGet packages](core/porting/nuget-packages.md)-->
+## [Building .NET Core](core/building/index.md)


Building -> Build

would it help to clarify what you're building? Build .NET Core from source, for example.

BillWagner

After making the changes @mairaw suggested, this LGTM. I'll close and reopen to force a new build, and then we will merge this, pending @mairaw 's approval.

BillWagner · 2017-07-07T17:49:40Z

closing and re-opening to force a new CI build.

mairaw · 2017-07-07T23:00:52Z

VSTS builds keep failing on this one which is odd since this doesn't touch code samples. I've also noticed the folder name still has ing, so I'll make this change and see what else was missed.

mairaw

I've renamed the folder now. Pending a good build, this is good to go.

bleroy added 12 commits March 29, 2017 17:25

Start the build from source section

2461840

Add package preview versioning, and side-by-side info for package nam…

1974044

…ing recommendations

Fix minor typo

d0357a4

Make dotnet-sdk depend on a versioned SDK package, move dotnet to…

00691da

… optional packages.

Placeholder for build from source doc.

f297f95

Merge remote-tracking branch 'origin/dotnet/build-from-source' into d…

ede8b12

…otnet/build-from-source

Clean dependencies

c3da9d5

Remove dotnet package.

60cb241

Remove update policy for dotnet package, which is gone.

0656ba7

Add current build instructions

44f13c3

Add to TOC, add asset id.

2870ea5

Mention CLI as part of the SDK; add roll forward precision

c6ae1cd

bleroy requested a review from ellismg April 25, 2017 19:27

dnfclas added the cla-required label Apr 25, 2017

bleroy requested review from BillWagner and mairaw April 25, 2017 19:27

mairaw closed this Apr 25, 2017

mairaw reopened this Apr 25, 2017

dnfclas added the cla-required label Apr 25, 2017

dnfclas added cla-signed and removed cla-required labels May 1, 2017

svick reviewed May 7, 2017

View reviewed changes

Merge branch 'master' into dotnet/build-from-source

952c977

mairaw requested changes May 9, 2017

View reviewed changes

bleroy added 2 commits May 9, 2017 13:14

Change dotnet-[major].[minor] to dotnet-runtime-[major].[minor]

02f6247

Address feedback.

19f1030

mairaw requested changes May 25, 2017

View reviewed changes

Address feedback on build from source section

af6a09f

dend closed this Jun 4, 2017

dend reopened this Jun 4, 2017

dnfclas added the cla-already-signed label Jun 4, 2017

Fix typo

d343dae

mairaw requested changes Jun 27, 2017

View reviewed changes

bleroy added 2 commits June 28, 2017 15:03

Address feedback.

7488d93

Fix sentence ordering.

ddd50e5

BillWagner approved these changes Jul 7, 2017

View reviewed changes

BillWagner closed this Jul 7, 2017

BillWagner reopened this Jul 7, 2017

dnfclas added the cla-already-signed label Jul 7, 2017

mairaw closed this Jul 7, 2017

mairaw reopened this Jul 7, 2017

dnfclas added the cla-already-signed label Jul 7, 2017

dotnet deleted a comment from bleroy Jul 7, 2017

ellismg approved these changes Jul 7, 2017

View reviewed changes

renaming folder

0ed492f

mairaw approved these changes Jul 11, 2017

View reviewed changes

mairaw added the verify-build-before-merge label Jul 11, 2017

mairaw merged commit e60b027 into dotnet:master Jul 12, 2017

mairaw removed the verify-build-before-merge label Sep 25, 2017


		.NET Core is made of three major parts that need to be packaged:

		1. The host (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that is not a strict requirement.


		# .NET Core distribution packaging

		As .NET Core becomes available on more and more platforms, it's useful to learn how to package, name, and version it, in order to ensure a consistent experience no matter where you choose to run .NET.


		#### Prerequisites

		In order to build .NET Command Line Interface, you need the following installed on you machine.


		The source code for the .NET Core CLI can be found in [the `dotnet/cli` repository on GitHub](https://github.com/dotnet/cli/).

		#### Prerequisites


		#### building the CLI

		In order to build, run `build.cmd` or `build.sh` from the root depending on your OS. If you don't want to execute tests, run `build.cmd /t:Compile` or `./build.sh /t:Compile`. To build the CLI in macOS Sierra, you need to set the DOTNET_RUNTIME_ID environment variable by running `export DOTNET_RUNTIME_ID=osx.10.11-x64`.


		#### Using your build

		Use `artifacts/{RID}/stage2/dotnet` to try out the `dotnet` command. You can also add `artifacts/{os}-{arch}/stage2` to the PATH if you want to use the build output when invoking `dotnet` from the current console.


		Some maintainers may choose to provide additional packages such as:

		* `dotnet-lts`: the latest "Long-Term Support" version of the shared framework. [LTS and Current release trains](~/docs/core/versions/lts-current.md) correspond to different cadences at which .NET Core gets released. Users have a choice of adopting one or the other train, based on how often they are willing to update. This is a concept that is also tied to support levels, so it may or may not make sense depending on the distro being considered.


		The source code for the .NET Core CLI can be found in [the `dotnet/cli` repository on GitHub](https://github.com/dotnet/cli/).

		In order to build .NET CLI, you need the following installed on you machine.


		### Using your build

		Use the `dotnet` executable from artifacts/{os}-{arch}/stage2 to try out the newly built CLI. You can also add artifacts/{os}-{arch}/stage2 to the PATH if you want to use the build output when invoking `dotnet` from the current console.

Add a build from source section #2014

Add a build from source section #2014

Conversation

bleroy commented Apr 25, 2017

Build .NET Core from source

Summary

Details

Suggested Reviewers

dnfclas commented May 1, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mairaw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mairaw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bleroy commented May 25, 2017

bleroy commented Jun 21, 2017

mairaw commented Jun 26, 2017

mairaw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BillWagner left a comment

Choose a reason for hiding this comment

BillWagner commented Jul 7, 2017

mairaw commented Jul 7, 2017

mairaw left a comment

Choose a reason for hiding this comment