30 ms·

.NET 5.0

791 points by benaadams 6y ago

Belphemur 6y ago
Does anybody knows if .NET 5.0 will be included in Windows as a Windows Update as the .NET Framework ?
- ocdtrekkie 6y ago
  It won't be. .NET Framework is an embedded component of Windows. .NET Core is something apps have to package along with them. (Due to this, .NET Core apps are larger than .NET Framework apps, but tend to have less compatibility issues in theory, since they bring everything they need with them.)
  - dt3ft 6y ago
    Are you sure it will not be distributed with Windows? Is 4.8 the last version being distributed with Windows, requiring all future .NET framework versions to be packaged with the apps?
    - ClumsyPilot 6y ago
      The idea is that its installed separately from windows, in the same way one might install java. So because you can have mutiple versions installed, or you can package it with an app , then the updates can be more rapid. The problem with .Net framework is that everything, including system services rely on it - that means it needs years of testing and can't have any breaking changes. Basically they decided that packaging .net as part of windows was a mistake.
      - ocdtrekkie 6y ago
        I feel their mistake was not allowing apps to call a specific version if needbe, not with the general decision to include it in Windows. While .NET Framework updates annoyingly force every app to use it, I expect .NET Core to make it super difficult to secure apps that decided to hardcode some specific ancient release of it and allow no way to override it.
        WorldMaker 6y ago
        .NET Framework was built to support and did allow systems to have multiple versions installed side-by-side and apps to call specific Framework versions and was built to support many versions side-by-side. But that turned out to be more difficult in practice than in theory. Multiple side-by-side Frameworks turned out to be more hassle than useful, and even with just 3 versions of the Framework that were built to live side-by-side (1.x, 2.x, sort of 4.x, long story) that was often pointed to as a source of bloat in Windows. The mistake to include it in Windows was partly why more versions weren't made (because then they'd have to be serviced for the length of a Windows version's service lifetime; because then they'd contribute way more to Windows bloat).
    - atraac 6y ago
      4.8 is the version of a .NET Framework. What we have now is essentially .NET Core 4, with a misleading name of .NET 5 that confuses people. .NET Core is not being provided with Windows Update, like someone already said, you need to package it yourself with your app.
    - jhoward321 6y ago
      There will be no future .NET framework versions so I believe he's correct. .NET 5 is a new version of .net core
    - ocdtrekkie 6y ago
      Yeah, .NET Framework will see no new features, so they'll continue to patch bugs in 4.8 probably for over a decade to come, and a lot of new apps will just not use it, and include .NET Core runtime instead.
  - jiggawatts 6y ago
    It also means that the first major vulnerability in .NET Core will be an unmitigated clusterfuck, as admins will have no automated tooling in place to update .NET Core with security patches. "Just recompile with the new version!" I hear the cries already, said by people that have never had to support literally a thousand applications in a government data centre, half of which were built years ago by a vendor that is long since bankrupt.
    - huzaif 6y ago
      Publish your apps without .net core (--no-self-contained) and install/manage runtimes as you usually would. If you have thousand apps, you probably also have a CI/CD system and you can gain fine grained control on your runtime management needs with .net build/publish. MS does quite a few things poorly but they have done a solid job of operating in large enterprises.
      - jiggawatts 6y ago
        > you probably also have a CI/CD system Or more realistically, dozens of CI/CD systems, covering less than a third of the applications.
      - ocdtrekkie 6y ago
        "Publish your apps" isn't the issue: I support a lot of applications I don't build or have the source code for. And they may be on my network for over ten years. The problem is if developers are publishing self-contained apps with .NET Core, IT staff will be up a creek on vulnerability mitigation. While being able to pin specific .NET Core versions is nice for developers, being able to require the most current .NET Core version be used is important for IT staff who have to support these applications.
        hackerfromthefu 6y ago
        I'm expecting as this issue plays out, there will be a way to inject an updated framework to an existing app with a utility tool. Probably first party but definitely third party.
  - int_19h 6y ago
    .NET Core apps don't have to package the framework. They can also require it to be installed separately, although it's still not an OS component in that case. https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-framework-dependent https://docs.microsoft.com/en-us/dotnet/core/deploying/#publ...
- mariusmg 6y ago
  Nope, since this .NET 5 is NOT a replacemnt for .Net Framework 4.8
Someone1234 6y ago
> From what we’ve seen and heard so far, .NET 5.0 delivers significant value without much effort to upgrade. 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]). 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. [0] https://docs.microsoft.com/en-us/aspnet/core/migration/mvc?view=aspnetcore-5.0 https://docs.microsoft.com/en-us/aspnet/core/migration/mvc?v...
- josteink 6y ago
  > From the previous version of .Net Core only. Which is already three major versions ahead off classic .net. You’re literally complaining about making upgrades past four major releases not being drop-in compatible. Can you show any other stack which has made such strides to modernise and maintain better compatibility?
  - Someone1234 6y ago
    No, I'm literally complaining about the misleading messaging surrounding .Net 5.0 "merging" .Net Framework and .Net Core. My post was very clear on that. Like this quote from the linked article: > .NET 5.0 is the first release in our .NET unification journey. We built .NET 5.0 to enable a much larger group of developers to migrate their .NET Framework code and apps to .NET 5.0.
    - HideousKojima 6y ago
      I believe that verbage is mostly referring to options for VB.NET, Winforms, and WPF being available in Core, meaning projects that use those can be ported
    - josteink 6y ago
      > No, I'm literally complaining about the misleading messaging surrounding .Net 5.0 "merging" .Net Framework and .Net Core. Yes, it’s kinda cheating. On the other hand it has been obvious since .Net Core 1.0 that this is where the future is going to be. All announcements before .Net 5 has been clear on the compatibility issues and preparations required, for a couple of years now. Whoever haven’t been planning this migration can thank themselves. Calling what is effectively .Net Core 4.0 for simply “.Net 5.0” is just a way to make it completely obvious, even to those not paying attention, that .Net Framework 4.8 is now superseded, and that the upgrade path is .Net (Core). There’s no other option around the corner. Get with the times. Etc.
maxpert 6y ago
With Linux support AOT compliation and other goodies I wonder how many people will prefer writing backends in .NET over Java.
- qz2 6y ago
  No thanks. I've been writing .Net since before day one and quite frankly I've been buggered around enough now to run as far away from this as possible.
  - apalmer 6y ago
    Interesting, I always felt C# was a step ahead of Java, while the JVM was some steps ahead of the CLR.
    - qz2 6y ago
      The language is absolutely brilliant and I love it. It's the vendor's schizophrenia that's the problem. I've run out of fingers to count things that have been deprecated painfully on after being promoted as the next greatest thing and sold hard. This has cost me, my clients and my employers ridiculous amounts of money to unfuck.
      - cpitman 6y ago
        Totally fair, anyone in the Microsoft development ecosystem has to learn to be incredibly skeptical of anything new. Anytime I spent on adopting Silverlight was essentially wasted. I had one client that had adopted a random WYSIWYG released by Microsoft to design WCF services, when anyone experienced in the ecosystem knew it had abandonware written all over it. Of course, other ecosystems have their own versions of this. But Microsoft might be the only one that essentially controls an entire ecosystem and still manages to give devs whiplash.
        qz2 6y ago
        Exactly. Yes I interviewed at a company where Silverlight and WCF was the future and they'd just rewritten everything in it. I didn't see it with the way everything was going. I dread to think of what happened to their business when the rug was pulled out overnight. "Microsoft says you need to start funding your entire product to be rewritten from scratch"
