Preview 3 edits

docs/core/preview3/deploying/index.md

@@ -118,7 +118,7 @@ Deploying a framework-dependent deployment with one or more third-party dependen
       </ItemGroup>
     ```
 
-Note that the SDK dependency remains in the above example. This is by design, since this depdendency is required to restore all the needed targets to allow the command line tools to function.  
+ Note that the SDK dependency remains in the above example. This is by design, since this depdendency is required to restore all the needed targets to allow the command line tools to function.  
 
 2. If you haven't already, download the NuGet package containing the third-party dependency. To download the package, execute the `dotnet restore` command after adding the dependency. Because the dependency is resolved out of the local NuGet cache at publish time, it must be available on your system.
 
@@ -186,7 +186,7 @@ Deploying a self-contained deployment with no third-party dependencies involves
     }
     ```
 
-3. Create a `<RuntimeIdentifiers>` tag under the `<PropertyGroup>` section in your `csproj` file that defines the platforms your app targets, and specify the runtime identifier of each platform that you target. See [Runtime IDentifier catalog](../../rid-catalog.md) for a list of runtime identifiers. For example, the following `runtimes` section indicates that the app runs on 64-bit Windows 10 operating systems and the 64-bit OS X Version 10.11 operating system.
+3. Create a `<RuntimeIdentifiers>` tag under the `<PropertyGroup>` section in your `csproj` file that defines the platforms your app targets, and specify the runtime identifier of each platform that you target. See [Runtime IDentifier catalog](../../rid-catalog.md) for a list of runtime identifiers. For example, the following example indicates that the app runs on 64-bit Windows 10 operating systems and the 64-bit OS X Version 10.11 operating system.
 
     ```xml
         <PropertyGroup>
@@ -316,16 +316,14 @@ If the availability of adequate storage space on target systems is likely to be
 
 To create a self-contained deployment with a smaller footprint, start by following the first two steps for creating a self-contained deployment. Once you've run the `dotnet new` command and added the C# source code to your app, do the following:
 
-1. Open the `csproj` file and replace the `frameworks` section with the following:
+1. Open the `csproj` file and replace the `<TargetFramework>` element with the following:
 
     ```xml
-    <PropertyGroup>
       <TargetFramework>netstandard1.6</TargetFramework>
-  </PropertyGroup>
   ```
 This operation indicates that, instead of using the entire `netcoreapp1.0` framework, which includes .NET Core CLR, the .NET Core Library, and a number of other system components, our app uses only the .NET Standard Library.
 
-2. Replace the `dependencies` section with the following:
+2. Replace the `<ItemGroup>` containing package references with the following:
 
     ```xml
     <ItemGroup>
@@ -356,7 +354,7 @@ This operation indicates that, instead of using the entire `netcoreapp1.0` frame
     ```
 
 
-A complete sample `csproj` file appears later in this section.
+ A complete sample `csproj` file appears later in this section.
 
 4. Run the `dotnet restore` command to restore the dependencies specified in your project.
 
@@ -386,7 +384,7 @@ The following is the complete `csproj` file for this project.
   <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />
   <PropertyGroup>
     <OutputType>Exe</OutputType>
-    <TargetFramework>netcoreapp1.0</TargetFramework>
+    <TargetFramework>netstandard1.6</TargetFramework>
     <VersionPrefix>1.0.0</VersionPrefix>
     <DebugType>Portable</DebugType>
     <RuntimeIdentifiers>win10-x64;osx.10.11-x64</RuntimeIdentifiers>

docs/core/preview3/tools/csproj.md

@@ -13,19 +13,18 @@ ms.devlang: dotnet
 ms.assetid: bdc29497-64f2-4d11-a21b-4097e0bdf5c9
 ---
 
-Additions to csproj format for .NET Core
-----------------------------------------
+# Additions to csproj format for .NET Core
 
-# Overview 
 This document outlines the changes that were added to the csproj files as part of the move from project.json to csproj and 
 [MSBuild](https://github.com/Microsoft/MSBuild). This document outlines **only the deltas to non-core csproj files**. If 
 you need more information about general project file syntax and reference, please consult [the MSBuild project file]() documentation. 
 
-> **Note:** this document will grow in the future, so please check back to see new additions. 
+> ![NOTE]
+> This document will grow in the future, so please check back to see new additions. 
 
-# Additions
+## Additions
 
-## PackageReference
+### PackageReference
 Specifies a NuGet dependency in the project. The `Include` attribute specifies the package ID. 
 
 ```xml
