Fit and finish updates (#1493)

Author: mcleanbyron

windows-apps-src/dotnet-native/getting-started-with-net-native.md

@@ -9,7 +9,7 @@ ms.assetid: fc9e04e8-2d05-4870-8cd6-5bd276814afc
 
 Whether you're writing a new UWP app or migrating an existing Windows 8.x app (previously also called a Microsoft Store app), you can follow the same set of procedures. To create a .NET Native app, follow these steps:
 
-1. [Develop a Universal Windows Platform (UWP) app that targets Windows 10](#Step1), and test the debug builds of your app to ensure that it works properly.
+1. [Develop a Universal Windows Platform (UWP) app](#Step1), and test the debug builds of your app to ensure that it works properly.
 
 2. [Handle additional reflection and serialization usage](#Step2).
 

windows-apps-src/dotnet-native/index.md

@@ -48,4 +48,4 @@ But .NET Native involves more than a compilation to native code. It transforms t
 | Deployed  | Ready-to-run binaries            | Ready-to-run binaries (ASM) |
 | Runtime   | MRT.dll (Minimal CLR Runtime)    | CRT.dll (C Runtime)         |
 
-For Windows apps for Windows 10, you upload .NET Native Code Compilation binaries in app packages (.appx files) to Microsoft Store.
+For UWP apps, you upload .NET Native Code Compilation binaries in app packages (.msix or .appx files) to the Microsoft Store.

windows-apps-src/dotnet-native/migrating-your-windows-store-app-to-net-native.md

@@ -7,7 +7,7 @@ ms.assetid: 4153aa18-6f56-4a0a-865b-d3da743a1d05
 ---
 # Migrate Your Windows 8.x App to .NET Native
 
-.NET Native provides static compilation of apps in the Microsoft Store or on the developer's computer. This differs from the dynamic compilation performed for Windows 8.x apps (also previously called Microsoft Store apps) by the just-in-time (JIT) compiler or the [Native Image Generator (Ngen.exe)](/dotnet/framework/tools/ngen-exe-native-image-generator) on the device. Despite the differences, .NET Native tries to maintain compatibility with [.NET for Microsoft Store apps](/previous-versions/windows/apps/br230302(v=vs.140)). For the most part, things that work on the .NET for Windows 8.x apps also work with .NET Native.  However, in some cases, you may encounter behavioral changes. This document discusses these differences between the standard .NET for Windows 8.x apps and .NET Native in the following areas:
+.NET Native provides static compilation of apps in the Microsoft Store or on the developer's computer. This differs from the dynamic compilation performed for Windows 8.x apps (also previously called Microsoft Store apps) by the just-in-time (JIT) compiler or the [Native Image Generator (Ngen.exe)](/dotnet/framework/tools/ngen-exe-native-image-generator) on the device. Despite the differences, .NET Native tries to maintain compatibility with [.NET for Windows 8.x apps](/previous-versions/windows/apps/br230302(v=vs.140)). For the most part, things that work on the .NET for Windows 8.x apps also work with .NET Native.  However, in some cases, you may encounter behavioral changes. This document discusses these differences between the standard .NET for Windows 8.x apps and .NET Native in the following areas:
 
 - [General runtime differences](#Runtime)
 
@@ -75,7 +75,7 @@ In .NET Native:
 
 - Private reflection over types and members in the .NET Framework class library is not supported. You can, however, reflect over your own private types and members, as well as types and members in third-party libraries.
 
-- The <xref:System.Reflection.ParameterInfo.HasDefaultValue%2A?displayProperty=nameWithType> property correctly returns `false` for a <xref:System.Reflection.ParameterInfo> object that represents a return value. In the .NET for Windows 8.x apps, it returns `true`. Intermediate language (IL) doesn't support this directly, and interpretation is left to the language.
+- The <xref:System.Reflection.ParameterInfo.HasDefaultValue%2A?displayProperty=nameWithType> property correctly returns `false` for a <xref:System.Reflection.ParameterInfo> object that represents a return value. In .NET for Windows 8.x apps, it returns `true`. Intermediate language (IL) doesn't support this directly, and interpretation is left to the language.
 
 - Public members on the <xref:System.RuntimeFieldHandle> and <xref:System.RuntimeMethodHandle> structures aren't supported. These types are supported only for LINQ, expression trees, and static array initialization.
 

windows-apps-src/dotnet-native/net-native-and-compilation.md

@@ -7,7 +7,7 @@ ms.assetid: e38ae4f3-3e3d-42c3-a4b8-db1aa9d84f85
 ---
 # .NET Native and compilation
 
-Windows Desktop applications that target the.NET Framework are written in a particular programming language and compiled into intermediate language (IL). At runtime, a just-in-time (JIT) compiler is responsible for compiling the IL into native code for the local machine just before a method is executed for the first time. In contrast, the .NET Native tool chain converts source code to native code at compile time. This topic compares .NET Native with other compilation technologies available for .NET Framework apps, and also provides a practical overview of how .NET Native produces native code that can help you understand why exceptions that occur in code compiled with .NET Native do not occur in JIT-compiled code.
+Windows desktop applications that target .NET Framework are written in a particular programming language and compiled into intermediate language (IL). At run time, a just-in-time (JIT) compiler is responsible for compiling the IL into native code for the local machine just before a method is executed for the first time. In contrast, the .NET Native tool chain converts source code to native code at compile time. This article compares .NET Native with other compilation technologies available for .NET Framework apps, and also provides a practical overview of how .NET Native produces native code that can help you understand why exceptions that occur in code compiled with .NET Native do not occur in JIT-compiled code.
 
 ## Generating native binaries