dustinmoris 6y ago
> It’s already in active use by teams at Microsoft and other companies... 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. > 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. 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. 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. > .NET 5.0 is the first release in our .NET unification journey. 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.
- louthy 6y ago
  I use Rider now, VS got to the point of being so slow that frequently I'd have to wait 0.5 seconds for each character I was typing to appear. The performance is utterly, utterly terrible. Yet, all I see from the VS team on Twitter is "look at this new useless feature we've added", when all I needed was for the code I'm typing to appear. God help you if you ever wanted to rename a symbol, it was Schrodinger's rename, it would either complete immediately, or never complete, lock up VS, and I'd have to restart. So I had to stop using it, and eventually I stopped using VS altogether. Rider has its own quirks and annoyances, but it's quick, and lets me type even when it's doing stuff. There seems to be something very wrong with the architecture of VS.
  - fuzzy2 6y ago
    Actually Visual Studio is quite fast again. It's just that Resharper does its very best to slow it down. I don't believe this will ever change. Well except maybe Microsoft will fully deprecate COM-based in-process extensions.
hbcondo714 6y ago
> .NET 6.0 will use the same approach, with net6.0, and will add net6.0-ios and net6.0-android Huge endeavor and launch! Looks like mobile app development will be the same with Xamarin
- yellowfool 6y ago
  Mobile development in C# is just dead. Flutter got all the momentum.
  - ocdtrekkie 6y ago
    Google will move on and then all of the developers who hinged their platforms on it will need somewhere to go to.
    - okareaman 6y ago
      This bugbear seems as outdated at "M$FT is evil." Every company cancels projects. Flutter/Dart appears to have staying power.
      - zokula 6y ago
        Huh? The saying "Microsoft is evil" is as valid today as it was 20 years ago.
  - untog 6y ago
    I don't know about that. Pretty much all cross-platform solutions are a rounding error compared to the first-party Swift/Java platforms. I can believe there's potential for another yet.
  - nbevans 6y ago
    Xamarin is huge in the .NET world and Microsoft is investing heavily into it. I know plenty of LOB apps, huge apps, built in Xamarin. I don't even know of a single app built in Flutter.
  - 6y ago
mmd45 6y ago
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
- ComputerGuru 6y ago
  The ReadWriteTimeout issue was insanely aggravating; MS was adamant it was not a bug but rather an internal implementation detail for the longest time. I'm really glad they changed their minds because it was a very unexpectedly petty stance they were taking in the GitHub issue.
  - mmd45 6y ago
    what makes you say they changed their mind? afaik it's same old story. it's really incomprehensible given that all they need to do is make a call on the underlying socket.
- ocdtrekkie 6y ago
  Refusing to support System.Speech is why my project will remain locked to .NET Framework. Apparently the Microsoft Speech team is part of Azure now, and has decided nobody needs local speech synthesis that doesn't require a subscription to a cloud service.
  - mwcampbell 6y ago
    IIUC, System.Speech was simply a .NET wrapper for the Microsoft Speech API (SAPI), which has been part of Windows for a long time. If you want to move to .NET Core, you can use SAPI via COM interop. Disclosure: I currently work at Microsoft on the Windows accessibility team. We don't own SAPI or System.Speech, but we consume SAPI in Narrator (via COM in C++).
    - mmd45 6y ago
      why doesn't MS just release the SAPI wrapper as a windows only nuget package since it already exists?
the_arun 6y ago
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?
- nwah1 6y ago
  It supports linux natively. Anything windows-specific requires libraries that you can optionally add.
- GordonS 6y ago
  Someone already answered this, but yes, it's native. I've been building with C# since it was first released, and dotnet core has really opened up development on Linux for me - I build apps for Linux and Docker all the time, and they "just work" the same as they do on Linux.
- MarkSweep 6y ago
  The C# libraries either invoke the native Linux libraries directly or go throw a thin wrapper[1] that does the normal things you have to do to support multiple flavors of Unix (epoll vs kqueue, etc). Parts of the C++ runtime are written in terms of the Win32 API and on Unix these API are implemented in the PAL[2]. The PAL is not that big and I don’t the steady state performance critical code paths go through it. 1: https://github.com/dotnet/runtime/tree/master/src/libraries/Native/Unix/System.Native https://github.com/dotnet/runtime/tree/master/src/libraries/... 2: https://github.com/dotnet/runtime/tree/master/src/coreclr/src/pal https://github.com/dotnet/runtime/tree/master/src/coreclr/sr...
- spoonspoon2 6y ago
  native support, no emulation etc.
- oaiey 6y ago
  It would never achieve its performance if it would wrap something. .NET on Linux is as native on Linux as is Java, Python or Go. Also priority in Microsoft has completely changed. Most .NET runs on Linux nowadays (dockerized or not). It actually does the opposite: it is able to expose memory-alike resources (from e.g. the network interfaces) deep into its consuming programs by using abstractions like Span<T>. And while that sounds like a wrapper, it is actually (depending on the "alike") just a typed and safe pointer.
elamje 6y ago
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. Additionally, there seems to be another new way to accomplish this. Normally class properties are accessed via get; and set; 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. C# has really been adding some great features the past few years and is certainly getting more expressive and concise which I appreciate.
- kroltan 6y ago
  You probably know, but F# exists if you want a functional language in the .NET ecosystem. Granted, you end up dealing with a bunch of OOP libraries still since .NET is very C#-centered, but the language is pretty good and the integration is painless.
  - forest_dweller 6y ago
    If I wrote a F# codebase at a lot of companies I would find myself swiftly booted out the door.
    - kroltan 6y ago
      Oh yes you'd definitely get booted for using F# in a C# shop. I love F# but would never use it at my current job because nobody else on my team knows anything about FP, even though the language itself can be learned in about a week since it's so simple.
      - forest_dweller 6y ago
        My comment was a glib comment and wasn't supposed to be taken too seriously.
modernerd 6y ago
F# gains string interpolation and typed string interpolation: https://devblogs.microsoft.com/dotnet/announcing-f-5/#string-interpolation https://devblogs.microsoft.com/dotnet/announcing-f-5/#string... Knew it was coming but still really happy to see this.
- arrow7000 6y ago
  These changes are huge! I'm interested to see what I can build with computation expression overloads
- gfody 6y ago
  if this can be used to make a type checker for SQL strings like https://github.com/MedFlyt/mfsqlchecker https://github.com/MedFlyt/mfsqlchecker or https://github.com/codemix/ts-sql https://github.com/codemix/ts-sql but for C# I will be stoked!
  - smoothdeveloper 6y ago
    The closest thing is https://github.com/rspeele/Rezoom.SQL https://github.com/rspeele/Rezoom.SQL which once compiled in your F# project, can be used in C# by referencing the generated assembly. Although this is nothing to do with string interpolation, the "typed string interpolation" refer to the F# printf format specifiers. You could also build such tool separately using FSharp.Compiler.Service (possibly using the analyzer infrastructure for ionide: https://github.com/ionide/FSharp.Analyzers.SDK https://github.com/ionide/FSharp.Analyzers.SDK), AFAIU there will be consolidation of this type of tooling relying on FSharp.Compiler.Service in the future to make this integrated to all F# tooling.
    - gfody 6y ago
      this is a nice looking project, I actually starred it in the past and had been meaning to check it out - thanks for reminding me!
