sdk VS ASP.NET Core

I opened an issue since I couldn't find docs that indicate what they were working on to improve the start time, and they replied:

https://github.com/dotnet/sdk/issues/49197

It's not about being "cool"

It's about the motives

"it's open source"

"it now works on linux"

it all doesn't matter if they'll go after your ass if you dare build tooling with their debugger (jetbrains)

of when they want to remove a feature overnight to make it exclusive to visual studio windows

https://github.com/dotnet/sdk/issues/22247

it's this kind of things that makes it hard to recommend to people, and Microsoft can't be trusted

I hate to defend telemetry of all things but in this particular case the criticism is unfounded and lacks context:

https://dotnet.microsoft.com/en-us/platform/telemetry

https://learn.microsoft.com/en-us/dotnet/core/tools/telemetr...

https://github.com/dotnet/sdk/tree/main/src/Cli/dotnet/Telem...

In any case, Debian would use https://github.com/dotnet/source-build and dotnet/dotnet, and could easily include the argument or a patch for this. It’s unlikely to be an issue. My bet it was not in Debian because there was no one to take initiative or there was but that person has faced a backlash by people in Debian who are similar to vocal minority here that posts FUD because of their little personal crusade.

FWIW telemetry can be easily opted-out, which the SDK explicitly tells you about, and there is a page that has full list of the kind of data that is collected (usage metrics and tooling crash stack traces). You can also review the metrics yourself.

About: https://learn.microsoft.com/en-us/dotnet/core/tools/telemetr...

Collected statistics: https://dotnet.microsoft.com/en-us/platform/telemetry

Source code: https://github.com/dotnet/sdk/tree/main/src/Cli/dotnet/Telem...

In either case, many CIs simply have 'DOTNET_CLI_TELEMETRY_OPTOUT=' and call it a day.

They used to gather all command line arguments until they later decided that (oops!) it's "not acceptable per our privacy policies"[0] and they really shouldn't have been doing that. They have also had issues with anonymization not being implemented properly, the opt-out mechanism not working in some edge cases, forgetting to even tell users about the need to opt out, and who knows what else.

Also, monetary value is not the only reason you might want to keep information private.

[0] https://github.com/dotnet/sdk/issues/6145#issuecomment-22010...

