Hacker News Reader

Comment by spaetzleesser | Hacker News Reader

I have worked with .NET for a long time and recently did some work with Java, node and python. .NET has a lot going for it but i feel MS is making things more complicated than they have to be. When I need to achieve something a little off the beaten path in the non .NET technologies this is often pretty straightforward to achieve whereas in .NET I have to find some obscure interface and overrides to implement and then deal with weird side effects. I think .NET has become too big for its own good to be maintained by one party. The documentation also has a lot of volume but almost no structure. When .NET started out it was pretty coherent but in the last few years it felt very disjointed without a central design philosophy. Don’t even mention desktop development which is a complete mess since Windows 8.

Maybe I am too negative on .NET but personally find the open source alternatives easier to work with and more fun.

View on HN

I find this very intriguing. As a runtime, .NET exposes a lot of high and low level stuff to the developer.

Can you give me an example of this offbeat thing you wanted to do that involves overriding an obscure interface?

.NET is big, but if you are using it for web app, your focus is only on that set of libraries. Comparing with similar stacks, none of them cover the area .NET covers.

Also, look at python. People don't see it as big because it does not have an IDE that asks you to select projects and what not, making it seem like it is a tool small enough for their work. However, if you combine every library or framework that covers what .NET does in Python (Web, Desktop, Gaming, System, ML) you will find Python is also just as large.

I have the same experience as the parent comment. For example, I wanted to have a process that runs both the asp.net service, a background discord bot, and another asp.net service.

On any other platform, it's just a good old "console app" equivalent, and you can start multiple services in your main function, catch SIGTERM, and control each service on your own.

On .NET, the project type has to be some weird Microsoft.Web.SDK things if you wanna run asp.net, and the IDE/build system would figure out what dependencies to build. And if I wanna run other services in the same binary, tough luck.

Why can't ASP.NET just be constructed as a regular console app, where you pull in nuget dependencies, instead of a completely different app type, for example.

https://www.syncfusion.com/blogs/post/how-to-develop-an-asp-...

Huh? I don't think you read what I'm saying.

Here's a simple challenge for you. Create a command line app (your csproj file should say Sdk="Microsoft.NET.Sdk"), ask the user to input a port number at runtime. Use this port number to start an ASP.NET service.

I have not had any luck to pull all the right nuget dependencies to do that so far. The only way to run asp.net app I could find is switching your whole project to be Sdk="Microsoft.NET.Sdk.Web"

You can run multiple asp.net core services on different ports on same machine. You could create an over-arching console application to automate the same, or you can do it with a simple script.

https://docs.microsoft.com/en-us/troubleshoot/developer/weba...

Nope. Not the same thing. Again, I want them to be in the same binary. Like the example I gave you, have the user input a port number *at runtime*, then use that port to start an asp.net service.

That's just an example. The point is mixing a regular console app with an asp.net service.

1. Create a new web project (it is actually a console app)

2. In program.cs add the following lines at the top:

    Console.Write("Port number:");
    var port = int.Parse(Console.ReadLine());

