Design for allowing restore of multiple equivalent frameworks

[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

[dsplaisted]

Could we use the new format only when the project multi-targets and there are multiple aliases that map to the same TargetFrameworkMoniker/TargetPlatformMoniker combination? That might avoid existing projects breaking with older tools.

[ericstj]

I'm interpreting this as supporting a case where you have a project that uses aliases referencing a project that's not using alias.

So if I have project 1 with TFs: net6.0-a;net6.0-b (where both are aliases for net6.0) and it referenced project 2 with TFs: net6.0;netstandard2.0 project1 could reference project 2 and select net6.0 because there is a single nearest framework.

If that's true this is a great middle ground for enabling aliases in a way that isn't viral.

[ViktorHofer]

The spec would benefit from an example to make the intent clear. I agree with your observation. Here are other examples that would work or not work with this algorithm:

Example 1

project1 net6.0-a;net6.0-b references project2 that references the same TFMs. Even though the GetReferenceNearestTargetFrameworkTask algorithm returns two matches, there's a single direct name match so it would choose net6.0-a from project2 for net6.0-a from project1 and same for net6.0-b.

Example 2

project1 net6.0 references project2 that references net6.0-a;net6.0-b. The GetReferenceNearestTargetFrameworkTask would algorithm returns two matches, there's no direct name match so the algorithm would fail and NuGet would report an error.

[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.

[jviau]

For a functions extensibility scenario, I am considering having extension packages include a well-known marker file in their nupkg. I was going to leverage the fact that the assets file already has all nupkg file contents listed in it to speed up that process.

With this change, is the suggestion I would need to manually scan the file system of every nuget package? Or do you have an idea of a more general way I can add metadata to a nuget package and read it during a build?

Today we have an assembly attribute and we use Mono.Cecil to scan runtime assemblies from nuget looking for that attribute. This is understandably not performant. Which is why I am considering the marker file approach. I wouldn't block on this change just for our use case, but some metadata system for nupkgs that can be read at build time would be helpful (but obviously that would be an entirely different proposal).