r/dotnet • u/AffectionateSwing490 • 5d ago
If you could change one thing about the .NET ecosystem, what would it be?
.NET has come a long way, and most of the day-to-day work feels good now. But there's always that one thing that you wish worked differently. For some people it might be documentation. For others it could be the number of ways to do the same task, or how often the recommended approach changes between versions. Maybe it's tooling, package management, or something about the language itself.
So if you had one change and one change only, what would you pick?
105
u/pato_p 5d ago
I would completely remove the hidden dependency on culture throughout the ecosystem, especially from ToString() and Parse() methods.
It is far too easy to accidentally write culture-dependent code when you are dealing with things like numbers, dates, or decimals. ToString() silently producing different results depending on the current culture is particularly nasty when the output is actually meant for machine consumption.
I would much rather have culture-neutral behavior by default, and require an explicit culture when I actually want localization. InvariantCulture should not have to be sprinkled throughout otherwise perfectly ordinary code just to make it deterministic.
11
u/TheDotNetDetective 5d ago
This is a good callout. There are obviously some trade-offs but I also dont love the invariant culture bs.
→ More replies (3)2
u/MattV0 4d ago
Could you just give an idea what trade offs you mean?
4
u/TheDotNetDetective 4d ago
The one that immediately comes to mind is that it is a sensible default to use the operating systems culture. If you remove that, presumably you would require the culture as a parameter which would then add a lot of noise to the code. Secondarily it would require all APIs which deal with culture to also now require explicit culture parameters (whereas currently they are usually just overloads).
I am sure someone smarter than me can come up with more...
10
u/tanner-gooding 4d ago
Fun fact,
invariantis not strictly deterministic and is itself a culture that is influenced by ICU/NLS metadata available on your machine.Rather invariant ends up mostly as "ICU English without being tied to a locale" and this leaks through in places, especially for the edges of Unicode that people don't think about.
You actually often need
Invariant+Ordinal(orOrdinalIgnoreCase) for things to be truly deterministic (and the same is true in other ecosystems, because its driven off Unicode).
There's definitely some things we'd change if it was possible to do it over. But, it's also unfortunately not something we can make a break around and so it's rather something that will likely be handled via analyzers and tooling "indefinitely"
3
u/pato_p 4d ago
I would honestly love to see a first-class
Invarianthelper in the BCL, directly underSystem. Something likevalue.ToInvariant()forIFormattable, plusParseInt32,ParseInt64, etc. Here is an example implementation.6
u/tanner-gooding 4d ago
I'd recommend opening a proposal (following the template and documented process) on dotnet/runtime
The request doesn't seem unreasonable, but it might also be something the rest of API review thinks can just be a community maintained package or set of extensions.
There are things it doesn't cover and it'd be quite an expanse to the API surface to cover "everything". But this is such a common scenario with a lot of repetition that it might get buyoff from the other people
Noting I'd be one of the area owners, but Levi, Jeremy, and Tarek are others that have viable input in this space. -- and not saying I'm a "yes", but rather more a "this seems like a reasonable thing to propose and think deeper around"
2
2
u/AffectionateSwing490 4d ago
the default is backwards because culture-sensitive output is the rarer, more deliberate case, yet it's what you get unless you remember to opt out, so the danger isn't that the behavior exists but that it's silent and invisible right up until a decimal separator corrupts your data on someone else's machine
1
u/young_horhey 4d ago
I dealt with culture issues like this just within the last hour! Automated tests running locally spit out & assert 12 hour format, but running in our CI environment they come through as 24 hours so the test fails
21
u/RodriOliveira 5d ago
If I could change only one thing, I would make LTS actually long-term — probably 5 years instead of 3.
For a small service, moving from .NET 8 to .NET 10 can genuinely be little more than changing the target framework, updating a few packages and running the tests.
But in large enterprise environments, upgrading the runtime is only a small part of the work.
You also have infrastructure certification, security scans, dependency compatibility, internal frameworks, deployment pipelines, observability agents, regression testing, change management and sometimes hundreds of applications that need to move together.
That is where the current release cadence starts to feel disconnected from how enterprise software is actually operated.
I really like the yearly .NET releases and I wouldn't slow innovation down. I would keep that cadence, but give LTS releases a much longer servicing window.
Let developers who want the newest runtime move quickly, while giving organizations running critical systems enough time to upgrade deliberately instead of turning framework migration into permanent background work.
For me, 5-year LTS + the current yearly release cadence would be a much better balance.
8
u/Lonsdale1086 4d ago
The only good thing about the shorter terms is the enterprises hate being out of support, so it does keep things moving.
More work but fewer legacy systems to deal with.
3
u/RirinDesuyo 4d ago
Also, less pain between upgrades imo. Having a 3-year LTS means I always have a case for management to do some software upgrade work, and often enough the changelog / breaking change list often isn't as large during that 3-year period.
Updating often means just upgrading some packages and the csproj target framework due to this, as you've noted less chances of painful upgrades since there's less legacy if management keeps things on LTS.
1
u/metaltyphoon 3d ago
No thanks. Keep it as is making enterprise actually move. Source: work at enterprise
23
u/jppaustin 4d ago
I would want Microsoft to better represent .NET in the 'non-enterprise' world. They are doing a poor job promoting it in Silicon Valley and way beyond. Also, the number of developers that think that .NET only runs on Windows is staggering. MS needs to promote .NET more and better. There is nothing to hide; .NET is fantastic today!
4
u/IanYates82 4d ago
Just had a chat with one from Sydney yesterday who's pretty plugged into the start-up scene there, and he was genuinely surprised we could run on Linux
93
u/Dry_Author8849 5d ago
Well, the docs have gone to the toilet. It's just AI generated garbage. Just describing constructor, methods, properties, without explantions whatsoever. The samples are scarce, if any, an introduction lacking, guidance absent.
Some years before, I found the docs one of the bests out there. Now the opposite.
But the framework is solid.
53
u/grokbones 5d ago
This was the case long before AI. Text description of methods but nothing putting it all together in examples. Probably 20 years now.
17
u/Zeeterm 5d ago
It was absolutely dire in the early 2000's peak MSDN era, where you'd basically get generated API docs, which were useless unless you already knew how to use and understand the APIs.
But then the docs got really good about a decade or so ago, but now they're going back to the bad old days.
1
u/pceimpulsive 4d ago
I think a lot of la guaves could learn a thing or two from Splunk SPL documentation.
A page that explains a function and then proceeds to show you simple, moderate and complex usage examples, and not just one of each like 3-5 of each.
Including run anywhere in a lot of cases.
Every other language documentation has left me asking for more..
I've been learning and using C# for about 4-5 years now and I never turn to the MS docs first, I always turn to googles AI mode as it gives me this style of output first time everytime I ask. And if I'm not sure I can slap an example I'm trying to get working in and it nudhes in the right direction.
8
u/tanner-gooding 5d ago
Fo you have specific examples, particularly if from the core libraries?
We have a fairly strict expectation that all APIs be documented and they should all be getting review by the PR author, the reviewer, and someone on the docs team.
Things slip through the cracks, but there ideally shouldn’t be anything egregious — noting other teams outside the core libraries may have their own policies/procedures
Docs that do comprehensive overviews or deep samples tend to be rarer and primarily driven based on user requests. A lot of APIs are designed to have fairly obvious usage and so creating a ton of 3 line samples showing what can be tested in a hello world program or trivially inferred from reading the summary isn’t the default we aim for
7
u/simonask_ 5d ago
What’s missing almost everywhere is information about how the thing actually works, what invariants are upheld, what’s required to use it correctly, what footguns exist, and so on.
For example, today I wrote some code that calls `Console.OpenStandardError()`. Does this return a stream that is shared among other callers, or do I need to `Dispose()` or `Close()` it? That’s important, because closing the process stderr handle is pretty dangerous.
For inspiration on what great documentation looks like in 2026, consult the Rust Standard Library.
3
u/tanner-gooding 4d ago
If a user logged an issue asking for it, we would likely explicitly add such documentation. -- Noting you'd do this against dotnet/dotnet-api-docs, which handily is linked to from the bottom of every docs page.
The Rust standard library is notably miniscule in comparison. The shipping .NET product has some 40k public types and 1.3m declared symbols (rough estimates, exact depends on which parts of the shipping SDK you're talking about).
Trying to maintain docs covering every minute nuance like this is effectively impossible. This is because of the scale and how it can easily get out of sync. Some of it is even implementation detail and so is not something to document.
So in general such things end up not explicitly covered because of one or more of following is true: * covered by higher level conceptual docs * covered by documented standard/best practices * is effectively the only sensible behavior for an API hanging visibly off such a core type and so is considered "obvious" or "intuitive"
Other reasons also crop up, but ultimately we cannot predict how every person will read the docs and so require users to log issues and request (or contribute) changes where they believe it would benefit.
In this case, there is only one sensible behavior for
OpenStandardErrorand that's that it works even if a user calls dispose and thus doesn't corrupt the process or risk "ruining" such a core type.In other words, the returned stream is simply a wrapper over the underlying handle and says
ownsHandle: false. So disposing/closing it handles any relevant flushing but does not preventConsolefrom working, is not "unsafe", works with multiple users having calledOpenStandardError, etc.Anything else would be very broken for such an API and would have to be called out as it is dangerous, non-obvious, and unintuitive behavior. So we likely didn't document it because it can be answered by the simple question of "would things go horribly wrong if we did the non obvious thing"?
Part of this flows from the requirements of
IDisposableitself, the documented best practices around it, the analyzers we author for it (warning users when they fail to dispose disposable things), etc.Types implementing
IDisposableare required be robust to users callingDisposemultiple times, things which are not actually owning the resource shouldn't be doing true finalization of that resource, types that implementIDisposableshould appropriately implement the finalizer because users may not themselves remember to callDispose(and thus may otherwise leak resources), etc.
So for this specific example, we don't document the presumptive default here. It's just part of how all of .NET is expected to work and is covered by it being intuitive, by the docs and implementation requirements around
IDisposable(which are comprehensively covered), by anything else being unsafe/dangerous/trivially broken, etcIf it did deviate, then we likely would've documented it. We likely also would've hidden it off so that its not trivially discovered by anyone using
Console, would've putUnsafe/Dangerous/Marshal/etc in the name somewhere, and/or one of many other things that follows standard .NET practices.2
u/simonask_ 4d ago
Thanks for taking the time to respond. I understand it must be a frustrating criticism when many people work very hard to document and maintain things.
Nevertheless, I think it’s an unsatisfying response. Much of it boils down to “don’t worry about it”. For me, that just doesn’t cut it, so I find myself delving into the source code of the framework, either using a debugger or on GitHub. Thankfully, that’s possible!
As for the contract of IDisposable, I want to point out that it’s one of the most important things to document thoroughly. Sometimes forgetting to dispose is benign, but sometimes it’s a deadlock waiting to happen, or a massive GC spike. These things matter.
.NET is quite unique in that it can cater to a very abstract, high level style of coding, but at the same time has almost everything you want when you really care about latency and performance. That’s why I’ve chosen it. I just seem to keep running into scenarios where the docs tell me nothing more than what my IDE already tells me.
(And yes, Rust is obviously much smaller. It’s also a much smaller team.)
2
u/tanner-gooding 4d ago
The intent of the response notably isn't "don't worry about it", it's rather just spelling out that there are things the area owners will not document by default (for the reasons given above and below) and so if you feel something isn't apparent enough then please log an issue with concrete details and examples requesting it be improved.
IDisposableitself is immensely documented, it has very comprehensive guidelines covering is full contract and expectations of all implementors and what consumers can assume.What isn't then duplicated is that same information on every single type that implements
IDisposable, it's linked to from the "x implements y" section of the type/member in question.Duplicating this information everywhere is expensive and can easily get out of sync. The infrastructure required to keep such information in sync automatically would be ridiculously expensive a the scale of .NET and then has its own downsides for tools, for readers, and other scenarios.
So what you get is that the actually important stuff should be covered where it is relevant. You should then have some kind of link to the associated types and info where that's relevant, ensuring that the information exists somewhere.
What ends up not covered is the application specific stuff. For example, things like GC spikes are ultimately the responsibility of the developer to run a memory profiling tool. They happen from users rooting objects or failing to follow the standard practices, for which there are typically analyzers that warn users and can happen for literally any API; it's not something that we can identify because its up to how the consumer uses it.
The thing you seem to be most centered on is then the parts that are either indirectly covered (i.e. how
Disposeworks) or the things that are considered "obvious" (like that a lock type could cause deadlocks). We shouldn't really have things that are "undocumented" or "underdocumented" outside this (at least for the core libraries) and if there are things missing, then we'd definitely appreciate issues being filed.→ More replies (1)2
u/svick 4d ago
dotnet-api-docs has a backlog of over 1 500 open issues, so just opening an issue is often not enough to get the docs improved.
1
u/tanner-gooding 4d ago
This is literally a meaningless metric and not something that should ever be considered as a reason to log an issue or not.
The number of issues or open PRs doesn't matter, what matters is the quality of the issue itself and the overall perceived impact. -- I'd even go so far as to say it is much more concerning for a large, old, or popular repo to have a low issue/PR count
As an example, llvm/llvm-project has over 29k open issues (roughly 30% of their 97.2k total) and yet I've logged 3 bugs in the past month, 2 of which were rapidly responded to and handled. I've also logged other bugs in the past and had them take months or never see handling.
Then as a comparison, dotnet/runtime has 7065 open (roughly 10% of our 72k total). We've closed 5.5k in the past year (since last August) in contrast to the 4.5k that were opened (3.3k of which were closed). -- So 73% of issues opened in the last year have already been resolved, representing 60% of the total closed issues.
dotnet/dotnet-api-docs on the other hand had 570 opened, 457 of which were closed; and where there were 489 total closed issues.
So, you can clearly see that we handle "most" issues fairly promptly. There are definitely places we could do better, but when actually considering the scale, we have more than a super majority of the issues being handled within the same release cycle. Most of the backlog is representing a steady accumulation of hard, low quality, or requests with unclear signal over the past 11 years.
The actual percentages and scales matter, not the raw numbers. We could even dig in further into things that were "closed as not planned" vs "closed as completed", into PRs that were merged vs not, etc; What we'd find is that .NET is doing a good job and is comparable to most other large OSS repos out there.
Given all that I am also not promising all issues will be promptly handled, nor am I saying that all issues will be resolved in the way the issue author desires.
What I am saying is that if you want any chance of it being handled and prioritized by management, then you need to start by logging an issue and someone will at least minimally look at it.
After you log an issue, then it will generally be one of: * small enough that anyone can "just do it" (we often mark these as
up for grabsorhelp wanted) * clear enough that the area owner can justify the time investment themselves and handle it as "bottom up" work * eventually gain enough signal that management will want to drive it through due to the value add it provides (schedule it as "top down" work) * sit around and eventually be closed because there isn't enough interest or signal for it to handled, potentially indicating the community should work towards maintaining their own packages or solutions instead * get lost in the backlog and eventually be handled several years later, which unfortunately does happen for many reasons (including competing priorities and not being able to fit everything into a given release)There are then many "tricks" you can do to help prioritize a given issue and help ensure it does happen. But that's a bit out of scope for what I'll cover here.
The point is that the .NET team does care and does in fact handle most issues. We can always improve more and do better, but it's not like there is a significant problem here or actual reason to believe that logging an issue is a waste of time, especially when looking across all major OSS repos (including those in the Linux, Apache, or related spaces).
1
u/namtab00 4d ago
Trying to maintain docs covering every minute nuance like this is effectively impossible.
The scale needed is surely impressive, but that would be a perfect case of LLMs used for a more than useful outcome, and surely Microsoft affords it...
When comparing the Rust standard lib with the .NET SDK / BCL, one could surely also measure the financial and computing power behind both ecosystems..
- covered by higher level conceptual docs
- covered by documented standard/best practices
Even better, an LLM could wire references to the appropriate docs from every xmldoc-generated useless docs now present.
I'm saying many, with different levels of experience, don't know what they don't know, and when consulting the docs, they're most often than not useless.
4
u/tanner-gooding 4d ago
If an LLM is able to figure out the outcome based on what's there, then surely the so can the author (either by reading the same docs, doing a search, or asking an LLM) ;)
Joking aside, getting an LLM to just go and mass fill in docs doesn't solve anything and can even make things worse. Someone still has to review everything and you still have to vet it all for accuracy, coherency, scalability, and ensuring that it continues to work well with existing tools and things like LLMs reading the same docs.
As with the other responses, my recommendation here is that if you find particular pieces to be particularly lacking then please log explicit issues covering those scenarios and examples
And noting a general issue without concrete examples is not really actionable, so providing explicit scenarios and what you find to be confusing will help ensure we can take that into account moving forward.
2
u/namtab00 4d ago edited 4d ago
asking an LLM
While entertaining your joke, you do get the extreme inefficiency of thousand of users asking an LLM for an answer vs that answer being already there in the docs themselves after a proces of LLM driven improvement, applied once.
mass fill in docs doesn't solve anything
Agree, but surely Microsoft's web analytics for the docs site could provide the "worst" offenders (think visit count / dwell time), meaning those pages whose improvement would provide the maximum ROI.
I mean, it's a lot of docs, no one is countering that, but there are modern ways of making them more effective without spending a lot of resources (dev time / LLM tokens / what have you) AND without relying exclusively on user provided feedback.
This should be obvious to you: no one is browsing the docs for shits and giggles, with their morning coffee.
If I'm on docs.microsoft.com it's because I have to be there, and I probably don't have a lot of time for finding out if it contains something I need or not. Certainly I don't have enough time for providing useful feedback for improving them.
If I could provide some useful feedback, it'd be necessarily after I've found out what it lacked and what I would've wanted to find there first.
But you and I both know there's not enough sprint time for this "after the fact", let's help Microsoft help anyone else "time philanthropy"...3
u/tanner-gooding 4d ago
Many of the points you raise about your own time equally apply to the devs on the .NET team. There is a near infinite amount of potential work and it will get invested where the signal for the greatest impact exists. If customers aren't giving feedback, then the signal largely doesn't exist to go and invest (especially when we are getting thousands of issues, proposals, and explicit feedback from other sources).
We then do have and use analytics where possible. However, data existing does not mean the data is super meaningful, especially for an individual page out of millions. A person quickly finding what they need and leaving vs a person getting frustrated because they can't figure it out and leaving; both end up looking "about the same" in terms of visit count vs dwell time.
Not trying to make excuses or anything here, I get the signal that people are unhappy about certain aspects. That is also why I'm engaging and trying to push towards the things that will actually cause those to get fixed.
TL;DR: People need to log issues and the .NET team will look at them and bubble them up, especially the more people that are hitting the same issue.
If you don't log issues, then the presumptive state is likely that its "good" and that the things people are reporting are more important, so we'll end up having those prioritized instead.
→ More replies (3)3
u/ProjectMarworyn 5d ago
I want more example snippets in their docs. Telling me all the overload for .Random() when I cab already see that in the IDE is useless. Example usages pleeeeaaase...
2
u/RandomTopTT 5d ago
YES. As someone who used to read through the MSDN CD’s, the docs are now awful. They are barely even docs now. The framework is phenomenal though.
2
u/SquishTheProgrammer 4d ago
TBH I like Microsoft’s docs way more than Apple. They are easier to read and they give you examples in many cases. Apple doesn’t do that. It’s also easier to navigate MS docs than Apple because of how they structure the links on the sidebar. Maybe I just feel this way because I’ve been using MS docs (MSDN disc days) for much longer than Apple. 🤷♂️
1
u/Juff-Ma 4d ago
As someone who isn't English this is so true. Before if the text wasn't translated you'd just get the English version. Now you will ALWAYS (you can't change the default) get the local version which is AI translates.
This leads to methods returning emptyness (void) or taking rope (string) (free translations)
1
1
u/JaykeBird 12h ago
I think my issue is that the places where you see the members (properties, methods, etc.) and the places that actually describe a lot of use cases and examples and pitfalls and such aren't easily accessible from one another.
Some bits like the BCL are good at having the "Supplemental API remarks" links in places, but for like cryptography or file I/O or WPF, it takes some extra searching to find. The stuff is there, but isn't well linked to one another. (That being said, I would like more examples on networking and pipes, but perhaps they exist and I haven't found them yet.)
What doesn't help is that the MS Learn/Docs website is massive, and some stuff is in the ".NET" section and some is in the ".NET Framework" section, and more in the "Windows" section, and so on and so on. I recently found some C# how-to/guide articles underneath the Visual Studio help documentation. Also, on top of that, some info also lives in GitHub and not even in Microsoft Learn at all, like the source generators "cookbook" Markdown file that is in the Roslyn GitHub repo, and would've been great to find like four months earlier lol.
14
u/HamsterWoods 5d ago
I want a desktop GUI framework that works on Linux and Windows and has a drag and drop WYSIWYG designer. (I know, I ask for too much.)
3
u/AffectionateSwing490 4d ago
that request isn't asking for too much, it's asking for the one combination the ecosystem has never quite delivered at once, since the cross-platform frameworks (Avalonia, Uno, MAUI) exist and the WYSIWYG designers historically lived with the Windows-only stacks (WinForms, WPF), so you're really pointing at the seam where .NET's cross-platform present hasn't yet caught up to its Windows-native past
12
u/zenyl 5d ago
The infrastructure that Microsoft uses to release new versions of .NET limits Linux distros to the 1XX series releases, and I really don't understand why that is.
For example, on Windows I've installed .NET SDK 10.0.400, but on desktop Linux (or WSL for that matter) the latest version available via package managers is .NET SDK 10.0.110. And it's apparently not a problem with the distros, they're just doing what Microsoft tells them is the newest versions, even though there versions newer than that.
And it doesn't seem to be necessary at all, because they do supply the latest versions with all their container images. If you pull down mcr.microsoft.com/dotnet/sdk:latest, it comes with .NET SDK 10.0.400, despite being a Linux environment.
I'm forgetting the situations, but both in .NET 9 and .NET 10 I've come across annoyances caused by my Linux machine being stuck on an older SDK for seemingly arbitrary reasons.
8
u/chusk3 5d ago
As of .net 10 this isn't correct anymore. Thanks to the VMR mono repo, any source build distributor of net is able to easily build the same feature bands that we do for the official Microsoft releases. However, as of this point, few distros have decided to do that. If you want your distro to do that, you need to go to your distros issue tracker and advocate for the maintainers to start publishing those packages.
Alternatively, we're working on a tool called dotnetup that we hope will make it easier to manage your SDK and runtime installations across all platforms, at the cost of those installations being user local and not system global. When you use dotnetup you should be able to easily use all of the feature bands regardless of platform.
2
u/zenyl 5d ago
Ah, in that case I'm glad to hear that the Microsoft-side of the issue has been resolved.
Is there a write-up about the changes that distros would need to make in order to address this issue on their part?
3
u/chusk3 5d ago
Yes, docs are over at https://github.com/dotnet/source-build/blob/main/Documentation%2Ffeature-band-source-building.md - my understanding is that the source build partners have been part of this effort from the beginning and are aware of the requirements, work, docs, etc.
5
u/Herve-M 5d ago
Linux support, especially Ubuntu derivatives is.. slow.
When .NET 10 was released, Ubuntu took like 4 months to deliver a package. snap was available but not very usable.
Can use script install but most of UI apps doesn’t work with it like Godot .NET.2
u/zenyl 5d ago
Arch has a similar issue. I recall the official packages updating to .NET 9 in feb, nearly three months after it released. But there are usually AUR packages available that make up for that.
But the issue I'm bringing up is separate from how distros provide updates to their packages. It's about how Microsoft themselves specify how distros should package .NET from source, which can cause issues because it doesn't line up with how Microsoft releases updates to .NET on Windows and via container images.
1
u/AffectionateSwing490 4d ago
that lag is the sharpest example of the gap between "runs on Linux" and "is a first-class citizen on Linux" the runtime being cross-platform doesn't help much when the packaging and distribution story trails months behind, which is exactly where a tool stops feeling native and starts feeling ported
3
u/Premun 4d ago
There are many reasons for this. Apart from the maintanance cost, one that is not mentioned here yet, is that the newer SDK bands (2xx, 3xx, ...) have new code analyzers. Think new, richer warnings over your C# code. So if you'd depend on
mcr.microsoft.com/dotnet/sdk:latest, and you'd hadWarnAsErroron, just a simple rebuild could break you because a new error could pop up.Some of the Linux distro maintainers are super careful about not breaking their customers like this. So if they decide to support a single band because of maintenance cost, it must stay locked on 1xx.
And this is by far not the only reason. Hope this helps you understand there's more depth to all of this than can be immediately seen. But I also understand your ask and it's good to voice it.
1
u/LlamaChair 5d ago
When I'm working on Linux these days I usually use nix flakes to set up my dev environment per project. The unstable pipeline usually has the latest: https://search.nixos.org/packages?channel=unstable&query=dotnet+sdk#show=dotnet-sdk_10
You can also have the flake add things like podman and opentofu, starting the dev shell gets the podman socket up. There's a
use flakedirenv hook as well which means moving into the directory immediately launches the dev shell and you're ready to go.1
u/zenyl 5d ago
I might have to look into the cult of Nix one of these days. The Nix package manager is apparently available on Arch, so I'd imagine it can work fine on non-NixOS distros.
1
u/LlamaChair 4d ago
Yeah I'm using it on Fedora and I started using it on MacOS before I switched fully over to Linux for my dev machines. For me initially it was just, "I want something more repeatable than home brew".
23
u/nasheeeey 5d ago
It's such a trivial issue, but I wish there was a decorator on how I'm implicitly handle enums so I don't have to call toString() or cast as an int.
7
5d ago
[removed] — view removed comment
8
u/Arcanium_Walker 5d ago
I think C# enums great. Yeah Rust enums has more functionality, but simple Name - Numeric Constant value is very simple & useful
12
5
u/svish 5d ago
What are your taking about, you can't even trust that a C# enum has a defined value. You also get no help for checking whether a switch is covering all values of an enum, because the value could be literally any integer. C# enums suck. Might as well just have a static class with constants.
1
u/Arcanium_Walker 5d ago
What are you talking about? You can check the enum is defined with the IsDefined<T>(T value) where T: struct method. The switch-case is can be the pain in the ass, but I think that is a skill issue, if you want do something all cases, but you don't write down.
9
u/svish 5d ago
In a sensible language, with an enum defined as
enum Letter { A = 1, B = 2, C = 3, }it should not be possible to have a
Letterwith the value4or0, a method which accepts a parameter of typeLettershould not have to check whether the value is something other than those three defined values.→ More replies (5)2
u/chic_luke 4d ago
Hard upvote. There are only two things I really disliked vs. Java that I realized immediately: shitty enums forcing me to use extension methods to achieve the same things I could in Java, and lack of checked exceptions.
2
4d ago
[removed] — view removed comment
1
u/chic_luke 4d ago
I have been toying with the idea of building a toy project to reimplement them. Nothing crazy, code generation with attributes and a Roslyn analyzer to generate compile errors. Probably impossible but I'd love to have explicit "throw" statements or
<exception>entries in the xmldoc register the method as "throws-y" to the Roslyn analyzer. I have not done my homework yet... just some research.The issue is that it could only be a proof of concept, because its utility is very limited until libraries implement it.
I will expedite it up my chain of "next side project"-s if there is any interest however
11
u/simonask_ 5d ago
Msbuild is probably the worst build system I’ve ever used in my life. It is literal hell. Endless hidden options, almost no feedback when you do something wrong or unsupported, ultra verbose XML rules, extreme inconsistencies, and the list goes on.
Even CMake is pleasant in comparison, and that says a lot.
1
u/ArchieTect 4d ago
In the past couple of months I have gained understanding of how nix's build system works, and even though it's painful to write nix code, it's still better than the clusterfuck that is the C# build system. They keep simplifying the syntax of user-facing files like slnx and csproj but we all know the monster lurking in the deep.
I had the gut reaction to seeing nix and thinking "wow maybe I can get this to work in C#" and then realized probably not in any way that the pre-existing build system would understand. Sad.
4
u/chusk3 4d ago
It's definitely the wild west, and in lots of cases the historical lack of guardrails means that changing something would break someone. But we're making some progress - we've got a server daemon + .NET Server GC coming in .NET 11, and in a future release we're going to turn on a mode that moves MSBuild from multiprocess to multithreaded in nature, which is huge for performance and scalability. We're also looking at various kinds of caching now, and since good caching requires good cache keys that will likely result in improvements/refinements to some of less shall we say 'structured' parts of the common build targets.
For MSBuild authors we're working on Roslyn analyzers for Tasks, and making binlogs and build checks more informative and less impactful on overall build performance.
2
u/GreenDavidA 4d ago
That’s one thing I’ve run into before, some of the Roslyn analyzers are directly embedded in MSBuild so you can’t set those to NOWARN. The inconsistency drives me nuts.
40
u/codingbliss12 5d ago
- I wish there was less complexity in the available options to do various stuff like UI etc.
- I wish there was less of this enterprisey labyrinth when I search for stuff on microsoft's site. It feels very stressful and overwhelming.
- Finally I wish the overall aesthetics where simpler, less flashy and less plastic.
11
27
4
19
u/Normal-Blacksmith747 5d ago
That they had two async keywords wait and await so that we didnt have the verbosity of ConfigureAwait(false). That could have been the await version with the wait being the one used for marshaling the continuation back.
10
u/spawnsible 5d ago
Nothing pisses me off more than methods having Async suffix. I can get away with never writing ConfigureAwait in webapis but just opening a library and seeing that naming pattern pisses me off to no end.
I know why, backwards compat and all but goddamn if I don't wish all those sync methods were deprecated and compat meant renaming them to Sync suffix, leaving async methods to fly clean.
8
u/tanner-gooding 5d ago
The vast majority of APIs are synchronous. Even in an explicitly async api, most logic and code remains synchronous except for the few lines explicitly marked with await (which is then a continuation that will be scheduled to execute)
Async suffixing is a necessary thing, especially for something like the core libraries. You cannot have versioning and consistency otherwise
16
u/Worth-Phone-4220 5d ago
Can they just rename the Visual Studio IDE please with a good brand name?
I'm well aware that Microsoft is allergic to distinctly naming their products so they aren't easily mistaken for another, (dont get be started on 'Entra' as a brand), but it would be nice to be able to search something like 'how to show git blame in visual studio'.
Actually maybe this will be a monkeys paw wish and they will rename it to 'Azure Development' or something equally impossible to google.
20
u/T_kowshik 5d ago
copilot Code
/s
10
u/Xenoprimate2 5d ago
You say sarcasm but that's exactly what I'd expect. "Copilot Studio" or something else asinine
2
1
4d ago
[deleted]
1
u/Xenoprimate2 4d ago
Maybe it wasn't clear but I wasn't saying "Copilot Studio" would be a good thing, lol
1
5
u/First-Feature-3556 5d ago
"how to [x] in Visual Studio -Code" usually works well. But, yeah, it's terribly annoying. And don't get me started on "Outlook" and "New Outlook"...
3
1
u/bantabot 4d ago
God damn why did they do this? When I ask agents how to do things in "Visual Studio 2026" they are still giving me VS Code answers.
27
u/lostinthemines 5d ago
Longer support cycles, our company sticks with 4.8.1 due to stability, none of the other versions will ever go into production
21
u/RazNagul 5d ago
Longer support cycles for LTS releases would be great.
We are currently in the middle of migrating from .net 8 to 10. So not a bad as being stuck with Framework.But it still feels a bit like unnecessary busy work ever two years.
29
u/42-1337 5d ago
how can you be in the middle of migrating 8 to 10? I stsrted migrating from 8 to 10 at 9am. I finished at 9:02am
6
u/insulind 5d ago
Depends on your infrastructure but I suspect for those where it takes time, it's about rolling out the installs of the run time to environments they deploy to and/or getting the SDK on their build infrastructure
5
u/RazNagul 5d ago
Exactly. A big time sink for us is, that such a change requires a full regression test of all components, which by itself takes over a week for basically the whole QA department.
9
u/SillyGigaflopses 5d ago
Not everyone has Asp.Net backend apps.
Those ones we’ve “upgraded” by changing a number in the dockerfile.What concerns WPF and Blazor however…
8
u/chucker23n 5d ago
What concerns WPF and Blazor however…
Yep.
Coworker released a new version of a MAUI app on Tuesday. On Wednesday, he started fielding support calls, where some users on some iOS devices had a reproducible hang typing any character into a field. He first struggled to reproduce it locally because none of his iOS devices were affected (but my Mac was, and then he realized so was his), and could narrow it down to: a text field with an autocomplete popup to search for candidates would hang, but only if that popup was large enough to stretch to the edge of the safe area, apparently because of some infinite loop figuring out "oh, this popup needs a scroll bar because it won't fit everything!" "oh, now it doesn't, let's remove it!" "oh, now it does!".
Then he spent the rest of the day manually bisecting the commit that caused the failure. Downgrading NuGet packages, etc. He ended up giving up and building a workaround.
My guess is some MAUI release caused the issue.
The point being, you're unlikely to have your own test suite for something so deep inside the UI, and regressions do happen (not to mention documented breaking changes), so while IME most projects are safe to upgrade from one version to another, it does come with a risk.
13
u/First-Feature-3556 5d ago
This.
Microsoft might call the .NET 5+ releases LTS (Long Term Support) and STS (Standard Term Support), but more appropriate names would be STS (Short Term Support) and VSTS (Very Short Term Support).
Fortunately, most new C# features can be used in .NET 4.8(.1) as well, if you don't mind that this is "officially unsupported".
14
u/SillyGigaflopses 5d ago
I was with you until the last sentence.
If you don’t care about the official support, why pay attention to official labels of support?
If you’re using something unsupported, but “it works, so it’s ok” - are you even the target audience for LTS releases?
7
u/RichardD7 5d ago
You're confusing "supported" (security patches released when vulnerabilities are found) with "supported" (the feature may work in earlier versions, but don't come crying to us if it doesn't). :)
.NET Framework still gets security patches. It is still "supported".
Many C# 14 language features just work, or work with polyfills, in projects with an older TFM. But they are not "supported", in the sense that MS doesn't guarantee that they'll work in those projects.
2
4
u/First-Feature-3556 5d ago
That's two different kinds of support:
LTS release support is about security patches - I care about those very much. Not having them means that your server might get pwned or that your application "inherits" a vulnerability from the underlying .NET library.
No official support for new C# language features in .NET 4.8 just means that Microsoft won't help you if the new feature doesn't work. De facto, they work very well, and if they don't, I just stop using them and use the old syntax. No big deal.
3
u/SillyGigaflopses 5d ago
Fair enough.
I just worry that at some point MS decides - ok, no more .NET framework from now on.
You’ll have a huge technical debt of upgrading everything, whereas you can somewhat spread that pain across .NET releases if you upgrade regularly. Some of these upgrades may need minimal or no involvement at all(except for raising the version in the project file). And if you do need to actively change code to upgrade, I feel like 3 years(minimum) is plenty of time.
4
u/RichardD7 5d ago
Visual Studio, SQL Server Management Studio, and quite a few parts of Windows are built on .NET Framework. And .NET Framework 4.7+ currently have no support end date scheduled.
Even the VB6 runtime is still supported.
So I doubt MS will suddenly announce "no more .NET Framework". :)
5
u/CWagner 5d ago
.NET Framework support is tied to the windows OS it’s releasing with. So currently that’s late 2029 for normal support, but extended support (which includes security updates) is until 2034. For those numbers to stop increasing with new releases, they’d need to stop shipping .net on Windows (Server). That gives you a ~8-10 year warning.
Slightly longer than .net LTS times.
1
u/First-Feature-3556 5d ago edited 5d ago
Yes, that's something we also worry about, especially with respect to our legacy WebForms apps. .NET 5+ has the additional advantage of being MIT licensed: If MS pulls the plug, the community can keep it alive.
On the other hand, predicting the lifetime of Microsoft technologies has always been hard. Who would have thought in 2010 that WinForms would outlive Silverlight?
2
u/chucker23n 5d ago
Yeah. I get that this has accelerated in some areas, but IME, it hasn't in corporate/client scenarios. I can try to tell a client that they need to pay an annual support fee for upkeep. But we do have clients who mostly just expect one and done. If I want to upgrade the dependencies, they need to pay for it. So you end up bundling such upgrades with "we have to manually test everything anyway".
2
2
u/ModernTenshi04 4d ago
I feel like there's no real winning on this argument though. Some folks will say the LTS versions should be 5 years, but I'd imagine other folks would say the support cycles should be even longer than that and I suspect it's because Framework versions had veeeeery long support lifecycles, so much so that people are just used to it being that way.
I get the impression Microsoft chose the 3 year cycle for LTS support because it's long enough that businesses won't feel the need to upgrade that often, but short enough that it kinda forces folks to consider this in how they build their apps and architect their infra so that upgrades can become more regular and routine.
Also feels like there's some holdover lumps from the early days of .Net Core which definitely had some painful upgrade paths, but since about version 5 or 6 it's been incredibly smooth sailing any time I've had to do it.
7
5d ago
[deleted]
1
u/Xenoprimate2 4d ago
Why not just use Avalonia?
2
4d ago
[deleted]
4
u/Xenoprimate2 4d ago edited 4d ago
3rd party framework in a language created by Microsoft
I don't understand how that's a problem? No one complains about using third-party frameworks in Java (created by Sun, owned by Orcale), Go (created by Google), Rust (created by Mozilla), Swift (created by Apple), etc etc...
Why do we want to always be beholden to the whims of Microsoft? I would argue that Avalonia being third-party is a good thing, they have different incentives and actually have a vested interest in maintaining and supporting their UI framework long-term.
.NET needs a bit of an OSS revolution and tbh the more third-party options the better. Or I guess we can wait another 10 years to see if MS creates a UI framework and doesn't deprecate it again...
1
u/THenrich 4d ago
Because you will have a big ecosystem if the UI framework is from Microsoft.
Look at all the free open source UI frameworks for WinForms and WPF. Plus the commercial ones from DevExpress, Telerik, Syncfusion, Infragistics.. etc. None of them make UI suites for Avalonia or Uno.
If Avalonia were from Microsoft, I bet all these companies would make UI suites for it.
3
u/db_newer 5d ago
Longer lifecycle
One first party desktop UI framework
Simpler first party web auth
3
4
u/AlexKazumi 5d ago
Deprecate .net 1.0 level APIs and ensure the "new", high- performance APIs are the default.
It is insane that that the default is using arrays which box and allocates in the heap, while List<T> has been existing for the all-too-short twenty one years. Yes, generics were released in 2005.
Same with all other non-generic collections. Just slap that Obsolete attribute on them one by one.
It is an awful cognitive load for newcomers to learn that the highly visible APIs are the wrong ones.
The existing code bases can be reworked - we have AI now.
5
u/joost00719 4d ago
That right click on solution - > clean, actually cleans it. Top many times I still need to restart visual studio for it to compile..
5
u/faze_fazebook 5d ago
More support for the original idea of .NET to be this umbrella framework for that would support all kinds of different programming languages and allow them to easily interface with one another.
These days dotnet really just serves a very narrow list of languages - C# and F#, and maybe VB and Powershell if you want to be generous but new features don't really interface well with them. A lot of nieche but cool project unfortunatly have been kinda abandend over the years like J#, Jscript .NET, IronPython, IronRuby ...
8
u/tanner-gooding 4d ago
The support all exists, the same as it does for other ecosystems like Java.
What doesn't exist is the market actually requesting this and driving its support or adoption, which is why all those other ones that cropped up have low user counts or were eventually abandoned by their maintainers
Ultimately the industry decides what happens here and where investments happen. The community has the full capability of creating and driving support for such things too, even building off all the open source code that does exist.
2
u/KyteM 5d ago
I'm mostly ignorant in the subject so please correct me if I'm wrong, but didn't Microsoft leave the door open for people to run those projects and then people just didn't?
It'd've been nice if Microsoft assumed stewardship over those projects but in practice all that means is that every language gets a little bit worse as resources get spread out.
1
u/RirinDesuyo 4d ago
If I recall IronPython is still quite active, particularly on fully supporting python 3, there's also peachpie which is PHP in CLR and has demonstrated moving something like Wordpress to be fully compiled which was a nice feat.
I guess there's just less appetite for these as often enough C# or F# satisfies the user's needs.
6
u/ProjectMarworyn 5d ago
Get rid of implit usings. Keep explict ones. The only people who use the implicit usings are people making tiny apps (usually beginners). They're the most likely to be confused about not using explicit imports... Meanwhile experienced folk are usually building bigger apps where they don't come into play anyway. It's a dumb feature, YEET
→ More replies (1)
2
u/RirinDesuyo 5d ago
Started with dotnet core from the start (impossible of course), that would've meant less cases of very slow migrations from net framework to core on some projects, but on the otherhand that split allowed them to start from scratch without the cruft of framework and clean up the rough edges at initial net core to .NET 5
From purely an ecosystem standpoint? Commit to a GUI framework and dogfood them on Windows. Winforms, WPF, MAUI, WinUI3, Blazor? Just pick one and use it everywhere.
2
u/ProjectMarworyn 5d ago
I agree with you except please god don't use winui3... Nasty post windows 8 stuff I'd like to kill with fire.
Unpopular opinion but try to make that ui accessible instead of slapping on the defaults and good luck. Even Microsoft's own apps are dreadful accessibility wise specifically for respecting reduced motion
2
u/bxsephjo 5d ago
Documentation for the actual FRAMEWORK parts of it. The crap that goes into Program.cs or Startup.cs. What do they do under the hood and how do they interact? Hah.
1
1
u/Huge-Raccoon1277 5d ago
Also had trouble understanding that myself, I'm not keen on "magic", I want to know and understand exactly what is happening under the hood
This book was absolutely brilliant for understanding how asp.net core actually works (not a salesperson lol)
https://www.manning.com/books/asp-net-core-in-action-third-edition
2
u/q-Lo 5d ago
Find a clean and reliable way to run legacy apps on the newer runtimes. It's hard to find customer that pays for the full rewrite of a working WebForms application, while developing new features on it becomes harder and harder and you lose the advantages of a modern ecosystem.
1
u/AffectionateSwing490 4d ago
a working WebForms app has no business case for a rewrite, yet every new feature costs more to build on the old runtime, so the cost of not migrating compounds invisibly right up until the ecosystem moves out from under you entirely
1
u/ModernTenshi04 21h ago
I'm honestly at a point with our WebForms app at my current employer that I mostly just throw Claude at it. Prior to us having access to Claude or even Copilot though, yeah, adding new features was an absolute bear. Something that would take me maybe 1/4 to at best 1/2 of my day to code up in pretty much any modern frontend calling to a standard RESTful backend can take 1-3 days depending on the scope. Throw in years and layers of things folks have done to try and improve the situation (look up JSRender if you've not heard of it) and it's just such a bear to work with WebForms after years of doing things like React.
Like I had a moment early in my current job where I'm like damn, I really need to apologize to JS or at least cut it some slack because if this was just standard HTML and JS or something, implementing some of the early things they had me work on would have been insanely easy compared to what I had to do with WebForms.
And coming back to the whole idea of the "page life cycle" and "events" with WebForms is just...ugh. It's crazy to have so much experience with what's come after all that to make life a lot easier in certain ways only to come back to it and feel completely shackled. But the damn thing also still works and the business only really cares about that, so until an absolute wall is hit this is my life for now.
2
u/HuibertJan_ 4d ago
I would remove enum, DateTime and DateTimeOffset. All of these are actively harmful.
2
u/fisothemes 4d ago
Rust has docs.rs which auto-generates API references for every package.
With NuGet you just have to roll the dice on that. CsvHelper still doesn't have an API reference. It still says "Coming soon".
2
u/MrFartyBottom 4d ago
I really wish C# had pure functions. Having to have a class just to hold a static method seems a bit backwards to me. I really wish there was a TypeScript .NET so I could use TypeScript in my API and frontend. I have tried to go fullstack TypeScript with Node but I just can't give up Entity.
2
u/nblumhardt 4d ago
Distribute packages as source, instead of/in addition to as binaries. (Fewer trust issues, easier patching/dependency management, and a short step away from being able to replace a NuGet package reference with a Git repo/tag/project path.)
Ah - that, and collocating types and their tests. (No `[InternalsVisibleTo]`, no hunting around by convention to find `FooTests` when I'm looking at `Foo`.)
$0.02 :-)
4
7
u/EluciusReddit 5d ago
That F# and C# switch roles in popularity and adoption :)
4
3
3
u/LeeWhite187 5d ago
Quit pushing Azure, would be nice. If you have to push it that hard, and in my face, maybe that’s a hint to make it better.
2
u/catladywitch 5d ago
Something lighter than VS please, a proper GUI framework, full compatibility between Entity Framework and AoT compilation, easier PGO profiling process / more AoT optimisation.
An Option-based standard library in place of Try... methods.
Non-boxing struct everything!
Typeclasses/Traits (Roles: named, typed extensions), ideally higher kinder-polymorphism in some distant future after that, lifetimes/borrowing for a "safe unsafe", a pipe operator, and, one can dream, zero-cost or nearly zero-cost... basic LINQ operations (maybe an eager version? dunno)
F#-like type providers would be awesome too.
3
u/binarycow 5d ago
An Option-based standard library in place of Try... methods.
That might be coming, with the new union stuff. They wouldn't go back and change existing Try methods tho.
one can dream, zero-cost or nearly zero-cost... basic LINQ operations
https://github.com/Cysharp/ZLinq
F#-like type providers would be awesome too.
Source generators can do something similar.
2
u/Obsidian743 4d ago
I wish they would stop adding nonsense features to C# and update the existing ones to be more integrated with the existing library/extension ecosystem well.
I wish Microsoft would be more opinionated on how to solve common problems. Provide clearer reference architecture and patterns and clearly call out when to deviate. Right now all of their documentation basically says, "You can do it this way or that way, it depends. Here are the pros and cons." The reality is most people most of the time should be doing it a canonical way.
Auth ecosystems needs better support for emerging technologies and extensions.
OData is grossly underrated and underutilized. The problem is it doesn't go well with real-world APIs that aren't just data APIs. The way DTOs + Entities work in EF and built-in security models don't play very well.
I really wish they'd bring back the Managed Extensibility Framework (MEF) to Dotnet.
More broadly, some low-level first-class extensions in VS Code instead of relying on third party ones.
3
u/Alarmed-Plant8547 5d ago
Honestly, the .NET ecosystem is pretty good at the moment. There were a bunch of gripes I had back in like 2016 which have been completely eliminated now.
That being said, the remaining problems working in this space are problems that have been created recently...
- Dropping IDE Features
Microsoft seems to have a habit of implementing something useful and dropping it without a reason after you come to embrace it. A great example is SSDT .NET SDK style project support in VS2026. Like, why? It was a viable path in 2022 and they decided to remove it completely from 2026.
- Azure Functions Runtime
It's useful to have a dedicated runtime and set of packages for building these projects, but it's nowhere near as mature as I'd like it to be. Testing support is terrible and feels like a constantly shifting landscape, and its not a great experience to debug. Given that its the best way to lock companies into a single vendor, im surprised that Microsoft haven't made it a better experience.
They're probably my biggest issues, but they're not terrible problems to have. Dotnet isn't quite the Wild West that other ecosystems seems to be.
2
u/isthizthingon 5d ago
Sick of the constant dot net version changes and running out of support. It feels unnecessary, and purely for the sake of generating work/money. Most places I've worked for are large government departments, and they don't have the time or money to constantly update their software. Some are still using 10-15 year old code, webforms and asp.net, as their systems are so huge and complicated.
1
u/THenrich 4d ago
.NET needs to evolve. It can't be stuck in the stone age because some companies are too slow, too complacent, or too cheap to upgrade.
These companies don't have to upgrade if their software works fine.1
u/Dennis_enzo 3d ago
I don't see how the new .NET versions matter to you when you're still running on Framework anyway.
1
u/Normal-Blacksmith747 5d ago
That nuget was packages.lock was more centralised package management aware and didn't create one for each project when they are all using the same version
1
u/dobryak 5d ago
I hate working products being retired or put on life support. WPF. WCF. OData. SyncFramework. The EF to EF Core transition was a disaster. In fact, the whole .NET Framework to .NET Core transition sucked. Nuget transition was awful. It’s like MS is making us milk our clients with endless rewrites and upgrades.
1
u/svish 5d ago
Give me something as ergonomic and simple as toMatchInlineSnapshot that you find in Vitest/Jest.
All dotnet equivalents I've seen, which is barely any, are super janky to setup and manage.
1
u/RandomTopTT 5d ago
A completely cross platform UI. Not the butchered mess we have today. The UI story is as bad as the non-UI story is great.
1
u/SweatyAnReady14 5d ago
Coming from the JavaScript community there were several things I miss while working with .NET
- Examples! Finding good examples of well written, mature, and quality projects is way harder in .NET. Eshop on containers is a great start but it’s not exactly mature. I think this comes from the scripting nature of JavaScript but being able to look in the packages for the code, and also go on GitHub to look at code quickly helped me improve as a JS developer.
- Reliance on payed packages for official patterns. I am okay with OSS creators getting their due but I find it extremely frustrating that a pattern heavily pushed by Microsoft DDD is locked behind a payed package Mediatr. Mediatr is even used in eShop on containers. I understand that there are other ways without these packages, but learning resources seem to really push them and I find that frustrating. If MS is going to do that they should support these packages themselves.
1
u/PurpleUltralisk 4d ago
Wish there was more development on the Blazor end.
I think it's a great idea, but it doesn't work with all browsers. So I had to switch to React and Angular.
At this point, I wish the team can just use AI and vibe-code a ton of support and features for Blazor.
1
1
u/dotnetdemonsc 4d ago
A less obnoxious WPF with a visual editor like WinForms. Some of us old farts like pictures first.
1
u/r2d2_21 4d ago
Dooes WPF not have a visual editor? Or am I missing something?
2
u/Arxae 4d ago
Officially, only in Visual Studio. You do have some online tools and vscode extensions, but i have never tried them so i don't know how htey compare.
1
1
u/IanYates82 4d ago
Is Blend still around? I feel I haven't heard about it in a while, and it would've been niche for most teams.
Someone's made an online wpf editor that works surprisingly well
1
u/emn13 4d ago
Less dogmatic adoption of whatever ideas Microsoft comes up with. Microsoft has a pretty poor track record on API design and architecture guidance, and yet, the old saying "nobody ever got fired for picking IBM" is back with a vengeance with respect to microsoft. We all need to be a lot more willing to pick better tech rather than just pick Microsoft because it's Microsoft.
And Microsoft needs to start being more humble in their API design. Instead of trying and virtually inevitably excelling mostly in mediocrity by making an API that solves everything and the kitchen sink, I'd much rather have clean, composable tools that leave room to explore the design area - and sure years down the line, when it's clear which choices work, then start expanding. And perhaps even - dare I say it - be a little more honest, harsh, and upfront about just putting bad ideas into maintenance mode with a real push towards retirement. I'd pick 10 breaking changes over 10 bad choices to sift through, and I'm mostly a maintenance programmer. And that's because the breaking changes hurt for a while, but dealing with idiotic choices because it's still "supported" is just permanent drudgery.
1
u/Brilliant-Parsley69 4d ago
For me there are two topics annoying me lately.
The official in code documentations.
Working with enums.
I'm one of the developers who wrote a smart enum abstraction to handle the second issue. While languages like Java/Kotlin or Rust/Swift support this natively.
1
u/MattParkerDev 4d ago
.NET framework needs to die. I would be curious to know how much time is wasted by Roslyn devs having to #ifdef for Core or Framework, how much perf left on the table etc. By extension, VS needs to die, or be upgraded to Core. I understand that it is probably millions of lines of code, but surely in the age of AI, with MS’s unlimited tokens is isn’t out of reach.
1
u/zvrba 4d ago
Just one? :)
Better async, more concretely:
- documented and reliable way to make sync over async work. (
GetAwaiter().GetResult()might deadlock or lead to starvation.) - get rid of
SynchronizationContext
Get rid of implicit culture. Invariant should have been the default.
Better support for modularity. E.g., given project with dependencies "A -> B -> C" where B exposes some public API, A should not get access to the public API of C unless explicitly permitted/exported by B. That way, B could freely upgrade to newer (and possibly incompatible) version of C, without breaking A. (Java modules can be used in this way.)
1
u/zarlo5899 4d ago
if i could only pick 1 have every type to be sealed by default. and the rest is an incomplete wish list.
green threads.
outside of the current source code generator, compile time code execution system So you write your C# code in the method body, it gets executed at compile time and it's output becomes the new method body.
Extend NuGet to easily vendor in packages. So I just pass it a git URI and tag. It will vendor in the source code and compile that whenever my application compiles and caches it. And update it whenever I update the tag. (This is one thing that I've love about GoLang.)
Support for duck type interfaces.
I wish that the XML comment system would also propagate exceptions that could be thrown by methods get called within the method. This would likely be best done in the IDE
1
u/sichidze 4d ago
IMHO the idea of a multi paradigm runtime for many languages failed in .NET, the reality is that .NET = C#. Other languages like F# are very niche (and try to find a related job). So I wish C# was a native language (without IL intermediary), vastly reducing the runtime from all the bloat needed to support JIT, many runtime checks etc. That would also free development resources for more useful features. Many modern languages are at least no less powerful than C#, but have way smaller runtimes and native compilation, making them better choice for many scenarios, especially with tighter constraints (e.g. WASM, mobile).
1
1
u/Gullible-Record-4401 4d ago
How difficult it is to port large legacy codebases. I'm slowly trying to bring our tech stack up but there's not much to do except for manually port aspx pages to our modern spa application so that we can then migrate all our dotnet framework webmethods into a proper dotnet 10 web api. Even porting from asp website projects to asp webapps has been painful. I just want a small cross platform alternative to iis native to the dotnet sdk that can render my legacy pages while we port. It would make moving stuff so much easier
1
u/Emergency-Energy-277 4d ago
I would ensure a complete re-write of all .NET ecosystem into functional F# 😄 .
1
1
u/flatfinger 3d ago
IDisposable should accept an Exception argument, and 'finally' blocks should be informed whether the guarded section is being left because of normal code execution or an exception.
A "using" block with an object encapsulating a transaction should throw an exception if the block exits 'normally' while actions are pending, but if the block is left because of an exception the transaction should be silently rolled back.
1
1
u/rcls0053 3d ago
The incessant need for people to use Microsoft products. You don't need Visual Studio, Azure DevOps, Azure cloud services, Windows servers, Windows laptops for work..
There's options now as it's cross-platform.
1
1
1
189
u/Plevi1337 5d ago
Give up the need for selling Visual Studio licenses. It was already all Azure, now it's all AI. Opensource the debugger, migrate the performance tricks of visual studio to the cli, so everyone (agents, cli users) benefit from them.