New Configuration System

[Anipik]

Things Done

• Restore Working for vertical Build & AllConfigurations
• Build Working for vertical Build & AllConfigurations
• Pack working for vertical Build & AllConfigurations

Things left

• Building Tests

This is for the first review.

Fixes #31052

[jkotas]

<TargetFrameworks>netstandard2.0;</TargetFrameworks>

Is the trailing semicolon required? It looks odd.

[danmoseley]

I love the cleanup. What will be the effect on the experience when I open projects in VS? I think you mentioned some things will improve, some will not?

Clearly making our projects look more like regular projects is a good thing 😄

[Anipik]

What will be the effect on the experience when I open projects in VS? I think you mentioned some things will improve, some will not?

eric has mentioned some of the pros here in the issue https://github.com/dotnet/corefx/issues/41512
But I will summarize the pros, cons, change of behavior in the VS and the plan to fix the VS stuff that this will break

[ViktorHofer]

Is this required for P2P to work?

[Anipik]

SDK requires TargetFramework to set TargetFrameworkIdentifier as this property cant be empty.
There is no use for it other than that

[ViktorHofer]

I went through all changes and left comments. Decide for yourself (based on the impact) to either address it in this PR or a follow-up one.

[Anipik]

I went through all changes and left comments. Decide for yourself (based on the impact) to either address it in this PR or a follow-up one.

Thanks Viktor for the review. I will try to address as many as possible while i am waiting/fixing the ci

[Anipik]

Can you please explain when to use TargetFrameworkSuffix and when to use OSGroup and what their semantics are?

TargetFrameworkSuffix refers to OS part specified in the targetFramework string. we set TargetsWindows\Linux on the basis of this property.

OSGroup referes to the OS we are building the product for. Earlier we were using the OSGroup for TargetFrameworkSuffix as well. Earlier we were setting this property using buildConfiguration and configuration that we were passing from the outer build to the innerbuild.
This flow avoids passing any extra info to inner builds from the outerbuild (apart from what sdk provides) and keeps the developer experience the same.
We were rarely using OSGroup before, developers instead prefered to use TargetsWindows, TargetsLinux properties.

[ghost]

Hello @Anipik!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[ViktorHofer]

TargetFrameworkSuffix refers to OS part specified in the targetFramework string. we set TargetsWindows\Linux on the basis of this property. OSGroup referes to the OS we are building the product for

When you say the "OS part of TargetFramework", doesn't that imply the OS we are targeting? So how is that different from OSGroup which also describe as the "OS we are building for"?

[safern]

"OS we are building for" could be Linux, but a project could just define tfm-Unix;tfm-Windows_NT TargetFrameworks, so when building in Linux we will pick tfm-Unix as the best TFM and so "OS part of TargetFramework" will be Unix.

[ViktorHofer]

I see that makes sense. Then BuildOS would really have been a better name, wouldn't it? OSGroup doesn't mean much at all.

[safern]

Yeah. I pushed back towards introducing BuildOS because I understood it was the same as _bc_OSGroup as we had before, and OSGroup being BuildOS, but it was the other way around. Sorry, @Anipik -- maybe we should put it back 🤦‍♂

[ericstj]

Another thought: what if you made BuildTargetFramework be the thing with the OS in it? Then derive OSGroup and TargetFramework from that? Would that be sufficient? Or do we still need to understand the parts of the original BuildTargetFramework at places lower in the stack that will have different values for OSGroup and TargetFramework as appropriate for their projects?

[ViktorHofer]

[Anipik]

BuildOS would really have been a better name, wouldn't it?

BuildOS could have been better, but another point @safern raised was that it might confuse developers who already use OSGroup to build stuff. So we wanted to keep the behavior same as well.

[safern]

Yeah, but now that I see how it behaves fully I was mostly confused, it might make sense to bring BuildOS back, or do something like @ericstj suggested if it meets our needs.

[ericstj]

And another thought. If we start using real RIDs instead of our made up ones we could use the property that defines the Packaging RID for this purpose