mattmanser 6y ago
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. 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. 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. 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 config injected! 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. Huge disadvantages with absolutely zero performance gains for 95% of programmers. 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.
- Lendal 6y ago
  I found Go to be a really nice replacement for C#. It has the static typing and garbage collection, but you also get a self-contained binary executing without the requirement of an external runtime environment. I also discovered that I don't miss classes at all.
  - tester756 6y ago
    >but you also get a self-contained binary executing without the requirement of an external runtime environment. I'm not sure whether we're talking about the same thing, but you can publish Self-Contained App (basically your app and framework together) and you don't have to install anything.
mmd45 6y ago
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.
- lostmsu 6y ago
  How did net48 bite?
  - mmd45 6y ago
    extensive changes to the gc exposed an application issue that was complex to address. and no way to rollback the machine to net472.
- josteink 6y ago
  Side-by-side. It’s effectively .Net Core 4.0, but they removed the “core” and versioned it 5.0 to make it more obvious that it supersedes and obsoletes .Net Framework 4.8 which lots of organizations are still clinging to.
  - mmd45 6y ago
    to be clear- you are saying it is side by side with netcore31?
    - josteink 6y ago
      Yeah. I guess it depends on how it gets installed, but there’s absolutely nothing preventing it from running side-by-side. I’ve been hot-swapping 3.1 and 5.0-rc2 for projects, preparing for the final 5.0 release.
      - mmd45 6y ago
        so, i see 4 different runtime installs (base/aspnet/aspnet-hosting/desktop) here https://github.com/dotnet/core/blob/master/release-notes/5.0/5.0.0/5.0.0.md https://github.com/dotnet/core/blob/master/release-notes/5.0... . where can i find instructions for doing a side by side install? thanks
nwah1 6y ago
Congratulations to the team. Microsoft has made exceptional strides in terms of performance and compatibility. The whole vision is what is really impressive, not any individual part. 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. Many of the surrounding libraries like ASP.NET, Kestrel, LINQ, Entity Framework Core, System.Text.Json, etc are best in class. I look forward to the Linker becoming stable, as this will really help in contexts such as Azure Functions and AWS Lambda.
deostroll 6y ago
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. 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). 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. 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. 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.
- jabart 6y ago
  You can use Notepad and run "dotnet run" to run your .net core programs, including winforms. .cshtml files can also be compiled at run-time or at build time with .net core.
- davidspiess 6y ago
  You could combine Node.js with TypeScript to regain type safety.
  - e12e 6y ago
    See also https://deno.land https://deno.land
- jiggawatts 6y ago
  > But I wish stuff was as simple as having a plain editor and getting started. This is the wrong thing to wish for. It's like... wishing for "simpler times" of the pre-modern era. You know, the simpler times without dentistry and plagues that make COVID look downright pleasant. Simpler times of backbreaking manual labour, shovelling ditches by hand. A typical computer can now process 10 billion general-purpose instructions per second. It is a power tool for the mind. Its entire purpose is to eliminate manual labour. The fundamental concept of computerised information technology is to automate away the processing of information as much as possible. If you don't get this, then you don't get IT at all. There is nothing at all good, or somehow more "pure" about programming with Notepad, or VI, or whatever text editor you fancy. This is like turning off the million dollar backhoe, stepping out of the cabin, and digging the ditch with your hands because you feel that it brings you "closer to the dirt" or something.
SloopJon 6y ago
Note that .NET 5.0 is not an LTS release: > .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.
- joshschreuder 6y ago
  I believe Microsoft are still recommending people move to .NET 5 though. Unless you're extremely risk averse it seems like a very simple upgrade from 3.1 to 5 and hopefully 5 to 6 next November (which will be the LTS release) is the same.
  - flamtap 6y ago
    I just did a straight up find-replace for `netcoreapp3.1` -> `net5.0` across 66 projects, built and passed tests without a hitch. Zero issues so far outside of the warnings resulting from enhanced nullable reference type smarts .
eatonphil 6y ago
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.
iso8859-1 6y ago
People who think this is actually cross-platform need to consider these points: * 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? * 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.
- tester756 6y ago
  >Microsoft won't commit to maintaining any cross-platform GUI libraries. Isn't that MAUI?
  - iso8859-1 6y ago
    MAUI is relying on the community to provide Linux support, just like with Xamarin.Forms. I worked with Xamarin.Forms, it doesn't support hardware acceleration in its GTK backend, making it unusable on HiDPI displays (consumes too much CPU). Why would MAUI be any different?
    - csharptwdec19 6y ago
      > Why would MAUI be any different? Speaking cynically, if it's tied enough into the main Microsoft Ecosystem it will have more community buy-in. You see this happen with other parts of .NET as well, often to the chagrin of the OSS Devs who filled Microsoft's gaps only to be replaced by an (often inferior) solution.
- GordonS 6y ago
  There may well be some niggles that affect a small number of people doing some niche things under specific circumstances, but I don't think that's enough to claims it's not cross-platform. Since dotnet core became a thing, I've been building cross-platform apps with great success - mostly Windows and Linux, occasionally MacOS too, and mostly x64, but also ARM too.
dotnethell 6y ago
Does Asp.NET identity still use a Guid for primary key? I remember it being hell trying to convert to int a few years ago which left a sour taste.
- kgwxd 6y ago
  I think the default is a string now (nvarchar 450). Here's [1] a guide on changing the PK type, but the example uses Guid instead of string. I assume int could be used too, but I wonder if changing to db generated value would cause headaches/show-stoppers. [1] https://docs.microsoft.com/en-us/aspnet/core/security/authentication/customize-identity-model?view=aspnetcore-5.0#change-the-primary-key-type https://docs.microsoft.com/en-us/aspnet/core/security/authen...
- twooclock 6y ago
  I belive it uses guid (or a string that stores guid :-/) but it's fairly easy to change it to int. That's what I have in my boilerplate-kickstart template, anyway. Still I remember I was "surprised" too.
- Yuioup 6y ago
  Why would you want to.
soapdog 6y ago
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. 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. This is bad, and part of the reason there are so few app running natively on the Surface Pro X.
- Longhanks 6y ago
  Meanwhile, this week launch three Apple products that come with a free toolchain and IDE tailored perfectly to the new architecture that supports old and new UI APIs. On the Windows side, Visual Studio is still a 32bit application, and as you have pointed out, on ARM, it supports basically nothing but the ancient Win32 C API.
  - hackerfromthefu 6y ago
    Yes but on Apple then you are at the mercy of the XCode environment. It's not all it's cracked up to be, and it's pretty cracked up..
  - masterofmisc 6y ago
    Yep, they are just quietly slogging away over there on thier singular vision. They are not all over the map like Microsoft have been in the past: Throw everything against a wall and see what sticks approach!
- doublerebel 6y ago
  Similarly, porting from HoloLens 1 (x86) to HoloLens 2 (aarch64) has been... challenging in many cases. For instance, there is no Fortran compiler easily available for Windows aarch64, but Apple has promised to ship one for the new Apple Silicon on day 1. EDIT: Here it is, right on time -- https://www.nag.com/news/first-fortran-compiler-apple-silicon-macs https://www.nag.com/news/first-fortran-compiler-apple-silico...
