.NET for Beginners (2020)
dusted.codes
dusted.codes
The expansive standard library, web/desktop/mobile/gaming output, Visual Studio (Code) IDEs, fantastic in-depth guides and documentation [1], dev evangelists like Scott Hanselman [2], and constant stream of content from MS team and community [3] makes it not only easy to get started but also continue until you're an expert.
I find it strange to complain about a 12 year old stackoverflow answer when other environments like nodejs are a nightmare once you get past the toy project stage. Anyone can write a simple tutorial for a to-do app, but it's how well you can grow that to a real complex system that determines how well-designed and productive an environment really is. And I've yet to find anything better.
1. https://dotnet.microsoft.com/ 2. https://www.hanselman.com/ 3. https://dotnet.microsoft.com/platform/community
Part of the problem is with web development, complicated as it is, the tutorials at least get you to a complete, working example. The windows tutorials seem to be very piecemeal where you start with a mostly complete app and fill in a couple things, but never get the whole picture.
And like in your first link, click on "Desktop". Ok, I want to make a desktop app. Now there are four options WPF, WinForms, UWP and Xamarin. Ok...Why are there four options? What are the differences? Are one or more of them about to be deprecated? What do I need to consider in order to choose one over the others?
I could go on. The windows developer website did point to some helpful C# tutorials and the language is actually pretty nice to work with, but figuring out how to do basic things like -- how do I store state in the application, has been very confusing.
My favorite platform is Lazarus/Free Pascal. The documentation is a bit sketchy, but the IDE and the applications it outputs seem solid. I'd prefer Delphi, but they priced themselves out of my world 20 years ago.
And they have a community edition...but if you make $5k or more as a consultant, -even if it's not using Delphi-, you can't use it.
I can’t speak for all of the challenges you might be dealing with, but this one in particular seems like something specific to native development. You have a wealth of options, and at the same time because of that fact there is are fewer defaults compared to web dev and you have to do more work to make the decision. Personally I default to two options unless performance requires otherwise: SQLite or JSON stored in files.
All of them are.
Not officially, of course, but practically speaking all of them are dead-ends.
MAUI is the "new hotness", which means that it'll only become obvious that it is also a dead end in about a year and a half.
I wish I was joking.
Now only WPF applications that try to show more than a dozen controls at a time make the GPU fan spin up, a huge improvement. I suppose this explains the new "flat" style with huge amounts of white space. It's not about elegance, or style -- it's the only way to keep fan speeds tolerable.
CPUs are fast, and rendering could be multithreaded, but 4-16 very fast cores will still be slower than the very very wide SIMD of GPUs that can simultaneously operate on many many pixels. GPUs can also change to a different “lane” to compute while it waits on IO like some graphics. You also got gradients, transparency and the like, so you basically always have to do a full pass over every pixel, so on the order of 1000*1000 pixels. So GUI rendering definitely doesn’t use negligible CPU resources. It is the canonical example for a task that can be parallelized, so it only makes sense to do so.
In early 2000s I've used a PC with 800x600px CRT monitor and one of early Intel Celerons. My memory is fuzzy, but at best it was cheapest Coppermine Celeron (more likely Mendocino). Nowadays I use notebook with Intel Core i5 2540M (quite old) and the biggest display I use has 2560x1440 pixels (much newer than notebook).
Now I have at most (2560x1440)/(800x600) ~ 8 times more pixels. I didn't find numbers from the same benchmark for Coppermine and i5 2540M, but I expect 2540M to be at least 10 times faster than slowest Coppermine.
So I think modern CPU are fast enough to render GUI at least as fast as 15-20 years ago. GPU of course can do this much faster, cannot argue with this.
> You also got gradients, transparency and the like
I wonder if users really want this or we have it for other reasons (like developers want to show-off and companies want to sell new OS/App). For me the peak GUI was around Windows 2000 - most of what come next was not really an improvement for me. I'm not representative (and mostly use i3 WM, not Windows), but the fact that Widnows XP was used well beyond official support ended and many users around the world still use Windows 7 tells that many users don't really want to follow the latest GUI trends, but instead they are forced to.
And I’m not sure about the dates, but iGPUs have been around for quite some time now. Also, Windows 7 (I think the change happened at Vista) most definitely uses a compositor, so there is no CPU rendering at that level.
If you're experienced with WPF you can build very complex applications quickly, but the learning curve is very steep. There's also a million gotchas when it comes to performance, and when things go wrong, they go wrong bad, and you end up spending many hours trying to figure out why you're getting a stack overflow exception :)
WinForms is a joy, though, and making custom GDI+ components is easy. I just wish they made WinForms 2, called it DotNetForms, made it cross-platform and high-DPI aware.
Maybe start with why people are still using a 19 year old UI framework.
Wait, I thought that Blazor Desktop was the "new hotness" this week?
I miss the days of writing desktop software, it was nice :)
What?! This wasn’t even on the list!
This is why people just stick with winforms.
However you can just use Electron if you want to reuse web UI skills on desktop (although HN hates that). Likewise you can solve the state problem the same as a web backend. Use an external database, or a local database, write to a file, just keep it in memory, or use any of the OS-specific options. I recommend starting with EntityFramework (an ORM) and using the Sqlite provider: https://docs.microsoft.com/en-us/ef/core/get-started/overvie...
No it isn't. WinRT, UWP and WinUI are all later than WPF.
You're most likely best of picking WinForms. It's old school, but it seems like it's going to be the one Microsoft will have the hardest time killing.
WPF, UWP and Xamarin fine frameworks, but for the 0.9X developer who just want a window, with a few input and some buttons, you can't beat WinForms in ease of use.
My reasoning is that most of the developers who saw WPF and jumped on that, are the same who will more easily jump to UWP, and from there to what ever comes next. The WinForms developer aren't moving.
That's pretty fantastic. Stealing this!
That sounds like talking it down, but I'm not actually.
Good for things like the sales guy wants something that pulls data out of a company database and sticks it in a excel file. And wants it tomorrow.
You will always be unhappy with any choice of UI framework, on any platform :)
Although F#-the-language is top-notch, the surrounding bits - editor experience, documentation, libraries, tooling - just don't get the investment they need to be on par with the sibling languages.
What I mean to say is, don't judge .NET just by your experience with F#. C# is the happy path.
Sure, there's a bunch of other languages that run on the CLR - but for the most part, the broadest, most well tested, path is doing stuff in C#.
Also like the others say, F# on dotnet is like Groovy for the JVM. It's nowhere near the popularity. Any reason you didn't try C# instead?
If you're just getting used to the platform, you're shooting yourself in the foot by going with niche setups. Try C# first to figure out your way around the platform and then branch out, not the other way around.
Nonsense all you have to do is install the dotnet sdk and run a single line in your terminal.
dotnet new console -lang "F#" -o "project"I think there was a Microsoft article that summed it up nicely: there are millions of C# developers (ergo the focus), tens of thousands if not low hundreds of thousands of VB.Net developers (ergo the life support) and maybe hundreds or low thousands of F# developers (ergo the fact that Microsoft offers some integration points but expects the already small community to develop and polish the actual implementation).
It took F# several years to fully get supported on .NET Core (type providers and such). I know, because I was watching the Github issue for it for at least 2 years).
Installing .NET 5 should be easy on macOS as they even provide an installer.
# Start fresh alpine
docker run -it alpine
# install tools and .NET 5.0
apk update && apk add wget bash vim icu-libs krb5-libs libgcc libintl libssl1.1 libstdc++ zlib
wget https://download.visualstudio.microsoft.com/download/pr/21fdb75c-4eb5-476d-a8b8-1d096e4b7b14/c1f853410a58713cf5a56518ceeb87e8/dotnet-sdk-5.0.202-linux-musl-x64.tar.gz
mkdir -p $HOME/dotnet && tar zxf dotnet-sdk-5.0.202-linux-musl-x64.tar.gz -C $HOME/dotnet
export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet
# create f# project
mkdir my-fsharp-demo && cd my-fsharp-demo
dotnet new console -lang f#
# run project, it will show "Hello world from F#"
dotnet run
Trying to use .NET on Linux with Visual Studio Code is pain: .NET developers expect you to learn APIs through intellisense and don't publish API docs, Windows tutorials assume you're running Visual Studio, and a lot of MS's own API docs are bewildering with .NET jargon that you won't understand.
I work in a small shop and most of the developers use Visual Studio with Linux or a Mac. Most of the developers that don't bother with anything outside of Windows won't be open sourcing their libs or documenting their stuff anyways.
This may have been true back in 2016/7 when .NET Core first turned up but it just isn't true anymore.
> Trying to use .NET on Linux with Visual Studio Code is pain: .NET developers expect you to learn APIs through intellisense and don't publish API docs,
I've used VS Code for small projects fine on my Mac. However I can see it being a pain on larger projects and you will need a large IDE. However the same could be said for a large Java project.
> Windows tutorials assume you're running Visual Studio, and a lot of MS's own API docs are bewildering with .NET jargon that you won't understand.
I don't want to sound like a dick, but yes the Windows tutorials will expect you to use Visual Studio as that is the IDE that primary IDE of people using Windows.
As for complaints about jargon. As a C# developer that now transitioning to Python. The Python docs having lot of Python Jargon you won't understand (at first). Every language has its own jargon.
> Windows tutorials will expect you to use Visual Studio as that is the IDE that primary IDE of people using Windows.
Yep, hence the bubble. Python doesn't have this problem, for example.
Almost all the projects I use with .NET have sufficient docs on their sites. MSDN has the full docs on their site. If there are specific projects that are a problem that are outside of that. Well that is a problem with their project, go and complain to them.
> Yep, hence the bubble. Python doesn't have this problem, for example.
Yes Python does have similar problems. A lot of time people assume you are using a *nix machine and if you aren't then you normally have to faff with some work around. Go has the same problem a lot of things just don't work properly on Windows (at the least the last time I bothered). The same is true with Java, Go, Ruby etc.
As for the tutorials. I've just gone on the ASP.NET site and there is a tutorial for Windows, Linux and MacOS in the tabs on the site.
.NET on Linux with Jetbrains Rider, is a far better experience than Windows and Visual Studio.
VSCode isn't worth looking at for .NET Development.
My point is not that experience is easy or hard, just that when comparing the two side by side, the experience of being a .NET developer on linux is good, and I would argue with jetbrains rider, is better than being on Windows with Visual Studio.
For me, even simple things like getting C# aliases working was a pain. I would not recommend a Linux developer to be picking up C# to do cross-platform development anytime soon. The only nice benefit I've seen is the amount of batteries included with .NET - but that's a solvable problem in other languages.
I suppose you mean using-aliases for types/namespaces? This is a C# language concept, not a very complicated one, and totally independent of the operating system
My advice after having tried it seriously - .NET does work crossplatform, I've seen it, but you need to be a Windows dev to tap into that. Would not recommend a mac/linux dev who's looking to do cross-platform work to pick .NET as the foundation.
So just fired up a VM with a clean install of Ubuntu.
No VSCode, No Rider.
> wget https://packages.microsoft.com/config/ubuntu/20.10/packages-... -O packages-microsoft-prod.deb
> sudo dpkg -i packages-microsoft-prod.deb
> sudo apt update && sudo apt install apt-transport-https dotnet-sdk-5.0 -y
> mkdir test
> cd test
> dotnet new console --output sample1
> dotnet run --project sample1
This is all on the MS Docs website for getting started.
So I'm really not sure what part you find difficult. Getting hello world is no more difficult than me getting hello world working for golang, nodejs, python.
> For me, even simple things like getting C# aliases working was a pain.
Aliases for what?!?
EDIT: Simplified the commands cos I can't format in comments.
Aliases: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe.... Support for those was only added in the last year or so to the dotnet/nuget/roslyn/whatever it is needed things to make it work. Microsoft's own documentation only documents how to use it for Visual Studio: too bad if you're using another IDE or the command line like you did above.
In terms of building a real world application. What are you struggling with? The code is no different regardless of IDE you use. VSCode, Visual Studio, and Rider all have a debugger and can step through code.
Right now it sounds like you’re just trying to make .net sound bad.
I don't understand what you dislike about the API documentation Microsoft provides with .NET, it's not always perfect, but I would say it has nearly 100% coverage: https://docs.microsoft.com/en-us/dotnet/api/
And because .NET used to be Windows only there are a lot of Windows tutorials. But you can anyway skip them, as they mostly describe the old .NET 4.x. Find newer .NET Core tutorials. Even if they provide you screenshots of Visual Studio on Windows, you can do all of it with any text editor. Some scaffolding you maybe need to do on the command line.
And I haven't said anything about building GUIs here yet, which is another world of pain on .NET.
Problem is, the past will remain with us in every book, code example or stackoverflow answer. As a beginner you need to understand the difference between .net framework and .net core because any blog post or tutorial will reference one or the other. Now people start calling it .net 5 or .net 6 instead of core, but you have to understand that this is incompatible with ".net framework" or ".net 4".
Or neither, if it was written before Core (in which case it's Framework).
The article makes a good point but 90% of is irrelevant to a beginner. Open Visual Studio, pick your project type, and start coding.
Windows-only desktop app is the latest to confound me, let alone cross platform.
The .NET variants confused the hell out of me for the longest time until I just sat on Wikipedia and read the whole damn history, because every variant and version seems to be in play simultaneously
Heck, they've even brought over Winforms -- that technology is over 19 years old! So I honestly think using the term deprecated is too strong. They've done the right thing and continued to maintain multiple branches .NET until the newest version is fully finished and can reasonably replace the old one.
As I said in another comment, the framework you choose doesn't even matter that much. You're unlikely to even a notice a difference and changing from one to another is often as easily as selecting it from a drop-down (or editing a file) and recompiling.
So the framework to pick for a new application is... I don't know. Ideally the answer would be UWP with some kind of automated fallback for older windows, but its not. [0]
This windows UI confusion (3 different gui systems in play, when iterating over system settings) seems like a direct result of this framework confusion
[0] Apparently Win7 is still like 30% of the market, so it's hardly ignorable. https://www.digitaltrends.com/computing/windows-7-end-of-sup...
You just described all UI the frameworks, what replaces what, and what the limitations are! Microsoft also lays that out here: https://docs.microsoft.com/en-us/windows/apps/desktop/choose...
I've answered this question for myself: WPF. It's neither bleeding edge nor is it obsolete.
You can complain about the current state of things but I don't think there's any argument that Microsoft is doing the wrong thing here. They're iterating on their platform, making improvements, and supporting existing technology.
The problem is that all options lack some core fundamental expected feature. From that chart, WinForms lack High DPI awareness and customizable UI (tbh I'm not sure what customizable means here -- that custom controls/views are difficult or just skinning is difficult?), WPF also lacks High DPI and UWP lacks fallbacks (and a bunch of basic OS features like direct file access? I don't know why that's the case).
The differences between them aren't even trade-offs, so much as randomly incomplete. Granted, I haven't spent any time whatsoever trying workarounds -- maybe it's simple enough (WPF is clearly the least problematic, if DPI scaling can be worked around without much trouble). I've just been looking at the charts like that, and my ultimate answer is "???"
>You can complain about the current state of things but I don't think there's any argument that Microsoft is doing the wrong thing here
I think there is; Microsoft runs the .net ecosystem as its steward -- it intentionally creates, markets and governs pretty much every major framework and components that exists. For better or worse, the state of .net ecosystem is owned by Microsoft -- unlike say, rust, golang, python, c++, ruby, etc where the language maintainers are mostly divorced from the language ecosystem, and make no real say in the matter beyond broad recommendation of community-run frameworks (python is a little different, being batteries-included, but it's also well-known that stdlib is where libraries go to die; no one recommends python stdlib as best-in-class of anything). .NET is of course a non-closed ecosystem, and the community does contribute quite significantly, but nonetheless, if it's first-class it's almost always MS.
The current state of affairs is essentially a result of bad ownership; the high rate of churn in the javascript ecosystem can be blamed on the JS communities. The high rate of churn in the MS ecosystem can be blamed on MS. They've constructed a complex environment with unclear recommendations and continuous deprecation (fine, they're never actually deprecated because MS policy on backwards compatibility is second to none, but its "legacy"), a terribly confused naming convention and wide swath of overlapping technologies.
Don't get me wrong, MS does cool work, but they've made quite a mess, and it's quite clearly a result of constantly changing vision of how the .NET ecosystem should look like -- in combination with new projects seemingly forgetting MS's stance on backwards compatibility (nothing is ever just superseded; there must be an upgrade path or you will end up maintaining both forever [Unity has the same fundamental misunderstanding of their feature development]).
If there are going to be 4 UI frameworks, they should be competing on different models, APIs and mindsets (eg MVC vs MVVC vs MVU -- it's absurd that they're competing on core fundamental features instead). Although on the web-side of things, I think this is actually the case for .NET -- blazor vs MVC5 represent entirely different ways of approaching the problem. But AFAICT winforms vs UWP are really, from the programmer's perspective, the same thing. The underlying technology support changes (but in that case, you would ideally have the options be functionally complete).
Anyways as I said I've only been looking at it for the last year but that's my interpretation thus far -- the only way to understand the .NET ecosystem is to understand all the paths MS has taken, untaken, and re-routed. because their actual messaging and vision (as it connects to what they've implemented) is quite confused
WPF is system-DPI aware but it's not aware of per-monitor DPI as that feature didn't exist at all when WPF was conceived. I guess these days Microsoft doesn't consider that good enough to be called High DPI aware.
> I've just been looking at the charts like that, and my ultimate answer is "???"
I don't know -- I guess find it much less difficult than picking a web framework. The problem is that GUI frameworks (in any platform) are a complex mix of trade-offs. .NET and Windows is not the unique in this regard.
> The high rate of churn in the MS ecosystem can be blamed on MS.
I'm not sure you can call frameworks that have been around for multiple-decades a high rate of churn. The problems that Microsoft have is no different any of other platforms you've discussed. Yes, it's one organization but the problems are all the same. New developments require new framework but developers have lots of existing code. The fact that Winforms still exists is the same reason jQuery still exists.
Microsoft wanted everyone to move over to UWP -- this is kind of exactly what you're suggesting -- but developers just weren't interested. So they had to go back and take a more broad approach. But UWP is/was supposed to be the future.
> it's quite clearly a result of constantly changing vision of how the .NET ecosystem should look like
Not just the .NET ecosystem but the broader software industry as well. Many of the changes that Microsoft is making to .NET relate to changes made in mobile and on the web. As the world changes, .NET changes, and thus Microsoft maybe adds a new GUI framework to fit that world. Without that sort of change, we'd all still be using Winforms.
But I don't disagree. Microsoft has been in a long transition period to .NET core and they're finally started to come out the other side. With that done, there will be renewed effort to bring everything else together as well. I suspect in another couple of years this mess will be a lot more cleaned up. But I expect, unlike with other platforms, that most of my code written today will still work with whatever Microsoft comes up with in the future.
No data but from a lot of anecdotal experience I don't believe so - quite3e opposite.
I've never seen beginners (interns generally) or non-C# programmers (adept at other languages) come up to speed and start meaningfully contributing to projects on any other language other than C#.
With other languages (I've worked with) this just isn't true. I've never seen anyone but the most prodigious pick up C++, Java, JavaScript as quickly in professional contexts.
IMO C# is such an easy on-boarding languages that when hiring into C# teams it's not even a factor considering a candidates particular language experience.
As much as this is due to the language and well-organized libraries I think the tooling is just as much to thank. The dev experience in VS with a copy of ReSharper installed is unparalleled in software engineering.
It's pretty great until you tried out Rider :D, okay it's more or less the same as Resharper.
I'm not a Java developer, but i suppose IntelliJ will give you quite a similar development experience as Resharper/Rider?
As someone who did exactly this 25 years ago with VB, I really feel bad for new developers who don't have this nice experience and instead need to wrangle with half broken tools.
The experience is surprisingly good.
If you want to create and build + run a .NET web API, you just do:
"dotnet new webapi"
>cd into the directory
"dotnet run"
Then: "Just think about the upcoming release of .NET 5 and how it will invalidate most of the lessons taught just a few months ago .... the wider .NET community has failed in making .NET a more beginner friendly language"
.NET isn't a language! It is, I will agree, absurd that Microsoft way back when decided to give the totality of the infrastructure around their language a name at all, let alone one as confusing as .NET, but that is all it is. A name applied to sometimes the compiler/runtime/core libraries or all of the above.
Unfortunately this has led to people wandering into forums asking "how can I learn C# and .NET?" nobody ever wanders into a forum asking "How can I learn C++ and llvm"?
Rather "C++ and Qt" or "C++ and Boost".
.net would be like the OpenJDK
> In particular questions around the differences between .NET, .NET Core, Mono, Xamarin, and the relation between C#, F#, VB.NET and what a target framework or a runtime is add very little to almost no benefit to one's initial learning experience.
So, I assume they primarily mean the particular set of libraries being used
Even those are complex questions with a few answers. I started with C# two decades ago with the command line compiler and a very large book. There was really only a single option, and since I didn't have MSDN access, no beta VS for me.
Today, I would suggest that a developer start with .Net 5 and VS Code, with the extension installed. Walking through the `dotnet` CLI. Unfortunately, getting started like that is convoluted with two decades of information/tutorials etc that will not directly apply, or be difficult to walk through.
For that matter, having followed .Net Core from the initial versions, it's been somewhat painful. Figuring out how to migrate/update web applications hasn't been anthing resembling transparent or consistent, and some things are just plain difficult to figure out along the way. There is a crap ton of secondary knowledge you need to be able to do a lot of things that are just easier in other platforms/languages.
Add support for an Authorize header with an RSA signed JWT token to your API.. go ahead... in Node, it took me a couple hours... with .Net Core having well over a decade of experience with C#, it took me the better part of 2 weeks to get things working the way I wanted to. All the tutorials were for older interfaces/apis etc. It was just ugly to say the least.
Hell, if MS would just standardize on keywork formats for thinggs... #dotnetcore3 or similar so that search terms via google could give you more relevant results... that just doesn't happen.
Don't get me wrong, I really appreciate C#, and .Net ... .Net Core itself had me working with .Net again with interest after years of migrating solutions towards options that are easier to write, containerize and scale.
I'm still more inclined to reach for Node or for that matter, to push for Go or Rust, at least it's a consideration again.
But it is anything but something easy to get started with, or for that matter, upgrade projects with. Python 2 to 3 was a cleaner migration option.
Visual Studio Community Edition 2019.
Done.
edit: I would encourage using regular .Net, not .Net Core until they've reached a certain threshold.
I absolutely hate most CLI tools and C#'s is no exception. I'm happy to say that I have never, in any of my time developing, been in a situation where I absolutely had to use one for C#. It's made me very happy.
.csproj's and .sln files are such a better design pattern for project management than raw folders that I wouldn't torment someone by requiring them to learn that alternative model when any good C# IDE will do all of that for them.
Same with Java.
If you want to require someone to learn everything CLI, then they should probably be learning a different language, to start.
In a similar tone, if I was teaching someone Python, I would start them with running `python` and then just ... typing commands. I wouldn't teach them if __name__ == __main__ until later on. Same reason. Unnecessary complexity for the kind of work they're doing.
When you start wanting to configure CI on Jenkins (not TFS, because TFS handles all this for you, too), then the command line has any value for C#, imo.
I certainly wouldn't encourage the first thing someone does when writing C# be "create an application that will run in a Docker container". Running locally and getting one's feet under them seems like a better first step.
It is valid, though, that the Linux development experience for C# is worse overall. If you're using Linux, though, your options are greatly reduced, though, so life becomes easier. You're either developing for Mono or .Net Core.
As I wouldn't recommend developing in C# for a Linux developer, in general, though, but that is my bias against .Net Core speaking out.
If someone's a Unity Developer on Linux, I would recommend MonoDevelop or whatever Unity's recommended IDE and pipeline are.
I do most of what I do with C# in WSL with VS Code (WSL Remote) ... because that's where I do most of my Programming. Where I work, pushing towards most of what we write to be able to deploy/operate in Linux/Docker environments. Doesn't make C# less of a language for the teams that have over a decade of experience with C#, but it is a mindset shift.
The bigger issues I have are with the framework and that it's very difficult to search for working paradigms as framework apis and interfaces have dramatically changed in a lot of areas the past few years. I like the dotnet cli better than what was before it... that said, it's still got a lot of rough edges.
And getting started, especially when you are experienced in other platforms, isn't always easy... even experience from .Net framework to newer runtimes has been painful in the past.
That's a major reason why, when I answered the top question, I was responding in a way to reference a new developer. I don't think they should be required to think of all of that hell, so I just wanted to point them to a particular library and to just live with it until they're asking the hard questions and have to move to something more complicated. For beginner-beginners, that shouldn't happen for a while.
Someone higher up said that this post should have been titled something like .NET for Professional Beginners, developers that already have a lot of experience and are wanting to develop a single, specific, advanced usecase, or a use case where they are required to work with .net core, it was like that.
I ran into something similar at my present job, trying to set up a webserver in Kotlin. It reminds me a lot of the woes I have with .net core with the numerous, almost adjacent, but not quite in the same package gradle packages.
At this point, I'm not sure there's very many batteries fully included languages left. C# was kinda the last bastion of it. Elsewhere someone, maybe you?, referenced PHP, but even that isn't batteries included. The only batteries included are the ones that PHP is good at, webservices.
Python is all about packages, and it just went through async hell, where the syntax for async changed over and over again over each version, so Google searching, as you mentioned struggling with in other threads, can be painful there, as well.
Ruby requires you to learn Rails (which isn't Ruby! it's written in Ruby but not part of the base framework!)
...
I guess Go is probably the closest to general purpose with its default framework.
I'm mostly playing devils advocate as it's not been a smooth transition and the best way to do many things has changed since some things are in the box, that didn't used to be, but still rough around some edges.
Many libraries and patters for web api projects are a bit different, better but different.
Or... I'm running a Mac.
It's just .NET 5, a cross-platform framework that is the next version of .NET Core taking over as the single framework.
This is terrible advice. .NET Framework has so many gotchas in its dependency management and binding redirect hell, not to mention ASP.NET 4.x is full of hidden "magic" and serious usability problems.
Anyone starting a new project should be on .NET 5/Core, and that's been true since the Core 2.x releases. Also, the generic hosting model[0] is a productivity game changer and gives you a complete batteries-included experience no matter the project type.
[0] https://docs.microsoft.com/en-us/dotnet/core/extensions/gene...
but ...I can barely read that page and understand what's going on!
This is something I did notice with the c# codebases I worked on; you could date them to the month based on whatever "hot shit" patterns were used by each project. I thought this was normal for every language, but since working on large codebases in other languages, I've found that it's mostly a C# thing (Java has a bit of that too).
But man, it's insane how much the language and the ecosystem has changed in 5 years.
It explains everything, including how to get started for every scenario, and answers to every question in all of your comments here.
A not too old (~2-3 years) book on the topic will explain everything in an easy to digest way, and it is much more likely that the author actually knows what he/she talks about.
The problem for a beginner (on any language or platform) is you have to know what you don't need to know. You get overwhelmed with terminology just in the "create new project" dialog. Most of it is not relevant for a beginner, but as a beginner you don't even know what is relevant and what is irrelevant.
I would have titled it, "Beginning .NET for Professionals."
Most of the concerns outlined in the article are really only relevant to professionals, or serious hobbyists. If you're truly a beginner most of those points are not concerns, at least until much later.
If you want to learn .NET, download Visual Studio Community Edition, fire up a console application, and tinker. Starting with C# is probably a good idea.
I did this with my sons, before there was a Community Edition, when they were about 11 and 8 - truly beginners. They had little problem getting going, writing small little programs to find primes or the lowest common denominator for a number. We didn't even cover OOP really, and the standard library only minimally.
So it can be done, even today after .NET has exploded. It's just hard for us pros who now have to confront that enormity.
- install the newest Visual Studio with default config
- create a new console app project
- start writing code in the template's main function
Granted, I have to know whether I want to create the console app in .Net Core 3.1 or .Net 5 or whatever, but I imagine I can find the answer to that pretty quickly and move on. Usually the answer will be "the newest version you have installed".
Any language feature I want to play with is just one automatic import tip away, and most of the features I would explore as a total novice don't even need that.
The complexity of various Nuget packages, ASP.Net versions, older versions of .Net only arrives once you need to uplift older projects, maintain libraries to be used across different framework versions etc. Those are tasks for a more experienced developer, for a good reason, and I believe this is true for any technology stack.
EDIT: formatting
And you don't even need a main function anymore; you can just start writing code at the top level in a blank file without any class.
Aside from hobby projects I’ve basically not given much thought to .NET Core because it’s such a moving target - and it’s a shame. In so many ways it’s far superior to the moribund .NET Framework - especially in terms of speed and memory use.
But there’s also many places in Core where there’s parity lacking with Framework, and migrating code can be a confusing and confounding experience. This is a place where things needed to be easy and they aren’t - and it doesn’t help that it’s so hard to figure out the difference between .NET Framework/Core/Standard/5 with UWP, WinRT, etc further confusing things.
Back in 2004 Joel Spolsky wrote the great article “How Microsoft Lost the API War” (https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...) and now some 17 years later it feels like little has changed. Some of the technology stacks may be different now but the frustrations are largely the same. It’s still the “MSDN Magazine camp” (or whatever today’s named equivalent would be) versus the “Raymond Chen camp”.
I don't know what it is about golang, but man, it's hard unless you just start up a WSL and install it on there.
There are pointers without pointer arithmetic, I really don't know why they are there. If you already know programming you will be fine with go, but if it's the first language someone learns I think they'll go catatonic when they are exposed to real pointers, dealing with shared memory, package management, generics, etc. because its going to be hard unlearning ways used in go.
On the plus side go is small and very performanent.
Because you need some way to distinguish between having a sequence of bytes in the middle of another sequence of bytes and having the former sequence of bytes somewhere else, at least in languages that allows both for any data type. For example, Java doesn't suffer from this since everything is pointers implicitly. And C# doesn't either because every type belongs to one of two kinds, the first kind corresponding to the former of the two cases above and the second kind corresponding to the latter. But Go doesn't have this luxury (intentionally, for the same reason as C does it).
This is a pretty common issue to run into with developer tooling on Windows, regardless of the language.
It would be nice if the go installer added its install dir to the PATH automatically like some tools do. But so much dev tooling on Windows does not you will need to know how to edit your PATH eventually.
When was this? Within the last two years? When Go was transitioning from the original GOPATH style setup to modules, I had a ton of issues like this. So many, that I kept my Go version on an earlier build so I didn't have to deal with it.
These days, thankfully, all those issues are taken care of. I've mostly switched to cross compiling from WSL(2), but compiling on Windows has been fine for a number of versions now.
Honestly, what's so technical about adding:
export PATH=/usr/local/go/bin:$PATH
mkdir myapp && cd myapp && go mod init myapp
Oh boy, you don't tutor many beginners in programming do you?
But C# is beginner friendly in that it's easy for inexperienced programmers to contribute business value to existing codebases. The everything-in-one ecosystem (IDE + autocomplete + database + deployment + source control + package management) removes many sharp edges that experienced programmers are used to working around and take for granted in other languages. I've known smart high school kids with limited programming experience become productive C# developers in weeks, and that doesn't happen the same for e.g. Java.
The evolution of .Net Core (now just .Net 5) has been interesting and at times very painful.
I’ve lost track, and I don’t even know how to keep tabs on this any more.
Too much information.
I envy the greenfield developers who can start with .Net Core or .Net 5.
Since the release of .NET 5 "unifies" Framework & Core (for some value of n), there is no longer a need for Framework, Core, nor a unifying Standard.
Recently I was reviewing the code of a library written in C# 9 and couldn't make head or tails of it. Half the code was using features that didn't exist a couple of years ago, enabling the author to use patterns which were not possible without those features.
Despite having gained some weight over the years, I still wouldn't call Anders Hejlsberg a committee.
It used to be that you only needed "current version of .net" and then you just ran forward with all of the standard libaries and Visual Studio handled all of that for you and it was wonderful.
Now you need to work with .NET Core and download a bunch of disjoint nuget packages to make everything work; and, then you download a specific nuget package and it requires updating all your other nuget packages, on to forever.
I was tasked with transitioning some of a former company's .net 4.something code to .net core, to see if we could do it, and the transition was a shock to the system, for sure.
In the past, I could choose when to engage with Nuget and which packages to work with. When I went to .net core, it seemed like anything complex that I wanted to do required yet another package - in my case, anything related to running a webserver.
Working with .net definitely became more complicated post .net core.
edit: for clarity and enjoying the downvotes.
I'm a seasoned .net developer and used it from 2009 until 2018-2019 for desktop applications and webservices. I've used nuget packages plenty for a variety of things, including Akka.net.
That said, I do feel the pain, the interface changes for binding web applications are very different, and if you relied on "Enterprise" libraries harder still. I'd rather do things the "new" way, but it's more the differences that make it harder.
Harder still, is when trying to google how to do X with .Net Core 3 or similar... Now that it's .Net 5, at least that should make some stuff easier, until 6 comes out at the end of the year, but that's more evolutionary. Getting search results that no longer apply is a pain. It's far less the C# language as it is the platform libraries themselves and the breaking evolution through .Net Core. I think TFA has a point that renaming .Net to something else instead of .Net Core or .Net 5 may have been a good idea.
Of course, now it's Azure * instead of a couple decades ago it was * .Net (anyone remember Office .Net, Windows .Net etc in early dev/beta marketing?)
You probably still will have more Nuget packages in your ASP.NET Core project than a classic .NET Framework project would.
Details about the new system: https://github.com/dotnet/designs/blob/main/accepted/2019/ta...
How many transitions have you done? As a long time dotnet developer I feel like there’s been constant transitioning and back and forth.
It isn’t simple to transition either. As you have to wait for all your dependencies to transition, there are usually many different solutions to update, there are breaking changes and bugs to deal with and on top of it there’s the constant moving target to be up to date. It’s definitely made it painful to use dotnet.
" .NET is a great technology for experienced developers who grew up with the platform as it matured, but I'm not sure if I'd still enjoy learning it today as much as I did in 2008. Whilst the complexity allows me to charge great fees to clients for writing software in .NET, I'd probably not recommend it to a friend who wants to learn how to code or I wouldn't use it for building my own startup from the grounds up. "
Is it really the case that the only argument for using .NET is that you can earn a lot of money by working as a .NET consultant? From my own experience I always assumed that it was, but I would love to learn about some actual benefits that .NET has over competing platforms.
Initially I had the same tribalism that a lot of people seem to have towards .NET, for whatever reason. Eventually though, my conclusions:
- .NET Core is pretty reasonable. Platform agnostic, easy to work with, decent command-line tooling, and doesn't force you into an IDE vertical unless you want to. - C# can be a nice language for certain types of business applications. I think it has a lot of the good modeling properties that once made Java the de-facto language for enterprise development, without some of the verbosity and other drawbacks (though maybe Java has changed too since I last looked at it :) ). It plays very nicely with Domain Driven Design and event sourcing, both of which are patterns that I find valudable on large-scale systems for managing business transactions.
Overall TLDR: I probably wouldn't use .NET if I started a company tomorrow, but when I start coding non-trivially sized things in Python I sometimes miss elements of what .NET/C# brings (particularly interfaces, which obviously also exist in other languages).
- Decent command-line tooling
- Doesn't force you into an IDE vertical unless you want to
I'm not saying that the points above aren't true exactly, but surely they are less true for .NET than they are for just about any other mainstream development stack?
Before I was forced to try it, if you had asked me whether having a "normal" development experience using .NET was possible I would have said "no way". After being forced to do it I was pleasantly surprised to see that it didn't feel particularly different to most other compiled languages that I've used. YMMV.
Most of your dev needs will be met by .NET Core.
Take "Enterprise Framework" (EF) and "EF Core". These are two independent ORM frameworks. From the names you would probably expect either that "EF Core" was the core of EF or that EF Core was a version of EF which ran on ".Net Core" (the previous name for .net 5). Neither is true - the frameworks are independent and both run on both .net 4.x and .net core/5. Apparently "core" just means "new incompatible version".
And how about ".net standard"? .Net Standard 2.0 was the standard API which was available with both .net 4.x and .net core/5. But from .net Standard 2.1, it was not compatible with .net framework anymore, which meant it wasn't standard anymore.
The actual technologies like C#, the BCL and EF Core are great, don't get me wrong, but the naming is so confusing.
Eventually Microsoft came to the conclusion that doing .NET Framework to .NET Core migration in tandem with an EF6 to EF Core migration would be a huge undertaking for legacy projects. So as of EF Core 2.1 they added support for .NET Framework 4.7.2+ so people could migrate that first, then move to .NET Core. Therefore you end up with the weirdness that it was .NET Core only, then eventually it wasn’t, despite being called EF Core.
As for Standard.. can’t help but agree, it was a bit of a mess unless you really understood what it meant for API compatibility. But with .NET 5.0, Standard is pretty much gone for new code. See https://devblogs.microsoft.com/dotnet/the-future-of-net-stan.... So I think Microsoft is slowly learning and fixing up some mistakes made in the “Core” era
As I understand it, core was conceived as an experimental alternative runtime which made it possible to run asp.net on non-windows platforms. It was not initially planned to be the replacement for full .net framework, so it didn't need to be fully backwards-compatible with the regular framework, which saved them some effort in the beginning. When the strategy changed to make core the next version of .net, the incompatibilites was so entrenched it was too late to solve, so we ended up with this enormous mess.
One of the reasons I chose to learn C# a couple decades ago over Java was the fact that interop was so much cleaner than JNI.
The fact that Microsoft mgt never ran/supported that prior to Satya and .Net Core had nothing to do with the platform and language design.
Only after Microsoft's Linux patent racket involving Suse, who Icaza worked for, branded them as the enemies of open source which became inconvenient once they realised the writing was on the wall for anyone who did not support open source.
I wanted to try to a server backend with it, but I was lost as to which framework to use (ASP.net / .NET Core / .Net 5) so I ended up choosing neither.
Which is a shame, because I really really like the language
Yes, you can get into situations where something you're doing needs one or the other but it's very rare.
You know that it will not matter that much, because you're familiar enough with all three. A beginner doesn't have that information.
Think about it like this: Is it better for beginners to have such a 'non-choice'? Or is it better for them to be presented 1 maybe 2 options and say pick from these 2 these are the differences?
The problem is you're informed enough to ask the question! If you had no idea about the different frameworks you wouldn't have a problem.
The new C# tutorials have solved a lot of this issue just by completely skipping over the legacy parts of .NET (.NET Framework & ASP.NET) and using the CLI to create a new project.
You install .NET 5 (for context, it's just a newer version of .NET Core with the naming realigned), and then write `dotnet new webapi` which will create a new ASP.NET Core API project.
However this sentence made me inadvertently laugh, because it captures every bit of confusion I had.
> You install .NET 5 (for context, it's just a newer version of .NET Core with the naming realigned), and then write `dotnet new webapi` which will create a new ASP.NET Core API project.
Haha, for further context, .NET 5 is the SDK + runtime. ASP.NET Core is the default Web framework that includes a ton of out of the box functionality.
I'd highly recommend taking a read of https://docs.microsoft.com/en-us/aspnet/core/introduction-to..., which links to the relevant tutorials for your scenario.
Currently there are better options than C# or .NET. You want simplicity, you have Go. You can create an API server so simple and easy to understand. You want a full framework, you have Rails. Rails give you everything so easy to be productive and start shipping. Just run gem install device and you have authentification. You need to storage files, images, etc., just a simple tag on your model and really to go.
You're late to the party, and your comment is a bit funny. C# was <<never>> a startup language :-) It was always an enterprise language, meant to fight Java.
If anything, C# is moving towards startups with the introduction of .NET Core and of the cross platform IDEs (VS for MacOS, VS Code + plugins, Rider).
I never understood the hype around it.
I think if you just start with .NET Core and learn basic console programming, the rest will come easily enough.
As the OP said, the overarching problem is probably trying to be all things to all people and pretending that all of those things are .Net. It also produces a sadly common attitude now of "we won't fix that in dotnet core 3, upgrade to .net 5" as-if that is even a possibility for many existing apps.
One idea that comes from way back in the day was having an IDE that you could set to beginner, intermediate and advanced so that when you start out, you only see a subset of things. You can then get more confident in the basics before seeing more options and windows.
Another idea I liked was removing older features so that you don't keep getting bigger and bigger.
Xbox One X, Xbox One S, Xbox series X, Xbox series S.
And also: Is Outlook the same as Office365? Is Outlook the new Live? Did Hotmail turn into Live? Am I the only confused by all of this?
The .NET ecosystem is huge, there are a lot of different frameworks associated to any kind of problem. Xamarin for mobile; EF 6, EF Core, ADO.NET for databases, and so on.
But as a beginner you shouldn't try to understand it all, right from the beginning. Just start somewehre.
It's like saying: "Biking is too complicated, there are so many different kind of bikes, who should know what to buy!" Just get the first best bike / framework (e.g. console app, or asp.net core) somebody recommends you and go with that until you know better. After a while you will understand the difference between a mountain bike and a downhill bike, or between EF 6 and EF Core.
I'm still a little lost on how asp.net runs in a Linux container.
At one stage I had a JS developer just try the F# template instead and the difference was stark. Explained to them Async F# - Promise JS, Module F# - Module JS, showed them a unit test example and they were writing production code in two weeks to a month. It made me realise that over the years there is a lot of knowledge I just take for granted that many beginners just don't have especially now when there are much friendlier languages for beginners. Things like dependency injection, how it resolves based on types, and which framework to use and why, mocking framework choice (vs simple stub functions), can only mock interfaces and why, the class structure and how you should group functions into appropriate classes, abstract classes vs interface default methods, LINQ vs OO style coding, nullability annotations all over the place, OO design patterns, the need for Resharper or equivalent unless you can write C# syntax from scratch, the list goes on and on. With most C# apps there is a lot of knowledge assumed and baked in which can be daunting for a newcomer. C# is not alone here I understand that - the same thing can be said for other languages too. But it has made it harder than it needs to be especially when it is actually a good platform but C# scares many developers away especially as it adds more and more features on top.
Litmus test for a language to me: Does it need an IDE and tooling to be productive in? The more tooling it needs the more complex IMO the underlying language is in syntax and complexity. Complicated refactoring tools? If so its probably too complex for a beginner especially now that the language space has quite a bit of competition. As an example watching a developer do this in a previous role in F# you just create a new file and cut and paste the functions around; in C# the dev's I've had usually resort to Resharper and a full blown IDE to extract variables/methods, do code generation, and basic refactorings unless they want a lot of manual work.
Like, dependency injection, mocking and the like are not at all beginner concepts, and are not made particularly easier with more modern languages.
Most F# code bases I've seen that make it to prod don't use frameworks for those concepts even as they scale; basic functional patterns seem to scale up to reasonable sized solutions. If they do use mocking/di/etc its only to make the code more C# consumable at the edge for some other C# framework they are required to use. I'm not talking about toy projects here. My point was more that at some point with C# you will need to learn these things quite quickly even for basic use cases or find yourself writing clunky boilerplate (which most new developers will default to - the you don't know what you don't know problem). However with some other languages you may never need to until much later in the learning cycle - I was working for a very successful large business that built the whole stack without ever using some of these things. If you want to encourage people onto your platform these are some of the people you need to win.
IMO It just seemed the standard to get nice code that was prod ready in F#, even JS or Go, doesn't require as much learning's as a C# app. It's not just a C# problem mind you but from what I've experienced first hand it has scared developers away.
This is my own personal experience here mentoring dev's in both technologies, especially when they come from different backgrounds. YMMV.