README.md link and grammar fixes

Fixing various typos, grammar mistakes, and broken links in the root README.md file.

2 files changed, 9 insertions, 9 deletions

diff --git a/Documentation/botr/intro-to-clr.md b/Documentation/botr/intro-to-clr.md
index 3ba3d3b81e..2e5b8de0a2 100644
--- a/Documentation/botr/intro-to-clr.md
+++ b/Documentation/botr/intro-to-clr.md
@@ -47,7 +47,7 @@ The second reason this goal is so important is that **ease of use is the fundame
 3. Strong consistency in the naming in the class library (e.g., requiring APIs to use whole words and consistent naming conventions)
 4. Great support in the tool chain needed to create an application (e.g., Visual Studio makes building CLR applications very simple, and Intellisense makes finding the right types and methods to create the application very easy).
 
-It is this dedication to ease of use (which goes hand in hand with simplicity of the user model) that stands out as the reason for the success of the CLR.  Oddly, some of the most important ease-of-use features are also the most "boring." For example, any programming environment could apply consistent naming conventions, yet actually doing so across a large class library is quite a lot of work.  Often such efforts conflict with other goals (such as retaining compatibility with existing interfaces), or they run into significant logistical concerns (such as the cost of renaming a method across a _very_ large code base).  It is at times like these that we have to remind ourselves about our number-one overarching goal of the runtime and ensure that we are have our priorities straight to reach that goal.
+It is this dedication to ease of use (which goes hand in hand with simplicity of the user model) that stands out as the reason for the success of the CLR.  Oddly, some of the most important ease-of-use features are also the most "boring." For example, any programming environment could apply consistent naming conventions, yet actually doing so across a large class library is quite a lot of work.  Often such efforts conflict with other goals (such as retaining compatibility with existing interfaces), or they run into significant logistical concerns (such as the cost of renaming a method across a _very_ large code base).  It is at times like these that we have to remind ourselves about our number-one overarching goal of the runtime and ensure that we have our priorities straight to reach that goal.
 
 # Fundamental Features of the CLR
 
diff --git a/README.md b/README.md
index abd081a867..902e6c851a 100644
--- a/README.md
+++ b/README.md
@@ -14,7 +14,7 @@ as part of the application (if desired), and thus can be updated quickly to fix
 
 ## If You Just Want to Use .NET Core
 
-Most users don't need to build .NET Core from source since there is already an built and tested version for any supported platform.
+Most users don't need to build .NET Core from source since there is already a 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
@@ -99,7 +99,7 @@ make a complete application.  More on this in the [Using Your Build](Documentati
 
 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)
+[Setting Up A Git Repository In Visual Studio 2017](https://github.com/Microsoft/perfview/blob/master/documentation/SettingUpRepoInVS.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.  
 
@@ -125,12 +125,12 @@ 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.  
+   can be difficult to debug.   Pass 'release' to the build script to 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 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.
+that is not necessary if you want to experiment with changes.   You can skip building
+the tests by passing 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
@@ -162,14 +162,14 @@ 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
+ 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 
+ See [Using corerun To Run .NET Core Application](Documentation/workflow/UsingCoreRun.md) for details on using 
  this technique.  
 
 ## Editing and Debugging
@@ -184,7 +184,7 @@ make modifications and debug any issues those modifications might cause.   See t
 ## 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. 
+time to run tests.  See [Running .NET Core Tests](Documentation/workflow/RunningTests.md) for more. 
 
 ## Contributing to Repository