bob1029 6y ago
Congrats to everyone involved. This is a huge accomplishment and arguably many steps in the right direction. 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. 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. 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. 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.
- flamtap 6y ago
  >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 FWIW, I just did a find/replace across 66 projects for `netcoreapp3.1` => `net5.0` and it build and passed tests first try. There were a fair few new nullable reference type warnings though!
  - dazbradbury 6y ago
    "Our migration from 4.7=>2.0 was the most difficult" Would love to see a write up of your challenges / approach. Seems to be a big lack of write ups on this process that I'm sure lots of devs would appreciate!
    - bob1029 6y ago
      I can give you a 500 word abstract here. The core challenge was dealing with 3rd party dependencies (Nugets) relative to each project. We ultimately found that attempting to mix Framework/Core/Standard projects together was an excellent substitute for nightmare fuel. So, the happy path for us turned out to be to do it all at once and only use .NET Core project types throughout (DLL/EXE). Trying to convert your overall solution 1 project at a time hoping for some sort of incremental outcome is probably going to be more frustration than it's worth. Assuming you bite the bullet on all or nothing, the next challenge will be: Is your code is even supported anymore? This is obviously going to vary wildly depending on your use cases. For us, the Microsoft.Windows.Compatibility shim was enough to restore 100% of the functionality (we rely on System.Drawing and DirectoryServices). But, there was also a lot of other rewrite to support new AspNetCore primitives, and we also moved over to Blazor for web UI (which is more of a rewrite than migration).
