Aram Tchekrekjian

Aram TchekrekjianAug 21, 2026

𝟭𝟮 𝗔𝘀𝘆𝗻𝗰/𝗔𝘄𝗮𝗶𝘁 𝗠𝗶𝘀𝘁𝗮𝗸𝗲𝘀 𝗶𝗻 𝗖# ⚡ Async/await makes C# applications more scalable. But using it incorrectly can do the exact opposite. Here are 12 async/await mistakes every .NET developer should avoid: 1. Blocking with .Result or .Wait() Blocks threads and can hurt scalability. 2. Using async void outside event handlers The caller cannot await it or easily handle exceptions. 3. Wrapping I/O operations in Task.Run() True async I/O already works without blocking a thread. 4. Awaiting independent tasks sequentially Run them concurrently with Task.WhenAll() when appropriate. 5. Ignoring CancellationToken Give callers a way to stop unnecessary work. 6. Creating unbounded concurrent tasks You can overwhelm APIs, databases, connection pools, and memory. 7. Forgetting to await a Task Execution continues early and exceptions may go unnoticed. 8. Using Task.Run() unnecessarily in ASP.NET Core It consumes another ThreadPool thread without making I/O work more scalable. 9. Using async when nothing is asynchronous Don't add async just for the sake of it. 10. Ignoring fire and forget exceptions Always make sure failures are observed and handled. 11. Holding locks across await calls Avoid keeping synchronization resources locked while awaiting work. 12. Using Task.Delay() for background scheduling Use BackgroundService or a proper job scheduler for reliable jobs. Async/await is not about making code run faster. It is about avoiding blocked threads while waiting for asynchronous operations. Use it intentionally. Any more mistakes you've seen? --------------------- ♻️ Repost if you think this is useful 📌 Save this post, one day you might need it ➕ Follow me ( Aram Tchekrekjian ) to improve your .NET skills 🔔 Turn on the notifications 📬 Join my free newsletters for .NET Tutorials: https://lnkd.in/eemzqhHJ

Aram TchekrekjianAug 19, 2026

𝗧𝗼𝗽 𝟭𝟯 𝗔𝗦𝗣.𝗡𝗘𝗧 𝗖𝗼𝗿𝗲 𝗟𝗶𝗯𝗿𝗮𝗿𝗶𝗲𝘀 𝗘𝘃𝗲𝗿𝘆 .𝗡𝗘𝗧 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝗦𝗵𝗼𝘂𝗹𝗱 𝗞𝗻𝗼𝘄 ASP .NET Core gives you a strong foundation. But the right libraries can make your applications easier to build, test, observe, integrate, and scale. Here are 13 libraries worth knowing: 1. EF Core Modern ORM for SQL databases, LINQ queries, migrations, and change tracking. 2. Serilog Structured logging with powerful sinks for Seq, Elasticsearch, files, consoles, and more. 3. FluentValidation Clean and expressive validation rules without filling your models with validation logic. 4. System.Text.Json High performance JSON serialization built directly into modern .NET. 5. OpenAPI Describe and expose your HTTP APIs using a standardized API specification. 6. Redis Distributed caching for improving performance and sharing cached data across application instances. 7. Refit Turn REST APIs into strongly typed C# interfaces with minimal boilerplate. 8. Hangfire Run background jobs, delayed tasks, recurring jobs, and retries with persistent storage. 9. Polly Handle transient failures using resilience strategies such as retry, timeout, circuit breaker, and fallback. 10. xUnit A popular testing framework for writing unit and integration tests in .NET. 11. NSubstitute Simple and readable mocking for isolating dependencies in your tests. 12. BenchmarkDotNet Measure code performance, memory allocations, throughput, and runtime behavior accurately. 13. SignalR Build real time applications with server to client communication over WebSockets and other transports. A solid ASP.NET Core stack could look like this: EF Core → Data Access Redis → Caching Serilog → Logging FluentValidation → Validation OpenAPI → API Documentation Refit → External APIs Polly → Resilience Hangfire → Background Jobs SignalR → Real Time xUnit + NSubstitute → Testing BenchmarkDotNet → Performance You probably don't need all 13 in every project. But knowing when and why to use each one can make a major difference in how you design production ready ASP.NET Core applications. Which library would you add to the list? --------------------- ♻️ Repost if you think this is useful 📌 Save this post, one day you might need it ➕ Follow me ( Aram Tchekrekjian ) to uplift your .NET and Architecture Skills 🔔 Turn on the notifications

Aram TchekrekjianAug 25, 2026

𝗔𝗦𝗣.𝗡𝗘𝗧 𝗖𝗼𝗿𝗲 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆: 𝟭𝟱 𝗥𝘂𝗹𝗲𝘀 𝗬𝗼𝘂 𝗦𝗵𝗼𝘂𝗹𝗱 𝗙𝗼𝗹𝗹𝗼𝘄 Security is not something you add after building the API. It should be part of how you design it from day one. Here are 15 practical security rules for ASP.NET Core APIs: 1. Enforce HTTPS and redirect all HTTP traffic. 2. Protect endpoints with `[Authorize]` and proper authentication. 3. Validate JWT issuer, audience, signature, and expiration. 4. Use roles, policies, claims, or custom authorization instead of hardcoded access rules. 5. Strictly validate every incoming request. 6. Use DTOs to prevent over-posting and unwanted data binding. 7. Configure CORS for trusted origins, headers, and methods only. 8. Never expose detailed exceptions or stack traces in production. 9. Apply rate limiting against brute-force attacks and API abuse. 10. Never log passwords, access tokens, secrets, or sensitive user data. 11. Add security headers such as HSTS and `X-Content-Type-Options`. 12. Keep NuGet dependencies updated and address known vulnerabilities. 13. Secure cookies with `HttpOnly`, `Secure`, and appropriate `SameSite` settings. 14. Remove unused endpoints, controllers, and unnecessary attack surface. 15. Enforce strong password policies when your application manages credentials. A secure ASP.NET Core API is not built with one security feature. It comes from applying multiple layers of protection across authentication, authorization, validation, transport, configuration, dependencies, and observability. Which of these rules do you see missed most often in production? --------------------- ♻️ Repost if you think this is useful 📌 Save this post, one day you might need it ➕ Follow me ( Aram Tchekrekjian ) to improve your .NET and Architecture skills 🔔 Turn on the notifications