diff --git a/releases/UWP/net-native2.0/README.md b/releases/UWP/net-native2.0/README.md
index cc50d22..93222d3 100644
--- a/releases/UWP/net-native2.0/README.md
+++ b/releases/UWP/net-native2.0/README.md
@@ -44,11 +44,11 @@ When using Visual Studio these packages require Visual Studio version 15.4 or la
 
 - **.NET Standard 2.0 and other .NET Library NuGet Packages**
     - While the vast majority of .NET Standard 2.0 APIs will work normally on the .NET Native platform, there are a small number of exceptions where the .NET Native platform could not fully support the expected behavior, typically because it would require JIT compilation or it is restricted by the app sandbox (AppContainer). An example is reading and writing process information with the Process class. As well, there are also some limitations in certain API that is not part of .NET Standard 2.0. See [https://github.com/dotnet/corefx/wiki/UWP-Compat](https://github.com/dotnet/corefx/wiki/UWP-Compat) for more details.
-    - Although NuGet will now allow you to reference packages that expect the desktop .NET Framework, it cannot determine whether those libraries use an API that is not available on .NET Native. To warn you of this, NuGet and Visual Studio will display a warning like, "NU1701: Package ‘PackageNameHere 1.0.0’ was restored using ‘.NETFramework,Version=v4.6.1’ instead of the project target framework ‘.NETStandard,Version=v2.0’. This package may not be fully compatible with your project.". When you receive this warning, you will want to make sure through testing or by reference to the library author that the package will indeed work in your .NET Native project. Over time, we expect many of these packages to re-package to avoid the warning.
-    - System.Diagnostics.Debugger.Log and System.Diagnostics.Debugger.IsLogging do not report the message to the debugger on Release (.NET Native) builds.  Debug (CoreCLR) builds function as expected.  [405171]
-    - System.Net.HttpWebRequest behavior change regarding POST'ing empty content with entity body related request headers (i.e. 'Content-Type', et. al.) from prior .NET Native releases. See [https://github.com/dotnet/corefx/wiki/ApiCompat](https://github.com/dotnet/corefx/wiki/ApiCompat) for more details.
+    - Although NuGet will now allow you to reference packages that expect the desktop .NET Framework, it cannot determine whether those libraries use an API that is not available on .NET Native. To warn you of this, NuGet and Visual Studio will display a warning like, ```NU1701: Package 'PackageNameHere 1.0.0' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.```. When you receive this warning, you will want to make sure through testing or by reference to the library author that the package will indeed work in your .NET Native project. Over time, we expect many of these packages to re-package to avoid the warning.
+    - ```System.Diagnostics.Debugger.Log``` and ```System.Diagnostics.Debugger.IsLogging``` do not report the message to the debugger on Release (.NET Native) builds.  Debug (CoreCLR) builds function as expected.  [405171]
+    - ```System.Net.HttpWebRequest``` behavior change regarding POST'ing empty content with entity body related request headers (i.e. 'Content-Type', et. al.) from prior .NET Native releases. See [https://github.com/dotnet/corefx/wiki/ApiCompat](https://github.com/dotnet/corefx/wiki/ApiCompat) for more details.
     - Exception thrown from C# dynamic binder when calling interface methods on WinRT objects. [476163]
-        - Exception: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException:The call is ambiguous between the following methods or properties: ```System.Collections.Generic.IDictionary<string,object>.Add(string, object)``` and ```System.Collections.Generic.IDictionary<string,object>.Add(string, object)```
+        - Exception: ```Microsoft.CSharp.RuntimeBinder.RuntimeBinderException:The call is ambiguous between the following methods or properties: System.Collections.Generic.IDictionary<string,object>.Add(string, object) and System.Collections.Generic.IDictionary<string,object>.Add(string, object)```
         - Workaround: The recommended fix would be to cast the dynamic object to the desired interface type and just make a call statically.
             - Example: ```dynamicObject.Add("key", value);```
             - Fix: ```((IDictionary<string, objecy>)dynamicObject).Add("key", value);```