Prevent tests from importing "normal" NuGet props/targets #80573
Conversation
We import them manually from a shared location. Usually this is not a problem because batch build (via the build script) does its own restore thing, but it is a problem in case the project is restored on its own, such as when it is built with "dotnet build".
ghost
added
the
community-contribution
|
Tagging subscribers to this area: @hoyosjs Issue DetailsCI testing...
|
|
@dotnet/runtime-infrastructure |
| <!-- Prevent project-specific NuGet props/targets from clashing with the ones we manually import below. --> | ||
| <ImportProjectExtensionProps>false</ImportProjectExtensionProps> | ||
| <ImportProjectExtensionTargets>false</ImportProjectExtensionTargets> |
There was a problem hiding this comment.
Not blocking this PR but here's some feedback from my side.
From someone that had to deal with non restore-able projects in corefx and the inability to do anything like PackageReference in the BCL, I would strongly argument towards allowing every project in this repo to use the SDK's common path, which includes importing NuGet props and targets.
What's the reason that props and targets files are manually injected into the test projects in the first place? Is it restore speed? Is it the intermediate's artifacts size?
There was a problem hiding this comment.
I suppose I don't have the context for why this is set up this way, though I do suspect build efficiency to be the primary motivation as there are a lot of runtime test projects.
There was a problem hiding this comment.
The concern is that there are so many runtime test projects that we exceed the memory on the system and cause MSBuild to crash with OOM. We avoid compounding this issue with having to shell out for both build and restore by restoring once into Core_Root and not restoring each test project itself. As we progress on the test merging work into the "merge projects/assemblies" stage (after the "merge test runs into a single process" stage), we should be able to reduce the number of project files down enough to enable us to do more traditional project behaviors.
|
CI failure is #73040. |
|
This time the CI failure is #75244. @dotnet/runtime-infrastructure - ping, are we ok to merge this change? |
Fixes #70658.