Build CoreCLR on Windows
========================
-These instructions will lead you through building CoreCLR and running a "Hello World" demo on Windows.
+These instructions will lead you through building CoreCLR.
-Environment
-===========
+----------------
+#Environment
You must install several components to build the CoreCLR and CoreFX repos. These instructions were tested on Windows 7+.
-Visual Studio
--------------
+## Visual Studio
Visual Studio must be installed. Supported versions:
+- [Visual Studio 2015](https://www.visualstudio.com/downloads/visual-studio-2015-downloads-vs) (Community, Professional, Enterprise). The community version is completely free.
-- [Visual Studio 2015](https://www.visualstudio.com/downloads/visual-studio-2015-downloads-vs) (Community, Professional, Enterprise)
-
-To debug managed code, ensure you have installed atleast [Visual Studio 2015 Update 3](https://www.visualstudio.com/en-us/news/releasenotes/vs2015-update3-vs).
+To debug managed code, ensure you have installed at least [Visual Studio 2015 Update 3](https://www.visualstudio.com/en-us/news/releasenotes/vs2015-update3-vs).
Make sure that you install "VC++ Tools". By default, they will not be installed.
Visual Studio Express is not supported.
-CMake
------
+##CMake
The CoreCLR repo build has been validated using CMake 3.5.2.
- Install [CMake](http://www.cmake.org/download) for Windows.
-- Add it to the PATH environment variable.
+- Add its location (e.g. C:\Program Files (x86)\CMake\bin) to the PATH environment variable.
+ The installation script has a check box to do this, but you can do it yourself after the fact
+ following the instructions at [Adding to the Default PATH variable](#add-to-the-default-path-variable)
+
+
+##Python
-Python
----------
-Python is used in the build system. We are currently using python 2.7.9, although
+Python is used in the build system. We are currently using python 2.7.9, althoughw
any recent (2.4+) version of Python should work, including Python 3.
- Install [Python](https://www.python.org/downloads/) for Windows.
-- Add it to the PATH environment variable.
-
-PowerShell
-----------
-PowerShell is used in the build system. Ensure that it is accessible via the PATH environment variable. Typically this is %SYSTEMROOT%\System32\WindowsPowerShell\v1.0\.
+- Add its location (e.g. C:\Python*\) to the PATH environment variable.
+ The installation script has a check box to do this, but you can do it yourself after the fact
+ following the instructions at [Adding to the Default PATH variable](#add-to-the-default-path-variable)
-Powershell version must be 3.0 or higher. This should be the case for Windows 8 and later builds.
-- Windows 7 SP1 can install Powershell version 4 [here](https://www.microsoft.com/en-us/download/details.aspx?id=40855).
+##Git
-Git Setup
----------
+For actual user operations, it is often more convinient to use the GIT features built into Visual Studio 2015.
+However the CoreCLR and te tests use the GIC command line utilities directly so you need to install them
+for these to work properly. You can get it from
-Clone the CoreCLR and CoreFX repositories (either upstream or a fork).
+- Install [Git For Windows](https://git-for-windows.github.io/)
+- Add its location (e.g. C:\Program Files\Git\cmd) to the PATH environment variable.
+ The installation script has a check box to do this, but you can do it yourself after the fact
+ following the instructions at [Adding to the Default PATH variable](#add-to-the-default-path-variable)
-```bat
-C:\git>git clone https://github.com/dotnet/coreclr
-C:\git>git clone https://github.com/dotnet/corefx
-```
+##PowerShell
+PowerShell is used in the build system. Ensure that it is accessible via the PATH environment variable.
+Typically this is %SYSTEMROOT%\System32\WindowsPowerShell\v1.0\.
-This guide assumes that you've cloned the CoreCLR and CoreFX repositories into C:\git using the default repo names. If your setup is different, you'll need to pay attention to the commands you run. The guide will always show you the current directory.
+Powershell version must be 3.0 or higher. This should be the case for Windows 8 and later builds.
+- Windows 7 SP1 can install Powershell version 4 [here](https://www.microsoft.com/en-us/download/details.aspx?id=40855).
-The repository is configured to allow Git to make the right decision about handling CRLF. Specifically, if you are working on **Windows**, please ensure that **core.autocrlf** is set to **true**. On **non-Windows** platforms, please set it to **input**.
+##DotNet Core SDK
+While not strictly needed to build or tests the .NET Core repository, having the .NET Core SDK installed lets
+you use the dotnet.exe command to run .NET Core applications in the 'normal' way. We use this in the
+[Using Your Build](Documentation/workflow/UsingYourBuild.md) instructions. Visual Studio 2015 (update 3) should have
+installed the .NET Core SDK, but in case it did not you can get it from the [Installing the .Net Core SDK](https://www.microsoft.com/net/core) page.
-Demo directory
---------------
+##Adding to the default PATH variable
-In order to keep everything tidy, create a new directory for the files that you will build or acquire.
+The commands above need to be on your command lookup path. Some installers will automatically add them to
+the path as part of installation, but if not here is how you can do it.
-```bat
-c:\git>mkdir \coreclr-demo\runtime
-c:\git>mkdir \coreclr-demo\ref
+You can of course add a directory to the PATH environment variable with the syntax
+```
+ set PATH=%PATH%;DIRECTORY_TO_ADD_TO_PATH
```
+However the change above will only last until the command windows closes. You can make your change to
+the PATH variable persistent by going to Control Panel -> System And Security -> System -> Advanced system settings -> Environment Variables,
+and select the 'Path' variable in the 'System variables' (if you want to change it for all users) or 'User variables' (if you only want
+to change it for the currnet user). Simply edit the PATH variable's value and add the directory (with a semicolon separator).
-Build the Runtime
-=================
+-------------------------------------
+#Building
-To build CoreCLR, run `build.cmd` from the root of the coreclr repository. This will do a x64/Debug build of CoreCLR, its native components, mscorlib.dll, and the tests.
+Once all the necessary tools are in place, building is trivial. Simply run build build.cmd script that lives at
+the base of the repository.
- C:\git\coreclr>build -rebuild
+```bat
+ .\build
[Lots of build spew]
- Repo successfully built.
-
Product binaries are available at C:\git\coreclr\bin\Product\Windows_NT.x64.debug
Test binaries are available at C:\git\coreclr\bin\tests\Windows_NT.x64.debug
+```
-**Note:** To avoid building the tests, pass the 'skiptestbuild' option to build.
-
-**build -?** will list supported parameters.
-
-Check the build output.
+As shown above the product will be placed in
- Product binaries will be dropped in `bin\Product\<OS>.<arch>.<flavor>` folder.
- A NuGet package, Microsoft.Dotnet.CoreCLR, will be created under `bin\Product\<OS>.<arch>.<flavor>\.nuget` folder.
- Test binaries will be dropped under `bin\Tests\<OS>.<arch>.<flavor>` folder
-You will see several files. The interesting ones are:
-
-- `corerun`: The command line host. This program loads and starts the CoreCLR runtime and passes the managed program you want to run to it.
-- `coreclr.dll`: The CoreCLR runtime itself.
-- `mscorlib.dll`: The core managed library for CoreCLR, which contains all of the fundamental data types and functionality.
-
-Copy these files into the demo directory.
-
-```bat
-C:\git\coreclr>copy bin\Product\Windows_NT.x64.debug\clrjit.dll \coreclr-demo\runtime
-C:\git\coreclr>copy bin\Product\Windows_NT.x64.debug\CoreRun.exe \coreclr-demo\runtime
-C:\git\coreclr>copy bin\Product\Windows_NT.x64.debug\coreclr.dll \coreclr-demo\runtime
-C:\git\coreclr>copy bin\Product\Windows_NT.x64.debug\mscorlib.dll \coreclr-demo\runtime
-C:\git\coreclr>copy bin\Product\Windows_NT.x64.debug\System.Private.CoreLib.dll \coreclr-demo\runtime
-```
-
-Build the Framework
-===================
-
-Build the framework out of the corefx directory.
+By default build generates a 'Debug' build type, that has extra checking (assert) compiled into it. You can
+also build the 'release' version which does not have these checks
- c:\git\corefx>build.cmd
+The build places logs in `bin\Logs` and these are useful when the build fails.
- [Lots of build spew]
-
- 0 Warning(s)
- 0 Error(s)
- Time Elapsed 00:03:14.53
- Build Exit Code = 0
-
-It's also possible to add -rebuild to build.cmd to force it to delete the previously built assemblies.
-
-For the purposes of this demo, you need to copy a few required assemblies to the demo folder.
-
-```bat
-C:\git\corefx>copy bin\Windows_NT.AnyCPU.Debug\System.Console\System.Console.dll \coreclr-demo\runtime
-C:\git\corefx>copy bin\Windows_NT.AnyCPU.Debug\System.Diagnostics.Debug\System.Diagnostics.Debug.dll \coreclr-demo\runtime
-C:\git\corefx>copy bin\AnyOS.AnyCPU.Debug\System.IO\System.IO.dll \coreclr-demo\runtime
-C:\git\corefx>copy bin\AnyOS.AnyCPU.Debug\System.IO.FileSystem.Primitives\System.IO.FileSystem.Primitives.dll \coreclr-demo\runtime
-C:\git\corefx>copy bin\AnyOS.AnyCPU.Debug\System.Runtime\System.Runtime.dll \coreclr-demo\runtime
-C:\git\corefx>copy bin\AnyOS.AnyCPU.Debug\System.Runtime.InteropServices\System.Runtime.InteropServices.dll \coreclr-demo\runtime
-C:\git\corefx>copy bin\AnyOS.AnyCPU.Debug\System.Text.Encoding\System.Text.Encoding.dll \coreclr-demo\runtime
-C:\git\corefx>copy bin\AnyOS.AnyCPU.Debug\System.Text.Encoding.Extensions\System.Text.Encoding.Extensions.dll \coreclr-demo\runtime
-C:\git\corefx>copy bin\AnyOS.AnyCPU.Debug\System.Threading\System.Threading.dll \coreclr-demo\runtime
-C:\git\corefx>copy bin\AnyOS.AnyCPU.Debug\System.Threading.Tasks\System.Threading.Tasks.dll \coreclr-demo\runtime
-```
-
-You also need to copy reference assemblies, which will be used during compilation.
-
-```bat
-C:\git\corefx>copy bin\ref\System.Runtime\4.0.0.0\System.Runtime.dll \coreclr-demo\ref
-C:\git\corefx>copy bin\ref\System.Console\4.0.0.0\System.Console.dll \coreclr-demo\ref
-```
-
-Compile the Demo
-================
+The build places all of its output in the `bin` directory, so if you remove that directory you can force a
+full rebuild.
-Now you need a Hello World application to run. You can write your own, if you'd like. Here's a very simple one:
+Build has a number of options that you can learn about using build -?. Some of the more important options are
-```C#
-using System;
+ * skiptests - don't build the tests. This can shorten build times quite a bit, but means you can't run tests.
+ * release - build the 'Release' build type that does not have extra development-time checking compiled in.
+ * -rebuild - force the build not to be incremental but to recompile everything.
+ You want this if you are going to do performance testing on your build.
-public class Program
-{
- public static void Main()
- {
- Console.WriteLine("Hello, Windows");
- Console.WriteLine("Love from CoreCLR.");
- }
-}
-```
-
-Personally, I'm partial to the one on corefxlab which will print a picture for you. Download the [corefxlab demo](https://raw.githubusercontent.com/dotnet/corefxlab/master/demos/CoreClrConsoleApplications/HelloWorld/HelloWorld.cs) to `\coreclr-demo`.
-
-Then you just need to build it, with csc, the .NET Framework C# compiler. It may be easier to do this step within the "Developer Command Prompt for VS2015", if csc is not in your path. Because you need to compile the app against the .NET Core surface area, you need to pass references to the contract assemblies you restored using NuGet:
-
-```bat
-csc /nostdlib /noconfig /r:ref\System.Runtime.dll /r:ref\System.Console.dll /out:runtime\hello.exe hello.cs
-```
-
-Run the demo
-============
-
-You're ready to run Hello World! To do that, run corerun, passing the path to the managed exe, plus any arguments. In this case, no arguments are necessary.
-
-```bat
-C:\coreclr-demo>cd runtime
-C:\coreclr-demo\runtime>CoreRun.exe hello.exe
-```
+See [Using Your Build](../workflow/UsingYourBuild.md) for instructions on running code with your build.
-If `CoreRun.exe` fails for some reason, you will see an empty output. To diagnose the issue, you can use `/v` to switch verbose mode on: `CoreRun.exe /v hello.exe`.
+See [Running Tests](../workflow/RunningTests.md) for instructions on running the tests.
-Over time, this process will get easier. Thanks for trying out CoreCLR. Feel free to try a more interesting demo.
--- /dev/null
+
+# Engage, Log Issues and Provide Feedback
+
+## Reporting Problems (Bugs)
+
+We track bugs, feature requests and other issues on the .NET Core's [Issues Page](https://github.com/dotnet/coreclr/issues).
+If you have a problem and believe that the issue is in .NET Core itself (native runtime or base level class library)
+you should log it there. If in the upper levels of the class library the [CoreFX Issues Page](https://github.com/dotnet/corefx/issues).
+
+Before you log a new issue, you should try using the search tool on the issue page on a few keywords to see if the issue was already logged.
+
+### NET Forums
+If you want to ask a question, or want wider discussion (to see if others share you issue), we encourage you to start a thread
+in the [.NET Foundation forums](http://forums.dotnetfoundation.org/).
+
+###Chat with the CoreCLR Community
+
+For more real-time feedback you can also start a chat session by clicking on the icons below.
+
+[](http://tattoocoder.com/aspnet-slack-sign-up/) [](https://gitter.im/dotnet/coreclr?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
+
+### Security issues
+
+To avoid tipping off malicious users wishing to exploit a vulnerability,
+security issues and bugs should be reported privately, via email, to the
+Microsoft Security Response Center (MSRC) <secure@microsoft.com>. You should
+receive a response within 24 hours. If for some reason you do not, please follow
+up via email to ensure we received your original message. Further information,
+including the MSRC PGP key, can be found in the
+[Security TechCenter](https://technet.microsoft.com/en-us/security/ff852094.aspx)
+
+### Issues with the .NET Desktop runtime
+
+The .NET Core repository is not an appropriate place to log issues for the 'Desktop' .NET Framework built into the Windows
+operating system. If you are having issues with the Full .NET Framework or .NET Runtime the best ways to file a bug
+are at [Connect](http://connect.microsoft.com/VisualStudio) or through
+[Product Support](https://support.microsoft.com/en-us/contactus?ws=support) if you have a contract.
+
--- /dev/null
+# Official Releases and Daily Builds of CoreCLR and CoreFX components
+
+If you are not planning on actually making bug fixes or experimenting with new features, then you probably
+don't need to don't need build CoreCLR yourself, as the .NET Runtime team routinely does this for you.
+
+Roughly every three months, the .NET Runtime team publishes a new version of .NET Core to Nuget. .NET Core's
+official home on NuGet is
+
+ * <https://www.nuget.org/packages/Microsoft.NETCore.Runtime.CoreCLR/>
+
+and you can expect to see new versions roughly three months. However it is also the case that the .NET
+Team publishes **daily builds** of all sorts of packages including those built by the CoreCLR and CoreFX
+repositories. You can see what is available from
+
+ * <https://dotnet.myget.org/gallery/dotnet-core>, and in particular you can see the builds of CoreCLR at
+ * <https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.NETCore.Runtime.CoreCLR>.
+
+Thus if your goal is just to get the latest bug fixes and features, you don't need to build CoreC*LR yourself you
+can simply add <https://dotnet.myget.org/F/dotnet-core/api/v3/index.json> to your Nuget Feed list.
+
+## Package Version Numbers
+
+Version numbers for Nuget packages look like the following
+```
+ 1.0.24214.01
+```
+Which have the form
+```
+ <major>.<minor>.<buildNumberMajor>.<buildNumberMinor>
+```
+
+* The major version number represents a compatibility band. If the next release of the package is not
+ backward compatible (most apps that run on version N-1 will run on version N) then this number is increased.
+ This number is not likely to change (we care about compatibility alot)
+
+* The minor number is increased every time interesting new features are added (not just minor bug fixes).
+ For CoreCLR we tend to update this every time we create a public release (every 3 months).
+
+* The Major Build Number is a number that represents a daily build. The last 2 digits of this build number
+ is the **day of the month** of the GIT commit that is being built. Thus we know in the example above this
+ build's last commit to GIT happened on the 14th day of the month. The most significant digits represents
+ the month count since April 1996. In the example above 242 represents Jun 2016.
+
+* The Minor Build number is something that disambiguates different builds that share the same
+ commit (or the different commits on the same day). It is a sequential number and is typically 1 for
+ official builds, and 0 for developer builds. (You can set the environment variable BuildNumberMinor if
+ you wish to set it for your own builds).
+
+
+
+See the [Package and File Versioning](https://github.com/dotnet/corefx/blob/master/Documentation/building/versioning.md) page
+for more details on how the build version number is generated.
+
+
+
+# Build/Test Status of the repository
+
+As mentioned we build the CoreCLR repository daily, and as part of that build we also run all
+the tests associted with this repository. Below is a table of the most recent results for all
+the different operating systems and architectures that we routinely build.
+
+If you click on the images below, you can get more details about the build (including the binaries)
+and the exact test results (in case your build is failing tests and you are wondering if it is
+something affecting all builds).
+
+| | Debug | Release |
+|---|:-----:|:-------:|
+|**CentOS 7.1**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_centos7.1)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_centos7.1)|
+|**Debian 8.4**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_debian8.4)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_debian8.4)|
+|**FreeBSD 10.1**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_freebsd)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_freebsd)|
+|**openSUSE 13.2**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_opensuse13.2)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_opensuse13.2)|
+|**openSUSE 42.1**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_opensuse42.1)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_opensuse42.1)|
+|**OS X 10.11**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_osx)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_osx)|
+|**Red Hat 7.2**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_rhel7.2)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_rhel7.2)|
+|**Fedora 23**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_fedora23)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_fedora23)|
+|**Ubuntu 14.04**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_ubuntu)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_ubuntu)|
+|**Ubuntu 16.04**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_ubuntu16.04)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_ubuntu16.04)|
+|**Ubuntu 16.10**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_ubuntu16.10)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_ubuntu16.10)|
+|**Windows 8.1**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_windows_nt)<br/>[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/arm64_cross_debug_windows_nt)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_windows_nt)<br/>[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/arm64_cross_release_windows_nt)|
--- /dev/null
+
+#Running .NET Core Tests
+
+TODO - Incomplete.
+
+See [Windows Instructions](../building/windows-test-instructions.md)
+See [Unix Instructions](../building/unix-test-instructions.md)
+
+
+
--- /dev/null
+
+# Using corerun To Run .NET Core Application
+
+In page [Using Your Build](UsingYourBuild.md) gives detailed instructions on using the standard
+command line host and SDK, dotnet.exe to run a .NET application with the modified build of the
+.NET Core runtime built here. This is the preferred mechanism for you to officially deploy
+your changes to other people since dotnet.exe and Nuget insure that you end up with a consistent
+set of DLLs that can work together.
+
+However packing and unpacking the runtime DLLs adds extra steps to the deployment process and when
+you are in the tight code-build-debug loop these extra steps are an issue.
+
+For this situation there is an alternative host to dotnet.exe called corerun.exe that is well suited
+for this. It does not know about Nuget at all, and has very simple rules. It needs to find the
+.NET Core runtime (that is coreclr.dll) and additionally any class library DLLs (e.g. System.Runtime.dll System.IO.dll ...).
+
+It does this by looking at two environment variables.
+
+
+ * `CORE_ROOT` - The directory where to find the runtime DLLs itself (e.g. CoreCLR.dll).
+ Defaults to be next to the corerun.exe host itself.
+ * `CORE_LIBRARIES` - A Semicolon separated list of directories to look for DLLS to resolve any assembly references.
+ It defaults CORE_ROOT if it is not specified.
+
+These simple rules can be used in a number of ways
+
+## Getting the class library from the shared system-wide runtime
+
+Consider that you already have a .NET application DLL called HelloWorld.dll and wish to run it
+(You could make such a DLL by using 'dotnet new' 'dotnet restore' 'dotnet build' in a 'HelloWorld' directory).
+
+If you execute the following
+```bat
+ set PATH=%PATH%;%CoreCLR%\bin\Product\Windows_NT.x64.Debug
+ set CORE_LIBRARIES=%ProgramFiles%\dotnet\shared\Microsoft.NETCore.App\1.0.0
+
+
+ corerun HelloWorld.dll
+```
+
+for Linux use /usr/share for %Program Files%
+
+Where %CoreCLR% is the base of your CoreCLR repository, then it will run your HelloWorld. application.
+You can see why this works. The first line puts build output directory (Your OS, architecture, and buildType
+may be different) and thus corerun.exe you just built is on your path.
+The second line tells corerun.exe where to find class library files, in this case we tell it
+to find them where the installation of dotnet.exe placed its copy. (Note that version number in the path above may change)
+
+Thus when you run 'corerun HelloWorld.dll' Corerun knows where to get the DLLs it needs. Notice that once
+you set up the path and CORE_LIBRARIES environment, after a rebuild you can simply use corerun to run your
+application (you don't have to move DLLs around)
+
+## Using corerun.exe to Execute a Published Application
+
+When 'dotnet publish' publishes an application it deploys all the class libraries needed as well.
+Thus if you simply change the CORE_LIBRARIES definition in the previous instructions to point at
+that publication directory but RUN the corerun from your build output the effect will be that you
+run your new runtime getting all the other code needed from that deployed application. This is
+very convenient because you don't need to modify the deployed application in order to test
+your new runtime.
+
+## How CoreCLR Tests use corerun.exe
+
+When you execute 'tests\runTest.cmd' one of the things that it does is set up a directory where it
+gathers the CoreCLR that has just been built with the pieces of the class library that tests need.
+It places this runtime in the directory
+```bat
+ bin\Product\<OS>.<Arch>.<BuildType>\test
+```
+off the CoreCLR Repository. The way the tests are expected to work is that you set the environment
+variable CORE_ROOT to this directory
+(you don't have to set CORE_LIBRARIES) and you can run any tests. For example after building the tests
+(running build-test at the repository base) and running 'test\runtest') you can do the following
+
+```bat
+ set PATH=%PATH%;%CoreCLR%\bin\Product\Windows_NT.x64.Debug
+ set CORE_ROOT=%CoreCLR%\bin\tests\Windows_NT.x64.Debug\Tests\Core_Root
+```
+sets you up so that corerun can run any of the test. For example
+```bat
+ corerun bin\tests\Windows_NT.X64.Debug\GC\Features\Finalizer\finalizeio\finalizeio\finalizeio.exe
+```
+runs the finalizerio test.
\ No newline at end of file
--- /dev/null
+
+# Using your .NET Core Build
+
+We assume that you have successfully built .NET Core Repository and thus have file of the form
+```
+ bin\Product\<OS>.<arch>.<flavor>\.nuget\pkg\Microsoft.NETCore.Runtime.CoreCLR.<version>.nupkg
+```
+And now you wish to try it out. We will be using Windows OS as an example and thus will use \ rather
+than / for directory separators and things like Windows_NT instead of Linux but it should be
+pretty obvious how to adapt these instructions for other operating systems.
+
+To run your newly built .NET Core Runtime in addition to the application itself, you will need
+you need a 'host' program that will load the Runtime as well as all the other .NET Framework code
+that your application needs. The easiest way to get all this other stuff is to simply use the
+standard 'dotnet' host that installs with .NET Core SDK.
+
+Thus the first step is to confirm that you have the 'standard' .NET Core SDK installed. If
+you can type
+
+* dotnet -?
+
+and it prints some help text, you are ready. Otherwise
+see [Installing the .Net Core SDK](https://www.microsoft.com/net/core) to install it.
+
+### Step 1: Create a App using the Default Runtime
+At this point you can create a new 'Hello World' program in the standard way.
+
+```bat
+mkdir HelloWorld
+cd HelloWorld
+dotnet new
+```
+
+### Step 2: Get the Version number of the CoreCLR package you built.
+
+This makes a 'standard' hello world application but uses the .NET Core Runtime version that
+came with the dotnet.exe tool. First you need to modify your app to ask for the .NET Core
+you have built, and to do that, we need to know the version number of what you built. Get
+this by simply listing the name of the Microsoft.NETCore.Runtime.CoreCLR you built.
+
+```bat
+ dir bin\Product\Windows_NT.x64.Release\.nuget\pkg
+```
+
+and you will get name of the which looks something like this
+
+```
+ Microsoft.NETCore.Runtime.CoreCLR.1.2.0-beta-24528-0.nupkg
+```
+
+This gets us the version number, in the above case it is 1.2.0-beta-24528-0. We will
+use this in the next step.
+
+### Step 3: Modify the Project.json for the App to refer to your Runtime.
+
+Now Modify the HelloWorld\project.json with the following modifications
+
+1. **Remove** (or comment out) the following line from the Microsoft.NETCore.App dependency
+This tells the build system that you don't want to use runtime and libraries that came with
+the dotnet.exe tool but to fetch the dependencies from the Nuget cache. If you don't do this
+the tools will ignore your request to make the app use an explicitly specified runtime.
+```
+ "type": "platform",
+```
+2. Add the following 'runtimes' line at the top level. The runtime name includes the OS name and the architecture name
+you can find the appropriate name for your OS [here](https://github.com/dotnet/core-docs/blob/master/docs/core/rid-catalog.md).
+This tells the tools exactly which flavor of OS and processor architecture you are running on, so it can find the right
+Nuget package for the runtime.
+```
+ "runtimes": { "win7-x64": {} }
+```
+3. Add the following line to the dependencies section. This is where you need the version number
+for your build of the runtime.
+This is the line that tells the tools that you want YOUR version of the CoreCLR runtime.
+```
+ "Microsoft.NETCore.Runtime.CoreCLR": "1.2.0-beta-24528-0"
+```
+4. Be sure to make sure you have all the commas you need when you add the lines to make it valid JSON.
+
+You should end up with something that looks something like this.
+
+```javascript
+{
+ "version": "1.0.0-*",
+ "buildOptions": {
+ "debugType": "portable",
+ "emitEntryPoint": true
+ },
+ "dependencies": {},
+
+ "frameworks": {
+ "netcoreapp1.0": {
+ "dependencies": {
+ "Microsoft.NETCore.App": {
+ // REMOVED "type": "platform",
+ "version": "1.0.0"
+ },
+ "Microsoft.NETCore.Runtime.CoreCLR": "1.2.0-beta-24528-0" // NEW, including comma before
+ },
+ "imports": "dnxcore50"
+ }
+ },
+ "runtimes": { // NEW including comma before.
+ "win7-x64": {}
+ },
+}
+```
+
+### Step 4: Place your build directory on your Nuget Path
+
+You can do this by creating a file named Nuget.Config in the 'HelloWorld' directory with the following XML
+Obviously **you need to update path in the XML to be the path to output directory for your build**.
+On Windows you also have the alternative of modifying the Nuget.Config
+at %HOMEPATH%\AppData\Roaming\Nuget\Nuget.Config (~/.nuget/NuGet/NuGet.Config on Linux) with the new location.
+This will allow your new
+runtime to be used on any 'dotnet restore' run by the current user.
+Alternatively you can skip creating this file and pass the path to your package directory using
+the -s SOURCE qualifer on the dotnet restore command below. The important part is that somehow
+you have told the tools where to find your new package.
+
+```xml
+<configuration>
+ <packageRestore>
+ <add key="enabled" value="True" />
+ </packageRestore>
+ <packageSources>
+ <add key="Local CoreCLR" value="C:\Users\User\Source\Repos\coreclr-vancem\bin\Product\Windows_NT.x64.Release\.nuget\pkg" />
+ </packageSources>
+ <activePackageSource>
+ <add key="All" value="(Aggregate source)" />
+ </activePackageSource>
+</configuration>
+```
+
+### Step 5: Restore the Nuget Packages for your application
+
+This consist of simply running the command
+```
+ dotnet restore
+```
+which should find the .NET Runtime package in your build output and unpacks it to the local Nuget cache (on windows this is in %HOMEPATH%\.nuget\packages)
+
+
+### Step 6: Run your application
+
+You can run your 'HelloWorld' applications by simply executing the following in the 'HelloWorld' directory.
+
+```
+ dotnet run
+```
+This will compile and run your app. What the command is really doing is building files in helloWorld\bin\Debug\netcoreapp1.0\win7-x64\
+and the runing 'dotnet helloWorld\bin\Debug\netcoreapp1.0\win7-x64\HelloWorld.dll' to actually run the app.
+
+### Step 6: (Optional) Publish your application
+
+In Step 5 you will notice that the helloWorld\bin\Debug\netcoreapp1.0\win7-x64 does NOT actually contain your Runtime code.
+What is going on is that runtime is being loaded directly out of the local Nuget cache (on windows this is in %HOMEPATH%\.nuget\packages).
+The app can find this cache because of the HelloWorld.runtimeconfig.dev.json file which specifies that that this location shoudl be
+added to the list of places to look for dependencies.
+
+This setup fine for development time, but is not a reasonable way of allowing end users to use your new runtime. Instead what
+you want all the necessary code to be gather up so that the app is self-contained. This is what the following command does.
+```
+ dotnet publish
+```
+After running this in the 'HelloWorld' directory you will see that the following path
+
+* helloWorld\bin\Debug\netcoreapp1.0\win7-x64\publish
+
+Has all the binaries needed, including the CoreCLR.dll and System.Private.CoreLib.dll that you build locally. To
+run the application simple run the EXE that is in this publish directory (it is the name of the app, or specified
+in the project.json file). Thus at this point this directory has NO dependency outside this publication directory
+(including dotnet.exe). You can copy this publication directory to another machine and run( the exe in it and
+will 'just work'. Note that your managed app's code is still in the 'app'.dll file, the 'app'.exe file is
+actually simply a rename of dotnet.exe.
+
+### Step 7: (Optional) Confirm that the app used your new runtime
+
+Congratulations, you have successfully used your newly built runtime. To confirm that everything worked, you
+should compare the file creation timestamps for the CoreCLR.dll and System.Private.Runtime.dll in the publishing
+directory and the build output directory. They should be identical. If not, something went wrong and the
+dotnet tool picked up a different version of your runtime.
+
+### Step 8: Update BuildNumberMinor Environment Variable!
+
+One possible problem with the technique above is that Nuget assumes that distinct builds have distinct version numbers.
+Thus if you modify the source and create a new NuGet package you must it a new version number and use that in your
+application's project.json. Otherwise the dotnet.exe tool will assume that the existing version is fine and you
+won't get the updated bits. This is what the Minor Build number is all about. By default it is 0, but you can
+give it a value by setting the BuildNumberMinor environment variable.
+```bat
+ set BuildNumberMinor=3
+```
+before packaging. You should see this number show up in the version number (e.g. 1.2.0-beta-24521-03).
+
+As an alternative you can delete the existing copy of the package from the Nuget cache. For example on
+windows (on Linux substitute ~/ for %HOMEPATH%) you could delete
+```bat
+ %HOMEPATH%\.nuget\packages\Microsoft.NETCore.Runtime.CoreCLR\1.2.0-beta-24521-02
+```
+which should mke things work (but is fragile, confirm wile file timestamps that you are getting the version you expect)
+
+
+## Step 8.1 Quick updates in place.
+
+The 'dotnet publish' step in step 6 above creates a directory that has all the files necessary to run your app
+including the CoreCLR and the parts of CoreFX that were needed. You can use this fact to skip some steps if
+you wish to update the DLLs. For example typically when you update CoreCLR you end up updating one of two DLLs
+
+* Coreclr.dll - Most modifications (with the exception of the JIT compiler and tools) that are C++ code update
+ this DLL.
+* System.Private.CoreLib.dll - If you modified C# it will end up here.
+* System.Private.CoreLib.ni.dll - the native image (code) for System.Private.Corelib. If you modify C# code
+you will want to update both of these together in the target installation.
+
+Thus after making a change and building, you can simply copy the updated binary from the `bin\Product\<OS>.<arch>.<flavor>`
+directory to your publication directory (e.g. `helloWorld\bin\Debug\netcoreapp1.0\win7-x64\publish`) to quickly
+deploy your new bits.
+
+
+### Using your Runtime For Real.
+
+You can see that it is straightforward for anyone to use your runtime. They just need to modify their project.json
+and modify their NuGet search path. This is the expected way of distributing your modified runtime.
+
+--------------------------
+## Using CoreRun to run your .NET Core Application
+
+Generally using dotnet.exe tool to run your .NET Core application is the preferred mechanism to run .NET Core Apps.
+However there is a simpler 'host' for .NET Core applications called 'CoreRun' that can also be used. The value
+of this host is that it is simpler (in particular it knows nothing about NuGet), but precisely because of this
+it can be harder to use (since you are responsible for insuring all the dependencies you need are gather together)
+See [Using CoreRun To Run .NET Core Application](UsingCoreRun.md) for more.
-.NET Core Runtime (CoreCLR)
+.NET Core Common Language Runtime (CoreCLR)
===========================
-The CoreCLR repo contains the complete runtime implementation for [.NET Core](http://github.com/dotnet/core). It includes RyuJIT, the .NET GC, native interop and many other components. It is cross-platform, with multiple OS and CPU ports in progress.
+This repository contains complete source code the runtime of [.NET Core](http://dotnet.github.io).
+If you are new to .NET Core start with the [About .NET](https://docs.microsoft.com/en-us/dotnet/articles/about/)
+that quickly points you to [.NET Core Tutorials](https://docs.microsoft.com/en-us/dotnet/articles/core/getting-started)
+
+
+.NET Core is best thought of as 'agile .NET'. Generally speaking it is the same as
+the [Desktop .NET Framework](https://en.wikipedia.org/wiki/.NET_Framework)
+distributed as part of the Windows operating system, but it is a cross platform
+(Windows, Linux, OSX) and cross architecture (x86, x64, arm) subset that can be deployed
+as part of the application (if desired), and thus can be updated quickly to fix bugs or add features.
+
+## If You Just Want to Use .NET Core
+
+Most users don't need build .NET Core from source since there is already an built and tested version for any supported platform.
+You can get the latest **released** version of the .NET Core SDK by following the instructions on
+the [.NET Core Getting Started](http://dotnet.github.io/getting-started/) page.
+If you need the most up to date (daily) version of this .NET Core installer you can get it from the
+[latest Installers of .NET Core and .NET Core SDK](https://github.com/dotnet/cli#installers-and-binaries).
+
+## Are you Here for Something Besides the Source Code?
+
+In addition to providing the source code, this repository also acts as a useful nexus for things
+related to .NET Core including:
+
+ * Want to **learn more** about .NET Runtime Internals? See the [Documentation on the .NET Core Runtime](Documentation/README.md) page.
+ * Need to **log a issue** or Provide Feedback? See then [Issues and Feedback Page](Documentation/workflow/IssuesFeedbackEngagement.md) page.
+ * Want to **chat** with other members of the CoreCLR community? See the [Chat Section](Documentation/workflow/IssuesFeedbackEngagement.md#Chat-with-the-CoreCLR-community) page.
+ * Need a **current build** or **test results** of the CoreCLR repository? See the [Official and Daily Builds](Documentation/workflow/OfficalAndDailyBuilds.md) page.
+
+## What Can you Make from this Repository?
+
+.NET Core relies heavily on the [Nuget](https://en.wikipedia.org/wiki/NuGet) package manager
+which is system to package, distribute and version software components. See [https://www.nuget.org/](https://www.nuget.org/)
+for more information on Nuget. For now it is enough to know Nuget is a system that
+bundles components into `*.nupkg` files (which are ZIP archives) and these packages can be 'published'
+either through a local file system path or by a URL (e.g. https://www.nuget.org/). There are then tools
+(e.g. Nuget.exe, Visual Studio, dotnet.exe) that based on a configuration file (project.json) know
+how to search these publishing locations and pull down consistent set of packages for the
+application.
+
+In a concrete terms, this repository is best thought of as the source code for the following Nuget package
+
+ * **Microsoft.NETCore.Runtime.CoreCLR** - Represents the object allocator, garbage collector (GC), class
+ loader, type system, interop and the most fundamental parts of the .NET class library (e.g.
+ System.Object, System.String ...)
+
+It also contains the source code for the following closely related support packages.
+
+ * **Microsoft.NETCore.Jit** - The Just In Time (JIT) compiler for the
+ [.NET Intermediate language (IL)](https://en.wikipedia.org/wiki/Common_Intermediate_Language)
+ * **Microsoft.NETCore.ILAsm** - An assembler for the
+ [.NET Intermediate language (IL)](https://en.wikipedia.org/wiki/Common_Intermediate_Language)
+ * **Microsoft.NETCore.ILDAsm** - A disassembler (Pretty printer) for the
+ [.NET Intermediate language (IL)](https://en.wikipedia.org/wiki/Common_Intermediate_Language)
+ * **Microsoft.NETCore.TestHost** - This contains the corehost.exe program, which is a small wrapper
+ that uses the .NET Runtime to run IL DLLs passed to it on the command line.
+ * **Microsoft.TargetingPack.Private.CoreCLR** - A set of assemblies that represent the compile time surface
+ area of class library implemented by the runtime itself.
+
+## Relationship with the [CoreFX](https://github.com/dotnet/corefx) Repository
+
+By itself, the Microsoft.NETCore.Runtime.CoreCLR package is actually not enough to do much.
+One reason for this is that the CoreCLR package tries to minimize the amount of the class library that it implements.
+Only types that have a strong dependency on the internal workings of the runtime are included (e.g,
+System.Object, System.String System.Thread, System.Threading.Tasks.Task and most foundational interfaces).
+Instead most of the class library is implemented as independent Nuget packages that simply use the .NET Core
+runtime as a dependency. Many of the most familiar classes (System.Collections, System.IO, System.Xml and
+so on), live in packages defined in the [dotnet/corefx](https://github.com/dotnet/corefx) repository.
+
+But the main reason you can't do much with CoreCLR is that **ALL** of the types in the class library **LOOK**
+like they are defined by the CoreFX framework and not CoreCLR. Any library code defined here
+lives in a single DLL called System.Private.CoreLib.dll and as its name suggests is private (hidden).
+Instead for any particular PUBLIC type defined in CoreCLR, we found the 'right' package in CoreFX where it naturally
+belongs and use that package as its **public publishing** point. That 'facade' package then forwards references
+to the (private) implementation in System.Private.CoreLib.dll defined here.
+For example the *System.Runtime* package defined in CoreFX declares the PUBLIC name for types like
+System.Object and System.String. Thus from an applications point of view these types live in System.Runtime.dll.
+However System.Runtime.dll (defined in the CoreFX repo) forwards references ultimately to System.Private.CoreLib.dll
+which is defined here.
+
+Thus in order to run an application, you need BOTH the Microsoft.NETCore.Runtime.CoreCLR Nuget package
+(defined in this repository) as well as packages for whatever you actually references that were defined
+in the CoreFX repository (which at a minimum includes the System.Runtime package). You also need some
+sort of 'host' executable that loads the CoreCLR package as well as the CoreFX packages and starts your code (typically
+you use dotnet.exe for this).
+
+These extra pieces are not defined here, however you don't need to build them in order to use the CoreCLR
+Nuget package you create here. There are already versions of the CoreFX packages published on
+https://www.nuget.org/ so you can just have your test application's project.json specify the CoreCLR you
+built it will naturally pull anything else it needs from the official location https://www.nuget.org/ to
+make a complete application. More on this in the [Using Your Build](Documentation/workflow/UsingYourBuild.md) page.
+
+--------------------------
+## Setting up your GIT Clone of the CoreCLR Repository
+
+The first step in making a build of the CoreCLR Repository is to clone it locally. If you already know
+how to do this, just skip this section. Otherwise if you are developing on windows you can see
+[Setting Up A Git Repository In Visual Studio 2015](https://github.com/Microsoft/perfview/blob/master/documentation/SettingUpRepoInVS2015.md)
+for for instructions on setting up. This link uses a different repository as an example, but the issues (do you fork or not) and
+the procedure are equally applicable to this repository.
+
+--------------------------
+## Building the Repository
+
+The build depends on GIT, CMAKE, Python and of course a C++ compiler. Once these prerequisites are installed
+the build is simply a matter of invoking the 'Build' script (Build.cmd or build.sh) at the base of the
+repository.
+
+The details of installing the components differ depending on the operating system. See the following
+pages based on your OS. There is no cross-building across OS (only for ARM, which is built on X64).
+You have to be on the particular platform to build that platform.
+
+ * [Windows Build Instructions](Documentation/building/windows-instructions.md)
+ * [Linux Build Instructions](Documentation/building/linux-instructions.md)
+ * [OSX Build Instructions](Documentation/building/osx-instructions.md)
+ * [FreeBSD Build Instructions](Documentation/building/freebsd-instructions.md)
+ * [NetBSD Build Instructions](Documentation/building/netbsd-instructions.md)
+
+The build has two main 'buildTypes'
+
+ * Debug (default)- This compiles the runtime with additional runtime checks (asserts). These checks slow
+ runtime execution but are really valuable for debugging, and is recommended for normal development and testing.
+ * Release - This compiles without any development time runtime checks. This is what end users will use but
+ can be difficult to debug. Passing 'release' to the build script select this.
+
+In addition, by default the build will not only create the runtime executables, but it will also
+build all the tests. There are quit a few tests so this does take a significant amount of time
+that is not necessary if you are just want to experiment with changes. You can submit the building
+of the tests with the 'skiptests' argument to the build script.
+
+Thus to get a build as quickly as possible type the following (using \ as the directory separator, use / on Unix machines)
+```bat
+ .\build skiptests
+```
+which will build the Debug flavor which has development time checks (asserts), or
+```bat
+ .\build release skiptests
+```
+to build the release (full speed) flavor. You can find more build options with build by using the -? or -help qualifier.
+
+## Using Your Build
+
+The build places all of its generated files under the 'bin' directory at the base of the repository. There
+is a 'bin\Log' directory that contains log files generated during the build (Most useful when the build fails).
+The the actual output is placed in a directory like this
+
+* bin\Product\Windows_NT.x64.Release
+
+Where you can see the operating system and CPU architecture, and the build type are part of the name. While
+the 'raw' output of the build is sometimes useful, normally you are only interested in the Nuget packages
+that were built, which are placed in the directory
+
+* bin\Product\Windows_NT.x64.Release\.nuget\pkg
+
+directory. These packages are the 'output' of your build.
+
+There are two basic techniques for using your new runtime.
+
+ 1. **Use dotnet.exe and Nuget to compose an application**. See [Using Your Build](Documentation/workflow/UsingYourBuild.md) for
+ instructions on creating a program that uses
+ your new runtime by using the NuGet packages you just created and the'dotnet' command line interface. This
+ is the expected way non-runtime developers are likely to consume your new runtime.
+
+ 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. Basically it has to be told where to get all the
+ necessary DLLs you actually use, and you have to gather them together 'by hand'. 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 testsing).
+ See [Executing .NET Core Apps with CoreRun.exe](Documentation/workflow/UsingCoreRun.md) for details on using
+ this technique.
+
+## Running Tests
+
+After you have your modification basically working, and want to determine if you have broken anything it is
+time to runt tests. See [Running .NET Core Tests](Documentation/workflow/RunningTests.md) for more.
-Note that the library implementation CoreFX (System.Collections, System.IO, System.Xml and so on) lives in another repo [dotnet/corefx](https://github.com/dotnet/corefx).
+## Contributing to Repository
-Build Status
-------------
-
-| | Debug | Release |
-|---|:-----:|:-------:|
-|**CentOS 7.1**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_centos7.1)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_centos7.1)|
-|**Debian 8.4**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_debian8.4)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_debian8.4)|
-|**FreeBSD 10.1**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_freebsd)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_freebsd)|
-|**openSUSE 13.2**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_opensuse13.2)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_opensuse13.2)|
-|**openSUSE 42.1**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_opensuse42.1)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_opensuse42.1)|
-|**OS X 10.11**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_osx)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_osx)|
-|**Red Hat 7.2**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_rhel7.2)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_rhel7.2)|
-|**Fedora 23**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_fedora23)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_fedora23)|
-|**Ubuntu 14.04**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_ubuntu)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_ubuntu)|
-|**Ubuntu 16.04**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_ubuntu16.04)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_ubuntu16.04)|
-|**Ubuntu 16.10**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_ubuntu16.10)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_ubuntu16.10)|
-|**Windows 8.1**|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/debug_windows_nt)<br/>[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/arm64_cross_debug_windows_nt)|[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/release_windows_nt)<br/>[](http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/job/arm64_cross_release_windows_nt)|
-
-Building the Repo
--------------
-
-|Linux |Windows |Mac OS X |FreeBSD | NetBSD |
-|--------|--------|---------|---------|--------|
-| [Instructions](Documentation/building/linux-instructions.md) | [Instructions](Documentation/building/windows-instructions.md) | [Instructions](Documentation/building/osx-instructions.md) | [Instructions](Documentation/building/freebsd-instructions.md) | [Instructions](Documentation/building/netbsd-instructions.md) |
-
-Get .NET Core
-----------------------
-You can get the latest released .NET Core SDK from the [.NET Core Getting started](http://dotnet.github.io/getting-started/) page. You can also get the latest development builds of .NET Core and the SDK from the [dotnet/cli repo](https://github.com/dotnet/cli#installers-and-binaries).
-
-Chat Room
----------
-
-Want to chat with other members of the CoreCLR community?
-
-[](http://tattoocoder.com/aspnet-slack-sign-up/) [](https://gitter.im/dotnet/coreclr?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
-
-Learn about CoreCLR and .NET Core
----------------------------------
-
-The best ways to learn about CoreCLR are to try out the product instructions and to read the "Book of the Runtime" architecture documents that describe the inner workings of the product. New devs to the CLR team are encouraged to read these documents before making substative changes to the product. They are equally useful for open source contributors.
-
-- [.NET Core Roadmap](https://github.com/dotnet/core/blob/master/roadmap.md)
-- [Product instructions](Documentation/README.md)
-- [Introduction to the Common Language Runtime](Documentation/botr/intro-to-clr.md)
-- [Book of the Runtime](Documentation/README.md#book-of-the-runtime)
-- [CoreCLR Documents](Documentation)
-
-.NET Core is part of ASP.NET Core and is a subset of the .NET Framework. You can learn more about .NET Core and how and where you can use it in the [CoreCLR is open source][coreclr blog post] blog post.
-
-The [.NET Core Libraries][corefx] repo contains the base class libraries, which provides data types and base functionality (ex: String, Collections, HttpClient) on top of CoreCLR. The two repos together make up .NET Core. The [.NET Core is Open Source][.NET Core oss] and [Introducing .NET Core][Introducing .NET Core] blog posts describes our .NET Core OSS strategy and road map in more detail.
-
-Engage, Contribute and Provide Feedback
----------------------------------------
-
-Some of the best ways to contribute are to try things out, file bugs, and join in design conversations. You are encouraged to start a discussion by filing an issue, or starting a thread in the [.NET Foundation forums](http://forums.dotnetfoundation.org/). If you are having issues with the Full .NET Framework or .NET Runtime the best ways to file a bug are at [Connect](http://connect.microsoft.com/VisualStudio) or through [Product Support](https://support.microsoft.com/en-us/contactus?ws=support) if you have a contract.
-
-Looking for something to work on? The list of [up-for-grabs issues](https://github.com/dotnet/coreclr/issues?q=is%3Aopen+is%3Aissue+label%3Aup-for-grabs) is a great place to start.
+Looking for something to work on? The list
+of [up-for-grabs issues](https://github.com/dotnet/coreclr/issues?q=is%3Aopen+is%3Aissue+label%3Aup-for-grabs) is a great place to start.
Please read the following documents to get started.
* [Contributing Guide](Documentation/project-docs/contributing.md)
* [Developer Guide](Documentation/project-docs/developer-guide.md)
-This project has adopted the code of conduct defined by the [Contributor Covenant](http://contributor-covenant.org/) to clarify expected behavior in our community. For more information, see the [.NET Foundation Code of Conduct](http://www.dotnetfoundation.org/code-of-conduct).
-
-### Reporting security issues and security bugs
+This project has adopted the code of conduct defined by the [Contributor Covenant](http://contributor-covenant.org/)
+to clarify expected behavior in our community. For more information, see the [.NET Foundation Code of Conduct](http://www.dotnetfoundation.org/code-of-conduct).
-Security issues and bugs should be reported privately, via email, to the
-Microsoft Security Response Center (MSRC) <secure@microsoft.com>. You should
-receive a response within 24 hours. If for some reason you do not, please follow
-up via email to ensure we received your original message. Further information,
-including the MSRC PGP key, can be found in the
-[Security TechCenter](https://technet.microsoft.com/en-us/security/ff852094.aspx).
+-------------------
+## Related Projects
-License
--------
+As noted above, the CoreCLR Repository does not contain all the source code that makes up the .NET Core distribution.
+Here is a list of the other repositories that complete the picture.
-.NET Core (including the coreclr repo) is licensed under the [MIT license](LICENSE.TXT).
+* [dotnet/corefx](https://github.com/dotnet/corefx) - Source for the most common classes in the .NET Framework library.
+* [dotnet/core-setup](https://github.com/dotnet/core-setup) - Source code for the dotnet.exe program and the policy logic
+to launch basic .NET Core code (hostfxr, hostpolicy) which allow you to say 'dotnet SOME_CORE_CLR_DLL' to run the app.
+* [dotnet/cli repo](https://github.com/dotnet/cli) - Source for build time actions supported by dotnet.exe Command line Interface (CLI).
+Thus this is the code that runs when you do 'dotnet build', 'dotnet restore' or 'dotnet publish'.
+* [dotnet/core-docs](https://github.com/dotnet/core-docs) - Master copy of documentation for
+[http://docs.microsoft.com/en-us/dotnet/](https://docs.microsoft.com/en-us/dotnet/)
-.NET Foundation
----------------
+## See Also
-.NET Core is a [.NET Foundation](http://www.dotnetfoundation.org/projects) project.
+* [Dotnet.github.io](http://dotnet.github.io) is a good place to discover .NET Foundation projects.
+* .NET Core is a [.NET Foundation](http://www.dotnetfoundation.org/projects) project.
+* [.NET home repo](https://github.com/Microsoft/dotnet) links to 100s of .NET projects, from Microsoft and the community.
+* The [.NET Core repo](https://github.com/dotnet/core) links to .NET Core related projects from Microsoft.
+* The [ASP.NET home repo](https://github.com/aspnet/home) is the best place to start learning about ASP.NET Core.
-Related Projects
-----------------
+## Important Blog Entries
-There are many .NET projects on GitHub.
+* [Announcement of .NET Core Open Source Project](http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx)
+* [Introducing .NET Core](http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx)
+* [Announcement of CoreCLR](http://blogs.msdn.com/b/dotnet/archive/2015/02/03/coreclr-is-now-open-source.aspx)
-- The
-[.NET home repo](https://github.com/Microsoft/dotnet) links to 100s of .NET projects, from Microsoft and the community.
-- The [.NET Core repo](https://github.com/dotnet/core) links to .NET Core related projects from Microsoft.
-- The [ASP.NET home repo](https://github.com/aspnet/home) is the best place to start learning about ASP.NET Core.
-- [dotnet.github.io](http://dotnet.github.io) is a good place to discover .NET Foundation projects.
+## License
-[.NET Core oss]: http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx
-[Introducing .NET Core]: http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx
-[coreclr blog post]: http://blogs.msdn.com/b/dotnet/archive/2015/02/03/coreclr-is-now-open-source.aspx
-[corefx]: http://github.com/dotnet/corefx
-[coreclr]: http://github.com/dotnet/coreclr
+.NET Core (including the coreclr repo) is licensed under the [MIT license](LICENSE.TXT).
projects / platform / upstream / coreclr.git / commitdiff