search

dotnet / source-build

A repository to track efforts to produce a source tarball of the .NET Core SDK and all its components
MIT License
266 stars 132 forks source link

ASPNet core overwrites local dotnet SDK when creating the shared framework layout for tests #3809

Open mmitche opened 9 months ago

mmitche commented 9 months ago

ASPNet has knowledge of the repo local installed .NET SDK (https://github.com/dotnet/aspnetcore/blob/main/Directory.Build.props#L194). It uses this when laying out the shared framework for testing. In a VMR context, this would be the shared .NET install.

Ideally, we would not overwrite any bit of the SDK or installs of the shared framework.

From @jkoritzinsky:

dotnet/runtime manually creates/manipulates the ResolvedTargetingPack, ResolvedRuntimePack, and ResolvedFrameworkReference MSBuild items to point the SDK to the correct locations for live references

https://github.com/dotnet/runtime/blob/main/eng/targetingpacks.targets

T-Shirt Size: Medium

mmitche commented 9 months ago

@jkoritzinsky @wtgodbe what do you think on that t-shirt size costing to resolve this?

jkoritzinsky commented 9 months ago

Given my lack of knowledge of how ASP.NET lays out their targeting packs/test shared framework, I think Medium is the right cost.

wtgodbe commented 9 months ago

Medium seems right to me. Just setting the properties & undoing the copy will fix some stuff, but there are some weird bits of logic baked into the repo that assume the layout will be in the spot we copied it to (e.g. I believe our custom shared framework/targeting pack builds use the dropped layout, as well as our helix infra & installer builds)