.NET 8
devblogs.microsoft.com
devblogs.microsoft.com
I decompiled it into C# and stripped the player aspect out of it leaving the code the peeled back the container and allowed me to export MP4 and other pieces. After getting to build into a console application on windows on .net 4 I think I decided to give it a go to upgrade it enough to compile AND run on linux. I upgraded 2x and then updated around 10-15 lines of code that no longer compiled. It was extremely easy considering there were 1000s of lines of code to parse this format. I finally got it running on linux and it only took about a day of full effort. Pretty crazy considering the code I was running was over 10 years old.
The main issue I have had is if you are trying to get into the .Net Ecosystem without spending money. There are quite good free tools, but you have to figure out what works best for you if you're used to the non-free ones.
I assume instead of Reflector for the decompilation, you used DotPeek?
If you're a real OG, you used `ildasm`.
A lot of what I know about C# is from his books. I wish every language had someone of his caliber write a book about it.
I think the version of the book I read was "CLR via c#" about 10 years ago
I suggest not trying to do this.
You can certainly make most of .NET8 work with a pure OSS toolchain, but your overall development experience is going to be destitute compared to that of the official tool chain. To be clear - I think paid alternatives, such as Rider are fantastic too, but even so I've had some trouble at the edges with paid 3rd party (Blazor apps, UWP, etc).
At the end of the day, you have to ask yourself about what your hourly rate is. If you are going to spend a 20 hour premium per week bandaging up a "free" .NET toolchain, whereas the official, $100/m stack costs you 1-2 hours, which one actually costs you more? What are your principles worth in terms of your free time?
Vscode stuff is ok too if you dislike big and featureful ides, but it’s behind rider. dotnet cli to run commands is sufficient until you have very strange builds.
Keep in mind the language has many ways to do the same thing, so rider helps you doing the “modern” things. The base class library is also very vast. Take your time, C# is great but it has a ton of features.
https://learn.microsoft.com/en-us/visualstudio/mac/what-happ...
At the end of the day it's a question of how much ROI are you getting. Your hourly rate is irrelevant, when you're just learning a new tech... because when you're hacking/learning the hourly rate is $0.
Which is why FOSS software took off in big companies, because it's easier for developers to sample things out and then ask for forgiveness instead of asking for permission.
Also, hobbies. It doesn't even matter if you have $20 to spend, or not. Hobbies depending on paid tools are risky.
People underestimate the importance of free tools because they judge from the perspective of their overinflated consultancy rates.
But hey! Talented people doing their best to break out of poverty is clearly a novel idea to you.
Should I have spent my full income for 3 months on an IDE, vs spending an extra 2 hours with the free tools?
It's not a hypothetical, that was the reality of my life in 2004. I had a lot of extra time, couldn't use it to make money and buying "enterprise grade" tooling wouldn't produce any extra value.
The ROI of an professional grade tool would have been - "you get to sleep extra two hours and have no food for 3 months"
Also the official stack is supposedly supported, which means you can contact Microsoft if you have an issue.
In practice, you get some underpaid outsourced employee in the chat, who is just going to follow their script - so it is more effective to go to Visual Studio feedback or Github, depending on the issue.
not everything is supported so not all assemblies will work, but large parts of the standard library are supported so it's most seemless.
.NET has been held down by the image of its early days, but it has become a pure joy to work with recently. The improvements in tooling and ergonomics have made it a replacement for Go in our org (we migrated from .NET Core 3.1 to Go back to .NET 6 recently).
I might be wrong though.
It's the same reason two sites that are more or less the same will have entirely different communities. There isn't any reason you couldn't implement the one on the other, but it's not in the core substance.
[1]: https://learn.microsoft.com/en-us/dotnet/orleans/deployment/...
A garden variety of keywords is async/await, TPL (tasks/futures and structured concurrency) and PLINQ (Rust's Rayon).
Admittedly that's also a long time ago.
If you're making over $1M/year or have more than 250 employees, you have to pay for Visual Studio or the C# DevKit in VS Code. Microsoft has been taking the open-core of VS Code and putting proprietary extensions into it. However, this isn't just C#. Microsoft has also replaced the open-source Python extension with something closed source.
There is an alternative to Microsoft's tooling with JetBrains' Rider. Rider is pretty amazing. It's much higher quality than any of the other JetBrains tools and part of that is that the .NET ecosystem is really amenable to tooling (and paying for tooling) and that JetBrains had been creating ReSharper for Visual Studio for a long time (so they already had all the .NET intelligence built out).
There was a thing where Microsoft was going to remove hot-reload from the dotnet CLI tool and make it only available in Visual Studio. I kinda felt like some of this was motivated by timing more than strategy, though. The CLI's hot reload had some rough edges and .NET has corporate style release dates with fanfare like .NET Conf. But the .NET hot-reload is quite excellent. Most edits can be hot reloaded and you can set it to simply re-compile and re-run for the ones that can't hot reload (and it just takes a couple seconds). It's dead simple to use and works (and the amount of time I've wasted to get hot reloading in Java is just incredible).
Really, every ecosystem tries to find some way to monetize. The creator of Elm has a great talk on this: https://www.youtube.com/watch?v=XZ3w_jec1v8.
Microsoft's monetization feels reasonably benign to me. If I'm bringing in $1M/year or have 250 employees, I can pay $500/year/engineer (or maybe less with volume or annual licensing; or $250-420/year/engineer for Rider for an organizational license). Sure, there are costs, but it's not like $500 is that interesting if I'm paying engineers $150,000/year. Likewise, Microsoft likes .NET as a bit of a halo project to get people into Azure. I don't use Azure at all and there aren't really Azure specific features, but in the same way that the iPod/iPhone brought a lot of people to the Mac, .NET probably brings some people to Azure. Even if you're a developer that knows better, you might have someone in your org who thinks "oh, it makes sense to deploy with Microsoft if we're developing with Microsoft." There's a lot of money up for grabs from that thinking. It likely also drives sales of things like Microsoft SQL Server. .NET works great with PostgreSQL or SQLite (and I'd assume MySQL as well, but I haven't used it), but I'm sure plenty of organizations pay for MS SQL Server with the "why not all from Microsoft" thinking.
So yes, Microsoft isn't looking for zero monetization, but the IDE license fees don't seem like a problem - either you're small enough that it doesn't matter or you're large enough that the fee is small. The rest of it is just stuff I can ignore (Azure, MS SQL Server).
But Microsoft's money often comes with some nice things. There's good documentation, a lot of great improvements each year, lots of great video sessions, and some truly amazing blog posts. .NET really has some amazing blog posts - and part of that is that Microsoft gives people the time to create some really high-quality content. If you haven't watched the Elm video I linked above, I highly recommend. It really talks about a lot of the things that money brings to a community. .NET comes with a lot of polish - more than I've seen in any other ecosystem and I've been programming a long time (and I've never been a Windows user).
If the cost of a healthy ecosystem is that companies with enough money to pay a few hundred dollars a year have to kick in a little support, I'm good with that. If I create something that starts bringing in $1M/year, I think it's reasonable to think I should kick in some money. I also understand others who don't like that - especially since it's kicking in money to Microsoft, not to some non-profit community foundation. But .NET feels practical to me. The money in the ecosystem means that a lot of high-quality stuff gets produced.
If you got .NET Core 7 somewhere, I’m sure it is monetized: that's often the point of a scam.
If it means running code in any lang, on a linux vm in Azure, so be it.
If it means giving away dotnet, so be it.
If it means that dotnet on AWS is also popular, so be it.
They're pretty clear and open about that, you don't have to look for hidden motives.
Good luck with your code base in 5 years when someone decide to add all the new stuff.
Also (see in comments too), upgrading .Net is very easy. There are man not-to-small codebases can be "easily" upgraded from .Net Core 3 to 8 without any hassle. Backwards comptability was always baked into Microsofts thinking.
.Net 7 and 8 did also (IMHO) not contain that many groundbreaking features, just some "smaller" stuff.
I'm not saying Go is 100% right in that, but it's much more conservative about stuff added into the language.
I also think that Go looks like a practical joke that escaped some INTERCAL-like satire committee in the 1970s.
Good sum types destructuring would probably also be useful in more languages like Go, but many languages today provide "async/await" pattern syntax benefits without anything at all like "proper" sum types. Sum types are "merely" a possible implementation detail of the Monad and it's the Monad laws that empower some things beyond just sum types.
Exception-based languages don't look monadic at first blush, they definitely aren't Sum types, but try/catch is one of the earliest and oldest of the monadic binding/combining approaches, even if it isn't often thought as such (and is barely considered more than goto/switch). It's far more obvious when you start to realize the intersection of async/await and try/catch is a working monad (and how that is reflected in Task/Promise monad instances).
Golang is the obvious odd one out where every other line of "best practice" code is `if err != nil` and the only other advice is "well you could just ignore errors". try/catch doesn't ignore errors, it just looks like it. Rust error chaining doesn't ignore errors, it just looks like it. Golang gives you the choice between micro-managing errors or BASIC-style "ON ERROR RESUME NEXT" and I cannot get anyone to convince me why this isn't either a practical joke or an intentional throwback to writing code like it is the 1970s all over again (even VB6 had better options than "ON ERROR RESUME NEXT", even if they maybe weren't used as often as they should be in some legacy 1990s/2000s codebases).
You have a valid point there, but it hurts my ears a little for you to use the word "monadic" or "monad" to make the distinction between how the way Golang handles errors differs from how other modern language do it. To me, for a language to "have monads" requires the type system to give the programmer the ability to distinguish between a value type, e.g., an integer, and a computation that produce a value type. Haskell's type system for example uses `Integer` to refer to the former and, e.g., `IO Integer` to refer to that latter. And clearly by that definition, Rust and most other modern languages just don't have monads, i.e., don't have monadic types (and consequently don't support a monadic programming style) -- unless perhaps Rust's macro system can be used in some complex way to define the monadic-computational types, but I've never seen it used that way. BTW, I'd actually go further and say that to get the benefits of monadic style, the IO monad or whatever the language calls it must be the only way to perform side-effecting computations (though there is a little wiggle room on the definition of side effect here).
To be more precise, the terminology I prefer is that a monad (in the context of programming languages) is a type that obeys the 3 monad laws: https://wiki.haskell.org/Monad_laws. There are other ways besides a monad for the type system to distinguish between a value and a computation producing a value; Explicit continuation passing is one such way: whereas in Haskell you'd read a character from standard input with `main = getChar >>= \char -> do something with char`, in a language that uses explicit continuation passing, you'd write `main = getChar (\char -> do something with char)` where in this language getChar takes one argument, which happens to be a continuation argument. But all the languages I know about that let the programmer use the type system to distinguish between a value and a computation producing a value use the monadic style to express that distinction (rather than something like explicit continuation passing) so I tend to use "monad" and "monadic" to refer both to the specific thing that obeys the 3 laws and for the deeper programming-language property.
That's one level of confusion in this conversation so far. However, the other problem is that monads don't just mean "computation". (Arguably the Lambda Calculus is way closer to the metal and more accurate to describe as the abstraction of "computation".)
Monads are useful for describing "computations as values" but that's not what the abstraction is entirely for and thinking of monads only as "computations" is how you fall into the easy mistake to make that IO in Haskell is the only "real" monad. There are lots of monads in the wild (Maybe, Either, Promise, List, ...), some of which don't really describe computation at all. We love to mock it, but the technical definition of a monad is "a monoid in the category of endofunctors"; nothing about that is "computation" specifically. Computation is a handy shorthand, of course, but its confusing one of the trees for the rest of the forest sort of thing, mostly because Haskell's IO was the first time monad escaped as a term of art for the deep abstraction that it is.
There is an importance to the monad laws and the two monad "operators", more importance than "computation" as a shorthand for thinking about monads. These operators are called "multiplication" and "identity" in raw Category Theory, but in programming "identity" is usually called "return" and "multiplication" is often called "bind", "bind" is interesting because it also has a dual generally called "join" and "join" is sometimes called "flatMap" or "SelectMany". (Yes, that does point out that most list structures in every modern programming language provide monad operators and obey the monad laws. Lists are a monad.)
A dumber, better shorthand for monads may be "glueable". Monads bind things together in a way that two binds of the same type of monad results in just one monad. (flatMap two lists together and get one list back.) The power of monads is that you can keep gluing things together. Whether by "executing side effects" in a "computation runtime" like the stalwart IO monad or in all the "boring" ways of Lists and Promises and Maybe and Either (that mostly have nothing to do with "computations", except Promises, sort of). The big useful bit is that the Monad laws imply that you can do all this "gluing" in a stable way. That stable way also makes room for the means to transform from one type of Monad to another (Monadic transformers).
Monadic transformers are where some of the real power of the IO monad as an abstraction lives (and other monads in terms of compile-time representations): the idea that the "notation" doesn't matter so much as the end "glued" result. Imperative looking do-notation is the same sort of "glue" as a lot of individual calls to the Monad operators bind and return, transforming from one form to the other is "relatively" "trivial" because the Monad laws say everything should be fine.
There is a usefulness to the IO Monad in Haskell and it is an interesting way to "describe side effects to perform", but the whole of monads and monadic binding is a lot more than just the IO Monad and if you are defining monads to only mean "the IO Monad" you are missing some of their other usefulness.
Show me one place in my writings where I imply that the IO monad (or state monads generally) is the only monad.
That comparison is not a fair comparison to Go, which has a much stricter guarantee around source and library compatibility within the 1.x series.
We're always thinking about the bloat concern when it comes to language development. However, our philosophy on it is that bloat primarily comes when you add replacement systems that are expected to supersede the previous mechanisms, not compliment them. So we try to do the former sparingly. In the history of C# there are very few times we've actually done this, and we do view those times as unfortunate cases where we likely rushed a feature too early and then regret having to live with those features forever.
To help combat this, we tend to go through long periods of design and experimentation, where we propose features, create prototypes of them, and then interact with a large set of diverse community groups to try things out. The feedback from this is tightly bound into our design process and allows us to refine (or even jettison) designs rapidly.
We also normally will both break up work into lots of smaller pieces (composing large language changes into small orthogonal, complimentary, composable blocks), and do designs over many years if appropriate. We think this approach has helped us create a language that is 25 years old, while being both very rich, and still very cohesive. There are a few mistakes we've made along the way ("anonymous-delegates", i'm looking at you), but we're very happy that our ratios here are very good given our continued investment in this space.
Still not really sure how I feel about class primary constructors on the other hand, will give them some time to marinate.
Can a single developer remember all of .NET? No, but that applies to most languages/ecosystems. But if you encounter something you've never seen, you can always check the docs.
And the thing hasn't been named ".NET Core" for 4 consecutive releases now.
WebForms would like a word.
People have been saying that for the past 4 years.
As someone who's never used .NET but develops embedded apps for Linux, I had high hopes for it become the best story for crossplatform development, it still feels like the crossplatform is held by ductape. It's still Xamarin for mobile, Avalonia (a 1-man project) for desktop Linux as the only choice, 2 confusing different UI frameworks (WinUI vs MAUI). They don't take this as seriously as I'd hoped.
When they made it open-source and cross-platform 6-7 years ago, they should've thrown enough manpower that within 3 years (or even 2, this is Microsoft with endless coffers) it was unquestionably the best development option for nearly every scenario.
Additionally, it's my understanding they don't release proper debuggers on Linux? I'm not gonna install Visual Studio just to debug my .NET app bro.
I solidly blame MS for shipping something like 10+ of their own frameworks and never E.G. including QT or anything else open. Apple's just as bad, if not actively worse, for relegating even open 3D modeling languages to second class.
Sorry to be pedantic, but it's cross-platform GUI that still doesn't have a good, officially supported story.
For non-GUI apps, cross-platform works very well! I've deployed a range of apps to production across Windows, Linux (both x64 and ARM), and Docker on Linux too (also both x64 and ARM) with great success.
I'd like to see an officially supported build for BSD, but that's about my only cross-platform want.
Yeah, but in the meantime there’re decent unofficial options. Once I compiled NanoVG into a DLL, consumed with C#, and implemented rich GUI on top of that. Worked pretty good overall. Eventually I’ve patched NanoVG for optimal font quality on low resolution touch screen of my target Linux device: https://github.com/Const-me/nanovg
Modern rich GUI needs much more than a renderer, but amount and development cost of that “much more” varies depending on GUI complexity. The device I developed is rather simple: low resolution screen, touch is the only input, English localization only, that’s how I was able to deliver in reasonable time.
For more complicated GUI I’d look for different technologies. Maybe QT, despite the high price.
People say cruft but sometimes I wonder how much more cruft it really is when you use the system browser rather than an embedded web browser. Usually many shared resources for it are already loaded into RAM.
If the end result is something like MAUI, I much rather just use a web page.
While I would prefer if I could use free tooling, Rider pays for itself in time savings very quickly.
You note that they open sourced it 7 years ago, but the original .NET Core was kinda an experiment. Microsoft didn't quite seem to know where they'd ultimately go with it. I think Microsoft really committed to it in 2018 or 2019. I think you also might have unrealistic expectations of how quickly things can be accomplished. Flutter is over 6 years old and still feels a bit mediocre to me - and I think Flutter is trying to solve a simpler problem since it isn't using native widgets.
For cross-platform UI, I think there is some disappointment in the .NET community. MAUI has succeeded Xamarin (except for Linux), but I think your sentiment that Microsoft isn't investing in it enough is shared by many in the community.
I think the problem is that Microsoft bit off more than it can chew with MAUI. Avalonia, Flutter, Compose Multiplatform, Electron, etc. tend to just paint non-native widgets via Skia or JS/HTML. With MAUI, Microsoft is offering actual native interfaces which means having to deal with a lot of platform differences to implement that rather than just painting their own widgets with a graphics library.
I'm not trying to talk you out of being disappointed with MAUI. It has been disappointing. However, I'm still hopeful for it simply because it's the only effort I see trying to offer a native cross-platform UI dev experience. Flutter, Avalonia, Compose Multiplatform, etc. are all saying "We'll just take a window and paint our stuff in it. Do you really care about an app feeling native?" It isn't always important, but it does feel like so many given up on native apps.
I'm hopeful that MAUI will keep getting better (as it has been) and that we'll have the opportunity for a native UI experience in the future.
There really isn't a simple way to do cross platform (Windows/Linux/macOS) UIs with any language. The least bad option is to make it a web page, maybe wrap it with Electron.
While I agree it is hard, there is no one who could rule this space better than .NET if they just would like.
Problem is: this is developer division funding which is not the Windows (which owns a UI stack) or office division (react native actually). DevDiv previous UI toolkits WPF was loved but then abondon because of the duplicity of UI toolkits in Microsoft.
I write Qt GUIs for Linux+Windows, and no Windows user can tell it's not "native" (not that there's a native Windows look anymore, what with MS being schizophrenic about scrapping the UI framework and starting a new one everytime a new PM wants attention, only the classic widget look associated with Windows is still the 2000/XP/7 is recognizable).
Qt apps are super performant, and write once, run anywhere for 99% of GUIs anyone wants to create.
OSX users might be the only one that complain, but they're a tiny minority of users, and it's good enough in most cases, with fantastic performance to shut up the doubters.
Electron apps are hideous, bloated, and slow, relative to the Qt apps I write. I'm only held back by C++ being a shitty archaic language/ecosystem, and if .NET offered an alternative I'd jump ship immediately, that's why I'm so disappointed it's an afterthought.
P.S. Languages designed for "hypertext markup" are not meant to create rich UIs, and can never compete with a native framework. Everything in the JS world to create rich applications is a hack and you can see it in the code and the endless churn of frameworks. When I write something like QML, the intent is clear. When I look at the JS UI frameworks people are hacking hideous HTML templates and conditional logic, list iteration, etc in HTML templates. And nearly every JS UI framework project is written by 1-2 intermediate devs with comparatively little API design talent, who inevitably break backwards compatibility within a year or two.
I might need to look into it once more, at least it won't run out of steam the second I want to do something else than have a standard text box or an input field on the screen - like all those "easy ui" -systems do every time.
It's not from Microsoft but who cares. They don't have a reputation of holding onto new UI frameworks anyway.
I have been in .NET since 2009. I don't what would lead anyone to replace Go with .NET? That seems like it's asking for a lot of problems you previously did not have.
Can you expound on your decision?
It will help numerous abstraction-heavy codebases the most thanks to guarded devirtualization of interface/virtual calls, delegate inlining and branch reordering which has progressively more impact the more bloated code is.
I have vague memory of reading somewhere that Mono or maybe just MonoBuild was completely obsolete since everything was now open source in .NET.
Does Mono still have a reason to exist? Is it all incorporated into .NET now?
(btw, I still don't get why it's called .NET, and I don't know if assemblies are native code or bytecode wrapped in the same binary format as .exe, where is the ".NET for hardcore open source Linux nerds" blog post?)
From .NET 5 onwards, the framework is cross-platform. So as a separate thing, Mono isn't usually needed or part of the mainstream any more.
> I don't know if assemblies are native code or bytecode wrapped in the same binary format as .exe,
Yes, they are. Either, depending on your build target.
For most .NET apps you can use .NET 5/6/7/8.
[0] https://devblogs.microsoft.com/dotnet/dotnet-8-performance-i...
Edit: seems some part of Mono still live.
If you're running Windows, Mac, or Linux I'm not aware of major reasons to use Mono.
[0] https://www.mono-project.com/docs/about-mono/supported-platf...
Microsoft eventually created .NET Core, their own cross-platform implementation of .NET, which eventually became .NET 5, 6, 7, and now 8.
Mono should not be used for new projects. .NET 8 is vastly superior. Mono is only still used for things like Unity who have decided to not or slowly migrate off of Mono.
In 2016 they started building .NET Core which is new open source implementation (built mostly by Microsoft) which runs on more platforms. For a while all three existed side by side.
Eventually .NET Core caught up and overtook the other implementations. These days Framework is legacy. Core has been renamed to just .NET (since it's now _the_ runtime) and Mono (as far as I know) has been totally replaced by it.
This is all from memory, so apologies for any inaccuracies!
I think there is nothing else left from the Mono project like the class library or the compiler/toolchain.
Still too many enterprise products stuck in the old ways.
As I mentioned a few times, I have been involved in projects were that full rewrite happened to be .NET Framework => Java, which shows how the customers were mad at what was left behind.
Although there is some irony in that, as Java's Python 2 problem is the transition into Java 9.
Binary incompatibility between 7 and 8 as well, we got an enterprise product that got bought by SAP and will eternally be stuck on Java 7, but at least unlike the other one, it doesn’t require much maintenance as it’s only used internally ;)
> Python 2 => 3 also has the issue that some things don't exist in Python 3, or are done in incompatible ways.
What doesn’t exist? I don’t like python, but it always seemed like those changes were all relatively minor?
Naturally some changes on the C API for native libraries as well.
.NET can now do either one - you can ship PE bytecode and require the dotnet runtime, which works in practice similar to e.g. Python or Ruby (you run `dotnet ./myapp.dll`), or you can precompile it into a single platform-specific binary that is just a native code app, similar to Go's static binaries.
I really really wish there was a good, straightforward desktop GUI for .Net that simply worked crossplatform and wasn't a complete pain in the ass to program.
I'd put my money on the competing "electron, but smarter" solutions that keep bubbling up, rather than any language-centric framework.
I hate hate hate it when a desktop app looks and acts like a web app.
I am currently fucking with Java via GraalVM, and packaging my app for distribution has been absolute hell:
jlink throws errors.
jpackage somehow gets stuck in an infinite loop that generates a directory tree of seemingly infinite depth (so deep that even Explorer can't delete it)
GraalVM native-image can't complete and throws all sorts of weird error messages
Trying to modularize the app has been hell too, it seems like every one of your dependencies needs to be modularized as well?
And like all I am using is Swing, FlatLaf, and MigLayout :(
How the hell are people getting apps running in a standalone environment?
I really like Java the language, but getting a desktop app running on it in 2023 is a nightmare.
This is honestly because you are taking the hard path and trying to do AOT compilation. Just use Swing with HotSpot. Native Image isn't meant for GUI applications and Swing internally uses a TON of reflection.
Using jlink and jpackage with HotSpot has been trivial in my experience.
This happens when your jar is in the same folder as the working directory: https://stackoverflow.com/a/64743880
>I really like Java the language, but getting a desktop app running on it in 2023 is a nightmare.
I think it's very easy. Do you use a build tool?
Getting the jar file is easy. But its deploying it that has been difficult
I've heard this "Microsoft has finally created a completely cross platform UI framework" like twenty times...
And that's assuming it even compiles or packages.
So far the only winner has been QT (via pyside6 for me)
Someone suggested switching the JVM to hotspot and using jlink/jpackage, I am going to give that a shot
On graalvm 20 I even got it to compile, but there were issues drawing/loading swing components
:(
It takes time to shift developers.
The roslyn compiler is open source since 2014.
I guess it's fine if people don't like .net but I think the open source part is not that relevant.
I think saying that Microsoft started open sourcing .NET in 2007 feels a bit disingenuous. Plus, wasn't it source-available under the Microsoft Reference License? Regardless, .NET was still tied to Windows unless you wanted to use Mono (which was slow and had an uncertain future).
If you were someone who developed on Mac or Linux and deployed to Linux, you couldn't choose .NET in 2007 or 2014. Even in 2016, are you going to choose a brand-new ASP.NET Core? Microsoft announced .NET Core 1.0 at the Red Hat Summit in 2016 which isn't exactly an endorsement that the company thought it was the future of .NET. It seemed like Microsoft was trying to open up just enough to hook a company on .NET Core and then tell them "well actually, you should really upgrade to the real .NET Framework on Windows" when they ran into problems. That's not what happened, but Microsoft certainly hadn't committed to .NET Core in 2016. Their messaging was "well, Red Hat will offer support for this thing we made."
If I didn't have a Windows PC in 2015, I couldn't do .NET development (Mono aside). If I wanted to deploy to Linux in 2015, I couldn't do .NET development (Mono aside). The open source part matters to lots of people because .NET simply wasn't a choice for those who didn't want to be beholden to Windows and licensing until recently. People definitely ignored .NET because it simply wasn't an option for them.
As for access to windows, to be honest I think that's pretty easy to have. Run on general purpose hardware, it's not that expensive.
I think that having access to a Mac is relatively harder than having access to a Windows machine.
When .net core came out I was under the impression that the product was the future of .net but maybe I was living in a bubble.
Anyway, I understand your point but I still think that the disinterest towards .net is tied to a generalized adversion to Microsoft (probably deserved) but not really related to the tech itself nor it's availability on Linux or Mac.
Mono never got traction within the startup culture. In part, because it operated in a legal grey area for many years regarding MS patents for web (or web adjacent) technologies like ASP.NET and ADO.NET.
It is soon 10 years. With 14 years of closed source before. But honestly, it is not .NET which is the problem maker, it is Visual Studio on Windows. Because that is the thing which cost and the thing which only runs on Windows. I hope they fix it in favor of VS Code (which looks good right now).
But I agree. It takes time.
I think you can always learn something from trying totally different tech, so i'm game to try it for a personal project, but want to hear what people love about it so I can dig in the right direction.
What are you comparing C# and .NET to?
If you prefer loosely typed languages such as Perl, Python, JavaScript then you will find C# too picky about types. Personally, I prefer to have the discipline.
If you are doing low-level stuff where a GC is out of the question then you would prefer C++ or Rust.
But in the in-between space; for most web or business apps, it's very good.
- New stuffs integrate nicely with existing features.
- C# and F# gets yearly updates.
- Somehow they manage to get the platform faster every year.
- Microsoft Orleans.
The tooling is all CLI based anyway so do what feels best. :)
I may suggest .Net for new WebAPI development (minimalist or otherwise), typically with a deployment target of containers and or Linux. It is a strong web back-end language in a similar way to Java but with Linq support, async/await, and a better primary programming language (C#). It has strong integrations into corporate software and all popular DBMS. But, frankly, Linq is the magic that makes .Net special.
Otherwise, for new development, I'd pick something else for creating user interfaces. Like Electron on the desktop and a popular TypeScript based JavaScript framework De jure on the web (utilizing WebAPI in .Net behind the scenes).
That's why I'm for isolating the front end from back end frameworks via something agnostic like WebAPI.
Maybe I use the term hybrid wrong, I am talking about the fat client hosting blazor/web view one. Basically electron shell just without js
My wife has worked QA for a number of .NET teams and it just seems like something I should at least keep my thumb on, but I've had nothing but frustration with it so far, even just trying to figure out what template to start with.
There's a pretty good starter tutorial for the Web API one here: https://learn.microsoft.com/en-us/aspnet/core/tutorials/firs...
Or here for the Web App MVC one: https://learn.microsoft.com/en-us/aspnet/core/tutorials/firs...
There's always more than a comment can talk about, but that's the gist. One good thing is that Visual Studio should be able to help you with a lot of stuff. It's pretty good at keeping you on a good path in the code and pointing out how to fix things.
You simply don't have to spend too much time researching what to do, just follow the docs and get started writing code and delivering features.
If you stray from the full integration of MS products, you start to lose some of the value proposition.
It's crucial for other major players on the market to participate in .NET if we want to ensure its longevity.
The more time I spend with AWS the less I like it. Simple issues are left unfixed, implementations are half baked, tooling incomplete.
e.g:
Their configuration extensions package still doesn't support loading a single SSM parameter, despite someone going to the effort of submitting a PR nearly a year ago.
There's zero support for YAML cloudformation templates in their VS extension.
There's no package that allows you to send OpenTelemetry data directly to XRay, they expect you to run an entirely separate container.
The whole platform feels like a jumble of half baked, and poorly exposed services that end up being outright painful to work with.
.NET and Java ecosystems are the only ones with tooling and developer experience that is somehow comparable to the Xerox PARC world. Note for the pedantic, comparable, not exactly the same.
Given the way .NET was born, there is a kind of yin/yang with both platforms.
Some scenarios or guest languages are better in other platform, while some other scenarios or guest languages are better in the other one.
Given this, when would I suggest .NET over Java?
It is closer to C++ in language features (as CLR was designed to accomodate C++ as well), and C# is getting some of those runtime features exposed since C# 7.
Because of this, and XNA/Unity, also got the love from many game studios (Capcom even has their own fork).
Microsoft also understands GUI much better than UNIX shops, so even with the ongoing GUI civil war in Redmond, most of the GUI offerings are still better than what Swing and JavaFX are able to do out of the box.
Blazor looks really cool as technology, however I was in the trenches with WebForms and JSF, so not really something I would like to experience again.
Example, using RichFaces, and then trying to use something from PrimeFaces, IceFaces, or something else Faces, was always open to surprises mixing their lifecycle expectations.
I was involved with a RichFaces based JSF framework, during three years, and afterwards going back to something like plain JSP and tag libraries felt quite refreshing.
I'm sorry but if you compare and contrast the rhetoric and tone of people who are in the .NET ecosystem there is certainly a fanaticism/love for it. And it's often done in a manner that puts other stacks/communities down.
I can't really let this comment stand since it's simply not true.
I say this as someone who has been in the .NET space since 2009.
Spring boot vs .NET is pretty similar, they both offer DI, Filters, Middlewares, etc. The ways I really proved to switch (given my development team is usually freshers) is to showcase the power of the Identity framework, LINQ (especially with EF Core and the ability to still use Raw Queries), and just overall being easier than Java (LINQ methods, extensions, syntax sugar).
Another big one is how damn easy it is to update and the performance posts MS does with the improvements. So you literally change one line in simple web apps and get performance boosts. Java doesn't really have that PR and the language (imo) is very verbose and painful to use (like their stream API).
All in all, we are building our rewrite in .NET (and Angular 17) and my team and I couldn't be happier.
Very strong tooling. Compiler APIs, debuggers, very strong IDEs (Visual Studio with free extensions and Rider)
Besides the controllers, models, and other things that might be separated from the views, I can mix my html and C# right there in the view - this is the biggest benefit IMO. In combination I use the Entity framework to interact with the DB, which adds to the simplicity.
The costs to run the internal application for several users is going to be around $6 a month for the Azure database. Hosting the web app is also on Azure, and it's free with the basic MSFT domain, which isn't a big deal to clients who use the software internally. This specific client will be saving over $200 a month once I release the app to them.
I can't tell you all the small details that the cool kids might be able to tell you, but I can produce reliable apps in lightening time and make my clients happy, which is ultimately my #1 goal with freelancing.
Once .NET is integrated with the new WasmGC features, it will get even better! (I don't think they mentioned WasmGC on the roadmap but I can bet anything they're going to do it).
But honestly, .NET is a enterprise thingy. Normal for them is that they coexist with angular, react, and many other UI toolkits. Reuse of css and web components is the customer need, not a Silverlight.
.NET is following the WASM GC stuff. There are some Post-MVP features for WASM GC that will benefit .NET. Note, I'm not an expert on this and this is coming from memory. That said, .NET has some features that won't be supported well by the WASM GC MVP. There's always a trade-off between supporting more and getting stuff out into the world so that languages that might not need the features can start using it (and they can learn from the usage which will benefit everyone). For example, .NET allows more pointer stuff than a lot of GC'd languages. .NET's `unsafe` isn't used much by most .NET programmers, but it is there. I think maybe .NET has stronger guarantees around finalizers than Java (where they aren't guaranteed to ever be run). The WASM GC is just an MVP at this point, but it has landed and they're working on its future. It really feels like we're getting to that point where WASM is going to really offer a better experience in the near future.
Ultimately, the timing of WASM GC wouldn't work out for the .NET 8 timetable, but I'd expect there to be a lot of work on it for .NET 9 next year. It's possible that a lot of Post-MVP stuff will land in WASM GC to help .NET and there's probably some opportunity to make Blazor work around other stuff. I think they haven't mentioned it or put it on the roadmap because they're still figuring out how it's going to go (and we'll probably know more in like February). But they are certainly looking at WASM GC and it's likely to offer a nice boost for .NET 9.
Building a professional component lib is a pita. Last I checked there were a billion React component libs and like one OSS Blazor lib in progress. Plus the usual commercial libraries you typically see in the .Net ecosystem.
Accessibility is a pita and aria requires JavaScript. How does this work?
State management in a way that's extendible? I love Mobx but the only thing active is a fluxor lib(yuck). Can other JavaScript code even plug into this?
Extensibility in general. Can new functionality be added via dynamic loaded plugins?
I would end up needing to interop with a parallel JavaScript(Typescript) codebase. My msbuild foo is pretty strong these days but would be nice to have a straightforward project config accounting for this.
And of course the Aspire announcement makes no mention of Dapr - I wonder if the teams have even spoken to each other!
I think it's a matter of time for Dapr stuff to be integrated. It is after all the first preview.
edit: here's more info about Dapr and Aspire
https://learn.microsoft.com/en-us/dotnet/aspire/reference/as...
Fast forward to now and it's only bug and compatibility fixes. A shame cause reminders v2 would have been an amazing addition.
I think workflows (durable async/await) are more useful than Reminders v2 alone (in some sense, workflows are Reminders v2), but an enhanced reminders system is likely part of that, as is the new log-structured storage system. The log structured storage issue discusses this: https://github.com/dotnet/orleans/issues/7691. We've been experimenting with a programming model for workflows and intend to share that more broadly soon. Currently, we are planning for .NET 9, so feedback is welcome (best provided via GitHub rather than here). Aspire will make it easier to build and deploy Orleans apps, which is one of the harder points for people getting started with Orleans currently.
I was being a bit hyperbolic with "only bug fixes" but.. A bit.
Haven't seen anything around workflows but will check it out and the structured storage stuff. Interested in running my own workflow engine on Orleans and reminders v2 looked like the perfect Quartz.Net replacement for my needs.
Thanks for replying; hoping you would. Someone asked about the future of Orleans 8 on GH a couple weeks back but nobody from the project chimed in last I looked. Know how it is with PMs and BAs and other work though.
Or are they completely different things?
Reminds me of project Manifold[1], the work they are doing is amazing eg. in-line type-safe SQL, GraphQL, etc. Mind bending, beyond next generation level stuff.
What they're likely aimed at is scenarios such as DI frameworks where there is currently "serious magic" code that generates code at runtime using reflection and lightweight code gen; and in new AOT scenarios all of this has to be done ahead of time, during compilation, in source generators, without runtime reflection. In other words, if you're not writing such an DI / AOP library, it's not for you.
But if you want to make a "PostSharp style AOP framework" then this is a tool for you to use when building it.
You can see the entire history of the proposal there. To answer you specific question, we went with `..` because that's what the language already uses for the complimentary 'pattern matching deconstruction' form for collection patterns.
In other words, you can already say this today:
if (x is [var start, .. var middle, .. var end]) { ... }
M([start, .. middle, end])
--
Now, if your next question is "why was .. picked for collection deconstruction?" the answer is "because we considered that the nicest syntax from the choices we considered". Syntax is often very subjective, and we often come up with numerous forms to consider (along with examining other languages to see what they've done). In this case, we simply preferred `..` over `...`. The extra dot didn't add anything for us, and we also felt like it might be an operator we might want to use in the future for other language features.
--
Finally, if you're interested in these sorts of questions/designs, def participate on github.com/dotnet/csharplang. We do all our design in the open over there, and are always interested in community perspectives on these sorts of things.
Thanks!
I've noticed that `...` is frequently used to denote that there's some code that's omitted. However with the spread operator being added (and being `...` in other languages) and "we also felt like it might be an operator we might want to use in the future for other language features" it's a bit confusing at a glance whether that's new syntax or just a shorthand. And it makes searching difficult.
I'm not sure what to replace it with, possibly a comment would be clearer: `/* code here */` or at least `/* ... */`.
P.S. Collection expressions are an awesome new addition!
Would .NET 8 be a good challenger ? I previously didn't consider it because the compilation to binary was looking more like an experiment, and the example I've seen were quite verbose (in a java way).
On the other hand, I would absolutely use verbose to describe both C# and Java. They are huge languages, with many features, a complex syntax, and conventions and patterns that lead to writing a lot of hard to understand code.
I'd use Go over both of them any day, especially when it comes to writing cross-platform GUI or console apps that can be quickly compiled and easily distributed.
Other options to consider might be Nim or Zig, but these are not as mature as Go.
I think those are quite innately related, yes. But I believe you also mix verbosity up in your very next sentence, for what it’s worth — readable, maintainable code is not as close a concept. In fact, certain type of verbosity helps readability, e.g. I argue that Go’s identifier capitalization harms readability, and marking it at a single place by public/private is much better, at a tiny price of more verbosity.
“Clever” code is another topic, there is definitely overly clever code, which is a net negative, but in this particular comparison, is a hand-written, 3-times nested for loop with any number of side effecting statements more clear to read than the “smart” stream/linq expression? I would argue the latter is much more readable and maintainable. For another, even better example there is that math proof, which can be done an order of magnitude faster by choosing a clever notation, but I can’t look up its name yet.
Re error handling, no, go doesn’t force you to handle the errors. It forces you to do some stupid meaningless if err ritual, that won’t result in correct handling of the error case, and will in fact often swallow errors. Java’s checked exception does force you to correctly handle it, though, but even runtime exceptions at least bubble up, making the default action (doing nothing) correct.
This was my first experience while getting started in the .NET ecosystem. I wanted something similar, I wanted to build small console tools/services and F# looked cool but hit the reflection issues too soon.
I mostly use crystal and golang, but both have their own issues. Hopefully F# improves with time to be fully usable with AOT!
Memory usage is important to me and golang is very good at that being light, but I really hate writing it for various personal reasons.
If I had more free-time I'd just simply go with Rust but you know, free time is limited :P.
[1] https://programming-language-benchmarks.vercel.app/csharp-vs...
Many tests there are at odds with the areas of optimizations that get most engineering effort investment in .NET: high level and/or application logic and high-performance primitives like Span, Vector, etc. (with the exception of perhaps Regex-Redux, but even there I'm not sure why the results are so low, because C# has one of the fastest[0] regex engines that only loses to Intel Hyperscan, Rust one and PCRE2).
Probably the best way to go about this is to just give it a try with a sample project and see if the RAM usage is to your liking - you can get far with plain 'dotnet new console --aot' and standard library (once you're done, .NET's variant of go/cargo build is 'dotnet publish -o {output folder}').
Overall, .NET tends to have higher memory footprint than Go because its GC is designed to sustain much higher allocation rate and heaps spiking to much higher use without severely throttling performance (which Go does). But there are interesting developments with the new GC mode called DATAS. I made a very simple example project some time ago to showcase .NET's concurrency and publishing experience to someone else which shows that it now rivals Go where it's the strongest[1].
[0] https://github.com/BurntSushi/rebar#summary-of-search-time-b...
It isn't exactly equivalent to the benchmark game's version. The biggest difference is that it doesn't permit parallelism.
For more details on the benchmark model: https://github.com/BurntSushi/rebar/blob/master/MODELS.md#re...
.NET does well overall in rebar's benchmarks, but less so in regex-redux (in both the benchmark game and in rebar's version of it). Not sure why. I haven't investigated. Of course, this is assuming you aren't using .NET's default interpreter engine. You've got to switch to the no-backtracking or compiled modes to get decent perf.
This is the benchmarks game:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
JIT: dotnet publish -p:PublishSingleFile=true -p:PublishTrimmed=true
AOT: dotnet publish -p:PublishAot=true
Avalonia[0] and MAUI[1] have known working templates with it, but YMMV.
[0] https://github.com/lixinyang123/AvaloniaAOT / https://github.com/AvaloniaUI/Avalonia/
[1] https://github.com/dotnet/maui (try out with just <PublishAot>true</PublishAot> in csproj - it is known to work e.g. on iOS)
.NET 6 was already capable of most things you are looking for, but there are some limitations. I personally think it is a really versatile language and if you know it, you can get the most things done somehow.
I wrote a little cross platform C# command line tool called `tone`[1] for tagging audio files and it compiles via github actions for windows(x64), linux(x64,arm64,arm6,arm7), macOS (x64, arm64) as a single monolitic binary (similar to `golang`), which is pretty cool.
With the right compiler flags it is not even too big (about 20MB, for comparison a `golang` binary with similar features would be about 5MB, `rust` more like 1MB or less). You can also go WASM (which is generally supported, but feels a bit experimental at times).
In the GUI department there are three main competitors:
- MAUI - Windows, macOS, Android, iOS (Microsoft's pet, xamarin successor)
- Avalonia UI - Windows, Linux, macOS, Android, iOS, WASM
- Uno Platform - Windows, Linux, macOS, Android, iOS, WASM
.NET may also still be incompatible / unfinished on other OS and platforms (e.g. RISC hardware or BSD operating systems). So if you only target the mainstream systems like x64 and the raspberry pi, it might not be a real problem.
I was thinking that flutter is a dart library/framework ? How is it compatible with C# ?
I think Flutter has a lot of advantages over the C# UI libraries and is worth learning when planning a Cross Platform UI or App.
It's possible with C#, but you have to work around a lot of shenannigans depending on the use case.
Command line apps are totally ok with C#...
It actually addresses several warts (finally span pinning!), brings some new shortands, makes the syntax more uniform and comes with some performance improvements as well.
[1]: https://devblogs.microsoft.com/dotnet/announcing-fsharp-8/
Does .NET have any "write a small program that is only a CLI?" options? Or GUI instead of web interface? Something modest.
Since 2014 they've released Community Editions of Visual Studio, with a lot more useful features and less restrictive licensing than the old Express editions.
But if you're used to writing Python in Notepad++ I'd skip VS entirely. You can install the dotnet SDK and just keep using Notepad++.
Here's literally everything to write a CLI app in .NET 7:
A csproj file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net7.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
</Project>
Console.WriteLine("Hello, World!");
Voila. A CLI executable is built in the .\bin\Debug directory.
I have noticed someone in a previous job who wrote an application that somehow tied itself to IIS despite not having any web site needed as a front end and found that somewhere between baffling (was there something I just wasn't getting? Is this how things are done now?) and intimidating (wow, that's a lot of infrastructure for something so small).
I'm looking for something which might target the IDE and little tips like the you have helpfully included.
If you do want to use an IDE, there are many choices available. First party options include Visual Studio itself (which has varying skus depending on what you're interested in). For just CLI development, the Community sku would work great. Then there is VSCode, which has both the open-source "C# Extension" (also built by us), and the closed-source add-on "DevKit" which enhances that further with more features".
Regardless of which environment you use, writing a CLI is extremely simple, and the language and environment cater to it. A simple 'Hello World' for C# literally is just:
Console.WriteLine("Hello World!");
We def want .Net, including the language, runtime, and tooling to scale all the way from these sorts of experiences to the "enterprisey" space, in a clean and consistent fashion.
If you do run into issues with any of the above, def let us know. You can see all the work we do in .Net over at github.com/dotnet/... Including what's being worked on now, and what we're continuing to invest in for future releases.
Thanks!
You may not know this, but ESRI is more or less the Microsoft of GIS (Geographic Information Systems). While they largely settled on Python, some of the newer "add-ins" for ArcGIS Pro rely on .NET, instead. As such, I thought it would be a good idea to begin looking into .NET, C#, and the like to see if I could develop some add-ins myself.
I'm one of those solo "dark matter" developers who ends up writing middleware, custom ETLs, and such that almost nobody will ever see and I had begun to despair of finding tooling for "the little guy." I will look into the SKUs you mentioned, it gives me some hope.
https://learn.microsoft.com/en-us/dotnet/standard/commandlin...
List expressions I'm overly excited about. Can't wait to use and of course dictionary expressions will be amazing in the future.
EF Core complex types. Also it'll be fantastic when these can be used to model composite keys.
The using enhancements. Hopefully I don't end up overusing tuples.
If Orleans had secretly been working on reminders v2 it'd be early Christmas.
Mono AOT supports a bit more, with focus on iOS and Android workloads.
None of them work with GUI frameworks or classical ASP.NET applications.
Also, you can statically link NativeAOT libraries into existing C/C++/Rust/etc. code, and you can statically link existing static libraries into NativeAOT binaries[1].
[0] https://devblogs.microsoft.com/dotnet/dotnet-8-performance-i...
[1] https://github.com/lixinyang123/AvaloniaAOT
[2] https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
Avalonia is great, however the biggest issue is with Microsoft own tech, as many of us are well aware, many companies are Microsoft shops and only care about what is in the Visual Studio box.
There, not only is Native AOT behind .NET Native, there is no plan to ever support AOT in Forms and WPF projects.
On the libraries I stand corrected regarding static linking.
Is that still the case?
In that case, go back to PHP or where-ever you come from ;-)
But .NET has a great option in this case: ReadyToRun. Basically, it AOT compiles a ton of stuff, but also creates the byte code which can be JIT optimized at runtime. The file output is larger which is a downside, but is usually a very minute downside. ReadyToRun takes care of start up times because you have the machine code to get things running fast. Plus, the JIT can sometimes make optimizations that can't be done at compile time so you can end up with better overall performance (at the cost of a larger executable file).
One of the things that is nice about .NET is that a lot of things come with sustained, multi-year effort with some good things coming every year. Microsoft is working on making more and more of .NET AOT-friendly and really upgrading the way things are done. Along the way, there are things like ReadyToRun which work really well for what most people want/need.
Seems like others are confused too: https://www.reddit.com/r/dotnet/comments/pqi891/net_maui_app...
.NET Framework 4.8 will be longer supported than .Net 5, 6, 7 and maybe 8.
Just like their Xboxes.
Any version < 4 is out of security support. Only one version number starting with 4 remains in security support but you don't want to use it if you can use a higher version number. .NET 8 is new/fresh/current LTS. The rest of the "naming scheme" is dead weight.
It will presumably have longer support than .Net 8.
- Lack of cross-platform support (Windows only)
- Lack of Ahead-of-Time compilation options
- Worse performance
- Disappearing community support (many common/favorite libraries have already dropped 4.8 support and/or maintenance and are only looking at the .NET 5+ present; more do that every day and generally greenfield fresh/new libraries won't even consider 4.8 support or testing at all; this includes major first party libraries such as ASP.NET and Entity Framework, you cannot use the latest on 4.8 full stop)
- Worse and more expensive tooling (8 can be entirely command line driven including locally and cheaper and easier CI/CD installs and scripts, has great support not just in expensive IDEs like Visual Studio or Rider but also [cheap as free] VS Code and through LSP tools even options like vim/neovim/emacs in ways that 4.8 has mostly never supported)
Yes, there's definitely a shift in LTS strategies with .NET 5+. It isn't tied to Windows support lifetimes anymore, which has benefits too (much easier to deploy new versions; I will never miss the days of "we can't use that feature because management keeps putting off the Windows upgrade migration"). It is using a very similar strategy to NodeJS of twice a year releases with "even releases" being LTS supported for two years. That certainly can sound like a more complicated maintenance burden, but faster release cycles and shorter support windows generally mean fewer backward compatibility breaks and an easier upgrade from version to version.
The way I see 4.8 "long term support": the VB6 runtime is still technically "supported" in Windows 11 for long-tail backward compatibility but such long "support" doesn't mean VB6 is a good option for writing code today for Windows (or has been for a decade or more), and the VB6 IDE and compiler have not been supported since Windows XP. Fortunately, 4.8 isn't the VB6 of .NET because there are clear and easy upgrade paths, plenty of good migration tools, plenty of good reasons to migrate (performance! cross-platform!), many developers have happily migrated with no intention of going back, many new developers to .NET have enviably never experienced .NET <5 for many good reasons (Linux support!), and .NET 5+ is still unarguably .NET in every way that matters (the languages are the same, a vast majority of the base class library is the same or distinguishably better). This isn't a hard fork at this point, this is much more clearly "present and most useful" versus "outdated and legacy". But the sentiment of "don't use VB6" is still there for 4.8: if you are still working on 4.8 this year you probably better have the excuse of a large "brownfield" application with a huge legacy footprint. You are probably going to have a bad time doing it, you are going to have an increasingly uphill battle to get new developers to go back to 4.8, and the IDE and tools for supporting 4.8 are going to lose support soon (the ones that haven't already) and will only get more expensive and rube goldberg-like, to be trapped in VMs of older Windows versions and increasingly network isolated because of that.
We're on .NET 6 now, because it's LTS. But as of today, it has 1 more year of support (1)
.NET Framework 4.8 as an OS component, is actually supported for longer - no end date given (2).
Note that .NET Framework 4.6.2 is supported until Jan 12, 2027 - that's longer than .NET 6 and 7, and maybe 8
1) https://learn.microsoft.com/en-us/lifecycle/products/microso...
2) https://learn.microsoft.com/en-us/lifecycle/products/microso...
Confusing.
That means "stable" as in "it is not going to change".
But from a developer perspective, binding redirects, brrrrrr.... Also, source-level framework debugging tends to break every so often. It is obvious their focus is on the new .NET.
It was many a moon ago I even thought about .NET Framework. Not everyone might be so lucky, of course.
I would view it as a major, even terminal red flag if I was offered a job involving .NET Framework 4.8 or lower again.
They had to handle a transition phase and as a .net dev at that time, it was surprisingly smooth
.NET Core was renamed to .NET 5, which became the mainline .NET. .NET 8 is simply the latest version.
.NET Standard is intended to be a common layer to help bridge between .NET Framework and .NET Core and .NET 5+. It shouldn't be used outside of that context.
.NET Framework is the old, Windows-only .NET. It should not be used for new projects and should be migrated away from.
If you are writing a .NET library _and_ want it to work with very old deployments, then you also have to care about .NET Standard.
.Net framework is the OG .Net and is windows specific. That stopped at v5 (I think)
.Net Core is the cross-platform reboot that was mostly a subset of framework, but not a proper subset.
If you wanted to write a library that worked across everything, you would target .Net standard, which wasn't a framework itself, but the intersection of APIs that existed everywhere.
Today, framework is discontinued, which makes standard kinda moot, and they dropped the "Core" branding. So as of .Net 6, that's pretty much all you'd write for new code.
If you have legacy code, then yeah you're back in that quagmire
.NET Framework Stopped at version 4.8
That's why .NET (formerly Core) could pick up at version 5.0
Like seriously: Windows XP -> Windows Vista -> Windows 7 -> Windows 8 -> Windows 10
or: xbox -> xbox 360 -> xbox one -> xbox series x/s
and a bunch of other things, like Azure Devops, which doesn't necessary have anything to do with Azure or Devops depending on how you use it. And their editor Visual Studio, and their other editor Visual Studio Code, which are not really related. IIRC, I also had to make a visual studio account in order to access the azure devops repository at my previous client, even though I don't use visual studio (the editor).
It's seriously like the Fast and Furious franchise.
They seem to be doing it for most of the microsoft products I can name, I wonder if there is a reason for it?
- Open-source, portable, updated, default choice: .NET Core 1 2 3, .NET 5/6/7/8 - Included with Windows or Unity, frozen in time: .NET Framework 4 (don't use anything older) - Want to support both: .NET Standard (this is a subset that both can run)