Get rid of package baseline (#64336)

Author: wtgodbe

AspNetCore.slnx

@@ -7,7 +7,6 @@
   </Configurations>
   <Folder Name="/eng/" />
   <Folder Name="/eng/tools/">
-    <Project Path="eng/tools/BaselineGenerator/BaselineGenerator.csproj" />
     <Project Path="eng/tools/RepoTasks/RepoTasks.csproj" />
   </Folder>
   <Folder Name="/src/" />

Directory.Build.targets

@@ -53,8 +53,6 @@
          '$(IsBenchmarkProject)' == 'true' OR '$(IsSampleProject)' == 'true' OR '$(IsMicrobenchmarksProject)' == 'true') ">false</IsPackable>
   </PropertyGroup>
 
-  <Import Project="eng\Baseline.Designer.props" />
-
   <PropertyGroup Condition=" '$(IsPackable)' != 'false' AND '$(IsServicingBuild)' == 'true' ">
     <IsPackageInThisPatch Condition="'$(IsPackageInThisPatch)' == ''">true</IsPackageInThisPatch>
     <!-- Used to distinguish between packages building -->
@@ -73,24 +71,6 @@
     <PackageVersionForPackageVersionInfo>$(PackageVersion)</PackageVersionForPackageVersionInfo>
   </PropertyGroup>
 
-  <PropertyGroup Condition=" '$(IsPackageInThisPatch)' != 'true' AND '$(BaselinePackageVersion)' != '' AND '$(IsServicingBuild)' == 'true' ">
-    <!-- This keeps assembly and package versions consistent across patches. If a package is not included in a patch, its version should stay at the baseline. -->
-    <AssemblyVersion Condition="$(BaselinePackageVersion.Contains('-'))">$(BaselinePackageVersion.Substring(0, $(BaselinePackageVersion.IndexOf('-')))).0</AssemblyVersion>
-    <AssemblyVersion Condition="! $(BaselinePackageVersion.Contains('-'))">$(BaselinePackageVersion).0</AssemblyVersion>
-    <!--
-      Ideally, we would also set the project version to match the baseline in case NuGet turns a ProjectReference into a nuspec depenendency, but
-      NuGet does not currently handle conflicts between packages and projects which have the same package id/version.
-      See https://github.com/NuGet/Home/issues/6795.
-
-      Because we still use static analysis to scrape versions, only set this during static analysis, which can be detected by checking for both NoBuild and DesignTimeBuild.
-    -->
-    <Version Condition="'$(NoBuild)' == 'true' AND '$(DesignTimeBuild)' == 'true'">$(BaselinePackageVersion)</Version>
-    <PackageVersion Condition="'$(NoBuild)' == 'true' AND '$(DesignTimeBuild)' == 'true'">$(BaselinePackageVersion)</PackageVersion>
-
-    <!-- For servicing builds, we want to resolve baseline versions of project packages that aren't building, always -->
-    <PackageVersionForPackageVersionInfo>$(BaselinePackageVersion)</PackageVersionForPackageVersionInfo>
-  </PropertyGroup>
-
   <PropertyGroup>
     <!-- Implementation projects are the projects which produce nuget packages or shipping assemblies. -->
     <IsImplementationProject Condition=" '$(IsImplementationProject)' == '' AND

docs/PreparingPatchUpdates.md

