summaryrefslogtreecommitdiff
path: root/README.md
diff options
context:
space:
mode:
authorDerek Beattie <derek.beattie@gmail.com>2016-12-10 00:17:15 -0600
committerDan Moseley <danmose@microsoft.com>2016-12-09 22:17:15 -0800
commitff38a7fb7530557499a94db6d1183f8c753e6376 (patch)
tree9f6f24d89811a1f21eaca19d744e5010416d68b3 /README.md
parent526a81a8e764738f79c38528f638122cee0e3ead (diff)
downloadcoreclr-ff38a7fb7530557499a94db6d1183f8c753e6376.tar.gz
coreclr-ff38a7fb7530557499a94db6d1183f8c753e6376.tar.bz2
coreclr-ff38a7fb7530557499a94db6d1183f8c753e6376.zip
Fix typos and grammer in coreclr README.md (#8561)
* Fix typeos and grammer in README.md * Fix a small grammar issue and remove a comma
Diffstat (limited to 'README.md')
-rw-r--r--README.md22
1 files changed, 11 insertions, 11 deletions
diff --git a/README.md b/README.md
index e6b496dd15..98dcb1abad 100644
--- a/README.md
+++ b/README.md
@@ -33,8 +33,8 @@ 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
@@ -42,7 +42,7 @@ either through a local file system path or by a URL (e.g. https://www.nuget.org/
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.