.NET Misconceptions
08/05/2022
6 minutes
.NET 7 is released in 2022 autumn. While .NET and C# have been steadily improving with new features year by year, as @markrendle wrote in 2017, .NET has a renaissance. However, non-.NET developers have been hardly keeping up with the framework and the language. Developers familiar only with the 'classic' .NET voice loads of misconceptions about modern .NET itself. This post aims to debunk these ideas.
History
A brief overview about the naming changes that cause confusion for the past years.
The 'classic' .NET 4.x is referred as .NET Framework these days. At the time of writing this post, the latest release is .NET 4.8. Depending on the minor versions, the Framework is not developed further, only patched with bug and security fixes.
.NET Core is an initiative of moving .NET Framework to open source. It has been released with version 1, 2 and 3 parallel to .NET Framework releases. The branding of .NET Core is discontinued.
.NET Standard defines a set of API-s. It is a contract that enables bridging from .NET Framework to .NET Core and .NET 5.
.NET (5, 6, 7, etc.) is the continuation of .NET Core, while it is also provides a strategy to migrate from .NET Framework. In the rest of the post, when I refer to .NET, I refer to the latest release of this work.
Misconceptions
Migrating a .NET Framework application to .NET Core is difficult, hence a lot of developers are 'left behind'
This has been true for .NET Core version 1 and 2, it is certainly not the case. Migrating a .NET Framework application to the current .NET version is easy. After migration several larger applications, I can certainly say it is. Migrating third party dependencies like Entity Framework and ASP.NET to its 'core' counterparts are more involved, but maintained dependencies provide a migration path. (Line of Business apps shall not depend on unmaintained libraries regardless.)
.NET is developed by Microsoft
.NET is managed by .NET Foundation. .NET is open-sourced on GitHub, anyone from the open-source community may issue a change through a pull-request or may fork the source. While Microsoft allocates developers to actively work on .NET a reasonable amount of changes are implemented by the community.
.NET is bad because it is relatable to Microsoft
There is a certain amount of bias in the argument above. To be fair, there is hardly any framework/language these days that is not backed or relatable to a larger corporation.
Java - Oracle
Swift - Apple
Angular - Google
React - Meta
Typescript - Microsoft
Go - Google
Rust - Mozilla
Is Microsoft better or worse than any other tech company? - It is difficult argue.
.NET is not open source
It is on GitHub.
.NET needs to install a runtime on the machine
As a developer, you may install the SDK. Depending on the way you package an application, .NET apps can be run as self-hosted apps, which does not require any installation on the target machine.
.NET is Windows only
.NET is cross platform is runs on Linux, Macs, Android, iOS, WASI and Windows as well.
.NET is managed code only
While at the time of writing .NET Native is lagging behind, there are several independent technologies to compile .NET AOT. Usually, the argument above goes along a dislike about JIT compilation. Certainly people arguing this forget that most modern CPU-s transform and optimize machine code internally to microcode and micro-ops. Which means that the output of other languages also gets 'interpreted' at runtime.
Another batch of developers, who bring this complain are usually JavaScript developers whose code run in browsers - as they claim - 'natively'. I assume there is a general lack of understanding on their side.
.NET is slow
.NET Team has been heavily focusing on performance for the past few years, which results as having for example ASP.NET Core in the top of techempower benchmarks.
.NET is only good for developing desktop applications
While .NET Framework used to have a reputation for being excellent for creating line of business desktop applications, this statement is just not correct anymore. There are several Application Modes from Microservices, IoT, Web, Machine Learning, Desktop, Cloud, etc. where a .NET application may strive. Code may run on a Raspberry Pi or on your browser with WebAssembly.
Only Visual Studio can be used to develop .NET
There are several IDEs: Visual Studio, Visual Studio Code, JetBrains Rider. One can use any text editor with the .NET CLI as well. Finally, one can even use GitHub Codespaces to write code in a browser. I think developer environments are usually superior to other languages and frameworks (not to say, there is always room for improvements).
.NET cannot be developed on Mac/Linux
Visual Studio has a Visual Studio for Mac, while it is not the same feature set of the Visual Studio, it enables writing code. Visual Studio Code on the other hand fully enables all features on Linux and Mac as well. I have developed projects fully with GitHub Codespaces on Linux containers.
.NET has limited community for creating libraries
While NuGet may seem to have fewer packages compared to npm, the size and functionality provided by NuGet packages tend to be larger to an npm package. For example, one would typically not create a NuGet package for concatenating strings.
.NET supports a single language only
.NET runtime runs MSIL. Any language may compile to IL code, which can be executed by the runtime. Today F#, Visual Basic and C# compiles to IL, while I see several other languages that can be compiled to IL code.
C# is dated
In the past years C# has major release aligned with to the release of .NET. The new releases introduce and overwhelming amount of new features. Many of the features also tend to improve and extend larger features that are being added over multiple years. For example, pattern matching is such a feature.
.NET (Native) Interop is difficult
.NET Framework 1.0 has been designed interop in mind. .NET allows excellent interop (usually with the help of DllImport attribute to JavaScript in WebAssembly/Blazor apps, C++, COM components, etc.
Interop tends to be difficult inherently.
.NET Framework developers cannot developer .NET Core
If that is the case, you are likely not dealing with a true .NET developer ;)