Use ProjectReferences in inbox src projects #106329
Open
+889
−905
Commits on Sep 3, 2024
-
Use ProjectReference items in inbox src projects
There are numerous benefits in using ProjectReferences consistently in all libraries: 1. An upfront "libs" build isn't required anymore and sfx libraries can now directly be built from a fresh clone (with dotnet build or inside VS). I.e. `dotnet.cmd pack src/libraries/System.Text.Json/src/` is now possible from a fresh clone. 2. Because of 1), we can now add a solution file for the whole sfx that can directly be opened and worked with from a fresh clone. 3. The overall root build is faster. Without this change, the build order was sfx-ref -> (sfx-src & sfx-gen) so the shared framework reference projects first had to be built and only then the sfx src and gen projects could be built. Now with this change, everything gets built in parallel. 4. Using P2Ps means that we now follow the common and well supported msbuild and SDK path instead of repo customization. The downside of doing this is that the dependency graph gets bigger, meaning that more projects get incrementally built when doing a "dotnet build". This is nothing new and the SDK team recommends to pass the "--no-dependencies" flag to "dotnet build" if incrementally (no-op) building the additional dependency nodes is noticeable. This is less of a concern inside VS as that has a "fast up-to-date check" feature that doesn't even attempt to build projects that didn't change. For VS, really the only noticeable change is that the solution explorer now lists more projects and that when opening a solution, more projects need to be evaluated. But, that should be fast enough when using an up-to-date version of VS. - A few observations that make the change more involved: There's a NuGet client bug that requires a few workarounds: NuGet/Home#10368 Because of that, as a workaround, PackageId had to be set to a different string for S.Numerics.Vectors and System.Memory. We should fix the NuGet tooling issue to eventually get rid of the workarounds introduced with this commit. There was already a PR in NuGet.Client open but it was closed because of staleness. - System.Data.Common.csproj is a weird project as it references CoreLib and reference assemblies. I had to disable transitive project references in order for type universes to not clash and explicitly set CompileUsingReferenceAssemblies=true as that gets set to false when the library explicitly references CoreLib.
-
-
-
-
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.