francisl 6y ago
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?! edit: 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).` Still wondering for .net 5 though
- oaiey 6y ago
  I think this will be a patch release soonish. ARM is well supported already and the toolchain on macOS is also present already. And they need it to support the development of .NET 6.
spoonspoon2 6y ago
You can now write very short functions in C#: int Factorial(int n) => n is <= 1 ? 1 : n * factorial(n -1);
PretzelFisch 6y ago
One day I would really like to see the ability to have C#, F# and other languages all in the same project.
- jackfoxy 6y ago
  That will be a stretch, since they require different compilers. C# and F# projects in the same solution not good enough?
acalzycalzy 6y ago
I’m just excited to see NET 5.0 things when checking to see windows os upgrades. I have no idea what it means or the significance of it.
rattray 6y ago
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.
- mdpm 6y ago
  There is no .NET Core 4? There was a .NET Framework 4. 5 is how the streams are being crossed.
- deleted 6y ago
  [deleted]
_acco 6y ago
The future is very bright for .NET. It has the right raison d'etre - .NET is part of the growth story for Nadella-Microsoft. 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. 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. One of the core issues feels so... trite. But experiencing it, I realized how real it really was: The Names. Microsoft has created a Ninja Warrior obstacle course of proper nouns. It is comical. It is worthy of parody. .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. 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. 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. It was almost never immediately clear if a document I was looking at on Microsoft's own website applied to me or not. That is a cardinal sin of technical documentation. Ultimately, this meant that .NET Core Web API (or whatever I was using) felt poorly documented. 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. 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.
- FridgeSeal 6y ago
  > Azure will win you over from AWS every time. Going to have to disagree here. That might be the case if Azure was not literally a tire-fire. I have been using Azure for work and it's the most frustrating, inconsistent, often-broken, confusing and stress-inducing cloud service that my teammates and I have ever been subjected to. It left such a bad taste that I am quite certain I would flat-out refuse to use it again in the future, or work somewhere that uses it. Take my advice: just don't use it. It's not worth it. Use AWS, use GCP, use Digital Ocean. Use some random cloud provider. Just don't use Azure.
  - 6y ago
thrower123 6y ago
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. This version will be nearly out of support by then...
- oaiey 6y ago
  When your code depend on stuff not migrated yet, it will no longer happen. From a .NET Framework position, .NET 5 is a huge breaking change by loosing capabilities and using different base libraries (which will not be recovered later). From a .NET Core 3.1 perspective, it is a minor update. .NET 5 reality is: They ported 90% of their app models (e.g. wpf, winforms, ...) and dropped some other (e.g. WCF, WWF, AppDomains, ...). That is not going to change. .NET ecoysystem reality is: What is not ported until now, will not be ported. .NET Core is now 6 years old (2014?) and everything new is currently .NET Core. Someone who wants to stay in business, has ported already 2-3 years ago.
  - thrower123 6y ago
    Well, I've still got to support integrations with other Microsoft products that are in support for the next decade, and only have Fx SDKs. Tooling in Visual Studio has sucked out loud for most of the Core stuff thus far. There's not a lot of value chasing the churn versus letting it settle out.
    - oaiey 6y ago
      I am also there. Ugly.
ablekh 6y ago
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). [1] https://www.infoq.com/articles/advanced-architecture-aspnet-core https://www.infoq.com/articles/advanced-architecture-aspnet-... [2] https://www.claudiobernasconi.ch/2019/01/24/the-ultimate-list-of-net-dependency-injection-frameworks https://www.claudiobernasconi.ch/2019/01/24/the-ultimate-lis... [3] https://docs.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support https://docs.microsoft.com/en-us/dotnet/core/tutorials/creat... [4] https://github.com/natemcmaster/DotNetCorePlugins https://github.com/natemcmaster/DotNetCorePlugins [5] https://maartenmerken.medium.com/announcing-prise-a-plugin-framework-for-net-core-4af7cf5b4d2b https://maartenmerken.medium.com/announcing-prise-a-plugin-f... [6] http://ewer.com.br/plugin-architecture-with-di-containers http://ewer.com.br/plugin-architecture-with-di-containers
- bob1029 6y ago
  The DI in .NET is really powerful and feels intuitive once you play around with it in a few different projects. We have almost 100 services injected into .NET Core DI and it always feels very stable and manageable. For us, we cheated a little bit on many services and just take a dependency on IServiceProvider to get at other services at runtime. This allows for any service to talk to any other service without worrying about some monster CTOR hierarchy. We used to try to keep things "correct" in terms of dependency chain, but we have found that the real world is a lot easier to work with when you permit circular dependencies between services and maintain 1 big flat collection of them. This is basically microservices but without the RPC ceremony and associated nightmares.
  - ablekh 6y ago
mrlonglong 6y ago
Even more important, what's been happening with .NET/VB?
- bhandziuk 6y ago
  Nothing is happening with VB.NET https://devblogs.microsoft.com/vbteam/visual-basic-support-planned-for-net-5-0/ https://devblogs.microsoft.com/vbteam/visual-basic-support-p...
sytelus 6y ago
Seems like .Net 6 will have cross-platform UX forms! That sounds very exciting.
xpressvideoz 6y ago
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. https://visualstudiomagazine.com/articles/2020/08/31/aot-survey.aspx https://visualstudiomagazine.com/articles/2020/08/31/aot-sur...
- Luuseens 6y ago
  I find CoreRT covers a lot of my current AOT needs. For me, one of the blockers was Winfows.Forms not working with AOT, which appears to have been resolved very recently: https://github.com/dotnet/winforms/pull/4177 https://github.com/dotnet/winforms/pull/4177
Siira 6y ago
There is also going to be a crossplatform (including mobile) UI library for .Net 6: https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/ https://devblogs.microsoft.com/dotnet/introducing-net-multi-...
txdv 6y ago
Where did Java interop go?
- oaiey 6y ago
  Educated guess: shifted with net6.0-android. That is the core driver. Same as swift integration with net6.0-ios.
szntb 6y ago
I really like where thing are heading with .NET. 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.

.NET 5.0

791 points by benaadams 6y ago

Belphemur 6y ago

Does anybody knows if .NET 5.0 will be included in Windows as a Windows Update as the .NET Framework ?

ocdtrekkie 6y ago
It won't be. .NET Framework is an embedded component of Windows. .NET Core is something apps have to package along with them. (Due to this, .NET Core apps are larger than .NET Framework apps, but tend to have less compatibility issues in theory, since they bring everything they need with them.)
- dt3ft 6y ago
  Are you sure it will not be distributed with Windows? Is 4.8 the last version being distributed with Windows, requiring all future .NET framework versions to be packaged with the apps?
  - ClumsyPilot 6y ago
    The idea is that its installed separately from windows, in the same way one might install java. So because you can have mutiple versions installed, or you can package it with an app , then the updates can be more rapid. The problem with .Net framework is that everything, including system services rely on it - that means it needs years of testing and can't have any breaking changes. Basically they decided that packaging .net as part of windows was a mistake.
    - ocdtrekkie 6y ago
      I feel their mistake was not allowing apps to call a specific version if needbe, not with the general decision to include it in Windows. While .NET Framework updates annoyingly force every app to use it, I expect .NET Core to make it super difficult to secure apps that decided to hardcode some specific ancient release of it and allow no way to override it.
      - WorldMaker 6y ago
        .NET Framework was built to support and did allow systems to have multiple versions installed side-by-side and apps to call specific Framework versions and was built to support many versions side-by-side. But that turned out to be more difficult in practice than in theory. Multiple side-by-side Frameworks turned out to be more hassle than useful, and even with just 3 versions of the Framework that were built to live side-by-side (1.x, 2.x, sort of 4.x, long story) that was often pointed to as a source of bloat in Windows. The mistake to include it in Windows was partly why more versions weren't made (because then they'd have to be serviced for the length of a Windows version's service lifetime; because then they'd contribute way more to Windows bloat).
  - atraac 6y ago
    4.8 is the version of a .NET Framework. What we have now is essentially .NET Core 4, with a misleading name of .NET 5 that confuses people. .NET Core is not being provided with Windows Update, like someone already said, you need to package it yourself with your app.
  - jhoward321 6y ago
    There will be no future .NET framework versions so I believe he's correct. .NET 5 is a new version of .net core
  - ocdtrekkie 6y ago
    Yeah, .NET Framework will see no new features, so they'll continue to patch bugs in 4.8 probably for over a decade to come, and a lot of new apps will just not use it, and include .NET Core runtime instead.
- jiggawatts 6y ago
  It also means that the first major vulnerability in .NET Core will be an unmitigated clusterfuck, as admins will have no automated tooling in place to update .NET Core with security patches. "Just recompile with the new version!" I hear the cries already, said by people that have never had to support literally a thousand applications in a government data centre, half of which were built years ago by a vendor that is long since bankrupt.
  - huzaif 6y ago
    Publish your apps without .net core (--no-self-contained) and install/manage runtimes as you usually would. If you have thousand apps, you probably also have a CI/CD system and you can gain fine grained control on your runtime management needs with .net build/publish. MS does quite a few things poorly but they have done a solid job of operating in large enterprises.
    - jiggawatts 6y ago
      > you probably also have a CI/CD system Or more realistically, dozens of CI/CD systems, covering less than a third of the applications.
    - ocdtrekkie 6y ago
      "Publish your apps" isn't the issue: I support a lot of applications I don't build or have the source code for. And they may be on my network for over ten years. The problem is if developers are publishing self-contained apps with .NET Core, IT staff will be up a creek on vulnerability mitigation. While being able to pin specific .NET Core versions is nice for developers, being able to require the most current .NET Core version be used is important for IT staff who have to support these applications.
      - hackerfromthefu 6y ago
        I'm expecting as this issue plays out, there will be a way to inject an updated framework to an existing app with a utility tool. Probably first party but definitely third party.
- int_19h 6y ago
  .NET Core apps don't have to package the framework. They can also require it to be installed separately, although it's still not an OS component in that case. https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-framework-dependent https://docs.microsoft.com/en-us/dotnet/core/deploying/#publ...
mariusmg 6y ago
Nope, since this .NET 5 is NOT a replacemnt for .Net Framework 4.8

Someone1234 6y ago

> From what we’ve seen and heard so far, .NET 5.0 delivers significant value without much effort to upgrade. 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]). 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. [0] https://docs.microsoft.com/en-us/aspnet/core/migration/mvc?view=aspnetcore-5.0 https://docs.microsoft.com/en-us/aspnet/core/migration/mvc?v...

josteink 6y ago
> From the previous version of .Net Core only. Which is already three major versions ahead off classic .net. You’re literally complaining about making upgrades past four major releases not being drop-in compatible. Can you show any other stack which has made such strides to modernise and maintain better compatibility?
- Someone1234 6y ago
  No, I'm literally complaining about the misleading messaging surrounding .Net 5.0 "merging" .Net Framework and .Net Core. My post was very clear on that. Like this quote from the linked article: > .NET 5.0 is the first release in our .NET unification journey. We built .NET 5.0 to enable a much larger group of developers to migrate their .NET Framework code and apps to .NET 5.0.
  - HideousKojima 6y ago
    I believe that verbage is mostly referring to options for VB.NET, Winforms, and WPF being available in Core, meaning projects that use those can be ported
  - josteink 6y ago
    > No, I'm literally complaining about the misleading messaging surrounding .Net 5.0 "merging" .Net Framework and .Net Core. Yes, it’s kinda cheating. On the other hand it has been obvious since .Net Core 1.0 that this is where the future is going to be. All announcements before .Net 5 has been clear on the compatibility issues and preparations required, for a couple of years now. Whoever haven’t been planning this migration can thank themselves. Calling what is effectively .Net Core 4.0 for simply “.Net 5.0” is just a way to make it completely obvious, even to those not paying attention, that .Net Framework 4.8 is now superseded, and that the upgrade path is .Net (Core). There’s no other option around the corner. Get with the times. Etc.

maxpert 6y ago

With Linux support AOT compliation and other goodies I wonder how many people will prefer writing backends in .NET over Java.

qz2 6y ago
No thanks. I've been writing .Net since before day one and quite frankly I've been buggered around enough now to run as far away from this as possible.
- apalmer 6y ago
  Interesting, I always felt C# was a step ahead of Java, while the JVM was some steps ahead of the CLR.
  - qz2 6y ago
    The language is absolutely brilliant and I love it. It's the vendor's schizophrenia that's the problem. I've run out of fingers to count things that have been deprecated painfully on after being promoted as the next greatest thing and sold hard. This has cost me, my clients and my employers ridiculous amounts of money to unfuck.
    - cpitman 6y ago
      Totally fair, anyone in the Microsoft development ecosystem has to learn to be incredibly skeptical of anything new. Anytime I spent on adopting Silverlight was essentially wasted. I had one client that had adopted a random WYSIWYG released by Microsoft to design WCF services, when anyone experienced in the ecosystem knew it had abandonware written all over it. Of course, other ecosystems have their own versions of this. But Microsoft might be the only one that essentially controls an entire ecosystem and still manages to give devs whiplash.
      - qz2 6y ago
        Exactly. Yes I interviewed at a company where Silverlight and WCF was the future and they'd just rewritten everything in it. I didn't see it with the way everything was going. I dread to think of what happened to their business when the rug was pulled out overnight. "Microsoft says you need to start funding your entire product to be rewritten from scratch"

dustinmoris 6y ago

> It’s already in active use by teams at Microsoft and other companies... 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. > 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. 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. 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. > .NET 5.0 is the first release in our .NET unification journey. 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.

louthy 6y ago
I use Rider now, VS got to the point of being so slow that frequently I'd have to wait 0.5 seconds for each character I was typing to appear. The performance is utterly, utterly terrible. Yet, all I see from the VS team on Twitter is "look at this new useless feature we've added", when all I needed was for the code I'm typing to appear. God help you if you ever wanted to rename a symbol, it was Schrodinger's rename, it would either complete immediately, or never complete, lock up VS, and I'd have to restart. So I had to stop using it, and eventually I stopped using VS altogether. Rider has its own quirks and annoyances, but it's quick, and lets me type even when it's doing stuff. There seems to be something very wrong with the architecture of VS.
- fuzzy2 6y ago
  Actually Visual Studio is quite fast again. It's just that Resharper does its very best to slow it down. I don't believe this will ever change. Well except maybe Microsoft will fully deprecate COM-based in-process extensions.

hbcondo714 6y ago

> .NET 6.0 will use the same approach, with net6.0, and will add net6.0-ios and net6.0-android Huge endeavor and launch! Looks like mobile app development will be the same with Xamarin

yellowfool 6y ago
Mobile development in C# is just dead. Flutter got all the momentum.
- ocdtrekkie 6y ago
  Google will move on and then all of the developers who hinged their platforms on it will need somewhere to go to.
  - okareaman 6y ago
    This bugbear seems as outdated at "M$FT is evil." Every company cancels projects. Flutter/Dart appears to have staying power.
    - zokula 6y ago
      Huh? The saying "Microsoft is evil" is as valid today as it was 20 years ago.
- untog 6y ago
  I don't know about that. Pretty much all cross-platform solutions are a rounding error compared to the first-party Swift/Java platforms. I can believe there's potential for another yet.
- nbevans 6y ago
  Xamarin is huge in the .NET world and Microsoft is investing heavily into it. I know plenty of LOB apps, huge apps, built in Xamarin. I don't even know of a single app built in Flutter.
- 6y ago

mmd45 6y ago

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

ComputerGuru 6y ago
The ReadWriteTimeout issue was insanely aggravating; MS was adamant it was not a bug but rather an internal implementation detail for the longest time. I'm really glad they changed their minds because it was a very unexpectedly petty stance they were taking in the GitHub issue.
- mmd45 6y ago
  what makes you say they changed their mind? afaik it's same old story. it's really incomprehensible given that all they need to do is make a call on the underlying socket.
ocdtrekkie 6y ago
Refusing to support System.Speech is why my project will remain locked to .NET Framework. Apparently the Microsoft Speech team is part of Azure now, and has decided nobody needs local speech synthesis that doesn't require a subscription to a cloud service.
- mwcampbell 6y ago
  IIUC, System.Speech was simply a .NET wrapper for the Microsoft Speech API (SAPI), which has been part of Windows for a long time. If you want to move to .NET Core, you can use SAPI via COM interop. Disclosure: I currently work at Microsoft on the Windows accessibility team. We don't own SAPI or System.Speech, but we consume SAPI in Narrator (via COM in C++).
  - mmd45 6y ago
    why doesn't MS just release the SAPI wrapper as a windows only nuget package since it already exists?

the_arun 6y ago

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?

nwah1 6y ago
It supports linux natively. Anything windows-specific requires libraries that you can optionally add.
GordonS 6y ago
Someone already answered this, but yes, it's native. I've been building with C# since it was first released, and dotnet core has really opened up development on Linux for me - I build apps for Linux and Docker all the time, and they "just work" the same as they do on Linux.
MarkSweep 6y ago
The C# libraries either invoke the native Linux libraries directly or go throw a thin wrapper[1] that does the normal things you have to do to support multiple flavors of Unix (epoll vs kqueue, etc). Parts of the C++ runtime are written in terms of the Win32 API and on Unix these API are implemented in the PAL[2]. The PAL is not that big and I don’t the steady state performance critical code paths go through it. 1: https://github.com/dotnet/runtime/tree/master/src/libraries/Native/Unix/System.Native https://github.com/dotnet/runtime/tree/master/src/libraries/... 2: https://github.com/dotnet/runtime/tree/master/src/coreclr/src/pal https://github.com/dotnet/runtime/tree/master/src/coreclr/sr...
spoonspoon2 6y ago
native support, no emulation etc.
oaiey 6y ago
It would never achieve its performance if it would wrap something. .NET on Linux is as native on Linux as is Java, Python or Go. Also priority in Microsoft has completely changed. Most .NET runs on Linux nowadays (dockerized or not). It actually does the opposite: it is able to expose memory-alike resources (from e.g. the network interfaces) deep into its consuming programs by using abstractions like Span<T>. And while that sounds like a wrapper, it is actually (depending on the "alike") just a typed and safe pointer.

elamje 6y ago

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. Additionally, there seems to be another new way to accomplish this. Normally class properties are accessed via get; and set; 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. C# has really been adding some great features the past few years and is certainly getting more expressive and concise which I appreciate.

kroltan 6y ago
You probably know, but F# exists if you want a functional language in the .NET ecosystem. Granted, you end up dealing with a bunch of OOP libraries still since .NET is very C#-centered, but the language is pretty good and the integration is painless.
- forest_dweller 6y ago
  If I wrote a F# codebase at a lot of companies I would find myself swiftly booted out the door.
  - kroltan 6y ago
    Oh yes you'd definitely get booted for using F# in a C# shop. I love F# but would never use it at my current job because nobody else on my team knows anything about FP, even though the language itself can be learned in about a week since it's so simple.
    - forest_dweller 6y ago
      My comment was a glib comment and wasn't supposed to be taken too seriously.

modernerd 6y ago

F# gains string interpolation and typed string interpolation: https://devblogs.microsoft.com/dotnet/announcing-f-5/#string-interpolation https://devblogs.microsoft.com/dotnet/announcing-f-5/#string... Knew it was coming but still really happy to see this.

arrow7000 6y ago
These changes are huge! I'm interested to see what I can build with computation expression overloads
gfody 6y ago
if this can be used to make a type checker for SQL strings like https://github.com/MedFlyt/mfsqlchecker https://github.com/MedFlyt/mfsqlchecker or https://github.com/codemix/ts-sql https://github.com/codemix/ts-sql but for C# I will be stoked!
- smoothdeveloper 6y ago
  The closest thing is https://github.com/rspeele/Rezoom.SQL https://github.com/rspeele/Rezoom.SQL which once compiled in your F# project, can be used in C# by referencing the generated assembly. Although this is nothing to do with string interpolation, the "typed string interpolation" refer to the F# printf format specifiers. You could also build such tool separately using FSharp.Compiler.Service (possibly using the analyzer infrastructure for ionide: https://github.com/ionide/FSharp.Analyzers.SDK https://github.com/ionide/FSharp.Analyzers.SDK), AFAIU there will be consolidation of this type of tooling relying on FSharp.Compiler.Service in the future to make this integrated to all F# tooling.
  - gfody 6y ago
    this is a nice looking project, I actually starred it in the past and had been meaning to check it out - thanks for reminding me!

mattmanser 6y ago

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. 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. 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. 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 config injected! 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. Huge disadvantages with absolutely zero performance gains for 95% of programmers. 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.

Lendal 6y ago
I found Go to be a really nice replacement for C#. It has the static typing and garbage collection, but you also get a self-contained binary executing without the requirement of an external runtime environment. I also discovered that I don't miss classes at all.
- tester756 6y ago
  >but you also get a self-contained binary executing without the requirement of an external runtime environment. I'm not sure whether we're talking about the same thing, but you can publish Self-Contained App (basically your app and framework together) and you don't have to install anything.

mmd45 6y ago

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.

lostmsu 6y ago
How did net48 bite?
- mmd45 6y ago
  extensive changes to the gc exposed an application issue that was complex to address. and no way to rollback the machine to net472.
josteink 6y ago
Side-by-side. It’s effectively .Net Core 4.0, but they removed the “core” and versioned it 5.0 to make it more obvious that it supersedes and obsoletes .Net Framework 4.8 which lots of organizations are still clinging to.
- mmd45 6y ago
  to be clear- you are saying it is side by side with netcore31?
  - josteink 6y ago
    Yeah. I guess it depends on how it gets installed, but there’s absolutely nothing preventing it from running side-by-side. I’ve been hot-swapping 3.1 and 5.0-rc2 for projects, preparing for the final 5.0 release.
    - mmd45 6y ago
      so, i see 4 different runtime installs (base/aspnet/aspnet-hosting/desktop) here https://github.com/dotnet/core/blob/master/release-notes/5.0/5.0.0/5.0.0.md https://github.com/dotnet/core/blob/master/release-notes/5.0... . where can i find instructions for doing a side by side install? thanks

nwah1 6y ago

Congratulations to the team. Microsoft has made exceptional strides in terms of performance and compatibility. The whole vision is what is really impressive, not any individual part. 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. Many of the surrounding libraries like ASP.NET, Kestrel, LINQ, Entity Framework Core, System.Text.Json, etc are best in class. I look forward to the Linker becoming stable, as this will really help in contexts such as Azure Functions and AWS Lambda.

deostroll 6y ago

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. 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). 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. 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. 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.

jabart 6y ago
You can use Notepad and run "dotnet run" to run your .net core programs, including winforms. .cshtml files can also be compiled at run-time or at build time with .net core.
davidspiess 6y ago
You could combine Node.js with TypeScript to regain type safety.
- e12e 6y ago
  See also https://deno.land https://deno.land
jiggawatts 6y ago
> But I wish stuff was as simple as having a plain editor and getting started. This is the wrong thing to wish for. It's like... wishing for "simpler times" of the pre-modern era. You know, the simpler times without dentistry and plagues that make COVID look downright pleasant. Simpler times of backbreaking manual labour, shovelling ditches by hand. A typical computer can now process 10 billion general-purpose instructions per second. It is a power tool for the mind. Its entire purpose is to eliminate manual labour. The fundamental concept of computerised information technology is to automate away the processing of information as much as possible. If you don't get this, then you don't get IT at all. There is nothing at all good, or somehow more "pure" about programming with Notepad, or VI, or whatever text editor you fancy. This is like turning off the million dollar backhoe, stepping out of the cabin, and digging the ditch with your hands because you feel that it brings you "closer to the dirt" or something.

SloopJon 6y ago

Note that .NET 5.0 is not an LTS release: > .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.

joshschreuder 6y ago
I believe Microsoft are still recommending people move to .NET 5 though. Unless you're extremely risk averse it seems like a very simple upgrade from 3.1 to 5 and hopefully 5 to 6 next November (which will be the LTS release) is the same.
- flamtap 6y ago
  I just did a straight up find-replace for `netcoreapp3.1` -> `net5.0` across 66 projects, built and passed tests without a hitch. Zero issues so far outside of the warnings resulting from enhanced nullable reference type smarts .

eatonphil 6y ago

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.

iso8859-1 6y ago

People who think this is actually cross-platform need to consider these points: * 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? * 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.

tester756 6y ago
>Microsoft won't commit to maintaining any cross-platform GUI libraries. Isn't that MAUI?
- iso8859-1 6y ago
  MAUI is relying on the community to provide Linux support, just like with Xamarin.Forms. I worked with Xamarin.Forms, it doesn't support hardware acceleration in its GTK backend, making it unusable on HiDPI displays (consumes too much CPU). Why would MAUI be any different?
  - csharptwdec19 6y ago
    > Why would MAUI be any different? Speaking cynically, if it's tied enough into the main Microsoft Ecosystem it will have more community buy-in. You see this happen with other parts of .NET as well, often to the chagrin of the OSS Devs who filled Microsoft's gaps only to be replaced by an (often inferior) solution.
GordonS 6y ago
There may well be some niggles that affect a small number of people doing some niche things under specific circumstances, but I don't think that's enough to claims it's not cross-platform. Since dotnet core became a thing, I've been building cross-platform apps with great success - mostly Windows and Linux, occasionally MacOS too, and mostly x64, but also ARM too.

dotnethell 6y ago

Does Asp.NET identity still use a Guid for primary key? I remember it being hell trying to convert to int a few years ago which left a sour taste.

kgwxd 6y ago
I think the default is a string now (nvarchar 450). Here's [1] a guide on changing the PK type, but the example uses Guid instead of string. I assume int could be used too, but I wonder if changing to db generated value would cause headaches/show-stoppers. [1] https://docs.microsoft.com/en-us/aspnet/core/security/authentication/customize-identity-model?view=aspnetcore-5.0#change-the-primary-key-type https://docs.microsoft.com/en-us/aspnet/core/security/authen...
twooclock 6y ago
I belive it uses guid (or a string that stores guid :-/) but it's fairly easy to change it to int. That's what I have in my boilerplate-kickstart template, anyway. Still I remember I was "surprised" too.
Yuioup 6y ago
Why would you want to.

soapdog 6y ago

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. 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. This is bad, and part of the reason there are so few app running natively on the Surface Pro X.

Longhanks 6y ago
Meanwhile, this week launch three Apple products that come with a free toolchain and IDE tailored perfectly to the new architecture that supports old and new UI APIs. On the Windows side, Visual Studio is still a 32bit application, and as you have pointed out, on ARM, it supports basically nothing but the ancient Win32 C API.
- hackerfromthefu 6y ago
  Yes but on Apple then you are at the mercy of the XCode environment. It's not all it's cracked up to be, and it's pretty cracked up..
- masterofmisc 6y ago
  Yep, they are just quietly slogging away over there on thier singular vision. They are not all over the map like Microsoft have been in the past: Throw everything against a wall and see what sticks approach!
doublerebel 6y ago
Similarly, porting from HoloLens 1 (x86) to HoloLens 2 (aarch64) has been... challenging in many cases. For instance, there is no Fortran compiler easily available for Windows aarch64, but Apple has promised to ship one for the new Apple Silicon on day 1. EDIT: Here it is, right on time -- https://www.nag.com/news/first-fortran-compiler-apple-silicon-macs https://www.nag.com/news/first-fortran-compiler-apple-silico...

bob1029 6y ago

Congrats to everyone involved. This is a huge accomplishment and arguably many steps in the right direction. 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. 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. 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. 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.

flamtap 6y ago
>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 FWIW, I just did a find/replace across 66 projects for `netcoreapp3.1` => `net5.0` and it build and passed tests first try. There were a fair few new nullable reference type warnings though!
- dazbradbury 6y ago
  "Our migration from 4.7=>2.0 was the most difficult" Would love to see a write up of your challenges / approach. Seems to be a big lack of write ups on this process that I'm sure lots of devs would appreciate!
  - bob1029 6y ago
    I can give you a 500 word abstract here. The core challenge was dealing with 3rd party dependencies (Nugets) relative to each project. We ultimately found that attempting to mix Framework/Core/Standard projects together was an excellent substitute for nightmare fuel. So, the happy path for us turned out to be to do it all at once and only use .NET Core project types throughout (DLL/EXE). Trying to convert your overall solution 1 project at a time hoping for some sort of incremental outcome is probably going to be more frustration than it's worth. Assuming you bite the bullet on all or nothing, the next challenge will be: Is your code is even supported anymore? This is obviously going to vary wildly depending on your use cases. For us, the Microsoft.Windows.Compatibility shim was enough to restore 100% of the functionality (we rely on System.Drawing and DirectoryServices). But, there was also a lot of other rewrite to support new AspNetCore primitives, and we also moved over to Blazor for web UI (which is more of a rewrite than migration).

francisl 6y ago

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?! edit: 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).` Still wondering for .net 5 though

