So, on the plus side with the new .net, I recently made a .net core web app on Linux, and generally it's been pretty easy.<p>I'm also impressed at just how fast asp.net core is compared to asp.net, the time it takes to open your site in debug mode has dropped dramatically, from what used to be 1/2 minute in asp.net to a few seconds in .net core.<p>On the bad side? Mainly the asp.net core team and their push for Dependency Injection and the really poor async code has got to be the most frustrating thing about the whole thing.<p>My biggest bugbear is the way you access your config, which is an absolute and utter kafka-esque mess. Because someone at MS was drinking the DI kool-aid you have to add a minimum of 5 lines of code to any class you want to access config values in, and you're in for an even bigger nightmare if you want to separate business logic and web code into two projects (which is a pretty common design). I've given up with the config DI and just assign them all to static variables. I still don't get why you'd even want your <i>config</i> injected!<p>The entire authentication uses async code too, which still has all the normal problems of being hard to debug, silently failing if you invoke it wrong and completely overwhelming the callerstack with a bunch of redundant calls.<p>Huge disadvantages with absolutely zero performance gains for 95% of programmers.<p>Having been using express again recently, I'm seriously thinking of ditching the asp.net core stack despite my general preference for statically typed languages. C# is great, but the asp.net core are so obsessed with shoving DI and async down your throat and making you write really unpleasant, boilerplate code. Feels like you're back in 1990 with all the FactoryFactoryFactories.
Congratulations to the team.<p>Microsoft has made exceptional strides in terms of performance and compatibility.<p>The whole vision is what is really impressive, not any individual part.<p>It is cross-platform, open source, and has almost complete coverage of the old .NET APIs. The new csproj format is vastly superior. The new dotnet CLI is a pleasure to use.<p>Many of the surrounding libraries like ASP.NET, Kestrel, LINQ, Entity Framework Core, System.Text.Json, etc are best in class.<p>I look forward to the Linker becoming stable, as this will really help in contexts such as Azure Functions and AWS Lambda.
The future is very bright for .NET. It has the right <i>raison d'etre</i> - .NET is part of the growth story for Nadella-Microsoft.<p>They already have you programming in their editors (VS/Code) and pushing to their VCS (Github). They're even teaching you the C# type system with TypeScript :) If they can just convince you to use their stack, Azure will win you over from AWS every time.<p>As a result, I really wanted to adopt .NET earlier this year. But they have some work to do to make the ecosystem approachable to newcomers.<p>One of the core issues feels so... trite. But experiencing it, I realized how real it really was:<p>The Names. Microsoft has created a Ninja Warrior obstacle course of proper nouns.<p>It is comical. It is worthy of parody.<p>.NET, the CLR, and their relation to C# and F#. ASP.NET, ASP.NET MVC, ASP.NET Web Api, Blazor vs Razor, .NET Core vs .NET Framework vs .NET Standard.<p>I think I could draw the lines between all those with about 50% accuracy. And I read like 3 books on .NET before diving in.<p>It's bad off the top when you're trying to figure out which way is up in the ecosystem. It goes from bad to worse when you're looking through docs and Stack Overflow answers.<p>It was almost never immediately clear if a document I was looking at <i>on Microsoft's own website</i> applied to me or not. That is a cardinal sin of technical documentation.<p>Ultimately, this meant that .NET Core Web API (or whatever I was using) felt poorly documented.<p>I'd find myself looking at docs that mention .NET Web API - but I can't remember if that rolls up to .NET Core or Framework -- or both? Am I using MVC? Is Web API a subset of MVC? No clue.<p>It's definitely a hard problem. Here's to hoping that now that everything is unified, they can work on paving clearer roads into their ecosystem.
As someone who uses .NET daily, but loves Clojure and other functional programming paradigms - Records seem like a very compelling feature. Immutable data structures without any hassle to set up. Simply write “record” where you would normally write “class” and boom, you are working with immutable objects. This is one step closer to one the best features of Clojure IMO -everything is immutable.<p>Additionally, there seems to be another new way to accomplish this. Normally class properties are accessed via get; and set;<p>Now we have the ability to use get; and init; which effectively makes the object immutable/read only after initialization. The syntax is just a little cleaner and more obvious to the reader how the property should be used.<p>C# has really been adding some great features the past few years and is certainly getting more expressive and concise which I appreciate.
F# gains string interpolation and typed string interpolation:<p><a href="https://devblogs.microsoft.com/dotnet/announcing-f-5/#string-interpolation" rel="nofollow">https://devblogs.microsoft.com/dotnet/announcing-f-5/#string...</a><p>Knew it was coming but still really happy to see this.
Congratulations to the team but more than a year after the Surface Pro X shipped and there is still no way to build desktop applications for aarch64 using dotnet/vs2019 on the local machine. Windows on ARM has no native support for WPF, WinForms, or WinUI.<p>Visual Studio 2019 running as x86 32bits application can't see the local machine as a target for aarch64 applications. When I asked microsoft, the response was to use a x86-64 machine to develop on the same LAN as the aarch64 machine and use remote debugging. So you need two machines to ship a desktop application.<p>This is bad, and part of the reason there are so few app running natively on the Surface Pro X.
> From what we’ve seen and heard so far, .NET 5.0 delivers significant value without much effort to upgrade.<p>From the previous version of .Net Core only. They've done absolutely nothing to make migrating from MVC 5 any easier, while proclaiming that this somehow merges .Net Framework and .Net Core. Going from MVC 5 to .Net 5.0 MVC is a complete re-write of the web layer from an empty project upon up (even according to their own article[0]).<p>I think the poor messaging on .Net 5.0 bugs me more than the actual work required for the mitigation (which hasn't changed significantly). .Net 5.0 is just .NET Core 4 with a fancy new name.<p>[0] <a href="https://docs.microsoft.com/en-us/aspnet/core/migration/mvc?view=aspnetcore-5.0" rel="nofollow">https://docs.microsoft.com/en-us/aspnet/core/migration/mvc?v...</a>
Note that .NET 5.0 is not an LTS release:<p>> .NET 5.0 is a current release. That means that it will be supported for three months after .NET 6.0 is released. As a result, we expect to support .NET 5.0 through the middle of February 2022. .NET 6.0 will be an LTS release and will be supported for three years, just like .NET Core 3.1.
I'm excited about this! I've used .NET Core to build some CLI tools for Linux in F#. It's great to have an alternative to Go in terms of mainstream, high level languages (read: has tons of good libraries) that can compile to an easily distributed Linux binary.
Congrats to everyone involved. This is a huge accomplishment and arguably many steps in the right direction.<p>We are very excited to get our hands dirty with .NET 5 sometime in Q1 next year. We currently run on .NET Core 3.1. I expect our migration from 3.1=>5.0 will be a total non-event, but we don't want to risk any regressions during our current crunch phase. Our migration from 4.7=>2.0 was the most difficult, but once we got everything off Framework and onto Core things have been going really smoothly with the incremental upgrades. Really hoping this trend continues indefinitely.<p>The only part of .NET 5.0 that has left me disappointed is the continued lack of polymorphic deserialization support in System.Text.Json - a la Newtonsoft.Json's TypeNameHandling enumeration. This is the only thing holding us back from migrating to this first-party dependency. I have already left feedback regarding our use case in the appropriate dotnet/runtime GH issue.<p>The biggest new features I am looking forward to are the performance enhancements surrounding startup time, GC, etc. Improved P95 latency is something that will be very welcome in some of our busier environments.<p>In terms of the overall package that .NET brings to the table, we couldn't be happier. Sure, VS could run a little smoother and some of the configuration/DI stuff can be very aggravating (at first), but overall its a fantastic experience.
> .NET 6.0 will use the same approach, with net6.0, and will add net6.0-ios and net6.0-android<p>Huge endeavor and launch! Looks like mobile app development will be the same with Xamarin
It is a bit sad that so-called "native AOT" was not included in the release. When I heard last year that .NET 5 would support single-file binary, I expected it to be the same as something like Rust or Go would offer. But no, Microsoft changed the meaning of AOT and moved the goal post, introducing the real AOT as "native AOT". Thankfully they are aware of the issue, so I hope to finally see in when .NET 6, which will also be an LTS release, is released.<p><a href="https://visualstudiomagazine.com/articles/2020/08/31/aot-survey.aspx" rel="nofollow">https://visualstudiomagazine.com/articles/2020/08/31/aot-sur...</a>
There is also going to be a crossplatform (including mobile) UI library for .Net 6: <a href="https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/" rel="nofollow">https://devblogs.microsoft.com/dotnet/introducing-net-multi-...</a>
the highlights are great. 2 lowlights:
- HttpClient/WebRequest ReadWriteTimeout is silently ignored which can result in infinitely hung sockets when doing synchronous network i/o
- System.Speech is unsupported
I wish the post was more direct that .NET 5 is the successor to .NET Core 4. I gathered this was the case but it didn't feel clear that I don't need '.NET Core' anymore to run .NET on mac/linux.
I really like where thing are heading with .NET.<p>On the other hand, I'm still missing an easier interop with other ecosystems. C# is an easy to use language and I would love to write some common code / business logic / whatever you name it in C# and expose it as webassembly and C/C++, this would cover mobile, web and desktop workloads. You can do something like that with Rust (or at least they claim it, I never tried), but with C# I don't see any _easy way_ doing it. I would be happy if someone could correct me If I'm wrong.
Maybe in a year or eighteen months, I'll be able to move to this, from Framework code that still has dependencies that nobody has ever updated to .NET Core.<p>This version will be nearly out of support by then...
I know .NET Core applications could run on Linux. But do they natively (without any wrappers) support Linux OR is there a wrapper to simulate windows within Linux?
Would most people here agree that .NET is a much better platform for developing applications with a plugin-based architecture (which, I think, more or less, implies following Hexagonal aka Clean Architecture / Ports and Adapters Pattern [1]) than popular alternatives (e.g., Python, TypeScript/Node.js) due to a diverse set of comprehensive dependency injection (DI) implementations [2]? While it is possible to use a manual / non-DI approach [3], the trend seems to be in either extending this approach [4-5], or - an arguably more elegant and flexible solution - using DI [6]. Would love to hear opinions on how you would approach developing a heavily plugin-based application (including an ability to use virtualization containers, such as Docker, as functional plugins).<p>[1] <a href="https://www.infoq.com/articles/advanced-architecture-aspnet-core" rel="nofollow">https://www.infoq.com/articles/advanced-architecture-aspnet-...</a><p>[2] <a href="https://www.claudiobernasconi.ch/2019/01/24/the-ultimate-list-of-net-dependency-injection-frameworks" rel="nofollow">https://www.claudiobernasconi.ch/2019/01/24/the-ultimate-lis...</a><p>[3] <a href="https://docs.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support" rel="nofollow">https://docs.microsoft.com/en-us/dotnet/core/tutorials/creat...</a><p>[4] <a href="https://github.com/natemcmaster/DotNetCorePlugins" rel="nofollow">https://github.com/natemcmaster/DotNetCorePlugins</a><p>[5] <a href="https://maartenmerken.medium.com/announcing-prise-a-plugin-framework-for-net-core-4af7cf5b4d2b" rel="nofollow">https://maartenmerken.medium.com/announcing-prise-a-plugin-f...</a><p>[6] <a href="http://ewer.com.br/plugin-architecture-with-di-containers" rel="nofollow">http://ewer.com.br/plugin-architecture-with-di-containers</a>
is this an in-place update to the netcore3.1 runtime or does it install side by side for net5.0? just want to know what kind of risk it is to install. i got bit by the netfx48 in place update.
People who think this is actually cross-platform need to consider these points:<p>* Debian can't package F# because it is built using MSBuild, and MSBuild is built using MSBuild. How can it be Microsoft doesn't have the resources to get it into a major distribution?<p>* Microsoft won't commit to maintaining any cross-platform GUI libraries. You will be relying on some random community project. Compare this with e.g. Python with PySide, which is officially supported by The Qt Company. The Qt Company is 460 times smaller than Microsoft, and they still manage.
Since Apple is announcing the new Macs with M1 SoC today, I'm wondering if it will support it from day 1 or we will have to wait?!<p>edit:<p>I guess I can't read.
`We expect that Apple will announce new Apple Silicon-based Mac computers any day now. We already have early builds of .NET 6.0 for Apple Silicon and have been working with Apple engineers to help optimize .NET for that platform. We’ve also had some early community engagement on Apple Silicon (Credit @snickler).`<p>Still wondering for .net 5 though
I used to be an asp.net developer before. I appreciated the idea behind asp.net during its early years - making websites fast and with templating (or scaffolding). Later realized that it is bloat.<p>Then asp.net mvc happened, a whole new paradigm shift. But then I disliked the idea of stuff getting inherited from somewhere. *.cshtml files and all. Soon I realized what the ide is actually doing behind the scenes. For e.g. the cshtml files are compiled and there is an intermediate binary format I guess. (Don't remember well).<p>This is why I came to like something like express. Guaranteed there is no type safety. (JavaScript is a dynamic language). But I enjoyed the simplicity of it. Ever since I have moved away from the .net platform.<p>I know this code generation and intermediate binary forms are necessary. But at times I was surprised by it. You find the similar stuff for other stuff you write for e.g winforms, windows presentation apps, etc. I realize there is no other alternative way for such platforms. But I generally disliked the idea that my editor does a lot of stuff behind the scenes. This makes me too dependent on the editor. For e.g. try making winforms app with just notepad. It's not impossible; just very cumbersome.<p>I have respect for .net. In fact I do write console programs time to time. But I wish stuff was as simple as having a plain editor and getting started.
> It’s already in active use by teams at Microsoft and other companies...<p>This means nothing anymore. MSFT says that about everything they release and users are still often left with the feeling that they are guinea pigs testing a very unfinished product.<p>> For Visual Studio users, you need Visual Studio 16.8 or later to use .NET 5.0 on Windows and the latest version of Visual Studio for Mac) on macOS. The C# extension for Visual Studio Code already supports .NET 5.0 and C# 9.<p>Reading this makes me wonder who is still using Visual Studio. That IDE is so bad it's beyond believe. .NET 5 is a standalone runtime which anyone can install. You can write C# in a text editor and build and run it from the command line. Why the hell do Windows developers need to install an entire new IDE in order to use the latest version of the .NET runtime? It's ridiculous beyond belief.<p>Really shows that Visual Studio Code is the future. All you have to do is install the latest runtime and update the plugin so it shows you suggestions for all the latest language features. No need to install a new version of Visual Studio Code itself.<p>> .NET 5.0 is the first release in our .NET unification journey.<p>This might cause confusion. .NET 5 is basically .NET Core 3.2 but has been renamed to .NET 5 so that .NET Framework 4.x users can finally get convinced to move to .NET Core. They just dropped the Core to make it look more appealing to them, but it's still .NET Core.