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

Please consider creating self-contained installed bundles #49562

Open
richlander opened this issue Jul 21, 2023 · 2 comments
Open

Please consider creating self-contained installed bundles #49562

richlander opened this issue Jul 21, 2023 · 2 comments
Assignees
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework enhancement This issue represents an ask for new feature or an enhancement to an existing one

Comments

@richlander
Copy link
Member

richlander commented Jul 21, 2023

We have received sporadic reports about users unable to correct configure ASP.NET Core on their machines. This centers on ASP.NET Core installers not including the runtime.

Here is a latest (and quite informative) description of that: dotnet/sdk#33793

image

Proposal is this:

  • Update x64 and x86 installers to install .NET runtime (matching version).
  • Do same on macOS and Windows (where we have fancy installers).
  • Deprioritize the hosting bundle. Perhaps only list it in release notes (or in a different section).

It appears that the zips bundle the runtime, but the EXEs don't. That seems like an odd design choice.

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label Jul 21, 2023
@mkArtakMSFT mkArtakMSFT added the enhancement This issue represents an ask for new feature or an enhancement to an existing one label Jul 25, 2023
@mkArtakMSFT mkArtakMSFT added this to the .NET 9 Planning milestone Jul 25, 2023
@richlander
Copy link
Member Author

richlander commented Aug 8, 2023

This came up again today. Can we get this issue moved to servicing instead of .NET 9? The current behavior is incorrect.

dotnet/runtime#90096

@dotnet-policy-service dotnet-policy-service bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@wtgodbe wtgodbe removed the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@dotnet-policy-service dotnet-policy-service bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@wtgodbe wtgodbe removed the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 13, 2024
@dotnet dotnet deleted a comment from dotnet-policy-service bot Feb 13, 2024
@dotnet dotnet deleted a comment from dotnet-policy-service bot Feb 13, 2024
@elinor-fung
Copy link
Member

We're continuing to get reports around this. It is particularly painful for developers trying to support their end users.
For example: dotnet/runtime#100006 (comment) cc @oblomingo

@wtgodbe I see that this is under 'next sprint' for .NET 9. Is this committed for .NET 9? Could this also be taken for servicing once in 9?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework enhancement This issue represents an ask for new feature or an enhancement to an existing one
Projects
None yet
Development

No branches or pull requests

4 participants