@@ -37,73 +36,74 @@ Specifies a NuGet dependency in the project. The `Include` attribute specifies t
 </PackageReference>
 ```
 
-### Version
-`<Version>` specifies the version of the package to restore. The element respect the rules of the NuGet versioning scheme.
+#### Version
+`<Version>` specifies the version of the package to restore. The element respects the rules of the NuGet versioning scheme.
 
-### IncludeAssets
+#### IncludeAssets
 `<IncludeAssets>` child element specifies what assets belonging to the package specified by parent `<PackageReference>` should be 
 consumed. 
 
 The element can contain one or more of the following values:
 
-* Compile � are the contents of the lib folder available to compile against
-* Runtime � are the contents of the runtime folder distributed
-* ContentFiles � are the contents of the contentfiles folder used
-* Build � do the props/targets in the build folder get used
-* Native - are the contents from native assets copied to the output folder for runtime
-* Analyzers � do the analyzers get used
+* Compile – are the contents of the lib folder available to compile against
+* Runtime – are the contents of the runtime folder distributed
+* ContentFiles – are the contents of the contentfiles folder used
+* Build – do the props/targets in the build folder get used
+* Native – are the contents from native assets copied to the output folder for runtime
+* Analyzers – do the analyzers get used
 
 Alternatively, the element can contain:
 
-* None � none of those things get used
-* All � all of those things get used.
+* None – none of those things get used
+* All – all of those things get used.
 
-### ExcludeAssets
+#### ExcludeAssets
 `<ExcluseAssets>` child element specifies what assets belonging to the package specified by parent `<PackageReference>` should not 
 be consumed.
 
 The element can contain one or more of the following values:
 
-* Compile � are the contents of the lib folder available to compile against
-* Runtime � are the contents of the runtime folder distributed
-* ContentFiles � are the contents of the contentfiles folder used
-* Build � do the props/targets in the build folder get used
-* Native - are the contents from native assets copied to the output folder for runtime
-* Analyzers � do the analyzers get used
+* Compile – are the contents of the lib folder available to compile against
+* Runtime – are the contents of the runtime folder distributed
+* ContentFiles – are the contents of the contentfiles folder used
+* Build – do the props/targets in the build folder get used
+* Native – are the contents from native assets copied to the output folder for runtime
+* Analyzers – do the analyzers get used
 
 Alternatively, the element can contain:
 
-* None � none of those things get used
-* All � all of those things get used.
+* None – none of those things get used
+* All – all of those things get used.
 
-### PrivateAssets
+#### PrivateAssets
 `<PrivateAssets>` child element specifies what assets belonging to the package specified by parent `<PackageReference>` should be 
 consumed but that they should not flow to the next project. 
 
-> **Note:** this is a new term for project.json/xproj `SupressParent` element. 
+> [!NOTE]
+> This is a new term for project.json/xproj `SupressParent` element. 
 
 The element can contain one or more of the following values:
 
-* Compile � are the contents of the lib folder available to compile against
-* Runtime � are the contents of the runtime folder distributed
-* ContentFiles � are the contents of the contentfiles folder used
-* Build � do the props/targets in the build folder get used
-* Native - are the contents from native assets copied to the output folder for runtime
-* Analyzers � do the analyzers get used
+* Compile – are the contents of the lib folder available to compile against
+* Runtime – are the contents of the runtime folder distributed
+* ContentFiles – are the contents of the contentfiles folder used
+* Build – do the props/targets in the build folder get used
+* Native – are the contents from native assets copied to the output folder for runtime
+* Analyzers – do the analyzers get used
 
 Alternatively, the element can contain:
 
-* None � none of those things get used
-* All � all of those things get used.
+* None – none of those things get used
+* All – all of those things get used.
 
-## DotnetCliToolReference
+### DotnetCliToolReference
 `<DotnetCliToolReference>` element specifies the CLI tool that the user wants restores in the context of the project. It is 
 a replacement for the `tools` node in `project.json`. 
 
-### Version
+#### Version
 `<Version>` specifies the version of the package to restore. The element respect the rules of the NuGet versioning scheme.
 
-## RuntimeIdentifiers
+### RuntimeIdentifiers
 `<RuntimeIdentifiers>` element allows specifying a semicolon-delimited list of [Runtime Identifiers](../../rid-catalog.md) for the project. 
 These allow publishing self-contained deployments. 
 

docs/core/preview3/tools/dependencies.md

@@ -12,39 +12,38 @@ ms.devlang: dotnet
 ms.assetid: 74b87cdb-a244-4c13-908c-539118bfeef9
 ---
 
-Managing dependencies in .NET Core Preview 3 tooling
-----------------------------------------------------
+# Managing dependencies in .NET Core Preview 3 tooling
 
-# Overview
 With the move of .NET Core projects from project.json to csproj and MSBuild, a significant invesment also happened that resulted in unification of the project file and assets that allow tracking of depenencies. For .NET Core projects this is similar to what project.json did. There is no separate JSON or XML file that tracks NuGet dependencies. With this change, we've also introduced another type of *reference* into the csproj syntax called the `<PackageReference>`. 
 
 This document describes the new reference type. It also shows how to add a package dependency using this new reference type to your project. 
 
-# The new <PackageReference> element
+## The new <PackageReference> element
 The `<PackageReference>` has the following basic structure:
 
 ```xml
