Corrected Typos and grammar (#20658)

* Corrected some typos and grammar as per English language guidelines.

* Reverted some of the changes

* Reverted back some changes Phase 2

10 files changed, 70 insertions, 73 deletions

diff --git a/Documentation/building/cross-building.md b/Documentation/building/cross-building.md
index d0047f90af..8554f731a5 100644
--- a/Documentation/building/cross-building.md
+++ b/Documentation/building/cross-building.md
@@ -24,7 +24,7 @@ Through cross compilation, on Linux it is possible to build CoreCLR for arm or a
 Requirements for targetting Debian based distros
 ------------------------------------------------
 
-You need a Debian based host and the following packages needs to be installed:
+You need a Debian based host and the following packages need to be installed:
 
     ben@ubuntu ~/git/coreclr/ $ sudo apt-get install qemu qemu-user-static binfmt-support debootstrap
 
@@ -55,7 +55,7 @@ To build them, use the following steps:
 
 Generating the rootfs
 ---------------------
-The `cross\build-rootfs.sh` script can be used to download the files needed for cross compilation. It will generate an rootfs as this is what CoreCLR targets.
+The `cross\build-rootfs.sh` script can be used to download the files needed for cross compilation. It will generate a rootfs as this is what CoreCLR targets.
 
     Usage: ./cross/build-rootfs.sh [BuildArch] [LinuxCodeName] [lldbx.y] [--skipunmount]
     BuildArch can be: arm(default), armel, arm64, x86
@@ -68,7 +68,7 @@ For example, to generate an arm rootfs:
 
     ben@ubuntu ~/git/coreclr/ $ sudo ./cross/build-rootfs.sh arm
 
-You can choose Linux code name to match your target, give `vivid` for `Ubuntu 15.04`, `wily` for `Ubuntu 15.10`. Default is `trusty`, version `Ubuntu 14.04`.
+You can choose Linux code name to match your target, give `vivid` for `Ubuntu 15.04`, `wily` for `Ubuntu 15.10`. The default is `trusty`, version `Ubuntu 14.04`.
 
     ben@ubuntu ~/git/coreclr/ $ sudo ./cross/build-rootfs.sh arm wily
 
@@ -80,7 +80,7 @@ For example, to generate an armel rootfs:
 
     hqu@ubuntu ~/git/coreclr/ $ sudo ./cross/build-rootfs.sh armel
 
-You can choose code name to match your target, give `jessie` for `Debian`, `tizen` for `Tizen`. Default is `jessie`.
+You can choose code name to match your target, give `jessie` for `Debian`, `tizen` for `Tizen`. The default is `jessie`.
 
     hque@ubuntu ~/git/coreclr/ $ sudo ./cross/build-rootfs.sh armel tizen
 
@@ -101,7 +101,7 @@ And with:
 
     ben@ubuntu ~/git/coreclr/ $ ROOTFS_DIR=/home/ben/coreclr-cross/arm ./build.sh arm debug verbose cross
 
-As usual the resulting binaries will be found in `bin/Product/BuildOS.BuildArch.BuildType/`
+As usual, the resulting binaries will be found in `bin/Product/BuildOS.BuildArch.BuildType/`
 
 
 Compiling System.Private.CoreLib for ARM Linux
diff --git a/Documentation/building/crossgen.md b/Documentation/building/crossgen.md
index cc825b4dde..256b72e1fc 100644
--- a/Documentation/building/crossgen.md
+++ b/Documentation/building/crossgen.md
@@ -7,14 +7,14 @@ Introduction
 When you create a .NET assembly using C# compiler, your assembly contains only MSIL code.
 When the app runs, the JIT compiler translates the MSIL code into native code, before the CPU can execute them.
 This execution model has some advantages. For example, your assembly code can be portable across all platforms and architectures that support .NET Core.
-However, this portability comes with a performance cost. Your app starts up more slowly, because the JIT compiler has to spend time to translate the code.
+However, this portability comes with a performance cost. Your app starts up more slowly because the JIT compiler has to spend time to translate the code.
 
 To help make your app start up faster, CoreCLR includes a tool called CrossGen, which can pre-compile the MSIL code into native code.
 
 Getting CrossGen
 ----------------
 
-If you build CoreCLR yourself, the CrossGen tool (`crossgen.exe` on Windows, or `crossgen` on other platforms) is created as part of the build, and stored in the same output directory as other CoreCLR binaries.
+If you build CoreCLR yourself, the CrossGen tool (`crossgen.exe` on Windows, or `crossgen` on other platforms) is created as part of the build and stored in the same output directory as other CoreCLR binaries.
 If you install CoreCLR using a NuGet package, you can find CrossGen in the `tools` folder of the NuGet package.
 
 Regardless of how you obtain CrossGen, it is very important that it must match other CoreCLR binaries.
@@ -55,8 +55,8 @@ Using native images
 -------------------
 
 Running CrossGen on an assembly creates a "native image" file, with the extension of `.ni.dll` or `.ni.exe`.
-You should include the native images in your app, either by replacing the original MSIL assemblies with the native images, or by putting the native images next to the MSIL assemblies.
-When the native images are present, CoreCLR runtime will automatically use it instead of the original MSIL assemblies.
+You should include the native images in your app, either by replacing the original MSIL assemblies with the native images or by putting the native images next to the MSIL assemblies.
+When the native images are present, the CoreCLR runtime will automatically use it instead of the original MSIL assemblies.
 
 Common errors
 -------------
@@ -64,4 +64,4 @@ Common errors
 The following are some of the command errors while creating or using native images:
 - "Error: Could not load file or assembly '...' or one of its dependencies. The system cannot find the file specified. (Exception from HRESULT: 0x80070002)": CrossGen wasn't able to find a particular dependency that it needs. Verify that you have the assembly specified in the error message, and make sure its location is included in `/Platform_Assemblies_Paths`.
 - CoreCLR unable to initialize: While there are many possible causes of this error, one possibility is a mismatch between System.Private.CoreLib.ni.dll and coreclr.dll (or libcoreclr.so). Make sure they come from the same build or NuGet package.
-- "Unable to load Jit Compiler": Please get a copy of `clrjit.dll` (or `libclrjit.so` or `libclrjit.dylib`, depending on your platform), and place it in the same directory as CrossGen (or use /JITPath option). You can either build `clrjit.dll` yourself, or get it from `Microsoft.NETCore.Jit` NuGet package. To avoid possible issues, please use `clrjit.dll` from the same build as `crossgen.exe` if possible.
+- "Unable to load Jit Compiler": Please get a copy of `clrjit.dll` (or `libclrjit.so` or `libclrjit.dylib`, depending on your platform), and place it in the same directory as CrossGen (or use /JITPath option). You can either build `clrjit.dll` yourself or get it from `Microsoft.NETCore.Jit` NuGet package. To avoid possible issues, please use `clrjit.dll` from the same build as `crossgen.exe` if possible.
diff --git a/Documentation/building/debugging-instructions.md b/Documentation/building/debugging-instructions.md
index 6f5074ad05..a2b67ceb33 100644
--- a/Documentation/building/debugging-instructions.md
+++ b/Documentation/building/debugging-instructions.md
@@ -9,16 +9,16 @@ Debugging CoreCLR on Windows
 1. Perform a build of the repo.
 2. Open solution \<reporoot\>\bin\obj\Windows_NT.\<platform\>.\<configuration\>\CoreCLR.sln in Visual Studio. \<platform\> and \<configuration\> are based
     on type of build you did. By default they are 'x64' and 'Debug'.
-3. Right click the INSTALL project and choose ‘Set as StartUp Project’
+3. Right-click the INSTALL project and choose ‘Set as StartUp Project’
 4. Bring up the properties page for the INSTALL project
 5. Select Configuration Properties->Debugging from the left side tree control
 6. Set Command=`$(SolutionDir)..\..\product\Windows_NT.$(Platform).$(Configuration)\corerun.exe`
-	1. This points to the folder where the built runtime binaries are present.
+    1. This points to the folder where the built runtime binaries are present.
 7. Set Command Arguments=`<managed app you wish to run>` (e.g. HelloWorld.exe)
 8. Set Working Directory=`$(SolutionDir)..\..\product\Windows_NT.$(Platform).$(Configuration)`
-	1. This points to the folder containing CoreCLR binaries.
+    1. This points to the folder containing CoreCLR binaries.
 9. Press F11 to start debugging at wmain in corerun (or set a breakpoint in source and press F5 to run to it)
-	1. As an example, set a breakpoint for the EEStartup function in ceemain.cpp to break into CoreCLR startup.
+    1. As an example, set a breakpoint for the EEStartup function in ceemain.cpp to break into CoreCLR startup.
 
 Steps 1-8 only need to be done once, and then (9) can be repeated whenever you want to start debugging. The above can be done with Visual Studio 2013.
 
@@ -56,38 +56,38 @@ For .NET Core version 1.x and 2.0.x, libsosplugin.so is built for and will only
 
 ### SOS commands ###
 
-This is the full list of commands currently supported by SOS. lldb is case-sensitive unlike windbg.
-
-	Type "soshelp <functionname>" for detailed info on that function.
-
-	Object Inspection                  Examining code and stacks
-	-----------------------------      -----------------------------
-	DumpObj (dumpobj)                  Threads (clrthreads)
-	DumpArray                          ThreadState
-	DumpStackObjects (dso)             IP2MD (ip2md)
-	DumpHeap (dumpheap)                u (clru)
-	DumpVC                             DumpStack (dumpstack)
-	GCRoot (gcroot)                    EEStack (eestack)
-	PrintException (pe)                ClrStack (clrstack)
-	                                   GCInfo
-	                                   EHInfo
-	                                   bpmd (bpmd)
-
-	Examining CLR data structures      Diagnostic Utilities
-	-----------------------------      -----------------------------
-	DumpDomain                         VerifyHeap
-	EEHeap (eeheap)                    FindAppDomain
-	Name2EE (name2ee)                  DumpLog (dumplog)
-	DumpMT (dumpmt)                    CreateDump (createdump)
-	DumpClass (dumpclass)
-	DumpMD (dumpmd)
-	Token2EE
-	DumpModule (dumpmodule)
-	DumpAssembly
-	DumpRuntimeTypes
-	DumpIL (dumpil)
-	DumpSig
-	DumpSigElem
+This is the full list of commands currently supported by SOS. lldb is case-sensitive, unlike windbg.
+
+    Type "soshelp <functionname>" for detailed info on that function.
+
+    Object Inspection                  Examining code and stacks
+    -----------------------------      -----------------------------
+    DumpObj (dumpobj)                  Threads (clrthreads)
+    DumpArray                          ThreadState
+    DumpStackObjects (dso)             IP2MD (ip2md)
+    DumpHeap (dumpheap)                u (clru)
+    DumpVC                             DumpStack (dumpstack)
+    GCRoot (gcroot)                    EEStack (eestack)
+    PrintException (pe)                ClrStack (clrstack)
+                                       GCInfo
+                                       EHInfo
+                                       bpmd (bpmd)
+
+    Examining CLR data structures      Diagnostic Utilities
+    -----------------------------      -----------------------------
+    DumpDomain                         VerifyHeap
+    EEHeap (eeheap)                    FindAppDomain
+    Name2EE (name2ee)                  DumpLog (dumplog)
+    DumpMT (dumpmt)                    CreateDump (createdump)
+    DumpClass (dumpclass)
+    DumpMD (dumpmd)
+    Token2EE
+    DumpModule (dumpmodule)
+    DumpAssembly
+    DumpRuntimeTypes
+    DumpIL (dumpil)
+    DumpSig
+    DumpSigElem
 
     Examining the GC history           Other
     -----------------------------      -----------------------------
@@ -107,7 +107,7 @@ However the common commands have been aliased so that you don't need the SOS pre
     clrthreads      -> sos Threads
     clru            -> sos U
     createdump      -> sos CreateDump
-	dso             -> sos DumpStackObjects
+    dso             -> sos DumpStackObjects
     dumpclass       -> sos DumpClass
     dumpheap        -> sos DumpHeap
     dumpil          -> sos DumpIL
@@ -135,7 +135,7 @@ However the common commands have been aliased so that you don't need the SOS pre
 It is also possible to debug .NET Core crash dumps using lldb and SOS. In order to do this, you need all of the following:
 
 - The crash dump file. We have a service called "Dumpling" which collects, uploads, and archives crash dump files during all of our CI jobs and official builds.
-- On Linux, there is an utility called `createdump` (see [doc](https://github.com/dotnet/coreclr/blob/master/Documentation/botr/xplat-minidump-generation.md#configurationpolicy)) that can be setup to generate core dumps when a managed app throws an unhandled exception or faults.
+- On Linux, there is a utility called `createdump` (see [doc](https://github.com/dotnet/coreclr/blob/master/Documentation/botr/xplat-minidump-generation.md#configurationpolicy)) that can be setup to generate core dumps when a managed app throws an unhandled exception or faults.
 - To get matching runtime and symbol binaries for the core dump use the symbol downloader CLI extension:
   - Install the [.NET Core 2.1 SDK](https://www.microsoft.com/net/download/).
   - Install the symbol downloader extension: `dotnet tool install -g dotnet-symbol`. Make sure you are not in any project directory with a NuGet.Config that doesn't include nuget.org as a source. 
@@ -161,7 +161,7 @@ lldb-3.9 -O "settings set target.exec-search-paths <runtime-path>" -o "plugin lo
 - `<host-path>`: The path to the dotnet or corerun executable, potentially in the `<runtime-path>` folder.
 - `<path-to-libsosplugin.so>`: The path to libsosplugin.so, should be in the `<runtime-path>` folder.
 
-lldb should start debugging successfully at this point. You should see stacktraces with resolved symbols for libcoreclr.so. At this point, you can run `plugin load <libsosplugin.so-path>`, and begin using SOS commands, as above.
+lldb should start debugging successfully at this point. You should see stack traces with resolved symbols for libcoreclr.so. At this point, you can run `plugin load <libsosplugin.so-path>`, and begin using SOS commands, as above.
 
 ##### Example
 
diff --git a/Documentation/building/freebsd-instructions.md b/Documentation/building/freebsd-instructions.md
index 9d29a930cb..cce1537f4e 100644
--- a/Documentation/building/freebsd-instructions.md
+++ b/Documentation/building/freebsd-instructions.md
@@ -239,7 +239,7 @@ If all works, you should be greeted by a friendly daemon you know well.
 
 Over time, this process will get easier. We will remove the dependency on having to compile managed code on Windows. For example, we are working to get our NuGet packages to include both the Windows and FreeBSD versions of an assembly, so you can simply nuget restore the dependencies. 
 
-A sample that builds Hello World on FreeBSD using the correct references but via XBuild or MonoDevelop would be great! Some of our processes (e.g. the System.Private.CoreLib build) rely on Windows specific tools, but we want to figure out how to solve these problems for FreeBSD as well. There's still a lot of work ahead, so if you're interested in helping, we're ready for you!
+A sample that builds Hello World on FreeBSD using the correct references but via XBuild or MonoDevelop would be great! Some of our processes (e.g. the System.Private.CoreLib build) rely on Windows-specific tools, but we want to figure out how to solve these problems for FreeBSD as well. There's still a lot of work ahead, so if you're interested in helping, we're ready for you!
 
 
 Run the test suite
@@ -279,7 +279,7 @@ llvm37 and llvm-devel include clang and lldb. Since clang is included with llvm
 
 After you have installed your desired version of LLVM you will need to specify the version to the build.sh script.
 
-For example if you chose to install llvm37 you would add the clangX.X to your build command as follows.
+For example, if you chose to install llvm37 you would add the clangX.X to your build command as follows.
 ```sh
 janhenke@freebsd-frankfurt:~/git/coreclr % ./build.sh clang3.7
 ```
diff --git a/Documentation/building/linux-instructions.md b/Documentation/building/linux-instructions.md
index 86713c198f..7696d37687 100644
--- a/Documentation/building/linux-instructions.md
+++ b/Documentation/building/linux-instructions.md
@@ -132,7 +132,7 @@ The current Docker tag being used by the CI can be found in the `getDockerImageN
 
 Libunwind issue
 ---------------
-ARM libunwind versions before 1.3 require a fix. The fix allows libunwind not to break when it is ordered to access unaccessible memory locations. See [this](https://github.com/dotnet/coreclr/pull/3923) issue for history.
+ARM libunwind versions before 1.3 require a fix. The fix allows libunwind not to break when it is ordered to access inaccessible memory locations. See [this](https://github.com/dotnet/coreclr/pull/3923) issue for history.
 
 If required, first import the patch from the libunwind upstream: http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=commit;h=770152268807e460184b4152e23aba9c86601090.
 
@@ -216,4 +216,3 @@ If you want to focus on the speed optimization for high-end devices, you have to
 
  SET (CLR_DEFINES_DEBUG_INIT              DEBUG _DEBUG _DBG URTBLDENV_FRIENDLY=Checked BUILDENV_
 ```
-
diff --git a/Documentation/building/test-configuration.md b/Documentation/building/test-configuration.md
index d799bfdaad..b3bb6d5d7d 100644
--- a/Documentation/building/test-configuration.md
+++ b/Documentation/building/test-configuration.md
@@ -38,7 +38,7 @@ Test cases are categorized by priority level. The most important subset should b
         // See the LICENSE file in the project root for more information.
     ```
 * Disable building of a test by conditionally setting the `<DisableProjectBuild>` property.
-	* e.g. `<DisableProjectBuild Condition=" '$(Platform)' == 'arm64' ">true</DisableProjectBuild>`
+    * e.g. `<DisableProjectBuild Condition=" '$(Platform)' == 'arm64' ">true</DisableProjectBuild>`
 * Exclude test from GCStress runs by adding the following to the csproj:
     * `<GCStressIncompatible>true</GCStressIncompatible>`
 * Exclude test from JIT stress runs runs by adding the following to the csproj:
@@ -59,7 +59,7 @@ Test cases are categorized by priority level. The most important subset should b
     * Not removing this can cause confusion with the way tests are generally handled behind the scenes by the build system.
 
 1. Set the `<CLRTestKind>`/`<CLRTestPriority>` properties.
-1. Add source files to new project.
+1. Add source files to the new project.
 1. Indicate the success of the test by returning `100`. Failure can be indicated by any non-`100` value.
 
     Example:
diff --git a/Documentation/building/testing-with-corefx.md b/Documentation/building/testing-with-corefx.md
index 4f1a6981ba..14c067dee3 100644
--- a/Documentation/building/testing-with-corefx.md
+++ b/Documentation/building/testing-with-corefx.md
@@ -133,4 +133,4 @@ The tests defined in TopN.Windows.CoreFX.issues.json or the test list specified
             ]
         }
     }
-```
\ No newline at end of file
+```
diff --git a/Documentation/building/unix-test-instructions.md b/Documentation/building/unix-test-instructions.md
index 9b0190c4a0..0bf3ab5894 100644
--- a/Documentation/building/unix-test-instructions.md
+++ b/Documentation/building/unix-test-instructions.md
@@ -40,7 +40,7 @@ Or
 
 For machines that have aarch64/armhf support, all the armhf packages will need to also be downloaded. Please note you will need to enable multiplatform support as well. Check with your distro provider or kernel options to see if this is supported. For simplicity, these instructions relate to aarch64 ubuntu enabling arm32 (hf) coreclr runs.
 
-Please make sure your device is running a 64 bit aarch64 kernel.
+Please make sure your device is running a 64-bit aarch64 kernel.
 
 ```
 # Example output
@@ -58,7 +58,7 @@ Linux tegra-ubuntu 4.4.38-tegra #1 SMP PREEMPT Thu Jul 20 00:41:06 PDT 2017 aarc
 [ubuntu:~]: sudo apt-get install libstdc++6:armhf
 ````
 
-At this point you should be able to run a 32-bit `corerun`. You can verify this by downloading and running a recently built arm32 coreclr.
+At this point, you should be able to run a 32-bit `corerun`. You can verify this by downloading and running a recently built arm32 coreclr.
 
 ```
 [ubuntu:~]: wget https://ci.dot.net/job/dotnet_coreclr/job/master/job/armlb_cross_checked_ubuntu/lastSuccessfulBuild/artifact/*zip*/archive.zip --no-check-certificate
@@ -113,7 +113,7 @@ In addition:
 <DisableProjectBuild Condition="'$(TargetsUnix)' == 'true'">true</DisableProjectBuild>
 ```
 
-Is used to disable the build, that way if building on unix cycles are saved building/running.
+Is used to disable the build, that way if building on Unix cycles are saved building/running.
 
 PAL tests
 ---------
diff --git a/Documentation/building/windows-instructions.md b/Documentation/building/windows-instructions.md
index 5d1cb1684c..cfd6293e3b 100644
--- a/Documentation/building/windows-instructions.md
+++ b/Documentation/building/windows-instructions.md
@@ -92,24 +92,22 @@ Powershell version must be 3.0 or higher. This should be the case for Windows 8
 - Windows 7 SP1 can install Powershell version 4 [here](https://www.microsoft.com/en-us/download/details.aspx?id=40855).
 
 ## DotNet Core SDK
-While not strictly needed to build or test 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 
+While not strictly needed to build or test 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](../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.  
 
 ## Adding to the default PATH variable
 
-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.  
+The commands above need to be on your command lookup path.   Some installers will automatically add them to the path as part of the installation, but if not here is how you can do it.  
 
-You can of course add a directory to the PATH environment variable with the syntax
+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
+However, the change above will only last until the command windows close.   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).
+to change it for the current user).  Simply edit the PATH variable's value and add the directory (with a semicolon separator).
 
 -------------------------------------
 # Building
@@ -120,19 +118,19 @@ the base of the repository.
 ```bat
     .\build 
 
-	[Lots of build spew]
+    [Lots of build spew]
 
-	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
+    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
 ```
 
-As shown above the product will be placed in 
+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
 
-By default build generates a 'Debug' build type, that has extra checking (assert) compiled into it. You can
+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
 
 The build places logs in `bin\Logs` and these are useful when the build fails.
@@ -140,7 +138,7 @@ The build places logs in `bin\Logs` and these are useful when the build fails.
 The build places all of its output in the `bin` directory, so if you remove that directory you can force a 
 full rebuild.    
 
-Build has a number of options that you can learn about using build -?.   Some of the more important options are
+The build has a number of options that you can learn about using build -?.   Some of the more important options are
 
  * -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.
diff --git a/Documentation/building/windows-test-instructions.md b/Documentation/building/windows-test-instructions.md
index de422ed571..d6f506d1c6 100644
--- a/Documentation/building/windows-test-instructions.md
+++ b/Documentation/building/windows-test-instructions.md
@@ -35,7 +35,7 @@ To run a clean, priority 1, crossgen test pass:
 
 ### Building Individual Tests
 
-Note: build-test.cmd or build.cmd skipnative needs to be run atleast once
+Note: build-test.cmd or build.cmd skipnative needs to be run at least once
 
 * Native Test: Build the generated Visual Studio solution or make file corresponding to Test cmake file.