Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish* properties should affect build -- making those apps RID-specific #34309

Open
richlander opened this issue Jul 27, 2023 · 3 comments
Open
Assignees
Labels
Area-NetSDK untriaged Request triage from a team member

Comments

@richlander
Copy link
Member

We've adopted the philosophy that we should apply user intent as early as possible in the development process so that developers have a chance to address all knowable problems while they are actively coding, avoiding preventable problems later in the process, and specifically in prod deployment. Crashes that could have been resolved (with more information) during active development are really unforgivable.

We call this philosophy "shift left". It's called that since we think of "left" as early in the development process and "right" as late, just like the process of reading a book (in a left to right language, like English).

We do this for analyzers, enabling various analyzers to run with build, based on the presence of Publish* properties. Example : https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=net7#aot-compatibility-analyzers

With that thinking, we should ensure that restore, build, and test do their best to provide high-fidelity results based on the intent described by Publish* properties.

The properties in scope:

  • PublishAot
  • PublishReadyToRun
  • PublishSelfContained
  • PublishSingleFile
  • PublishTrimmed

These properties all require/enforce a RID-specific. When any of those properties are present, the app should be RID-specific (including for restore).

It isn't clear that there is another change to infer, beyond making apps RID-specific. If there is, we should discuss it.

I'm proposing we make this change for 8.0.200. It's a breaking change, but arguable resolving a correctness issue. This would be a first step to making all apps RID-specific by default in .NET 9. I'm not entirely sure what the gesture would be to undo this change in behavior (if you didn't want it). We'd have to invent one. I think we had some ideas on that previously.

This change would also make these app types work better with Docker since various packs would be downloaded sooner (shifting those left as well).

Related: #34198

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-NetSDK untriaged Request triage from a team member labels Jul 27, 2023
@richlander
Copy link
Member Author

@rolfbjarne
Copy link
Member

Implementation note: mobile apps may use "RuntimeIdentifiers" (plural), as opposed to "RuntimeIdentifier", and should still be considered "RID-specific". If not taken into account this may happen: #33414

@richlander
Copy link
Member Author

That makes sense. Assuming you get two RID-specific builds for dotnet build, then your app type doesn't have the problem that this issue is proposing to resolve.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-NetSDK untriaged Request triage from a team member
Projects
None yet
Development

No branches or pull requests

3 participants