-<PackageReference Include="<Package_ID>">
+<PackageReference Include="PACKAGE_ID">
     <Version>PACKAGE_VERSION</Version>
 </PackageReference>
 ```
 
-If you are familiar with MSBuild, it will look familiar to the other [reference types]() that already exist. The key is the `Include` statement which specifies the package id that you wish to add to the project. The `<Version>` child element specified the version to get. The versions are specified as per [NuGet version rules](https://docs.nuget.org/ndocs/create-packages/dependency-versions#version-ranges).  
+If you are familiar with MSBuild, it will look familiar to the other [reference types]() that already exist. The key is the `Include` statement which specifies the package id that you wish to add to the project. The `<Version>` child element specifies the version to get. The versions are specified as per [NuGet version rules](https://docs.nuget.org/ndocs/create-packages/dependency-versions#version-ranges).  
 
-> **Note:** if you are not faimilar with the overall `csproj` syntax, you can use the [MSBuild project reference documentation]() to get acquainted.  
+> [!NOTE]
+> If you are not familiar with the overall `csproj` syntax, you can use the [MSBuild project reference documentation]() to get acquainted.  
 
 Adding a dependency that is available only in a specific target is done using conditions:
 
 ```xml
-<PackageReference Include="<Package_ID>" Condition="'$(TargetFramework)' == 'netcoreapp1.0'">
+<PackageReference Include="PACKAGE_ID" Condition="'$(TargetFramework)' == 'netcoreapp1.0'">
     <Version>PACKAGE_VERSION</Version>
 </PackageReference>
 ```
 
 The above means that the dependency will only be valid if the build is happening for that given target. The `$(TargetFramework)` in the condition is a MSBuild property that is being set in the project. For most common .NET Core applications, you will not need to do this. 
 
-# Adding a dependency to your project
-Adding a dependency to your project is straightforward. Here is an example of how to add `JSON.net` version `9.0.1` to your project. Of course, it is applicable to any other NuGet dependency. 
+## Adding a dependency to your project
+Adding a dependency to your project is straightforward. Here is an example of how to add Json.NET version `9.0.1` to your project. Of course, it is applicable to any other NuGet dependency. 
 
 When you open your project file, you will see two or more `<ItemGroup>` nodes. You will notice that one of the nodes already has `<PackageReference>` elements in it. You can add your new dependency to this node, or create a new one; it is completely up to you as the result will be the same. 
 
@@ -90,7 +89,7 @@ The full project looks like this:
 </Project>
 ```
 
-# Removing a dependency from the project
+## Removing a dependency from the project
 Removing a dependency from the project file involves simply removing the `<PackageReference>` from the project file. 
 
 

docs/core/preview3/tools/dotnet-build.md

@@ -28,7 +28,7 @@ dotnet-build -- Builds a project and all of its dependencies
 
 The `dotnet build` command builds multiple source file from a source project and its dependencies into a binary. 
 By default, the resulting binary is in Intermediate Language (IL) and has a DLL extension. 
