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.

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.

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.

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.

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

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

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.

nit

nit

nit

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.

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

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?

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