When everything has switched to .net core, what about the fate of .net non core? Is the .net framework still alive? Yep, he is still alive, until now Microsoft is still continuing to update the development of the latest .net framework, namely .net framework 4.8. And it looks like this is the last .net framework (hopefully).
Why do I really hope that the .net framework moves entirely to the core? The age of the .net framework is now quite old, this year they are 19 years old. There are millions of applications built on top of it, making use of every single piece of functionality Microsoft have ever built in.
The weight of all of these applications makes Framework incredibly ‘heavy’. Every change needs to be weighed and measured with a primary focus on not breaking anything. The opportunity to really innovate at the core (no pun intended) of .NET Framework is fading fast.
What’s the answer to this conundrum? Everyone who’s supporting an 18 year old code base knows the answer! It’s time for a ground up re-write! And that is really what we have with .NET Core. A fresh start for .NET with none of the legacy issues.
And just look at some of the benefits! With barely any legacy applications to support, all of the newest innovations are in Core. This means better performance, practically across the board. Not to mention much better support for containers, cross platform (obviously!), and a really ‘baked in’ focus on microservices.
The planned features in .Net Framework 4.8
The initial beta version of .Net Framework 4.8 was released in mid-June 2018. The new beta build, released in December 2018, centers on fixes for performance, reliability, accessibility, and stability across framework libraries. Build 3707 also includes the updated .Net 4.8 runtime and the .Net 4.8 Developer Pack, which bundles the runtime as well as the .Net Framework 4.8 targeting pack and SDK.
New features planned for Net Framework 4.8 include:
- For ASP.Net, an issue has been fixed involving the handling of multivalue HTTP headers that may affect multipart data processing.
- For the BCL (Base Class Library), the number of object finalizations occurring as a result of using X509Certificate2 and related types has been reduced.
- Also for the BCL, an API has been added to obtain thumbprints with a caller-specified digest algorithm.
- For the CLR (common language runtime), issues were fixed in which incorrect values were sent as EventListeners.
- Enabled labels in Windows Forms are now always rendered via a high-contrast text color when a high contrast mode is enabled. This affects applications recompiled to target .Net Framework 4.8.
- The hashing algorithm used to generate XOML file checksums when building projects with XOML files has been changed. Developers can still use the previous algorithm if the new one causes problems.
- The hashing algorithm for calculating keys to internal memory caches has been modified. Developers can still use the previous algorithm.
- A memory leak issue has been fixed that affected HttpWebRequest when communicating with an HTTPS server through a proxy.
- For Windows Forms, enabled labels are now rendered using a high-contrast text color whenever a high-contrast mode is enabled.
- With Windows Presentation Foundation, a memory leak has been fixed that had arisen when removing data items from parent collections when UIAutomation was present.
- In Windows Communication Foundation, an accessibility problem has been fixed that had caused ComboBox controls to be incorrectly themed in high-contrast themes.
