dotnet · gewarren · May 8, 2020 · May 7, 2020 · May 7, 2020 · May 7, 2020
diff --git a/docs/core/compatibility/2.2-3.0.md b/docs/core/compatibility/2.2-3.0.md
@@ -375,7 +375,7 @@ If you're migrating from version 2.2 to version 3.0 of .NET Core, ASP.NET Core,
 
 ## MSBuild
 
-- [Resource manifest file name change](#resource-manifest-file-names)
+- [Resource manifest file name change](#resource-manifest-file-name-change)
 
 [!INCLUDE[Resource file names](~/includes/core-changes/msbuild/3.0/resource-manifest-name.md)]
 

diff --git a/docs/core/compatibility/2.2-3.1.md b/docs/core/compatibility/2.2-3.1.md
@@ -378,7 +378,7 @@ If you're migrating from version 2.2 to version 3.1 of .NET Core, ASP.NET Core,
 
 ## MSBuild
 
-- [Resource manifest file name change](#resource-manifest-file-names)
+- [Resource manifest file name change](#resource-manifest-file-name-change)
 
 [!INCLUDE[Resource file names](~/includes/core-changes/msbuild/3.0/resource-manifest-name.md)]
 

diff --git a/docs/core/compatibility/fx-core.md b/docs/core/compatibility/fx-core.md
@@ -48,6 +48,16 @@ If you're migrating an app from .NET Framework to .NET Core, the breaking change
 
 ***
 
+## MSBuild
+
+- [Resource manifest file name change](#resource-manifest-file-name-change)
+
+### .NET Core 3.0
+
+[!INCLUDE[Resource file names](~/includes/core-changes/msbuild/3.0/resource-manifest-name.md)]
+
+***
+
 ## Networking
 
 - [WebClient.CancelAsync doesn't always cancel immediately](#webclientcancelasync-doesnt-always-cancel-immediately)

diff --git a/docs/core/compatibility/msbuild.md b/docs/core/compatibility/msbuild.md
@@ -7,7 +7,7 @@ ms.date: 02/10/2020
 
 The following breaking changes are documented on this page:
 
-- [Resource manifest file name change](#resource-manifest-file-names)
+- [Resource manifest file name change](#resource-manifest-file-name-change)
 
 ## .NET Core 3.0
 

diff --git a/includes/core-changes/msbuild/3.0/resource-manifest-name.md b/includes/core-changes/msbuild/3.0/resource-manifest-name.md
@@ -1,78 +1,36 @@
-### Resource manifest file names
+### Resource manifest file name change
 
-Starting in .NET Core 3.0, the generated resource manifest file name has changed.
+Starting in .NET Core 3.0, in the default case, MSBuild generates a different manifest file name for resource files.
 
 #### Version introduced
 
 3.0
 
 #### Change description
 
-Prior to .NET Core 3.0, when [DependentUpon](/visualstudio/msbuild/common-msbuild-project-items#compile) metadata was set for a resource (*.resx*) file in the MSBuild project file, the generated manifest name was *Namespace.Classname.resources*. When [DependentUpon](/visualstudio/msbuild/common-msbuild-project-items#compile) was not set, the generated manifest name was *Namespace.Classname.FolderPathRelativeToRoot.Culture.resources*.
+Prior to .NET Core 3.0, if no `LogicalName`, `ManifestResourceName`, or `DependentUpon` metadata was specified for an `EmbeddedResource` item in the project file, MSBuild generated a manifest file name in the pattern `<RootNamespace>.<ResourceFilePathFromProjectRoot>.resources`. If `RootNamespace` is not defined in the project file, it defaults to the project name. For example, the generated manifest name for a resource file named *Form1.resx* in the root project directory was *MyProject.Form1.resources*.
 
-Starting in .NET Core 3.0, when a *.resx* file is colocated with a source file of the same name, for example, in Windows Forms apps, the resource manifest name is generated from the full name of the first type in the source file. For example, if *Type.cs* is colocated with *Type.resx*, the generated manifest name is *Namespace.Classname.resources*. However, if you modify any of the attributes on the `EmbeddedResource` property for the *.resx* file, the generated manifest file name may be different:
+Starting in .NET Core 3.0, if a resource file is colocated with a source file of the same name (for example, *Form1.resx* and *Form1.cs*), MSBuild uses type information from the source file to generate the manifest file name in the pattern `<Namespace>.<ClassName>.resources`. The namespace and class name are extracted from the first type in the colocated source file. For example, the generated manifest name for a resource file named *Form1.resx* that's colocated with a source file named *Form1.cs* is *MyNamespace.Form1.resources*. The key thing to note is that the first part of the file name is different to prior versions of .NET Core (*MyNamespace* instead of *MyProject*).
 
-- If the `LogicalName` attribute on the `EmbeddedResource` property is set, that value is used as the resource manifest file name.
+> [!NOTE]
+> If you have `LogicalName`, `ManifestResourceName`, or `DependentUpon` metadata specified on an `EmbeddedResource` item in the project file, then this change does not affect that resource file.
 
-  Examples:
+This breaking change was introduced with the addition of the `EmbeddedResourceUseDependentUponConvention` property to .NET Core projects. By default, resource files aren't explicitly listed in a .NET Core project file, so they have no `DependentUpon` metadata to specify how to name the generated *.resources* file. When `EmbeddedResourceUseDependentUponConvention` is set to `true`, which is the default, MSBuild looks for a colocated source file and extracts a namespace and class name from that file. If you set `EmbeddedResourceUseDependentUponConvention` to `false`, MSBuild generates the manifest name according to the previous behavior, which combines `RootNamespace` and the relative file path.
 
-  ```xml
-  <EmbeddedResource Include="X.resx" LogicalName="SomeName.resources" />
-  -or-
-  <EmbeddedResource Include="X.fr-FR.resx" LogicalName="SomeName.resources" />
-  ```
-
-  **Generated resource manifest file name**: *SomeName.resources* (regardless of the *.resx* file name or culture or any other metadata).
-
-- If `LogicalName` is not set, but the `ManifestResourceName` attribute on the `EmbeddedResource` property is set, its value, combined with the file extension *.resources*, is used as the resource manifest file name.
-
-  Examples:
-
-  ```xml
-  <EmbeddedResource Include="X.resx" ManifestResourceName="SomeName" />
-  -or-
-  <EmbeddedResource Include="X.fr-FR.resx" ManifestResourceName="SomeName.fr-FR" />
-  ```
+#### Recommended action
 
-  **Generated resource manifest file name**: *SomeName.resources* or *SomeName.fr-FR.resources*.
+In most cases, no action is required on the part of the developer, and your app should continue to work. However, if this change breaks your app, you can either:
 
-- If the previous rules don't apply, and the `DependentUpon` attribute on the `EmbeddedResource` element is set to a source file, the type name of the first class in the source file is used in the resource manifest file name. More specifically, the generated file name is *Namespace.Classname\[.Culture].resources*.
+- Change your code to expect the new manifest name.
 
-  Examples:
+- Opt out of the new naming convention by setting `EmbeddedResourceUseDependentUponConvention` to `false` in your project file.
 
   ```xml
-  <EmbeddedResource Include="X.resx" DependentUpon="MyTypes.cs">
-  -or-
-  <EmbeddedResource Include="X.fr-FR.resx" DependentUpon="MyTypes.cs">
+  <PropertyGroup>
+    <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
+  </PropertyGroup>
   ```
 
-  **Generated resource manifest file name**: *Namespace.Classname.resources* or *Namespace.Classname.fr-FR.resources* (where `Namespace.Classname` is the name of the first class in *MyTypes.cs*).
-
-- If the previous rules don't apply, `EmbeddedResourceUseDependentUponConvention` is `true` (the default for .NET Core), and there's a source file colocated with a *.resx* file that has the same base file name, the *.resx* file is made dependent upon the matching source file, and the generated name is the same as in the previous rule. This is the "default settings" rule for .NET Core projects.
-
-  Examples:
-
-  Files *MyTypes.cs* and *MyTypes.resx* or *MyTypes.fr-FR.resx* exist in the same folder.
-
-  **Generated resource manifest file name**: *Namespace.Classname.resources* or *Namespace.Classname.fr-FR.resources* (where `Namespace.Classname` is the name of the first class in *MyTypes.cs*).
-
-- If none of the previous rules apply, the generated resource manifest file name is *RootNamespace.RelativePathWithDotsForSlashes.\[Culture.]resources*. The relative path is the value of the `Link` attribute of the `EmbeddedResource` element if it's set. Otherwise, the relative path is the value of the `Identity` attribute of the `EmbeddedResource` element. In Visual Studio, this is the path from the project root to the file in Solution Explorer.
-
-#### Recommended action
-
-If you're unsatisfied with the generated manifest names, you can:
-
-- Modify your resource file metadata according to one of the previously described naming rules.
-
-- Set `EmbeddedResourceUseDependentUponConvention` to `false` in your project file to opt out of the new convention entirely:
-
-   ```xml
-   <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
-   ```
-
-   > [!NOTE]
-   > If the `LogicalName` or `ManifestResourceName` attributes are present, their values will still be used for the generated file name.
-
 #### Category
 
 MSBuild