Design for allowing restore of multiple equivalent frameworks (Target Frameworks as Aliases)

[nkolev92]

Design for #5154

Rendered

cc @dsplaisted

[Nirmal4G]

Some ideas and suggestions. Feel free to ignore it. 😅🙃

[nkolev92]

Thanks for taking a look @Nirmal4G

For context, this is design I'm still working on, I'd say it's at about 50%.

Hoping to add more details about the scenarios and just in general provide more concrete proposals soon.

[Nirmal4G]

@nkolev92 These are some of my observations and preliminary suggestions, ideas and takeaways from this draft. I'm not taking this as a concrete proposal. I'm just viewing this from a 10-foot view (or design perspective) of the proposal to see how it could impact normal as well as advanced users. In that mindset, read through my comments again. You would then see what I was talking about.

[Nirmal4G]

Hoping to add more details about the scenarios and just in general provide more concrete proposals soon.

Sure, Will look though once you mark this ready for review. Sorry for the uninvited comments. I'll stop now.

[nkolev92]

Hoping to add more details about the scenarios and just in general provide more concrete proposals soon.

Sure, Will look though once you mark this ready for review. Sorry for the uninvited comments. I'll stop now.

Oh no worries. I appreciate the feedback as this is a large doc so getting feedback early on is always great.

My comment was more about that fact that I'll be adding even more info to the doc, setting expectations about when something like this would even be close to happening :)

[JonDouglas]

@ViktorHofer & @ericstj

[ghost]

This PR has been automatically marked as stale because it has no activity for 30 days. It will be closed if no further activity occurs within another 15 days of this comment, unless it has a "Status:Do not auto close" label. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch.

[zivkan]

oops, vacation and other priorities has kept this feature on the backburner, but it's still planned.

[nkolev92]

@ericstj @ViktorHofer @dsplaisted @baronfel @zivkan @jeffkl

This is ready for review.

It's a complicated, but I'd love to get through it async as much as possible because of the length itself :D

[zivkan]

Customers are expected to change SDKAnalysisLevel if they have build errors when upgrading to a newer SDK. I can't remember the name of the property, but there's an SDK version that feels more appropriate for what this is aiming to achieve.

[nkolev92]

Yeah, there's an SDK version property for sure, we raise telemetry on that, but I see SDKAnalysisLevel to mean, behave like the previous SDK version, and to me that'd imply the older restore behavior in general.

I don't feel too strongly though, and can easily be convinced otherwise.

[zivkan]

In my mind, SdkAnalysisLevel is about warnings and errors (diagnostics), not features, and looking at the original spec, I feel my opinion is reinforced: https://github.com/dotnet/designs/blob/main/proposed/sdk-analysis-level.md

The spec doesn't say it, but I always thought SdkAnalysisLevel was inspired by Roslyn's AnalysisLevel, and Roslyn also has LangVersion which I consider to be the feature toggle. The SDK/NuGet doesn't have a "global feature toggle" like Roslyn does with LangVersion. Using SdkAnalysisLevel is a choice that can be made, but then customers lose the ability to enable new features while disabling new diagnostics. I guess we need to decide whether that's an important distinction to allow customers to have.

[nkolev92]

I think Chet has a good compass when it comes to SDKAnalysisLevel.

Curious what you think @baronfel

tldr;
NuGet will introduce a V4 of the assets file.
It requires a new .NET SDK reader, ie a specific .NET SDK version.

Should that "switch" be based off of the SDKAnalysisLevel or NETCoreSdkVersion property.
More context on the pros and cons in the above comments.

[nkolev92]

@baronfel attempted to post the below, but was facing GH problems:

---

The intent of SdkAnalysisLevel is to easily apply behaviors to all kinds of SDK-level analysis - not just Roslyn Analyzers, but built-in diagnostics, MSBuild BuildChecks, and similar. Any kind of validation that we do during a build was in scope.

This has evolved slightly to controlling behaviors as well - I am entirely supportive of this. The main reason for this evolution/broadening of meaning is that the user-facing view of this property is often "make the current SDK behave like the SDK band I tell you to". With this lens, applying SdkAnalysisLevel to behaviors in addition to validations is entirely appropriate.

