Finally! Perfect for making a quick utility to use in a script. There have been third party solutions but having to install something to do this was always another obstacle / headache
Finally! Perfect for making a quick utility to use in a script. There have been third party solutions but having to install something to do this was always another obstacle / headache
I feel like top level statements were created specifically to open the door to C# scripts. The syntactic sugar of top level statements doesn't make sense in regular .NET production apps that you need to build and run, but for quick scripts they do represent important improvements in DX. Well done.
Their argumentation for both is accessibility for learning environments. Python and node were eating the cake there with ease of first use (python file.py). And what the academia is using today's is next year's company language
As someone mostly focused on JVM, .NET and nodejs ecosystems, this won't cut it.
The problem with UNIX culture shops not picking up .NET has everything to do with the Microsoft stigma, and everything the management keeps doing against .NET team efforts, like VSCode vs VS tooling features, C# DevKit license, what frameworks get to be on GNU/Linux, and the current ongoing issues with FOSS on .NET and the role of .NET Foundation.
Minimal APIs and now scripting, which already existed as third party solutions (search for csx), won't sort out those issues.
They can even start by going into Azure and check why there are so many projects now chosing other languages instead of .NET, when working on the open.
This would already be the first place to promote .NET adoption.
>UNIX culture shops
Jesus christ, it sounds like a religion
Welcome to technology flamewars.
The only change through the times is where they take place and how hard, or low, they might get.
I mean I don't want the viability of my business to be dependent on the whims of Microsoft either. Unfortunately your business is going to have counterparty risk no matter what your tech stack is but Microsoft's record is pretty mixed.
AFAIK, you could always dotnet run app/app.csproj since 2016. Obviously you needed dotnet sdk installed.
Installing the full dotnet sdk was very high friction, in addition to the full csproj scaffolding. Running a single cs file is a HUGE ux improvement.
If python hadn't (nearly) caught up to c# in typing support, I'd seriously consider moving or at least running it...but as it stands, python has established itself too well for me.
> Installing the full dotnet sdk was very high friction, in addition to the full csproj scaffolding.
What's the difference between installing .NET or, say, python of node?
Python typing hasn’t nearly caught up with C#. I regularly use both and c#’s type system is pragmatic and very helpful in avoiding bugs, whereas Python has no types by default and doesn’t check them by default when it does have them. It’s worse than typescript because at least typescript fails to compile if you have a type error.
You still need full dotnet sdk, the tool merely automates full csproj scaffolding, which is then compiled with full dotnet sdk, roslyn, nuget, compiler server and everything, and allows to customize msbuild project properties with pragmas in code. The only difference is that before you had sdk+folder+my.cs+my.csproj, now you have sdk+folder+my.cs
Yes, but this change now also allows you to do the same with, say, script.cs file.