|
|
@@ -33,16 +33,16 @@ related to .NET Core including: |
|
|
|
|
|
## 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/)
|
|
|
+.NET Core relies heavily on the [Nuget](https://en.wikipedia.org/wiki/NuGet) package manager,
|
|
|
+which is a 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
|
|
|
+In 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.
|
|
|
@@ -59,7 +59,7 @@ It also contains the source code for the following closely related support packa |
|
|
* **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.
|
|
|
+ area of the class library implemented by the runtime itself.
|
|
|
|
|
|
## Relationship with the [CoreFX](https://github.com/dotnet/corefx) Repository
|
|
|
|
|
|
@@ -79,19 +79,19 @@ belongs and use that package as its **public publishing** point. That 'facade' |
|
|
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
|
|
|
+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
|
|
|
+(defined in this repository) as well as packages for whatever you actually reference 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
|
|
|
+https://www.nuget.org/ so you can have your test application's project.json specify the CoreCLR you
|
|
|
+built and 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.
|
|
|
|
|
|
--------------------------
|
|
|
@@ -128,8 +128,8 @@ The build has two main 'buildTypes' |
|
|
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
|
|
|
+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.
|
|
|
|
|
|
Thus to get a build as quickly as possible type the following (using \ as the directory separator, use / on Unix machines)
|
|
|
@@ -156,7 +156,7 @@ 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.
|
|
|
+These packages are the 'output' of your build.
|
|
|
|
|
|
There are two basic techniques for using your new runtime.
|
|
|
|
|
|
|
dbeattie71
committed
with danmosemsft
0 comments on commit
ff38a7f