-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Reconsider supporting aspnet and runtime chiseled-aot and chiseled-extra for Ubuntu #5014
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
CodePages (ICU) and TZ tzdata are needed. Might be there a guide how to add them to a resulting image ? |
Please consider providing these image variants. Globalization is unfortunately required in a Web Frontend in order to render localized dates and numbers, and to make use of .resx files. Related discussion: #4955 |
In fact ASP.NET 8 does not support common app: AUTH, MVC or SIGNALR are not compatible - thus AOT looks like a dead-end when considering chiseled image. For me docker file example how to add globalisation support but not using AOT and trimming would be helpful. |
So this is all the magic ? What parametr makes is ? I do not understand how ICU and TZ sneak inside the image ?
|
Aha ! That's what I have been voting for ! So it really exists. This was from MSFT communication not clear to me. I thought it was just an idea... Thx |
If we're doing a |
Adding my vote. We use a shared framework deployment for a number of similar containers and several need ICU/TZDATA. Ideally they would share the same base image, i.e. "aspnet-jammy-chiseled-extra". Currently we manually build our own "extra" base image along the lines of #21, but would very much prefer an official source of such an image. Then we know it is up-to-date, without also diving into build triggers, etc., to keep the hand-crafted base image up-to-date with latest security patches |
We have several microservices all using EF Core which requires ICU through the SqlClient dependency. Having a aspnet/jammy-chiseled-extra image would allow us to slice 40+ MB of every single container by not using self contained publish. Are projects using EF Core (or SqlClient) really in such a minority that the aspnet variant is not justified? Looked at 10 services so far and only one can use the aspnet/jammy-chiseled variant, all others are using either EF Core or Hangfire with a SqlClient dependency. |
Hi folks, we're working on the Ubuntu Chiseled .NET Runtime/ASP.NET Core images now thanks to your feedback. You can track the work in #5021. You should expect these to ship and be officially supported with the January .NET 8 servicing release. |
[Triage] These images are available in the nightly aspnet and nightly runtime repos now. They will be officially supported with the next .NET servicing release (Jan). |
I need TZData as well, ICU could also be helpful |
Great news! I see that the .NET Runtime/ASP.NET Core distroless images with globalization support (-extra variant) are only available with Ubuntu Chiseled. Do you also plan cbl-mariner or alpine? And more generally, is there a guideline available regarding the choice of the distribution to use? |
[Triage] @joegoldman2, there are no plans currently to add There is currently no guidance for choosing between the distros we offer. The closest we have is the Supported Platforms documentation, but that's more about what we offer. @mthalman or I will file an issue to create some guidance there. |
These images are now available in the main |
We ran into an issue recently where we swapped to jammy-chiseled images for our applications and got an error where Microsoft.SqlClient routinely failed. It doesn't support Globalization Invariant Mode and you can set DOTNET_SYSTEM_GLOBALIZATION_INVARIANT to true or false and it won't work in either scenario with jammy-chiseled. aspnet and runtime jammy-chiseled-extra would have solved the problem while keeping dependencies to a minimum though.
dotnet/SqlClient#2206
dotnet/SqlClient#220
The text was updated successfully, but these errors were encountered: