Introducing .NET 5
Today, we’re announcing that the next release after .NET Core 3.0 will be .NET 5. This will be the next big release in the .NET family.
There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.
We will introduce new .NET APIs, runtime capabilities and language features as part of .NET 5.
From the inception of the .NET Core project, we’ve added around fifty thousand .NET Framework APIs to the platform. .NET Core 3.0 closes much of the remaining capability gap with .NET Framework 4.8, enabling Windows Forms, WPF and Entity Framework 6. .NET 5 builds on this work, taking .NET Core and the best of Mono to create a single platform that you can use for all your modern .NET code.
We intend to release .NET 5 in November 2020, with the first preview available in the first half of 2020. It will be supported with future updates to Visual Studio 2019, Visual Studio for Mac and Visual Studio Code.
Check out .NET Core is the Future of .NET to understand how .NET 5 relates to .NET Framework.
.NET 5 = .NET Core vNext
.NET 5 is the next step forward with .NET Core. The project aims to improve .NET in a few key ways:
- Produce a single .NET runtime and framework that can be used everywhere and that has uniform runtime behaviors and developer experiences.
- Expand the capabilities of .NET by taking the best of .NET Core, .NET Framework, Xamarin and Mono.
- Build that product out of a single code-base that developers (Microsoft and the community) can work on and expand together and that improves all scenarios.
This new project and direction are a game-changer for .NET. With .NET 5, your code and project files will look and feel the same no matter which type of app you’re building. You’ll have access to the same runtime, API and language capabilities with each app. This includes new performance improvements that get committed to corefx, practically daily.
Everything you love about .NET Core will continue to exist:
- Open source and community-oriented on GitHub.
- Cross-platform implementation.
- Support for leveraging platform-specific capabilities, such as Windows Forms and WPF on Windows and the native bindings to each native platform from Xamarin.
- High performance.
- Side-by-side installation.
- Small project files (SDK-style).
- Capable command-line interface (CLI).
- Visual Studio, Visual Studio for Mac, and Visual Studio Code integration.
Here’s what will be new:
- You will have more choice on runtime experiences (more on that below).
- Java interoperability will be available on all platforms.
- Objective-C and Swift interoperability will be supported on multiple operating systems.
- CoreFX will be extended to support static compilation of .NET (ahead-of-time – AOT), smaller footprints and support for more operating systems.
We will ship .NET Core 3.0 this September, .NET 5 in November 2020, and then we intend to ship a major version of .NET once a year, every November:
We’re skipping the version 4 because it would confuse users that are familiar with the .NET Framework, which has been using the 4.x series for a long time. Additionally, we wanted to clearly communicate that .NET 5 is the future for the .NET platform.
We are also taking the opportunity to simplify naming. We thought that if there is only one .NET going forward, we don’t need a clarifying term like “Core”. The shorter name is a simplification and also communicates that .NET 5 has uniform capabilities and behaviors. Feel free to continue to use the “.NET Core” name if you prefer it.
Mono is the original cross-platform implementation of .NET. It started out as an open-source alternative to .NET Framework and transitioned to targeting mobile devices as iOS and Android devices became popular. Mono is the runtime used as part of Xamarin.
CoreCLR is the runtime used as part of .NET Core. It has been primarily targeted at supporting cloud applications, including the largest services at Microsoft, and now is also being used for Windows desktop, IoT and machine learning applications.
Taken together, the .NET Core and Mono runtimes have a lot of similarities (they are both .NET runtimes after all) but also valuable unique capabilities. It makes sense to make it possible to pick the runtime experience you want. We’re in the process of making CoreCLR and Mono drop-in replacements for one another. We will make it as simple as a build switch to choose between the different runtime options.
The following sections describe the primary pivots we are planning for .NET 5. They provide a clear view on how we plan to evolve the two runtimes individually, and also together.
High throughput and high productivity
From the very beginning, .NET has relied on a just-in-time compiler (JIT) to translate Intermediate Language (IL) code to optimized machine code. Since that time, we’ve built an industry-leading JIT-based managed runtime that is capable of very high throughput and also enabled developer experiences that make programming fast and easy.
JITs are well suited for long-running cloud and client scenarios. They are able to generate code that targets a specific machine configuration, including specific CPU instructions. A JIT can also re-generate methods at runtime, a technique used to JIT quickly while still having the option to produce a highly-tuned version of the code if this becomes a frequently used method.
Our efforts to make ASP.NET Core run faster on the TechEmpower benchmarks is a good example of the power of JIT and our investments in CoreCLR. Our efforts to harden .NET Core for containers also demonstrates the runtime’s ability to dynamically adapt to constrained environments.
Developer tools are another good example where JIT shines, such as with the
dotnet watch tool or edit and continue. Tools often require compiling and loading code multiple times in a single process without restarting and need to do it very quickly.
Developers using .NET Core or .NET Framework have primarily relied on JIT. As a result, this experience should seem familiar.
The default experience for most .NET 5 workloads will be using the JIT-based CoreCLR runtime. The two notable exceptions are iOS and client-side Blazor (web assembly) since both require ahead-of-time (AOT) native compilation.
Fast startup, low footprint, and lower memory usage
The Mono Project has spent much of its effort focused on mobile and gaming consoles. A key capability and outcome of that project is an AOT compiler for .NET, based on the industry-leading LLVM compiler project. The Mono AOT compiler enables .NET code to be built into a single native code executable that can run on a machine, much like C++ code. AOT-compiled apps can run efficiently in small places, and trades throughput for startup if needed.
The Blazor project is already using the Mono AOT. It will be one of the first projects to transition to .NET 5. We are using it as one of the scenarios to prove out this plan.
There are two types of AOT solutions:
- solutions that require 100% AOT compilation.
- solutions where most code is AOT-compiled but where a JIT or interpreter is available and used for code patterns that are not friendly to AOT (like generics).
The Mono AOT supports both cases. The first type of AOT is required by Apple for iOS and some game consoles, typically for security reasons. The second is the preferred choice since it offers the benefits of AOT without any of its drawbacks.
.NET Native is the AOT compiler we use for Windows UWP applications and is an example of the first type of AOT listed above. With that particular implementation, we limited the .NET APIs and capabilities that you can use. We learned from that experience that AOT solutions need to cover the full spectrum of .NET APIs and patterns.
AOT compilation will remain required for iOS, web assembly and some game consoles. We will make AOT compilation an option for applications that are more appliance-like, that require fast startup and/or low footprint.
Fundamentals and overlapping experiences
It is critical that we continue to move forward as an overall platform with startup, throughput, memory use, reliability, and diagnostics. At the same time, it also makes sense to focus our efforts. We’ll invest more in throughput and reliability in CoreCLR while we invest more in startup and size reduction with the Mono AOT compiler. We think that these are good pairings. Throughput and reliability go together as do startup and size reduction.
While there are some characteristics where it makes sense to make different investments, there are others that do not.
Diagnostics capabilities need to be the same across .NET 5, for both functional and performance diagnostics. It is also important to support the same chips and operating systems (with the exception of iOS and web assembly).
We will continue to optimize .NET 5 for each workload and scenario, for whatever makes sense. There will be even greater emphasis on optimizations, particular where multiple workloads have overlapping needs.
All .NET 5 applications will use the CoreFX framework. We will ensure that CoreFX works well in the places it is not used today, which is primarily the Xamarin and client-side Blazor workloads. All .NET 5 applications will be buildable with the .NET CLI, ensuring that you have common command-line tooling across projects.
C# will move forward in lock-step with .NET 5. Developers writing .NET 5 apps will have access to the latest C# version and features.
The birth of the project
We met as a technical team in December 2018 in Boston to kick off this project. Design leaders from .NET teams (Mono/Xamarin and .NET Core) and also from Unity presented on various technical capabilities and architectural direction.
We are now moving forward on this project as a single team with one set of deliverables. Since December, we have made a lot of progress on a few projects:
- Defined a minimal layer that defines the runtime <-> managed code layer, with the goal making >99% of CoreFX common code.
- MonoVM can now use CoreFX and its class libraries.
- Run all CoreFX tests on MonoVM using the CoreFX implementation.
- Run ASP.NET Core 3.0 apps with MonoVM.
- Run MonoDevelop and then Visual Studio for Mac on CoreCLR.
Moving to a single .NET implementation raises important questions. What will the target framework be? Will NuGet package compatibility rules be the same? Which workloads should be supported out-of-the-box by the .NET 5 SDK? How does writing code for a specific architecture work? Do we still need .NET Standard? We are working through these issues now and will soon be sharing design docs for you to read and give feedback on.
The .NET 5 project is an important and exciting new direction for .NET. You will see .NET become simpler but also have broader and more expansive capability and utility. All new development and feature capabilities will be part of .NET 5, including new C# versions.
We see a bright future ahead in which you can use the same .NET APIs and languages to target a broad range of application types, operating systems, and chip architectures. It will be easy to make changes to your build configuration to build your applications differently, in Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps or at the command line.
Any details of what Java interop will look like? Is it two-way?
Yes. We intend to build two-way interop. One-way is only half the fun, right?
I’d be interested in implementation details, e.g. will .jar files be transpiled to .NET IL (my preference)? or will IL be transpiled to run on the JVM? or will stubs be generated to marshall data between the JVM and the CLR?
Can you clarify if this feature is still part of the .NET 5.0 plan?
It doesn’t seem so from the announcements for the preview 1 and 2.
This is a very important feature for our team.
I would highly appreciate a clarification.
Thanks in advance.
Java interop should be based on what Xamarin.Android uses. Broadly speaking, this will require two pieces:
2. “Porting” of Mono’s GC bridge to CoreCLR.
Java.Interop already works today, in various forms, on desktop macOS and Windows; the Xamarin.Android Designer relies on it.
Xamarin.Android? We have many of us out here using windows phones. Sorry but I believe we need to continue the windows phone support. Java might work but I don’t believe that moving the direction where we have to have more developers than room available in a building and have found that going that direction, as in SAP, you spend, spend and spend. Moving the direction where a framework is comepleted and adding small app’s internally is a much simpler and less resource dependent operation. We need to become less dependent on India to develop our applications and thinning our resources isn’t getting the job done. If we open our eyes and see the loss of control in business here in our country maybe we can begin to build our resource base away from gaming and into the business where it belongs.
I am Indian.
I have Windowa Phone.
Even i have 2 Windows Phone.
I LOVE windows Mobile.
I Support all The Things You Said.
Microsoft Should Support Back To Windows 10 Mobiles.
With More Capabilities than Android.
Some Features i Suggest.
Mobile Should Be Like Real Windows that support 3rd Party Softwares..
Also Support Emulator like Bluestacks.
Mobiles Support Real 4G or 5G Sim With VoLTE .
My Vision said Microsoft Mobiles are More Popular than IOS or Android.
Thanks And Regards
So we get Java interop but no WCF. I would like to try what the folks planning this are smoking.
I don’t understand the purposeful killing of WCF. It seems sadistic. They got us to buy in and make our apps rely on it, and now they’re telling us we can’t use it in the future, when our apps are already deeply tied to it.
This is useful for some use cases: https://github.com/dotnet/wcf However for new stuff, where you want the performance of a binary protocol and you don’t need a REST API, I would definitely go down the gRPC route. Support from .Net Core 3 is going to be very good, by the look of it.
I last saw WCF production deployment in 2013, and it was already considered legacy (moving to new system). I guess it’s time to move to HTTP APIs, no matter how painful it is
Agree, WCF requires too much time to support/setup and develop rather than HTTP REST API (I am comparing to Simplify.Web).
If you have a good architecture of your services (like, WCF-lelated layer is not tightly coupled with you business logic), then it is not hard to migrate to any HTTP REST APIs.
Well but you are referring to WCF only as a Rest API… and WCF is able to handle TCP, FULL Duplex, HTTP Rest and others… HTTP REST is pretty much only used for web applications, not for fast network communication.
And we simply don’t have other alternative to WCF regarding to network communications (real-time systems). So basically not having WCF in .NET Core (.NET 5) means all backbone systems (which processes and communicates real time data) are unable to use .NET 5.
Really? What about distributed transactions, service discovery,routing, service announcements?
How about ability to switch your underlying communication channel (TCP, Net Pipes, UDP) without rewriting code? What about ordered message delivery, control over service instantiation, service sessions?
This comment has been deleted.
The W in WCF is Windows which is the very antithesis of .NET Core on the server.
Please proper AOT support for F# this time.
Already exists. AOT (Mono, CoreRT, .Net Native) supports F#, with the latter two having trouble only for minor features that are overcomplicated in F# (sprintf mainly). Mono has fewer issues but it’s less ambitious as AOT goes (https://medium.com/@MStrehovsky/fight-the-global-warming-compile-your-c-apps-ahead-of-time-9997e953645b). The main remaining issue for full UWP support (https://github.com/dotnet/corert/issues/6055#issuecomment-472634385) is a packaging issue not an AOT issue.
This comment has been deleted.
And still not a real xaml standard cross platform (xamarin and uwp at least)
Well written and greatly explained. Keep up the good work & continue!
Great news! I got curious about the AOT, F#, and Generics and WebAssembly possibilities. Also would be great to hear news about Universal / Cross-platform XAML that runs on Web, Mobile, Desktop and IoT.
Xaml is just an optional markup language for some ui platforms. Making it universal didn’t make sense which is why that effort stalled: the underlying UI platforms had different features and classes, so why would a markup language describing them be the same?Xaml really became too much of an obsession in .Net for a while, and extended too far. But not it’s being humiliated by being used as a PR term (“XAML islands”, “Microsoft.UI.Xaml”) for things that have nothing to do with markup.
If you had running water to your home that was shut off for obscure reasons, you’d get a little obsessive with making sure it gets turned back on, too. 😁 Saying it’s being humiliated now is a good way of putting it. There was another announcement @ //build last year for a “performant” Xaml that had nothing to do with markup. It was pure code which basically circumvented all the elegant visual designer aspects that Xaml was intended to leverage. I forget its name and it’s not worth the effort to look it up.
XAML and associated design tooling is decent and makes sense for design. But the binding approach is massively hacky and can’t be fixed without starting from scratch. Xamarin would have 1/2 the size and 1/2 the bugs if it didn’t include bindings.
Visual Studio 2019 is made with WPF and XAML. It’s not just for Xamarin. 🙂 The editor now supports hot reload for Xamarin forms, but also for making editor extensions.
Tony and others interested in this subject, feel free to reach out to me directly at firstname.lastname@example.org and we can set up a deeper discussion on this topic. I’d love to understand your scenarios and why this is important to you.
Great news! How will com interop look like in this brave new world?
Same as it is in .NET Core 3.0. See that we just added support for expose .NET core libraries as COM components? https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0-preview-5/
Excellent, i missed that. What about the other way around – calling native com from .net
Hi Richard, Do you have any details on .net Framework 4.x EOL? We are heavily invested in WF which I know isn’t in .net core. We have been looking for a migration plan and would rather not be rushed.
There is another post going out this afternoon on that. Check back in a few hours (posting between 2 and 3pm pacific).
Echoing the above, but my environment is HEAVILY using WCF. Right now we’re doing all kinds of RPC research to figure out what else can work best for us. The biggest issue is the support for various binding types and the extensibility model.
It will continue to work great! There are so many Microsoft services running on .NET Framework, including HEAVILY using WCF. Microsoft itself is the exact same as your environment in this respect. Many services will stay on .NET Framework for many years. Other teams are adopting .NET Core, as you would guess. Some are adopting ASP.NET Core and others are looking at gRPC. .NET Framework will be there for you and .NET Core will continue to move forward when you decide to get on that train. You’ve got lots of good choices available.
Frankly speaking I am annoyed with all that ‘It will continue to work great!’ mantra. No one will rewrite millions dolar worth system to gRPC. Instead of providing easier way to move to .net core by enabling WCF Service Host in .net core we, loyal MS customers who invested heavily in WCF because years ago on another Build conference we heard it is a way to go, we are offered with a dead end.No newer C# version goodies on 4.8. No newer netstardards on .NET 4.8. So next time please rethink ‘it will contnue to work gereat’ statement.Thanks.
Look its the Microsoft way to lead developers down painful, expensive dead ends. Why would they want to change this when they can piss off even more customers? WCF is still huge in corporate environments and even within Microsoft’s own products and services. But then again these are the guys that thought Windows 8 was a good idea and that a visual studio menu shouting at all caps as default was a win. They have lost their way. Declining build attendance being a good indicator.
And announcements for that matter. Seems like .NET 5 was the only blip on the radar. That said, I wouldn’t mark .NET as a dead end with all its cross-platform support now. Also, investments in performance are very tell-tale. They want users to adopt this and they are — or at the very least, .NET is getting respect outside of MSFT circles.
Agreed! However, .Net is being pushed out. I love it .Net and use it daily. I’m a SharePoint developer and that is my livelyhood. I would love to see us using it to it’s potential rather than thrown away because everyone wants to reinvent the wheel on every project.
It would enough to open source basic parts of WCF and make it working on asp.net core (let’s say WS-I Basic Profile 1.1). Communuty would do the rest.I know it wouldn’t be 100% drop in replacement due to nature how asp.net core http stack is oriented but that would be acceptable.But apparently we are not going to be given even that.
Why are you leaving so many comments about WCF? WCF is dying dude. It’s not 2008 anymore. Communications frameworks are evolving, and if “corporate environments” don’t evolve with it, they will die, just like every other enterprise platform that has coupled itself with dead end technologies.
Well, WCF and SOAP may be dead to Microsoft, it is not dead in the enterprises. The standard bodies are still publishing XML standards, which are used to define the communicate contracts for enterprises and governemnt entities.
What is the rational for Microsoft deciding to kill it and force us all to look different strategies to filling the void?
WCF is not dying and probably will not for a foreseeable future. There is simply no alternative for it in .Net Core. Can you enlist your services in a single transaction ? Not in .Net Core. Is there service discovery, service announcements, routing available out of the box with . Net Core ? How about managing your service instancing : per- call, per-session, single? – not there.
We are using these features extensively and will continue until there is anything comparable in Net Core.
> Expand the capabilities of .NET by taking the best of .NET Core, .NET Framework, Xamarin and Mono.
Wow this is great news! Mono has the breadth of support (iOS, Android, webassembly) but .Net Core has the robustness and performance. So having the best of both worlds is excellent. Of course this is a natural step, but one that takes a lot of effort, so I’m grateful that Microsoft is making it.
> We’ll invest more in throughput and reliability in CoreCLR while we invest more in startup and size reduction with the Mono AOT compiler.
My experience of the various AOTs is that .Net Native/CoreRT is a higher quality AOT framework, so I would think it would be easier to add an interpreter to .Net Native/CoreRT (which is ongoing work) than make Mono AOT robust and efficient.For example https://medium.com/@MStrehovsky/fight-the-global-warming-compile-your-c-apps-ahead-of-time-9997e953645b says Mono AOT has 300ms startup time compared with 50ms for CoreRT: a noticeable chunk of slowness for Xamarin apps.
> The second is the preferred choice since it offers the benefits of AOT without any of its drawbacks.
Makes sense to have this as default. But disallowing slow things like reflection is good hygiene in consumer-facing apps, so it’s good to have a compiler option which enforces that.
Great point. We’ll be taking the next year to make an AOT story that you will love. As you suggest, we are not short on tech.
What will happen to Web Forms, given that it’s a part of .NET Framework but not .NET Core? I’ll personally be very happy if you kill it off.
Nevermind, I saw Rich’s tweet that Web Forms will remain .NET Framework 4.8 only.
Not porting WebForms is huge mistake that Microsoft and the larger web will regret. It is ensuring that a huge swath of the internet remains stuck on an outdated platform with absolutely no viable upgrade path. One that will eventually become insecure when MS stops issuing patches for .NET Framework.
I’m using WebForms since 2007. Every 2-3 years I try to look for something better (inside .NET), but I must say that all new alternatives, from perspective of maturity level do not reach 30% of WebForms. I agree that today its model is outdated, a website markup should not be rendered on server side anymore, but somehow still this is the most efficient and productive way to start to build something, and then to include new features, like including fancy js libs and adding the supporting services/APIs using some new .NET features. I’m also preferring WCF over REST, because from perspective of abstraction is better. Even if its configuration is hard. For me, REST is bound too much to http. Today web and http are trendy, but I’m writing software more than 25 years and I already learned nothing stays forever. From ORM side I also like the best the old good XSD Dataset, these give the most freedom to make an ORM layer. EF is for me a limitation, it degrades the performance a lot, too automatic, no room for tricks and hacks. Today there are 100 ways to do things, but every way is only on a low maturity level, poor tool/designer support, forcing developers into many limitations. In the last 5-8 years this industry is somehow stuck, tries to find its way out of the jungle of millions of possibilities, but can’t show up a real progress, only newer and newer experiments. Until this is not stable, I thinks it’s a bad idea to drop old good working methods, like the WebForms are.
Try Blazor webassembly if you can – it has all the good bits of webforms but brought up to a much more scaleable modern paradigm. If we are talking RAD then you can get all the benefits of a react / redux js stack with c# all the way down. Serioisly I have found it to be incredibly rapid to knock out POC stuff whilst its been in development and now its just gone prod support.
I will just say that I agree with Sam and leave it at that. Big mistake leaving Web Forms behind. Microsoft deleted my last message rather than addressing why they are screwing Web Forms developers.
Every few years, MS tell us “this is the new way forward”, as they did with WCF. Now they drop WCF. In my view no great loss – they took all the complexity that was in code (where is could be debugged) and moved it into config files (I’ve spent many hours fiddling with config).
I regularly browse .Net core fora, and find that some basic yet essential feature is coming in the next release.
There is so much across the Microsoft spectrum that is half-finished or coming soon – Look at Edge – from day 1 it hasnt supported NTLM properly, now its being getting chromium stuffed in, and lo and behold, Edge-dev supports NTLM like IE11, except the HTML5 input types work.
On desktop, UWP was very clever, supporting every windows platform from Phone to Server. MS Dropped Windows phone, so now its Raspberry Pi to server, both of which often run headless, dont need clever UI. UWP on the PC? Yes, but its slow to write and debug, slow to start – so slow they had to build in a “loading page” to give the appearance of quick run, and of course if you want cross-platfrom, you have xamarin – almost UWP but not.
If we use Web forms / Win forms, its not because we’re Luddites / sticks-in-the-mud / afraid of new tech. Its because we’re paid to be productive, creating stable, quick, familiar applications which may well get dropped on to 4-10 year old Operating Systems, with restricted amounts of RAM.
I’ve yet to hear a client say her business users are demanding the “dirty glass” Aero caption bars on the new LOB application.
I completely agree, the productivity and stability that I can have with WeForms is not comparable with other technologies today.
I think that considering what happened in these years it would make sense to rethink that decision.
What they are doing with server-side Blazor is fantastic, but it leaves me – if possible – even more frustrated.
@Mason McGlothlin What’s it to you whether Microsoft “kills” off Web Forms? If you don’t like it, then, don’t use it. Maybe one day whatever garbage it is that you’re using will get killed off too.
I agree with you. Many people comment about old techs as if we will always write new applications and have choices to use the latest technologies without having to maintain decade-old code bases. I get fed up with “advices” such as “abandon WCF and use X instead” or “so do not upgrade”.
Porting Web Forms would be very difficult for Microsoft – there is a lot of legacy code and it is too tightly bound to IIS, and honestly, I cannot imagine it without significant breaking changes.
However, if you have Web Forms applications, you might want to look at DotVVM. It is an open source framework (a member of the .NET Foundation) that is inspired by Web Forms but it is MVVM. It is easy to learn for any Web Forms developer, and it supports both old ASP.NET and new ASP.NET Core. Thanks to that, it can be used to migrate Web Forms applications to .NET Core. It is not a magic wizard which will do the migration automatically – you still need to rewrite all the pages to DotVVM syntax (it is quite similar, see the comparison page) and extracting the business logic into the viewmodels, but it is still much less work than rewriting the entire application from scratch. The best thing is that you can do the migration page by page and you can add new features in the app at any time. After you get rid of all the Web Forms stuff, you can just switch the project to .NET Core. If you like Web Forms, I am quite sure you will like the MVVM way of doing things in DotVVM.Here is the sample repo showing the process of migration.
Not entirely accurate, since around .Net 2 a webform (aspx page) could be hosted in a .Net application. Admittedly it would need work to build a full web server, but webforms don’t intrinsically require IIS.
As for “significant breaking changes” yeah, look at openid connect – our next big task is to rebuild our authentication scheme.
And Microsoft.Azure.CosmosDB.Table vs Microsoft.Azure.Cosmos.Table
System.ComponentModel.DataAnnotations vs System.ComponentModel.Annotations
Well… we are talking about the Microsoft, not the pizza & fichi & co… I think they can manage to do the porting… And also some significant breaking changes are completely acceptable or even desirable.
The point here is that the programming style used by WebForms is great once understood. And it sounds really a waste for people that is productive and happy with .aspx to abandon it.
MVC and razor was somehow a step behind. I remember the guys telling me… “look, it’s easy it is almost like it was in asp.classic”. Yes and then your code is a mess (as it was in asp.classic).
This is also proven by the fact that everyone (included me) is now exited by Blazor. But the question comes straight to me: “Why Blazor server side yes and WebForms server side no?”
Does this mean we’ll finally get .NET Core for x86 on Linux? I’m still stuck on Mono because x64 .NET Core builds have unacceptable high memory requirements compared to x86 Mono, it uses around twice as much memory. Jumping from 1GB to 2GB is just not acceptable.
Maybe. We’ve had very few people ask for it. Is this for a web server or something else. Mail me @ rlander@ms and tell me more about your scenario.
I think this is important with disregard to Tobias’s usecase. GNU/Linux is IOT and mobile — sure you want to target these? Besides, with WSL getting improved nowadays one would expect more and more people finding out about GNU/Linux and trying it out, and hence trying out targeting .net on these platforms as well. Furthermore: there already are 2 big existing ecosystems: GNU/Linux and .NET applications. Sure users of the first may want nice things from the second ecosystem.
TL;DR: cross-platform should be cross-platform.
Are you saying that your app uses twice the memory with 64-bit builds? That’s not normal and the solution really should be to fix 64-bit rather than to improve 32-bit support, as 32-bit is outdated and has been for a decade and it’s on the way out.
64-bit pointers are twice longer than 32-bit, so the applications can grow a bit less than twice in memory usage if the application has lots of in-memory data.
Btw, regarding “it’s on the way out”, not agree with that.
For most e-commerce applications, the memory usage is not that much – tops 64MB per session should be enough.
Note that even Visual Studio up to 2017 itself did not offer 64-bit version because of the expected memory usage increment.
And then if your web application needs 32-bit library to do certain things (say, some pretty well known 2-factor authentication libraries that only exists as 32-bit ISAPI module), if your company is not going to pay for upgrade and replace all the tokens (that costs ALOT), you’re stuck in 32-bit builds.