With the new versions of .NET releasing every year, just like when .NET 6.0 released this November. The top-level statements were done almost a year ago. It went well until the console top-level templates were done in the new .NET 6.0.
The Proposal
During the development of the new .NET 6.0 framework (not the closed-source “.NET Framework” 6.0), one of the developers in GitHub, tthiery, has proposed the idea of using the new feature of the top-level statements to change the console template so it can benefit from this feature. They have summarized that it simplified things for new developers or the developers who came from the Python, PHP, or Python backgrounds, just like what they said here:
Onboarding new developers from Python, PHP, JavaScript, or completely new background with a no-using, global-sdk-usings, no-namespace, no-main-method is a very valid goal.
For new .NET 6.0 projects, this results in the main console method code changing to the new format:
// See https://aka.ms/new-console-template for more information
Console.WriteLine("Hello, World!");
from the old, traditional gem:
using System; using System.Collections.Generic; using System.Linq;
namespace MyApp // Note: actual namespace depends on the project name.
{
public class Program
{
public static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}
However, that doesn’t mean that the old main-method console template will be gone forever; it just stays, albeit it will have a different template name that you can use when using the “dotnet new” command.
However, do not forget what safety a traditional main-method console template brings to programmers with C, C++ or Java background (aka. fresh converts). Or us 20 year veterans of .NET itself.
According to them, we can use the new template to create a new console application using the “dotnet new console” command, or the “dotnet new main” command. The new template is, again, to simplify the main code file to just statements.
We do not like too much SDK magic like global using System; or auto generated namespaces. Especially for the console app model which should be a vanilla app model (not be too flavored like a e.g. SwiftUI like DSL or a i-will-never-open-program.cs-in-wpf-app).
–
dotnet new console: with a modern single-line, no-using, global-sdk-usings, no-namespace, no-main-method variant–
dotnet new main: for our converts from C, C++, Java and .NET veterans. Just what we always had.
Source: https://github.com/dotnet/templates/issues/520
The Reception
Since the initial proposal, it had received mixed reception from different programmers across the entire C# community, but most of them were negative, of which we will discuss later in the article.
At first, the developers were happy about how it simplified their workflow, especially during the execution of the simplest code files that exist in the whole world, just like the famous “Hello World” example, and the education for the programming.
This seems like a good compromise; my first thought was that refactoring hints would be sufficient (e.g. a hint to refactor a template using Main to the top-level syntax)
mducharm
In my opinion, the move to remove clutter is a very good one. I was also quite shocked when I first saw it, but when I teach coding to newcomers, it makes things so much easier. No more “just ignore all that stuff and focus on the things between the {}”.
luetm
The concept of this being magic is more along the lines of this being more magical than having to write all of the boilerplate code. The compiler is magic.
chrislarabell
As the time went, more and more developers were talking about how this new template degraded their development experience in various ways, such as making the main entry point code more confusing. Let’s see how this affected their business in the below section.
Source 1: https://github.com/dotnet/templates/issues/520
Source 2: https://github.com/dotnet/docs/issues/27420
The Outcry
Fellow developers, who are experienced in C#; especially the long-time ones ranging to above 20 years of .NET coding experience, have had negative views about this change because of how it was implemented. It was implemented in a way that it made the entry point code more confusing to read than the classic implementation of the Console template. Going back to 2002, if that top-level template was implemented in .NET Framework 1.0 and was a default in the first versions of Visual Studio .NET, nobody would have used C# as an easy-to-learn managed language and a hate cesspool would have grown.
Not only that, but most of the protestors have disregarded the new template as ugly, just like what bynarie said:
In my opinion, this should be an optional global setting in visual studio. The new style template is ugly and I dont think anyone likes this. Thank you!
This new template was further criticized by how it was oversimplified to the point that you would think that you can write a C# program exactly like Python when it turns out that you can’t because it was an Object Oriented Language. One developer, rposener, tried this new template out, and said that they didn’t know how to use the “args” variable in the new format.
Where are args in the new format? How do you use Command
We can provide workarounds for some of the issues in the future. Let’s continue with the few criticism from the developers.
It doesn’t feel like the people who built this feature actually build a lot of software from scratch frequently. It feels like you’re just showing off what you can do instead of building a tool for professionals to use. This adds several minutes to my startup time every time and takes me out of my flow.
hbrumleve
I just dont understand why this template was changed. Its not logical.
bynarie
This template speed up project creating process, but it is completely useless.
– Application creation tooks less then 1% of all programming time
– Template does not have access to command line parameters
– Template hides function definition and return value logic
AlexieScherbakov
Not only that, but this makes learning C# more difficult for the new developers.
The current trend in technology seems to favaor PFM (pure freaking magic) and in my opinion makes it far harder for someone new to any given technology to understand what is really going on.
DiverBW
To make matters even worse, what if you, as an experienced developer, wanted to make the Main function an asynchronous function? What if you wanted to change the signature of the Main function, like adding an extra argument to it?
This is too much abstraction away from the core. What if I wanted to use the
syntechtixasyncversion?
This change also removed backwards compatibility and introduced few more difficulties as a consequence of using the new format.
cho7052002 said:
- implicitly defined
string[] args - implicitly defined using directives
- fixed Main method signature
- no backward compatibility of program enterance code
- confuses programmers
Let’s make some of the points a bit clearer. Implicitly defined string[] args means that you don’t know where in your main program code did the arguments variable become defined if you’re using the new template to make your console applications. Moreover, you might think that it doesn’t exist, but if you wrote “args” somewhere in your code, IntelliSense shows you that it indeed exists. This shows that it was a hidden declaration of the arguments variable.
The implicitly defined using directives means the same thing as above, but for the using statement. If you’ve seen a class or two from a namespace that you’ve imported from in the main code file but not in any others, then it’s because of the implicit using directives. This means that you’ll have to waste time having to make your investigations regarding the matter of “mysterious” classes.
The fixed Main method signature means that you can’t change the parameters of the method if your console application is using the new console top-level template. What if you wanted to add an extra parameter to the method?
The last two points are clear. The new template confuses programmers a lot.
Source 1: https://github.com/dotnet/docs/issues/26313
Source 2: https://github.com/dotnet/docs/issues/27420
The Workarounds
Don’t worry about it! We can always fix this problem and restore the old behavior, but you have to do it for each and every new project created using the .NET 6.0 framework target.
If you wanted to make a project using .NET 6.0 but using the old console template, you have to use the workaround provided by KathleenDollard, because apparently,
There is no direct way to do this in .NET 6. There are two approaches:
- Copy the code that appears in this docs article.
- Target .NET 5 in your template, and then change the framework to .NET 6 in your project file after the project is created
The command to simplify the process to do this workaround is simply this: dotnet new console --framework net5.0
Then, edit the project file and change the target framework to net6.0 so it looks like this:
<TargetFramework>net6.0</TargetFramework>
The Suggestions
People suggested different ideas to make the new template completely optional to eliminate the top-level template being the default.
bravecobra suggested this:
- An option in each template that toggles top-level statements
- An analyzer with a codefix…
Source: https://github.com/dotnet/docs/issues/26313
Our opinion
We have come to the conclusion that, by trying the feature out by ourselves, we have had negative responses regarding this new console template, because the change was unexpected. We couldn’t support this new template, because it hinders our style of coding, especially when we’re doing the projects that are meant to be released to the public.
When we first saw this, we initially thought that our Visual Studio was broken. However, as the code ran, we’ve discovered that it wasn’t Visual Studio who was broken. It was the new console template that we despise due to its oversimplication Python-esque.
Join our #RestoreOldConsoleCSharp movement on Twitter to make the old console template the default and serve justice for both experienced and new developers.
Follow this blog for more info.
Aptivi 
Thoughts?