ProjectReference protocol documentation updates

documentation/ProjectReference-Protocol.md

@@ -22,7 +22,7 @@ Importing `Microsoft.Common.targets` includes logic that consumes these items an
 
 ## Who this document is for
 
-This document describes that process, including what is required of a project to be referenceable through a `ProjectReference`. It is intended for for MSBuild SDK maintainers, and those who have created a completely custom project type that needs to interoperate with other projects. It may also be of interest if you'd like to see the implementation details of references. Understanding the details should not be necessary to _use_ `ProjectReferences` in your project.
+This document describes that process, including what is required of a project to be referenceable through a `ProjectReference`. It is intended for MSBuild SDK maintainers, and those who have created a completely custom project type that needs to interoperate with other projects. It may also be of interest if you'd like to see the implementation details of references. Understanding the details should not be necessary to _use_ `ProjectReferences` in your project.
 
 ## Targets related to consuming a reference
 
@@ -51,7 +51,7 @@ These targets should exist in a project to be compatible with the common targets
 
 These targets are all defined in `Microsoft.Common.targets` and are defined in Microsoft SDKs. You should only have to implement them yourself if you require custom behavior or are authoring a project that doesn't import the common targets.
 
-If implementing a project with an “outer” (determine what properties to pass to the real build) and “inner” (fully specified) build, only `GetTargetFrameworkProperties` is required in the “outer” build. The other targets listed can be “inner” build only.
+If implementing a project with an “outer” (determine what properties to pass to the real build) and “inner” (fully specified) build, only `GetTargetFrameworks` is required in the “outer” build. The other targets listed can be “inner” build only.
 
 * `GetTargetFrameworks` tells referencing projects what options are available to the build.
   * It returns an item with the following metadata:
@@ -106,7 +106,7 @@ As of MSBuild 16.10, it is possible to gather additional properties from referen
 
 These properties will then be gathered via the `GetTargetFrameworks` call.  They will be available to the referencing project via the `AdditionalPropertiesFromProject` metadata on the `_MSBuildProjectReferenceExistent` item.  The `AdditionalPropertiesFromProject` value will be an XML string which contains the values of the properties for each `TargetFramework` in the referenced project.  For example:
 
-> :warning: This format is being changed. Soon, the schema will replace <net5.0> with <TargetFramework Name="net5.0">. You can opt into that behavior early by setting the _UseAttributeForTargetFrameworkInfoPropertyNames property to true. This property will have no effect after the transition is complete.
+> :warning: This format is being changed. Soon, the schema will replace `<net5.0>` with `<TargetFramework Name="net5.0">`. You can opt into that behavior early by setting the `_UseAttributeForTargetFrameworkInfoPropertyNames` property to true. This property will have no effect after the transition is complete.
 
 ```xml
 <AdditionalProjectProperties>
@@ -176,7 +176,7 @@ Project B: Unmanaged, has `$(Platforms)` constructed from its `Platform` metadat
 Because `AnyCPU` does not map to anything architecture-specific, a custom mapping must be defined. Project A can either:
 1. Define `PlatformLookupTable` in its project or a Directory.Build.props as `AnyCPU=x64` or `AnyCPU=Win32`.
 2. Define `PlatformLookupTable` as metadata on the `ProjectReference` item, which would take priority over a lookup table defined elsewhere.
-     *  When only one mapping is valid, you could also directly define `SetPlatform` metadata as `Platform=foo` (for unmanaged) or `PlatformTarget=bar` (for managed). This would skip over most negotiation logic.
+     *  When only one mapping is valid, you could also directly define `SetPlatform` metadata as `Platform=foo`. This would skip over most negotiation logic.
 
 Example of project A defining a lookup table directly on the `ProjectReference`:
 ```xml

src/Tasks/Microsoft.Common.CurrentVersion.targets

@@ -1941,13 +1941,7 @@ Copyright (C) Microsoft Corporation. All rights reserved.
     ============================================================
                                     GetTargetFrameworkProperties
 
-    Overrridden by cross-targeting projects to return the set of
-    properties (in the form "key1=value1;...keyN=valueN") needed
-    to build it with the best target for the referring project's
-    target framework.
-
-    The referring project's $(TargetFrameworkMoniker) is passed
-    in as $(ReferringTargetFramework)
+    OBSOLETE: present only for theoretical backward compatibility.
   -->
   <Target Name="GetTargetFrameworkProperties" />