Feedback

Author: jeffkl

docs/concepts/Auditing-Packages.md

@@ -160,7 +160,7 @@ If security vulnerabilities are found and updates are available for the package,
 If a known vulnerability exists in a top-level package's transitive dependencies, you have these options:
 
 - Add the fixed package version as a direct package reference. **Note:** Be sure to remove this reference when a new package version update becomes available and be sure to maintain the defined attributes for the expected behavior.
-- Use [Central Package Management with the transitive pinning functionality](../consume-packages/Central-Package-Management.md#pinning-transitive-packages-to-different-versions).
+- Use [Central Package Management with the transitive pinning functionality](../consume-packages/Central-Package-Management.md#transitive-pinning).
 - [Suppress the advisory](#excluding-advisories) until it can be addressed.
 - File an issue in the top-level package's tracker to request an update.
 

docs/consume-packages/Central-Package-Management.md

@@ -72,38 +72,6 @@ The version will be resolved from the corresponding `<PackageVersion />` entry i
 
 Now you're using Central Package Management and managing your versions in a central location!
 
-### Using Different Versions for Different Target Frameworks
-
-As NuGet packages evolve, package owners may drop support for older target frameworks.
-This can cause issues for developers of libraries that still target older frameworks but want to reference newer versions of packages for newer target frameworks.
-
-For example, if your project targets .NET Standard 2.0, .NET 8.0, and .NET Framework 4.7.2, but `PackageA` no longer supports .NET Standard 2.0 in its latest version, you can specify different versions for each target framework.
-
-```xml
-<Project Sdk="Microsoft.NET.Sdk">
-  <PropertyGroup>
-    <TargetFrameworks>netstandard2.0;net8.0;net472</TargetFrameworks>
-  </PropertyGroup>
-  <ItemGroup>
-    <PackageReference Include="PackageA" />
-  </ItemGroup>
-</Project>
-```
-
-In this case, define different versions for each target framework in your `Directory.Packages.props` using [MSBuild conditions](/visualstudio/msbuild/msbuild-conditions):
-
-```xml
-<Project>
-  <PropertyGroup>
-    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
-  </PropertyGroup>
-  <ItemGroup>
-    <PackageVersion Include="PackageA" Version="1.0.0" Condition="'$(TargetFramework)' == 'netstandard2.0'" />
-    <PackageVersion Include="PackageA" Version="2.0.0" Condition="'$(TargetFramework)' == 'net8.0' Or '$(TargetFramework)' == 'net472'" />
-  </ItemGroup>
-</Project>
-```
-
 ## Central Package Management Rules
 
 The `Directory.Packages.props` file has specific rules regarding its location and context within a repository.
@@ -157,7 +125,39 @@ To fully onboard your repository, follow these steps:
 
 For an example of how Central Package Management may look, refer to our [samples repository](https://github.com/NuGet/Samples/tree/main/CentralPackageManagementExample).
 
-## Pinning Transitive Packages to Different Versions
+## Using Different Versions for Different Target Frameworks
+
+As NuGet packages evolve, package owners may drop support for older target frameworks.
+This can cause issues for developers of libraries that still target older frameworks but want to reference newer versions of packages for newer target frameworks.
+
+For example, if your project targets .NET Standard 2.0, .NET 8.0, and .NET Framework 4.7.2, but `PackageA` no longer supports .NET Standard 2.0 in its latest version, you can specify different versions for each target framework.
+
+```xml
+<Project Sdk="Microsoft.NET.Sdk">
+  <PropertyGroup>
+    <TargetFrameworks>netstandard2.0;net8.0;net472</TargetFrameworks>
+  </PropertyGroup>
+  <ItemGroup>
+    <PackageReference Include="PackageA" />
+  </ItemGroup>
+</Project>
+```
+
+In this case, define different versions for each target framework in your `Directory.Packages.props` using [MSBuild conditions](/visualstudio/msbuild/msbuild-conditions):
+
+```xml
+<Project>
+  <PropertyGroup>
+    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
+  </PropertyGroup>
+  <ItemGroup>
+    <PackageVersion Include="PackageA" Version="1.0.0" Condition="'$(TargetFramework)' == 'netstandard2.0'" />
+    <PackageVersion Include="PackageA" Version="2.0.0" Condition="'$(TargetFramework)' == 'net8.0' Or '$(TargetFramework)' == 'net472'" />
+  </ItemGroup>
+</Project>
+```
+
+## Transitive Pinning
 
 You can automatically override a transitive package version without an explicit top-level `<PackageReference />` item by opting into a feature known as transitive pinning.
 This promotes a transitive dependency to a top-level dependency implicitly on your behalf when necessary.

docs/reference/errors-and-warnings/NU1011.md

@@ -28,7 +28,7 @@ The use of floating versions introduces the possibility for a bad package to be
 This can lead to a situation where you made no changes in your repository but suddenly something is broken due to a problem in a new package and there is no way for you to get back into a good state without removing the floating version or pushing a newer version of the package which is fixed.
 Using non-floating versions means that every upgrade to a package is backed by a commit in your repository, making it easy to determine what change caused the break and allows you to revert a commit to get back into a good state.
 
-Also, when using the [transitive pinning](../../consume-packages/Central-Package-Management.md#pinning-transitive-packages-to-different-versions) feature of [Central Package Management](../../consume-packages/Central-Package-Management.md), using a floating version as an override could make restores of different projects end up with different versions for the package that what is supposed to be pinned, thus going against the promise of using the centrally defined version.
+Also, when using the [transitive pinning](../../consume-packages/Central-Package-Management.md#transitive-pinning) feature of [Central Package Management](../../consume-packages/Central-Package-Management.md), using a floating version as an override could make restores of different projects end up with different versions for the package that what is supposed to be pinned, thus going against the promise of using the centrally defined version.
 
 NuGet recommends you use automation like [Dependabot](https://docs.github.com/code-security/dependabot/working-with-dependabot) to keep package versions up-to-date which provides
 a streamlined way of updating package versions while integrating into your existing developer workflow of a pull request, automated build validation, and testing all backed by a commit in your repository.