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

Red Hat’s wishlist for .NET for 2024 #4005

Open
omajid opened this issue Jan 23, 2024 · 2 comments
Open

Red Hat’s wishlist for .NET for 2024 #4005

omajid opened this issue Jan 23, 2024 · 2 comments
Labels
area-product-experience Improvements in the end-user's product experience

Comments

@omajid
Copy link
Member

omajid commented Jan 23, 2024

Over at Red Hat, we have been thinking about the most important things we would like to see from the .NET project in 2024. This is the list that we ended up with, roughly sorted in order of priority/importance to Red Hat.

Minimize differences between different builds of .NET 9

Issue: #4010

This includes both how the product is built, and what product is built.

We know that Microsoft also intends to move to using the VMR for releases, but there are still differences between how (and what) things are built by Microsoft vs source-build. We would like to see everyone building out of one repo/commit/tag as much as possible and minimize the differences in sources between the sources used for various builds of .NET.

There is also a difference between the contents of the generated SDK, such as which files are in the SDK (see the baseline diff) as well as contents of the files (eg, optimization levels, or the .NET TFMs they are targeting).

Support building SDKs that can build self-contained, ReadyToRun and NativeAOT without nuget.org.

Issue: #1215

Customers like to create smaller self-contained applications, and we would like to be able to support them by making sure that the components used are from the SDK, and we can fix any issues that come up.

This is a left-over from last year.

Finished/polished user story for sources, binaries and symbols for debugging.

Issue: #3225

We would like for users using .NET tools (like VSCode) to be able to build/debug their .NET applications using a source-build SDK, and have the same experience.

We want to make sure any customers running .NET workloads in production can use standard tools like dotnet-dump (and others suggested by Microsoft support) against .NET running on RHEL and containers.

Copy link

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.

@ashnaga
Copy link
Member

ashnaga commented Feb 28, 2024

Discussions and progress -
Minimize differences between different builds of .NET 9 -
Unified build is foundational and will be step-by-step process to minimize the differences (In-progress).

Support building SDKs that can build self-contained, ReadyToRun and NativeAOT without nuget.org. -
This is in progress where bug-fix level work is left- #1215 (comment)
Last step would be to enable acquiring source built ILCompiler pack. @tmds on it.

Finished/polished user story for sources, binaries and symbols for debugging -
With this being broad topic, starting to investigate with VSCode and will share the learnings.

@MichaelSimons MichaelSimons added area-product-experience Improvements in the end-user's product experience and removed untriaged labels Mar 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-product-experience Improvements in the end-user's product experience
Projects
Status: 9.0
Development

No branches or pull requests

3 participants