The art of simplicity

As we see security as a top priority, for every new application that we put in production, we let it be penetration tested first. One remark we got with the last pen test was about the information our servers inadvertently revealed through HTTP response headers. Although I think it is not the biggest possible security issue, exposing details about their technology stack through headers like Server and X-Powered-By , gives some reconnaissance information to potential attackers for free. n this post, we'll explore why you should hide these headers and demonstrate several methods to remove or customize them in ASP.NET Core applications. Generated with Bing Image Creator Why hide server headers? Server identification headers might seem harmless, but they can pose security risks: Information Disclosure : Headers like Server: Kestrel or X-Powered-By: ASP.NET immediately tell attackers what technology stack you're using, making it easier for them to target known vulnerabili...

If you are not using custom instructions with GitHub Copilot, than this post will maybe help to finally get started. Writing your own set of custom instructions can be a challenge and although multiple examples are available , it still can be a challenge coming up with the right set of instructions. But what if we can let GitHub Copilot create the instructions for us? Let’s find out how… Why custom instructions? Custom instructions in GitHub Copilot can significantly improve your coding experience and productivity in several key ways: Code quality and consistency Custom instructions help ensure Copilot generates code that follows your specific style guidelines, naming conventions, and architectural patterns. Instead of getting generic suggestions, you'll receive code that matches your project's existing standards and practices. C ontext awareness By providing instructions about your tech stack, frameworks, and project structure, Copilot can make more relevant s...

After making a small change to an ASP.NET core application, I got the following runtime error: System.InvalidOperationException: 'Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.' Here is the code that caused the error: Let's explore why this happens, when it occurs, and most importantly, how to fix it properly. Why does this exception occur? Starting with ASP.NET Core 3.0, Microsoft made a significant architectural change: synchronous I/O operations are disabled by default on the server. This decision was made to improve application performance and prevent thread pool starvation. In traditional synchronous I/O operations, threads are blocked while waiting for data to be read or written. In a web server handling hundreds or thousands of concurrent requests, this can quickly exhaust the thread pool, leading to: Poor scalability Increased response times Potential deadlocks Resource exhaustion As...

I’m currently working on 'Aspirifying' (don't know if that is a correct verb' multiple applications. After enabling Aspire for one application, the Aspire Host failed to launch with the following error message: Aspire.Hosting.DistributedApplicationException: 'Failed to get effective launch profile for project resource ' '. There is malformed JSON in the project's launch settings file at 'C:\projects\<ProjectName> \Properties\launchSettings.json'.' The inner exception gave some extra details: JsonException: The JSON value could not be converted to System.Nullable`1[System.Boolean]. Path: $.profiles[‘<ProjectName>.API'].dotnetRunMessages | LineNumber: 21 | BytePositionInLine: 33. I opened up the mentioned launchSettings.json file: The culprit is the dotnetRunMessages setting where instead of a 'true' string, we should specify a boolean value: No idea where this setting is coming from, but I certainly never ...

When upgrading an ASP.NET Core application to .NET 9, I encountered the following error in my integration tests: System.InvalidOperationException: No application configured. Please specify an application via IWebHostBuilder.UseStartup, IWebHostBuilder.Configure, or specifying the startup assembly via StartupAssemblyKey in the web host configuration. I had updated my custom TestHost to switch from using a Startup.cs file to directly using the Program.cs file and the Minimal API approach. Therefore I added a partial Program.cs and updated the WebApplicationFactory class to use the Program.cs instead (more about this change in this post ). Here is the updated code: But this code didn’t work and resulted in the error message above. While giving the code a second look, I noticed that I was still referring to the Startup.cs that I didn't remove yet. I updated the code to use my Program.cs file instead: Doing that resulted in another error: A public method named ...

If you're like most developers, you probably don't get excited about upgrading legacy applications (at least I don't) . The process is traditionally time-consuming, risky, and filled with tedious manual work. But Microsoft has recently released something that could change that experience entirely: the GitHub Copilot app modernization – Upgrade for .NET extension , now in public preview. What is it? The sales pitch is that is more than just an upgrade tool—it's an AI-powered upgrade companion that leverages GitHub Copilot and Visual Studio's new Agent Mode to intelligently modernize your .NET applications. Think of it as having an experienced developer sitting beside you, understanding your codebase, planning the upgrade path, and making changes while keeping you in the loop when critical decisions need to be made. It promises an intelligent approach to the upgrade process using the following techniques: Dependency-aware planning Instead of blindly upgradi...