oaiey 6y ago
I think this will be a patch release soonish. ARM is well supported already and the toolchain on macOS is also present already. And they need it to support the development of .NET 6.

spoonspoon2 6y ago

You can now write very short functions in C#: int Factorial(int n) => n is <= 1 ? 1 : n * factorial(n -1);

PretzelFisch 6y ago

One day I would really like to see the ability to have C#, F# and other languages all in the same project.

jackfoxy 6y ago
That will be a stretch, since they require different compilers. C# and F# projects in the same solution not good enough?

acalzycalzy 6y ago

I’m just excited to see NET 5.0 things when checking to see windows os upgrades. I have no idea what it means or the significance of it.

rattray 6y ago

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.

mdpm 6y ago
There is no .NET Core 4? There was a .NET Framework 4. 5 is how the streams are being crossed.
deleted 6y ago
[deleted]

_acco 6y ago

The future is very bright for .NET. It has the right raison d'etre - .NET is part of the growth story for Nadella-Microsoft. 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. 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. One of the core issues feels so... trite. But experiencing it, I realized how real it really was: The Names. Microsoft has created a Ninja Warrior obstacle course of proper nouns. It is comical. It is worthy of parody. .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. 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. 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. It was almost never immediately clear if a document I was looking at on Microsoft's own website applied to me or not. That is a cardinal sin of technical documentation. Ultimately, this meant that .NET Core Web API (or whatever I was using) felt poorly documented. 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. 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.