@@ -9,6 +9,3 @@ In order to prepare this repo to build a new servicing update, the following cha
     -  <AspNetCorePatchVersion>7</AspNetCorePatchVersion>
     +  <AspNetCorePatchVersion>8</AspNetCorePatchVersion>
     ```
-
-* Update the package baselines. This is used to ensure packages keep a consistent set of dependencies between releases.
-  See [eng/tools/BaselineGenerator/](/eng/tools/BaselineGenerator/README.md) for instructions on how to run this tool.

docs/ReferenceResolution.md

@@ -12,7 +12,6 @@ The requirements that led to this system are:
 
 * Versions of external dependencies should be consistent and easily discovered.
 * Newer versions of packages should not have lower dependency versions than previous releases.
-* Minimize the cascading effect of servicing updates where possible by keeping a consistent baseline of dependencies.
 * Servicing releases should not add or remove dependencies in existing packages.
 
 As a minor point, the current system also makes our project files somewhat less verbose.
@@ -26,13 +25,9 @@ As a minor point, the current system also makes our project files somewhat less
 * Only use `<ProjectReference>` in test projects.
 * Name the .csproj file to match the assembly name.
 * Run `eng/scripts/GenerateProjectList.ps1` (or `build.cmd /t:GenerateProjectList`) when adding new projects
-* Use [eng/tools/BaseLineGenerator/](/eng/tools/BaselineGenerator/README.md) if you need to update baselines.
-* If you need to make a breaking change to dependencies, you may need to add `<SuppressBaselineReference>`.
 
 ## Important files
 
-* [eng/Baseline.xml](/eng/Baseline.xml) - this contains the 'baseline' of the latest servicing release for this branch.
-  It should be modified and used to update the generated file, [eng/Baseline.Designer.props](eng/Baseline.Designer.props).
 * [eng/Dependencies.props](/eng/Dependencies.props) - contains a list of all package references that might be used in the repo.
 * [eng/ProjectReferences.props](/eng/ProjectReferences.props) - lists which assemblies or packages might be available to be referenced as a local project.
 * [eng/Versions.props](/eng/Versions.props) - contains a list of versions which may be updated by automation. This is used by MSBuild to restore and build.
@@ -86,20 +81,6 @@ Steps for adding a new package dependency to an existing project. Let's say I'm
         The attribute value should be `"Microsoft.CodeAnalysis.Razor"` for dotnet/runtime dependencies in
         dotnet/aspnetcore-tooling.
 
-## Example: make a breaking change to references
-
-If Microsoft.AspNetCore.Banana in 2.1 had a reference to `Microsoft.AspNetCore.Orange`, but in 3.1 or 5.0 this reference
-is changing to `Microsoft.AspNetCore.BetterThanOrange`, you would need to make these changes to the .csproj file
-
-```diff
-<!-- in Microsoft.AspNetCore.Banana.csproj -->
-  <ItemGroup>
--    <Reference Include="Microsoft.AspNetCore.Orange" /> <!-- the old dependency -->
-+    <Reference Include="Microsoft.AspNetCore.BetterThanOrange" /> <!-- the new dependency -->
-+    <SuppressBaselineReference Include="Microsoft.AspNetCore.Orange" /> <!-- suppress as a known breaking change -->
-  </ItemGroup>
-```
-
 ## A darc cheatsheet
 
 `darc` is a command-line tool that is used for dependency management in the dotnet ecosystem of repos. `darc` can be installed using the `darc-init` scripts located inside the `eng/common` directory. Once `darc` is installed, you'll need to set up the appropriate access tokens as outlined [in the official Darc docs](https://github.com/dotnet/arcade/blob/master/Documentation/Darc.md#setting-up-your-darc-client).

docs/UpdatingMajorVersionAndTFM.md

@@ -21,7 +21,6 @@ Typically, we will update the Major Version before updating the TFM. This is bec
 * Mark APIs from the previous release as Shipped by running `.\eng\scripts\mark-shipped.cmd`. **Note that it's best to do this as early as possible after the API surface is finalized from the previous release** - make sure to be careful that any new API in `main` that isn't shipped as part of the previous release, stays in `PublicAPI.Unshipped.txt` files.
   * One way to ensure this is to check out the release branch shipping the previous release (**after API surface area has been finalized**), run `.\eng\scripts\mark-shipped.cmd` there, copy over all of the `PublicAPI.Unshipped.txt` and `PublicAPI.Shipped.txt` files into a new branch based off of `main`, and build the repo. Any failures there will tell you whether or not there are new APIs in main that need to be put back into the `PublicAPI.Unshipped.txt` files.
     * The result of `.\eng\scripts\mark-shipped.cmd` should be checked in to the release branch as well, as part of the RTM release.
-* Update `.\eng\Baseline.xml` to reflect the set of RTM packages that were just shipped. Then, `dotnet run` `.\eng\tools\BaselineGenerator\BaselineGenerator.csproj`, which will update `.\eng\Baseline.Designer.props`. If RTM hasn't shipped yet, do this in a separate PR once it has. See https://github.com/dotnet/aspnetcore/pull/49269.
 * **In the new release branch**, add files named `.\eng\PlatformManifest.txt` and `.\eng\PackageOverrides.txt`. These files should be found by downloading the just released RTM version of the `Microsoft.AspNetCore.App.Ref` package, and copying over the files from the `data` folder.
 * Update [helix-matrix.yml](https://github.com/dotnet/aspnetcore/blob/436556163a671259c8b14ae1c90d72767af62d18/.azure/pipelines/helix-matrix.yml#L12-L16) to list the currently active release branches.
     * This should be done in `main` as well as the relevant release branch.