3. Change the bottom line App.Run()` to

    app.Run($"https://localhost:{port}");

You now have an application which asks for a port and launches your empty website on that port.

A `Microsoft.NET.Sdk.Web` project is still a console app. The "web" variant has some other default packages and (crucially) it has some other defaults for how to compile files such as cshtml.

I can confidently tell you that what you put here won't work. Try it.

I did. It works. The above code lines are cut directly from a test project that I made.

Several people have pointed out how a web app in .NET 5/6 is really a console app which only starts a web server configured with an application and waits for it to complete (i.e. shut down).

It really is that simple.

The whole point here is that the project does not target the Sdk.Web thing. Yours only works because the project is targeting Sdk.Web (instead of Sdk).

When I said console app, I literally meant using the project that you would create if you do `dotnet new console`.

To copy from my other comment:

That is exactly the thing. I do not want to have the Sdk=...Web/Worker. Imagine this scenario, you started a new project with the Sdk targeting Worker. Then you need that binary to also target web. What do you do?

- If you switch the project to Sdk=...Web, you won't have the dependencies to build the worker services.

- If you keep it as Sdk=...Worker, you won't have the dependencies to build asp.net

The "Sdk.Web thing" is the way the project is built.

As I and several people in this thread has pointed out to you, the application the resulting application is not a "web" application. It is a console app that launches a webserver.

The Sdk (without web) is not designed to compile cshtml and/or razor source files. It has nothing to do with package dependencies.

If you do want to start of with a console app sdk, then look at "minimal API". You simply add package references to Microsoft.AspNetCore and Microsoft.AspNetCore.App to your console app, and then you can start using the minimal API samples. They will also launch a website.

The example I showed you above was literally adding two lines and changing one line; and then you had a console app which asked the port and launched a webserver on that port.

If you start from a console app, you will not have build targets configured for cdhtml and razor files. However, to prove that you can launch a webserver the same way you can do this (yes I have tried it and it works):

1) Add dependencies to your "console sdk" project:

    <PackageReference Include="Microsoft.AspNetCore" Version="2.2.0" />
    <PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.8" />

2) Replace program.cs with this (this is the entire app):

    using Microsoft.AspNetCore.Builder;
    var builder = WebApplication.CreateBuilder(args);
    var app = builder.Build();
    app.MapGet("/", () => "Hello World!");
    app.Run();

Voila. A web server.

Can you build with just these package references? because I did exactly did a while ago and I could not.

This is almost the correct answer, https://news.ycombinator.com/item?id=30667145 is more accurate.

Here you go:

  <Project Sdk="Microsoft.NET.Sdk">
  
    <PropertyGroup>
      <TargetFramework>net6.0</TargetFramework>
      <Nullable>enable</Nullable>
      <ImplicitUsings>enable</ImplicitUsings>
      <OutputType>exe</OutputType>
    </PropertyGroup>
  
    <ItemGroup>
      <FrameworkReference Include="Microsoft.AspNetCore.App" />
    </ItemGroup>
  
  </Project>

Just create an empty ASP.NET Core project, change the SDK, add a FrameworkReference and a OutputType.

Read the console args and configure the web app with a port as desired.

Thanks! This is what I was looking for (not anymore, sorry switched to a different language/ecosystem for this project).

This still begs the question, or my original point still stands—why framework reference vs. nuget reference? I'm sure there's a perfectly rationale explanation, but this in itself, having at least two "official" ways of managing dependencies (framework reference vs. package reference on nuget), it's kind of a "code smell" imo.

Because ASP.NET Core is a framework that is installed with .NET. It isn’t a set of Nuget packages.

Why? .NET Core 1.x tried making everything a Nuget package and it was a disaster. ASP.NET is big which meant a huge number of dependencies, easy to create conflicts, long restore and build times.

It was much better to just include ASP.NET Core in the box with .NET and simplify it down to a single reference. And most people use the web SDK which does it for you so they don't even need that.

What about the option to just make everything asp.net one single nuget package? And how come other ecosystems/languages don't have this issue? What's the difference?

The other question is, why isn't what you posted the default, but defaulting to this <Project Sdk=...>? To me, it's a lot more intuitive, signaling that each project can have multiple framework references, vs. just one SDK attribute.

You're searching for ways to make things more difficult than they need to be.

Make the simple easy. Make the complex possible.

Disagree here. This is where I would quote the principles of two other language.

From Python: have one way of doing things

From Go: explicit is bette than implicit.

Is Sdk=... is just a short cut to pull in a handful of framework references? Or are there actually more things happening under the hood?

https://news.ycombinator.com/item?id=30673710

sigh I can't help it...

Python really isn't a great choice for making your case. "Have one obvious way of doing things" has become an ironic meme since forever, and toolchaining and dependency management has traditionally been a hot mess (yes, even with pip and virtualenv, just not the total clusterfudge it was before. And don't get me started on pipenv.), and only gotten better recently with 3rd party tools like poetry, or even conda.

>What about the option to just make everything asp.net one single nuget package? And how come other ecosystems/languages don't have this issue? What's the difference?

It's no different to e.g. create-react-app vs npm install react.

You can set the ports via the kestrel options: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/se...

> I have not had any luck to pull all the right nuget dependencies to do that so far.

thats because they are not directly on nuget. at least not in the included one, you need a framework reference, since for packaging reasons they have a runtime and a "web runtime" (kinda like that)

https://docs.microsoft.com/de-de/aspnet/core/fundamentals/ta...

ASP.NET Core apps are actually straightforward console applications. In fact most of the application types you’ll run on .net core are configured in a main method in program.cs. The answer to your specific questions about mixing different services in one app will be some combination of the following links.

https://khalidabuhakmeh.com/hosting-two-aspnet-core-apps-in-...

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/ho...

That’s the problem. You have to read multiple articles to achieve simple things.

Well how would you do it if another platform if you are a beginner. Because I am a beginner in Rust, this is the process I would use:

1. search Google, read few articles or posts

2. write code

3. make it compile

4. encounter bugs

5. research the bugs on yet other articles or posts

6. fix the bugs

7. ???

8. profit!

It's not about if you should or should not search. It's about how often you have to do that, and how easy it is to search for what you want. It boils down to how much anti pattern a framework/ecosystem has. In this case, their default template caused me to search "dotnet core project multiple SDK", which yielded nothing, and is actually a completely wrong track.

The answer the asp.net team shared below, was instead of using the SDK attribute, use a completely different thing called FrameworkReference. Which can completely replace this SDK attribute, it seems.

Hence my question to them below was, why is framework reference not the default? Especially since it does lead to better searchability, and the template shows that one could have multiple of these per project, intuitively.

The original poster is going slightly off the beaten path and therefore has to manually compose three or four different concepts together to come to the right solution vs relying on the out of the box experience.

I, and a lot of other devs, would be able to solve this particular problem without looking up the docs but I can’t assume any knowledge on the poster’s behalf so I posted the links to the docs about the building blocks and an article showing one possible way of composing them.

The same exact problem as posed by the poster was thought of by the dotnet/aspnet teams and the pieces (apis/docs/samples) are all there, just not the default.

> I, and a lot of other devs, would be able to solve this particular problem without looking up the docs

Look through the rest of this comment thread and see how many failed attempts at solving this problem there were before two high profile members of the ASP.NET team came in (JamesNK and davidfowl).

It's not about looking up or not looking up. The criticism here is that the way the framework is laid out is not intuitive enough. It's very "different" from the rest of the industry (in this case, there are 3 potential ways of pulling in dependencies for ASP.NET). This requires a lot of time investment for its users to solve these slight one-off issues.

My question to them below was why isn't what they shared here the default. If they had done that, it would be intuitive to know that one can add other "FrameworkReferences" in a project, or know what to search for. Instead, the default is "each project can only target one SDK".

JamesNK also answered this. We started off with just nuget packages, it was beautiful for about 5 minutes until we ended up with ~300 in the default project. Then physics kicked in, slower build times, slower compilation times, slower intellisense. All of those old O(N/N^2) algorithms started to show up on profiles and we had to do something about it. That was just the practical performance side of things, then there was the customer confusion around which packages had which APIs. We offered a .NET buffet that customers hated. On top of that, the versioning got nuts. Each of those packages could in theory version independently, who is going to test all of those combinations of things? What happens when you need tot publish ~300 + packages to your server deployment because you didn't want to "install the framework"? You'd be complaining that they were too many assemblies (which people did). Amplify that by deploying these binaries to the same physical machine when running multiple .NET Core applications there (very popular for IIS setups). We pre-JIT (ready to run) the core libraries and ASP.NET to improve startup time, that makes the assemblies bigger (as they contain both native code and IL), this makes your applications bigger by default.

We got LOTS of feedback that this was all really terrible and we listened.

We did this from .NET Core's inception to .NET Core 3.0 when we pulled the plug. We set things up so that the base install/platform/framework was not composed of packages but framework references. We merged several assemblies together to get rid of some of the unnecessary layering. We invented shared frameworks so that people could install the framework once and run lots of applications using shared libraries so that:

- Customers have faster publish times as you only need to deploy your application bits, the framework can be pre-installed - Loading the same dll on disk into multiple processes allows for more virtual memory sharing (a handy performance optimization) - We could version the set (.NET, ASP.NET Core) as a coherent unit - We could pre-JIT (R2R) the built in stuff so it's installed on the machine once and usable by many apps.

As for being intuitive, the default experience is to use the Web SDK. I didn't even get into SDKs but it does more than default the framework reference. It also exposes capabilities that tooling use to light up behaviors in the build and in the IDE.

PS: This stuff is harder than it looks on the surface and we spend lots of time and take lots of care designing it (making the typical tradeoffs you make when doing software engineering).

@David, thanks, and completely aligned on why we don't use nuget packages anymore.

> As for being intuitive, the default experience is to use the Web SDK. I didn't even get into SDKs but it does more than default the framework reference. It also exposes capabilities that tooling use to light up behaviors in the build and in the IDE.

It is these "does more than default framework reference" are precisely the things in discussion here. All of these hidden functionalities and dependencies are like a black box. What's the difference between what James shared here and the default Sdk=...Web, then? It's the lack of uniformity, where "ASP.NET is a first class citizen" rather than just another piece of the ecosystem that is a turn off.

Compared to other ecosystems, for example: Go, Rust, even Java for example, where everything is just code that one can pull in, and the customization is in the code, not the runtime/JVM.

That is exactly the thing. I *do not* want to have the Sdk=...Web/Worker. Imagine this scenario, you started a new project with the Sdk targeting Worker. Then you need that binary to also target web. What do you do?

- If you switch the project to Sdk=...Web, you won't have the dependencies to build the worker services.

- If you keep it as Sdk=...Worker, you won't have the dependencies to build asp.net

But those are just sets of convenient defaults? You could just start with the default sdk and add the imports/targets yourself (or in practice: let the IDE do it for you.)

And

>- If you switch the project to Sdk=...Web, you won't have the dependencies to build the worker services.

Yes you will, since the worker sdk is simply a subset of the web sdk.

> You could just start with the default sdk and add the imports/targets yourself (or in practice: let the IDE do it for you.)

That's what I have been calling out. I have not had much luck in pulling in the right dependencies needed. Could not find any documentation on it. Everything relies on that Sdk=...Web thing on the official documentation.

If you’re just looking to be unblocked, use the Web SDK because you’re building and running combined web + hosted services [1]. The section linked shows the precise difference between the Web and Worker SDKs for hosted services.

If you’re looking for docs on what all the SDKs are/do, and their source code, start here [2].

If you’re looking to just add the asp net core packages/apis to your basic sdk/console project, here [3]. But note that your app build/publish probably won’t work 100% because msbuild won’t be configured to do so.

If you want to fix that manually (i.e do what the Web SDK does automatically), You can use the Web SDK props file as a starting point [4]. (Linked to in [2])

It seems well documented to me, but you’re welcome to propose new docs to the aspnet docs team. They’re very responsive [5].

[1] https://docs.microsoft.com/en-us/aspnet/core/fundamentals/ho...

[2] https://docs.microsoft.com/en-us/dotnet/core/project-sdk/ove...

[3] https://docs.microsoft.com/en-us/aspnet/core/fundamentals/ta...

[4] https://github.com/dotnet/sdk/blob/ee98c8c25188195fd4f8a145b...

[5] https://github.com/dotnet/AspNetCore.Docs

Well, not much to add to what jkulubya said, but: Just use Web, then - that's what it's for and it just worksTM.

We have almost your exact scenario in production - a (Quartz.NET-based) service for background/scheduled jobs, with a web dashboard and a healthcheck API, all from a single console executable without external dependencies. And it was super straightforward to implement.

I agree with your sentiment. It's probably a legacy left-over from the .NET Framework days where you had to choose upfront what app you are going to build and where it was going to run and then you had the full IDE experience configured. .NET team has made a lot of right steps to fix this, however they haven't fixed MSBuild. As a long-term .NET developer (not anymore sadly, but still find it the best development experience) I always found MSBuild confusing but it has only become harder to learn because it has too much going on under the hood.

So, if you want to do what you are saying, you should look into learning more MSBuild because .NET certainly allows you to do that without workarounds if you have your build configured correctly.

I think C# is incredibly close to Java in this regard.

Not in the specifics of e.g. your problem, but the big "solutions" tend to be very enterprise solution-y, single-goal orientated. Spring in JAVA (also J2EE) had a similar sort of issue, where everything worked as long as you weren't veering off of the beaten path, but things got wildly over-complicated as soon as you dared to stray...

The claims made in this article also sound a lot like what Java folk would say back when their platform wasn't yet "cool" - they are nevertheless somewhat successful today, so maybe they have a point?

Regardless, you can absolutely do web dev from a simple C# console app, I don't know there are pre-build server frameworks for doing so. If you don't like MS's offering, tough.

They did that around .NET Core 1.x, but it became unwieldy (trust me it was a complete mess) and they switched it for the framework references, and they switched that for the SDK included dependencies iirc.

The .NET frameworks (blazor, etc) are too complicated. Peak FizzBuzzEnterpriseEdition there.

The interop layer than you have to go through to do a lot of stuff is actually quite tame. It just needs more time on Linux.

>The interop layer than you have to go through to do a lot of stuff is actually quite tame. It just needs more time on Linux.

What do you mean?

I have software on prod on Linux for years and the only problem I had was lack of some fonts installed that made some problem when it comes to pdf generation

Binding to C/C++ libraries or other system libraries is not something that's well documented, officially. On Windows there's a lot of 3rd party effort that is easily searchable. But for a long time the interop layer was not (and still may not be?) working on Linux.

The first iterations of .NET were just for webapps. You could only work with and call .NET code, the only functions provided were basic IO and network.

Hmm, I've been using .NET since beta 1 in 2000. Maybe you had access to earlier bits? It was never just about webapps. In fact, Windows Forms was meant as a more sane MFC if anything.

Interop with native code was always very easy. From PInvoke to managed C++ there were a lot of ways to do it with ease. Things have changed but I still think this is one area where .NET has great support.

They probably mean .NET Core, it's somewhat true in that case.

Native interop in .NET has always been via what they call "P/Invoke". On .NET Core, P/Invoke is cross-platform and you can also call .so/.dylib functions on Linux/MacOS just like you could always call .dll functions on Windows on .NET Framework before we had .NET Core.

I'm curious to know what you needed to do with native libraries. I've been programming with .NET around 20 yrs and find it fairly rare that I need to use P/Invoke... But I'm sure it depends on what you're building.

I maintain a thingy written in C# that does cool things with keyboard backlights on System76 machines in Linux. Like make the left-third respond to CPU usage, right third blink when you have unread notifications, etc. The biggest one was turning off the keyboard when the screen blanked[1]. Almost all of the fun stuff requires native interop.

1: https://withinboredom.info/blog/2019/11/26/detecting-if-a-sc...

You end up using P/Invoke any time you need to control hardware. In the last few months I needed to use P/Invoke to control cameras, motors, and compute FFTs with the GPU.

You need to use them if you need to control raw GDI objects like bitmaps.

That's the normal Java culture, which is not surprising given that MS created .NET as a competitor to Java.

> The .NET frameworks (blazor, etc) are too complicated. Peak FizzBuzzEnterpriseEdition there.

I dunno, Blazor feels like the one ASP framework that makes sense. MVC, Web Apps, Web Forms all feel impenetrable to me.

Blazor IMV is more sane than React. It is an SPA that is structured around routing and pages, which happen to have component hierarchies in them.

React is the other way around. Routing in React seems to be an afterthought. And I hate it with a passion.

Page based way of thinking (or "screens" if you will) is a better way to do web dev.

Also, the Dependency Injection system is extremely productive. State management in Blazor is very easy and a breeze to use.

If not for the intricacies of hosting models, and a slightly large default build size for the full WASM client mode, Blazor would have replaced React / Angular / Vue by now.

> Dependency Injection system is extremely productive

Sure, but there is a downside to it. You want to add a feature to the class that uses DI? Great, just add an injected object to the constructor. Except now a 100 unit tests broke because you changed the constructor. A 10 minute functionality change turns into a massive cut and paste operation in your Tests project.

Sorry, if tests are not adaptable to changing code, why are they called tests?

I thought tesring was to check software,not be a constraint on software development.

Also, I think using DI in the test process itself will mitigate the issue.

Some tests are not adaptable to changing code because of the way MS uses DI. A lot of DI is done by adding new parameters to the constructor.

It’s the same with async. Needing an async function somewhere can result in a huge cascade of changes.

Constructor inject is generally a positive here, though, as the compiler will tell you where you need to add the new dependency. If you find that you have to add the dependency in lots of places just to satisfy the compiler, not because the functionality actually requires the dependency, that's usually a sign the class should be broken up into classes with more clearly defined responsibilities.

“If you find that you have to add the dependency in lots of places just to satisfy the compiler, not because the functionality actually requires the dependency, that's usually a sign the class should be broken up into classes with more clearly defined responsibilities.”

Sure in theory this is correct but you can’t always anticipate future needs. The class may still have very clearly defined responsibility but it just needs another piece of information that you can get only with DI. I feel this over dependence on DI in .NET forces you to design around the framework and not around what makes sense.

I solved this with a test helper method that creates a fully mocked instance and returns a struct with the mocked instance and all the mocks that it consumes. Unit test setup starts by getting a new instance and overriding the mocks that it cares about. Now constructor breakage is isolated to fixing the default mocks in the helper method.

Maybe I should write this up somewhere.

I did that too and it should be the default. Constructor injection is a bad pattern.

What do you mean by "constructor injection"?

In .NET a lot of DI is done by adding another interface to the constructor. So if you need some service way down the stack you add it to the constructor. This then in turn can require adding this dependency to all the tests that use this service.

My comment describes a way to organize unit tests to work around this issue.

Comments like these really amaze me. What sort of competent editor cannot handle such simple refactorings?

Maybe but in Blazor you have the choice of Property or Constructor DI. This choice is in all the major DI container libraries I've worked with in .NET, around a dozen over the years.

>Maybe I should write this up somewhere.

Please do, as it sounds interesting.

I have seen that too. They do way too much DI.

We use a tool called AutoFixture to automatically generate objects being tested. It will automatically mock constructor dependencies, so a change like you described doesn't require any test changes unless the new mock requires some setup for the test to pass.

Compared to JS SPAs such as React/Vue/Angular, Blazor obviates a huge amount of toolchain complexity, multi-language and transpilation impedance, and jank of leaky abstractions building a component model on top of Javascript.

Having worked with a mix of these, I found Blazor to be clearly much simpler, approaching though not quite reaching the simplest possible implementation for a component based UI.

I think it's probably more a matter of what you are used to than inherent complexity. The things you are familiar with seem 'easy' and the unknown seems 'hard'.

Stick with it, it really pays dividends when you get good at it!

I can definitely see the appeal of a simplified .NET lacking a lot of the baggage it has from 21 years. .NET core was an attempt at stripping a lot of stuff out but over time they've had to add stuff back because it turns out telling developers they have to rewrite all their code (or give up on doing things at all) is a bad idea.

Node benefits from being a newer ecosystem (~2009) that started out with simpler goals, so it accumulated cruft more slowly. Ecosystems like node also deploy breaking changes more often - .NET 1.0 software can still be run on a modern Windows machine using the latest regular framework, though as of 5.0 they finally decided to kill existing .NET code (the old framework still works, 5.0 and later just use a separate one).

I'm personally still writing and maintaining .NET 4.x code and some of it is working stuff I wrote in ~2005 and it has been serving me well that whole time. I have extensive experience with C++, JS, Python etc and C# is still my first choice when it comes time to solve problems (Python is a somewhat distant but still respectable 2nd place - the REPL is great.)

From time to time I've been able to solve difficult problems with built-in .NET tooling - I wrote a custom compiler for a DSL from scratch entirely using built-in 4.x features and it can do hot reloading, generate debug information, allow me to set breakpoints in visual studio, etc. I simply can't get this anywhere else.

Reply on news.ycombinator.com