ASP.NET Core VS CodeBehind Framework

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.

> I'm hoping this is satire.

Me too. It's one thing to accept single LFs in protocols that expect CRLF, but sending single LFs is a bridge to far in my opinion. I'm really surprised most of the other replies to your comment currently seem to unironically support not complying with well-established protocol specifications under the misguided notion that it will somehow make things "simpler" or "easier" for developers.

I work on Kestrel which is an HTTP server for ASP.NET Core. Kestrel didn't support LF without a CR in HTTP/1.1 headers [until .NET 7](https://github.com/dotnet/aspnetcore/pull/43202). Thankfully, I'm unaware of any widely used HTTP client that even supports sending HTTP/1.1 requests without CRLF header endings, but we did eventually get reports of custom clients that used only LFs to terminate headers.

I admit that we should have recognized a single LF as a line terminator instead of just CRLF from the beginning like the spec suggests, but people using just LF instead of CRLF in their custom clients certainly did not make things any easier or simpler for me as an HTTP server developer. Initially, we wanted to be as strict as possible when parsing request headers to avoid possible HTTP request smuggling attacks. I don't think allowing LF termination really allows for smuggling, but it is something we had to consider.

I do not support even adding the option to terminate HTTP/1.1 request/response headers with single LFs in HttpClient/Kestrel. That's just asking for problems because it's so uncommon. There are clients and servers out there that will reject headers with single LFs while they all support CRLF. And if HTTP/1.1 is still being used in 2050 (which seems like a safe bet), I guarantee most clients and servers will still use CRLF header endings. Having multiple ways to represent the exact same thing does not make a protocol simpler or easier.

At Elanat, we will provide WebForms Core technology to all web-based programming languages. Of course, there are a lot of programming languages, some of which are obsolete, some of which are obscure, and some of which are not used on the web, so our effort is to support Webforms Core technology in more than 99% of programming languages ​​​​that are also used on the web.

Good news for Java developers: You can now experience WebForms Core technology in Java. Elanat has update the WebForms class for Java with the latest version of WebFormsJS, 1.6. The WebForms class on the server and the WebFormsJS library on the client constitute the WebForms Core technology.

Repository link: https://github.com/elanatframework/Code_behind

WebForms Core is a high-level technology for manipulating HTML tags on the server, introduced by Elanat in 2024. It works both online and offline without requiring repeated requests to the server. With WebForms Core, there is no need to develop front-end (use front-end frameworks or write JavaScript code on the client).

In 2024, Elanat gave a new meaning to web development by introducing WebForms Core. WebForms Core technology allows you to manage HTML tags from the server. This technology simplifies the complex process of web development. In WebForms Core technology, the server load is low and is similar to JSON responses in front-end frameworks. The server response is just a small command in INI format that is sent to the client, which results in an update of the HTML page. This technology enables users to interact with other parts of the application while waiting for the server response.

CodeBehind on GitHub: https://github.com/elanatframework/Code_behind

In 2023, a Back-End framework based on .NET version 7 called CodeBehind was created by Elanat. About a year later, Elanat created a revolutionary technology called WebForms Core and added it to the core of the CodeBehind framework. Now the CodeBehind framework is a Full-Stack framework that manages both the Back-End and the Front-End together.

Microsoft has not yet added WebForms to .NET Core and it seems that it has no intention of doing so, but Elanat offers a revolutionary technology called WebForms Core that allows you to manage HTML DOMs from the server.

WebForms Core technology is a new feature in the CodeBehind framework. By using WebForms Core, all HTML DOMs are controlled on the server and there is no need to develop the front (scripting on the client side). In this technology, server only generates commands in INI format and these commands are rendered on the client side; therefore, there is no pressure on the server.