[zivkan]

Considering the assets file has an entry for the ridless target, in addition to the per-rid targets, I think it would be challening to tell the difference between the two.

If the parser keeps raw strings in memory and then parses the alias/rid only once all targets are parsed from json, then you can find what the max number of / are, and assume the ridless has n-1.

But I think it's easier if we fail restore if the alias has a /. It's easier to block first and later allow, than the other way around.

Since we're already incrementing the version number, I think it'd be ideal if we could make another breaking change to the format, so instead of

"targets": {
   "alias" : {  },
   "alias/rid": {  }
}

we could instead have

"targets": {
   "alias": {
     "": { },
     "rid": {  }
  }
}

But I suspect this might be a lot harder to implement.

However, as is pointed out just below, the target alias is used as the directory name for the obj and bin directories, and / is a directory separator, so I think that's another reason we could just block / from the alias

[nkolev92]

Yeah, I'd be fine with blocking that yeah.
Honestly, I can't image this to be a super critical scenario that would need to be addressed.
The more changes we make, the higher the risk of the change anyways.

[donnie-msft]

I had a couple questions, and left a few nits.
Suggest having Copilot review spelling/etc and also telling it to put each sentence on a new line in the markdown, as I know Andy prefers that.

[donnie-msft]

And this ages out after 3 major releases, based on how SDKAnalysisLevel works, right?
In other words, there's ample time (years?) for a customer to move a solution to version 4.

[nkolev92]

Yes, it allows plenty of time to move to newer SDKs.
By that time, all .NET SDKs in support will support v4.

[donnie-msft]

As a reader not as familiar with targetAlias, I'm not understanding how this is simple. Why would I use targetAlias and framework?

[nkolev92]

The simplicity I am referring to is from an implementation perspective.
It would allow us not to version the "PackageSpec", but just the assets file.

If we drop the targetAlias, we'll need to somehow version the package spec to tell the writer what to set as the TargetAlias.

Hopefully the implementation PR clarifies this.

[donnie-msft]

Is there a scenario where targetAlias can be selecting 1 of multiple aliases? Let's say I have "production" and "staging" and "development", can I then set targetAlias to any of those three?

[nkolev92]

Who's the setting them in this case?
I'm not sure I understand the scenario.

This is mostly just technical details for us.

[donnie-msft]

Could this be simplified from the textual scenarios into a small matrix of scenarios?

[nkolev92]

I'll push a follow-up to this.

[baronfel]

Quick feedback on this spec (which is comprehensive in all the right ways - thank you!) that I wanted to get down:

Bundling more kinds of 'things' into TargetFramework-shaped holes makes sense because the only kind of 'foreach' we've built into our platform so far is TargetFramework. An alternative, which would likely be much more work but may be more extensible and/or orthogonal, would be to

Consider making the 'pivots' of multitargeting more extensible

Meaning, let a project and/or MSBuild SDK define a list of properties that should be cartesian-product-ed together when doing any kind of 'for-each-able' workflow (build, pack, publish, etc).

Now, I don't necessarily think we should do this, bit it comes to mind as an alternative to this proposal, and I don't see a section where alternatives are considered and criteria for rejection are listed.

[ericstj]

Dependencies only have a single slot for TargetFramework. I agree that there is no solution to alias dependencies.

Assets/build-output on the other hand is a different story. For example, folks using alias for runtime it's perfectly reasonable to include all aliased frameworks and allow each target to specify it's package path.

Then it's up to the project to decide which alias is used for dependencies.

I can imagine us building first-class support for this behavior. We could designate one alias as being used for dependencies, or we could allow the project to assert that all aliases should have identical dependencies (and validate that).

A couple common cases that I'd like to see us build minimal examples:

1. Project building a .NET package for multiple runtimes with API and dependencies represented in runtime-less output.
2. Project building a roslyn analyzer targeting multiple roslyn versions, omitting all dependencies.