FridgeSeal 6y ago
> Azure will win you over from AWS every time. Going to have to disagree here. That might be the case if Azure was not literally a tire-fire. I have been using Azure for work and it's the most frustrating, inconsistent, often-broken, confusing and stress-inducing cloud service that my teammates and I have ever been subjected to. It left such a bad taste that I am quite certain I would flat-out refuse to use it again in the future, or work somewhere that uses it. Take my advice: just don't use it. It's not worth it. Use AWS, use GCP, use Digital Ocean. Use some random cloud provider. Just don't use Azure.
- 6y ago

thrower123 6y ago

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. This version will be nearly out of support by then...

oaiey 6y ago
When your code depend on stuff not migrated yet, it will no longer happen. From a .NET Framework position, .NET 5 is a huge breaking change by loosing capabilities and using different base libraries (which will not be recovered later). From a .NET Core 3.1 perspective, it is a minor update. .NET 5 reality is: They ported 90% of their app models (e.g. wpf, winforms, ...) and dropped some other (e.g. WCF, WWF, AppDomains, ...). That is not going to change. .NET ecoysystem reality is: What is not ported until now, will not be ported. .NET Core is now 6 years old (2014?) and everything new is currently .NET Core. Someone who wants to stay in business, has ported already 2-3 years ago.
- thrower123 6y ago
  Well, I've still got to support integrations with other Microsoft products that are in support for the next decade, and only have Fx SDKs. Tooling in Visual Studio has sucked out loud for most of the Core stuff thus far. There's not a lot of value chasing the churn versus letting it settle out.
  - oaiey 6y ago
    I am also there. Ugly.