[DllImport("libc")] private static extern uint geteuid(); public bool IsCurrentProcessElevated() { if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) { // https://github.com/dotnet/sdk/blob/v6.0.100/src/Cli/dotnet/Installer/Windows/WindowsUtils.cs#L38 using var identity = WindowsIdentity.GetCurrent(); var principal = new WindowsPrincipal(identity); return principal.IsInRole(WindowsBuiltInRole.Administrator); } // https://github.com/dotnet/maintenance-packages/blob/62823150914410d43a3fd9de246d882f2a21d5ef/src/Common/tests/TestUtilities/System/PlatformDetection.Unix.cs#L58 // 0 is the ID of the root user return geteuid() == 0; }

> There's definitely things they tried to improve on that... weren't really improvements. The way "assemblies" are matched in .NET is much more sophisticated- the goal there was to try to kill DLL hell. It evolved into the Global Assembly Cache, which is sort of the Windows Registry of DLLs. Not a huge fan of those bits.

The Global Assembly Cache did not make the jump to the modern .NET (Core). There was the thing called `dotnet store`, but it’s broken since .NET 6: https://github.com/dotnet/sdk/issues/24752

The assembly redirection hell has also been greatly reduced there.

I do the same.

I have a small write-up here: https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-wit...

You get end-to-end type safety (even better once you connect it to EF Core since you get it all ways to your DB).

With this setup with hot-reload (currently broken in .NET 8 [0]), productivity is really, really good. Like tRPC but with one of the most powerful ORMs out there right now.

[0] https://github.com/dotnet/sdk/issues/36918

Noticed an open issue just now.

You're thinking of https://github.com/dotnet/sdk/issues/22247

Libuv describes itself as a multi-platform support library with a focus on asynchronous I/O. It is widely used in many web servers (e.g., Kestrel) and runtimes such as Node.js and Python (via uvloop). As of Zig 0.14.0, there is no native async I/O, so you must work directly with threads or create your own async API using OS primitives like epoll or kqueue. In many cases, you would likely choose a cross-platform library rather than implementing your own async API. That’s where using libuv, libevent, or libxev (written in Zig) becomes useful.

UserStore.cs

Swashbuckle.AspNetCore is being removed in .NET9 (Is Swashbuckle is deprecated ?) “The ASP.NET Core team began shipping web API templates with a dependency on Swashbuckle in the .NET 5 timeframe. The decision allowed the team to provide built-in support for OpenAPI, a language-agnostic, platform-neutral representation of web-based APIs that contains everything needed to discover and interact with HTTP-based service endpoints. You may be more familiar with the name “Swagger” that refers to a set of tools for working with OpenAPI documents. The information in the OpenAPI document enables scenarios like client code generation, stubbing server code, creating documentation and dynamically producing a web-based UI to interactively test the API. It also is heavily used in artificial intelligence applications to provide prompts that describe the API for use by generative AI. Swashbuckle is a great project, and we appreciate the time and effort its owner and community contributors have put into it. The project is no longer actively maintained by its community owner. Issues have not been addressed or resolved, and there is not an official release for .NET 8. The ASP.NET Core team will provide a solution for this in the .NET 9 release. The plan is to remove the dependency on Swashbuckle.AspnetCore from the web API template and extend the capabilities introduced with Microsoft.AspNetCore.OpenApi to provide OpenAPI document generation.” For more details on the deprecation of Swashbuckle.AspNetCore, refer to this GitHub issue:

Recently, I experimented with PersistentComponentState, hoping to transfer state between the pre-rendering phase and the final rendering phase. My goal was to resolve the double loading issue while still benefiting from pre-rendering. However, I discovered that pre-rendering—even in .NET 9 (SDK 9.0.101)—behaves inconsistently. There also seems to be an unnecessary “page-loading” phase that wastes CPU and memory resources without achieving anything meaningful. I reported this issue on the .NET GitHub repository: Issue #59569.

GenHTTP has a strong focus on developer experience - from a new project created by a template to a fully functional Docker service in a couple of minutes. Projects are fully described in source code, lowering the learning curve compared to ASP.NET and making it a good choice for hobby projects.

As mentioned above, there is a built-in RateLimitingMiddleware in ASP.NET Core. Its basic usage is extensively covered in Microsoft Learn and community blogs, so allow me to skip it. There is not much inside: the midlleware basically does two things:

Note that Blazor has serious deployment problems since ~2021 [0] due to MS picking some idiotic packaging format defaults.

I.e. Let's make it look like a Windows executable! And go ahead and name it .dll! I'm sure no default firewall settings will have an issue with that.

So any wide Blazor app deployment also requires overriding the default packaging and adding obfuscation.

Supposedly that's experimentally fixed in NET 8... [1]

[0] https://github.com/dotnet/aspnetcore/issues/31048

[1] https://github.com/dotnet/aspnetcore/issues/36978#issuecomme... https://github.com/dotnet/runtime/issues/80807

My mid- and early senior developer years were intense. Due to a mix of reorgs and personal interests, I found myself on a new team every year or so. As a result, I had to learn new codebases in quick succession. They included .NET System.Xml, OData, Entity Framework, Entity Framework Designer, ASP.Net SignalR, ASP.Net Core, and the Alexa mobile app, and most of them were over one hundred thousand lines.

At Microsoft, I worked on a few high-profile open-source projects like Entity Framework or ASP.Net Core. As thousands of developers used our products, we received a decent number of bug reports. Unfortunately, we often couldn't understand what issue was being reported, how to reproduce it, and the expected behavior. Following up on these issues was painful. The back-and-forth took weeks. The "bugs" slipped from release to release while we were waiting for the details we requested. Eventually, we closed most of these bugs without resolution as it was hard to prioritize them over other issues we could immediately investigate and fix.