-`dotnet build` also drops a `\*.deps` file which outlines what the host needs to run the application.  
+`dotnet build` also drops a `*.deps` file which outlines what the host needs to run the application.  
 
 Building requires the existence of an asset file (a file that lists all of the dependencies of your application), which 
 means that you have to run [`dotnet restore`](dotnet-restore.md) prior to building your code.

docs/core/preview3/tools/dotnet-new.md

@@ -36,9 +36,9 @@ After this, the project is ready to be compiled and/or edited further.
 
 Prints out a short help for the command.  
 
-`-l|--lang <C#|F#>`
+`-l|--lang C#`
 
-Language of the project. Defaults to `C#`. Other valid values are `csharp`, `fsharp`, `cs` and `fs`.
+Language of the project. Defaults to `C#`. Other valid values are `csharp` and `cs`.
 
 `-t|--type`
 
@@ -50,10 +50,6 @@ Create a C# console application project in the current directory:
 
 `dotnet new` or `dotnet new --lang c#` 
 
-Create an F# console application project in the current directory:
-
-`dotnet new --lang f#`
-
 Create a new ASP.NET Core C# application project in the current directory:
 
-`dotnet new -t web`
+`dotnet new -t web`

docs/core/preview3/tools/dotnet-nuget-delete.md

@@ -71,7 +71,7 @@ Deletes version 1.0 of package MyPackage:
 
 Deletes version 1.0 of package MyPackage, not prompting user for credentials or other input:
 
-`dotnet nuget delete MyPackage 1.0 --non-ìnteractive`
+`dotnet nuget delete MyPackage 1.0 --non-interactive`
 
 Deletes version 1.0 of package MyPackage, specifying a custom config file *./config/My.Config*:
 

docs/core/preview3/tools/dotnet-restore.md

@@ -88,7 +88,7 @@ Restore dependencies and tools for the project in the current directory:
 
 Restore dependencies and tools for the `app1` project found in the given path:
 
-`dotnet restore ~/projects/app1/app1.csproj``
+`dotnet restore ~/projects/app1/app1.csproj`
 
 Restore the dependencies and tools for the project in the current directory using the file path provided as the fallback source:
 

docs/core/preview3/tools/dotnet-test.md

@@ -111,6 +111,8 @@ Configuration under which to build. The default value is `Release`.
 
 Directory in which to find the binaries to run.
 
+`-f|--framework [FRAMEWORK]`
+
 Looks for test binaries for a specific framework.
 
 `-r|--runtime [RUNTIME_IDENTIFIER]`
@@ -133,7 +135,7 @@ Run the tests in the project in the current directory:
 
 Run the tests in the test1 project:
 
-`dotnet test /projects/test1/test1.csproj` 
+`dotnet test ~/projects/test1/test1.csproj` 
 
 ## See also
 

docs/core/preview3/tools/extensibility.md

@@ -75,12 +75,12 @@ API, here is a console application's project file that uses that tool:
     </PackageReference>
   </ItemGroup>
 
-   <!-- The tools reference -->
-   <ItemGroup>
+  <!-- The tools reference -->
+  <ItemGroup>
     <DotNetCliToolReference Include="dotnet-api-search">
-        <Version></Version>
+      <Version></Version>
     </DotNetCliToolReference>
-    </ItemGroup>
+  </ItemGroup>
 
   <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
 </Project>

docs/core/preview3/tools/index.md

@@ -48,6 +48,7 @@ the [driver](#driver) section.
 The following commands are installed by default:
 
 * [new](dotnet-new.md)
+* [migrate](dotnet-migrate.md)
 * [restore](dotnet-restore.md)
 * [run](dotnet-run.md)
 * [build](dotnet-build.md)
@@ -115,7 +116,8 @@ You can learn more about both of these in the [.NET Core application deployment]
 If you used Preview 2 tooling and project.json projects, you can consult the [dotnet migrate](dotnet-migrate.md) command docs
 to get acquainted with the command and how to migrate your project. 
 
-> **Note:** the `dotnet migrate` command currently does not migrate pre-preview 2 project.json files. 
+> [!NOTE]
+> The `dotnet migrate` command currently does not migrate pre-preview 2 project.json files. 
 
 ## Extensibility
 Of course, not every tool that you could use in your workflow will be part of the core CLI tools. However, .NET Core