ablekh 6y ago

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). [1] https://www.infoq.com/articles/advanced-architecture-aspnet-core https://www.infoq.com/articles/advanced-architecture-aspnet-... [2] https://www.claudiobernasconi.ch/2019/01/24/the-ultimate-list-of-net-dependency-injection-frameworks https://www.claudiobernasconi.ch/2019/01/24/the-ultimate-lis... [3] https://docs.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support https://docs.microsoft.com/en-us/dotnet/core/tutorials/creat... [4] https://github.com/natemcmaster/DotNetCorePlugins https://github.com/natemcmaster/DotNetCorePlugins [5] https://maartenmerken.medium.com/announcing-prise-a-plugin-framework-for-net-core-4af7cf5b4d2b https://maartenmerken.medium.com/announcing-prise-a-plugin-f... [6] http://ewer.com.br/plugin-architecture-with-di-containers http://ewer.com.br/plugin-architecture-with-di-containers

bob1029 6y ago
The DI in .NET is really powerful and feels intuitive once you play around with it in a few different projects. We have almost 100 services injected into .NET Core DI and it always feels very stable and manageable. For us, we cheated a little bit on many services and just take a dependency on IServiceProvider to get at other services at runtime. This allows for any service to talk to any other service without worrying about some monster CTOR hierarchy. We used to try to keep things "correct" in terms of dependency chain, but we have found that the real world is a lot easier to work with when you permit circular dependencies between services and maintain 1 big flat collection of them. This is basically microservices but without the RPC ceremony and associated nightmares.
- ablekh 6y ago

mrlonglong 6y ago

Even more important, what's been happening with .NET/VB?

bhandziuk 6y ago
Nothing is happening with VB.NET https://devblogs.microsoft.com/vbteam/visual-basic-support-planned-for-net-5-0/ https://devblogs.microsoft.com/vbteam/visual-basic-support-p...

sytelus 6y ago

Seems like .Net 6 will have cross-platform UX forms! That sounds very exciting.

xpressvideoz 6y ago

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. https://visualstudiomagazine.com/articles/2020/08/31/aot-survey.aspx https://visualstudiomagazine.com/articles/2020/08/31/aot-sur...

Luuseens 6y ago
I find CoreRT covers a lot of my current AOT needs. For me, one of the blockers was Winfows.Forms not working with AOT, which appears to have been resolved very recently: https://github.com/dotnet/winforms/pull/4177 https://github.com/dotnet/winforms/pull/4177

Siira 6y ago

There is also going to be a crossplatform (including mobile) UI library for .Net 6: https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/ https://devblogs.microsoft.com/dotnet/introducing-net-multi-...

txdv 6y ago

Where did Java interop go?

oaiey 6y ago
Educated guess: shifted with net6.0-android. That is the core driver. Same as swift integration with net6.0-ios.

szntb 6y ago

I really like where thing are heading with .NET. 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.