Enable Windows Build in the VMR

[ViktorHofer]

Contributes to dotnet/source-build#3706, dotnet/source-build#3786, dotnet/source-build#2974
Fixes dotnet/source-build#3677, dotnet/source-build#3682, dotnet/source-build#3783

Code comes from dotnet/dotnet#46. I didn't port all commits over as many of those don't make sense anymore and cleaning them up would have been too much work. Instead I brought the changes over and then grouped them into logical units.

Validation: CI & locally (Stage 1 and stage 2 builds succeeded locally on Ubuntu 22.04 with node 20.x installed)

---

Important for reviewers: The following changes are really hard to review and I suggest to skip them:

• Directory.Build.props
• eng/build.sourcebuild.targets (contains the source build specific code from build.proj without any significant changes aside from clean-up)
• repo-projects/Directory.Build.props
• repo-projects/Directory.Build.targets

To summarize changes in those files:

1. Define central root properties for OS and Architecture: BuildOS, HostOS, TargetOS, BuildArchitecture, HostArchitecture and TargetArchitecture.
2. Remove dead properties, items, targets and env vars and a lot of general msbuild clean-up. Move properties into the actual places where they are needed instead of having everything in the root Directory.Build.props.
3. For the projects that don't import the Arcade.Sdk, define the properties that are needed (i.e. NetCurrent, ArtifactsDir, RepositoryEngineeringDir, RepoRoot and a few others with clear markers that this code should be kept in sync with what's in the Arcade.Sdk). This makes the artifacts output path the same as in other Arcadified repositories, without using the Arcade.Sdk itself for some projects. We follow that exact same approach in other repos like runtime.
4. Rewrite the inner build command properties for The default source build command script should be eng/common/build.* source-build#3783 and to remove a lot of unnecessary complexity in the current properties.
5. Make the msbuild sdk resolver custom code more understandable and better grouped together.

Kudos to @mmitche who is the co-author of these changes.

[MichaelSimons]

Lots of nice clean-up - thanks. IMO it would have been a lot easier to review and you would get better feedback had this been split apart into more incremental PRs.

My main feedback/question is the use of previous source-build artifacts in non-source-only builds. IMO we should be building with the previous artifacts all of the time.

Have you validated an offline build? After seeing the changes, I feel like this is warranted.

[MichaelSimons]

Why run this (and others like ExtractToolPackage) only running in source only builds? I was of the opinion all builds should be building with n-1. This helps ensure consistency across the build types.

[ViktorHofer]

I talked about this with @mmitche offline. We believe that this requires a separate discussion as we don't see this as a goal for the UB effort right now. We don't have a separate "previously built from the VMR" registry aside from nuget.org and the SDK and it's not clear to us why we would want one. Condition this logic out for non source built is the tactical fix here to make progress on the non source built lanes. Let's have this discussion in our next sync meeting.

[MichaelSimons]

I don't get the meaning of collapsed here. Can you help me understand?

[ViktorHofer]

Maybe "flat" better transports the meaning? Collapsed here means that multiple projects/repos write into this folder. In msbuild, intermediate output and output paths exist and are isolated per project.

[MichaelSimons]

Thanks for the explanation. flat doesn't help much IMO. Would shared make sense?

[mmitche]

No major issues here. Some comments but nothing blocking

[ViktorHofer]

@MichaelSimons

Lots of nice clean-up - thanks. IMO it would have been a lot easier to review and you would get better feedback had this been split apart into more incremental PRs.

Thanks for the review and the points that you bring up. I will submit a follow-up to clean the things up that you and others mentioned and file issues for items that require more discussion or are entirely unrelated to this PR.

I tried to submit as many separate PRs as possible during the Windows PoC work (remember the random 10+ PRs that went into installer over the last weeks). Still, at some point I had to rely on previously established work from the PoC that wasn't easy to bring over without a large amount of work on my side (untangling those changes would have been very hard as we pushed ~200 commits).

That said, I'm quite happy with the review that I got and feel that the changes are well tested and reviewed.

Have you validated an offline build? After seeing the changes, I feel like this is warranted.

Yes I did a stage 1 and stage 2 built and both of those were offline builds.

---

As I didn't see any blocking feedback I'm going to merge this PR in now and will submit a follow-up change with clean-up and open tracking issues for other things that came up. Thanks everyone for the feedback.