Earlier quoted context omitted.
About the 'dependency problem': It's not as bad as in npm with node_modules, because .NET provides a lot of base functionality in the standard library. But when you start to use multiple nuget packages, sooner or later you will also enter dependency hell, where managing versions and updates of nuget packages gets very painful. All in all we have to reference about 10 external libraries. The visual studio nuget packag…
Did you really mean only 10 external libraries? If you'd said 100 I could understand - I hit a version conflict issue in a recent project on adding what was probably package #60 or so, but solved it easily enough after a bit of googling. And we knew we were using a lot of quite old packages (including .NET 2.1 EF, because of a rare breaking change they introduced with 3.0 that we didn't have a good solution for).
The Case for C# and .NET
271–280 of 376 posts
Re: The Case for C# and .NET
#272Just use F# instead and you will have Rust, typescript, Javascript, dart, python all at once https://twitter.com/FableCompiler/status/1550429007443017729...
Re: The Case for C# and .NET
#273My understanding is that with .NET Core, the experience of developing and running on Linux is on-par with Windows(?). However, my impression is that once it comes to building web services, ASP.NET has more "windows-specific" assumptions/moving parts - can someone knowledgeable on this correct me if I'm wrong?
Any .NET NuGet packages targeting .NET Core/.NET 5+ without the -windows TFM will run on any platform that CoreCLR runs on. ASP.NET 6 is no exception. There is nothing Windows-specific in there any longer, and there hasn't been for quite some time. ASP.NET now runs by default on Kestrel, Microsoft's cross-platform web server.
Re: The Case for C# and .NET
#274Earlier quoted context omitted.
I think for swagger documentation you install the swashbuckle nuget package and then add these three lines services.AddSwaggerGen(); app.UseSwagger(); app.UseSwaggerUI();
ASP.NET configuration is one of the most arcane parts of .NET that I don't like. You have to perform the incantation thrice: add package reference, add service reference, invoke the builder extension. And there's the right order and the wrong order of invocations, and if you pick the wrong one, your app silently won't work correctly.
Re: The Case for C# and .NET
#275C# and TypeScript seem to be far and away the most popular programming languages today. At least from the perspective of recruiting in Australia. Python is on the way up and third most popular but well behind C# and TypeScript. Golang is on the way up but very small in terms of number of developers. Java is on the way down but will never vanish, it's just not super popular any more. Ruby is small enough to just be a…
SQL - 11,425 jobs
Java - 7,390 jobs
Python - 6,777 jobs
C# - 4,995 jobs
JavaScript - 4,208 jobs
TypeScript - 758 jobs
Ruby - 252 jobs
Golang - 206 jobsRe: The Case for C# and .NET
#276The thing I miss the most with C# and dotnet is offline documentation. With Java, I can install the java-17-openjdk-javadoc package and have the full API reference (at /usr/share/javadoc/java/index.html), and download a couple of PDF files to have also the full language and bytecode specification. With Rust, I can install the rust-doc package and have the full API and language reference (at /usr/share/doc/rust/html/i…
Re: The Case for C# and .NET
#277Just use F# instead and you will have Rust, typescript, Javascript, dart, python all at once https://twitter.com/FableCompiler/status/1550429007443017729...
Unfortunely not with same tooling level as C# and VB enjoy.
Re: The Case for C# and .NET
#278> For the front-end, JavaScript is unavoidable (for now) Author really needs to give Blazor a try. I wrote some comments last week speculating that I'd use Dart or TypeScript with C# .NET on the client because WebAssembly doesn't do DOM manipulation, but turns out I should have waited to learn it better before making a comment. I've learned I can add events and event handlers to elements without ever leaving C#. Then…
Re: The Case for C# and .NET
#279Earlier quoted context omitted.
I've been a .NET developer professionally for seven and a half years. Rider is the way to go. Visual Studio has improved dramatically over the last decade or so, but Rider is still way ahead of it on code search/discovery, performance, and general user experience. I did a tech talk at my company where I demoed Rider vs Visual Studio 2019 performance on our bigger projects... it was embarrassing for VS. VS 2022 was su…
Rider does not have a community edition unlike IDEA. It was created due to a combined threat of VS Code and Roslyn and is the reason ReSharper is almost neglected these days.
Re: The Case for C# and .NET
#280I wouldn't lose a second to C# or any MS platform unless required for employment reasons. https://github.com/OmniSharp/omnisharp-vscode/issues/5276
Sorry, but OmniSharp sucks, and this is not a controversial opinion even among Microsoft employees. I am all for the .NET experience in VS Code improving greatly from where it is with OmniSharp. This will actually help increase adoption of .NET, which, I remind you, is open source.