My Journey with .NET — From Framework 4.6 to .NET 10+
All articles
.NET.NET FrameworkEntity FrameworkSQL Server

My Journey with .NET — From Framework 4.6 to .NET 10+

June 29, 20269 min read

From .NET Framework 4.6 to .NET 10, I have spent years working with Microsoft's ecosystem across internships, professional projects, and large-scale enterprise systems. This is not a tutorial — it is a personal account of what it actually feels like to grow with a platform that keeps getting better every single year.

Where It All Started — A Final Year Project and .NET Framework 4.6

My first encounter with .NET was during my final year university project, what we call a Projet de Fin d'Études (PFE). I had to deliver a real, functional application for a charity organization — a donation management system.

The backoffice covered everything: donors, donations, statistics, events, spending tracking, and more. The frontoffice was the public-facing website representing the organization. It was a full product, not a school exercise.

My professor recommended .NET Framework with SQL Server, and at the time I had no experience with either. So I did what every developer does when starting from scratch — I spent weeks watching tutorials, reading documentation, and building small experiments before touching the real project.

What surprised me the most was ADO.NET. You could connect your application to the database, select your entities, and generate CRUD views automatically. The scaffolding would produce a working list view that fetched and displayed data in a table right out of the box. At the time, that felt like magic.

I built on top of that scaffolding — customized the styling, wrote business logic, and learned Razor, .NET's template engine for server-side HTML rendering. Razor felt natural. It mixed C# with HTML in a way that was clean and readable once you understood the syntax.

By the end of the project, I had delivered a fully functional application. I liked the combination: .NET Framework for the backend, SQL Server for the database, Visual Studio as the IDE, and SSMS for database management. Everything worked together seamlessly, and I could feel that this ecosystem was built with consistency in mind.

A Brief Detour with Spring Boot

After graduating, my first professional role involved Spring Boot and Java. I worked with REST APIs, Hibernate for ORM, the code-first approach, and Maven for dependency management. It was a valid experience, but it was short.

Coming from .NET's tightly integrated ecosystem, Spring Boot felt more fragmented. Not bad — just different. The Java ecosystem requires you to assemble more pieces yourself. I respected it, but I knew where I wanted to be.

My Professional Journey with .NET Begins — 2019

Shortly after, I joined a project that would define the next chapter of my career. We were building an e-commerce and services platform from scratch. It had three distinct parts:

  • An e-commerce section for selling physical products
  • A booking system for training sessions
  • A digital services section for design work (ads, flyers, branding) and digital marketing

It was an MVC application using .NET Framework, Razor as the template engine, ADO.NET for database access, and SQL Server. My previous experience with .NET gave me a head start, and within a couple of months, the full application was delivered.

For the first time, I also handled deployment. I used Web Deploy — Microsoft's tool for publishing .NET applications directly to IIS on a Windows Server. It was my first hands-on experience with taking a .NET application from development to production, and despite some initial friction, it worked reliably once configured correctly.

Moving to .NET Core — Feeling the Difference

I was already aware of .NET Framework's limitations: Windows-only, not container-friendly, heavier runtime. Microsoft knew this too, which is why they introduced .NET Core.

The moment I started working with .NET Core, the difference was immediate. The framework felt lighter, faster, and genuinely cross-platform. Running a .NET application on Linux, building Docker images, deploying to cloud environments — all of this became natural and straightforward.

I worked with multiple versions of .NET Core, from the early versions through to the modern annual releases. Each version brought meaningful improvements: better performance, improved Minimal APIs, cleaner dependency injection, enhanced Entity Framework capabilities, and tighter cloud integration — particularly with Azure.

Microsoft made deploying .NET Core applications to Azure almost effortless. With built-in tooling inside Visual Studio, you could publish directly to Azure App Service or configure CI/CD pipelines without leaving the IDE.

Entity Framework and the Database-First Approach

One of the features I relied on heavily in professional projects was Entity Framework with the database-first (scaffold) approach. When working with existing databases or legacy systems, this workflow is incredibly efficient.

You point EF Core at your database, specify the tables you want, and it generates the entity classes and DbContext for you. The database becomes the single source of truth, and your application code stays in sync with the schema.

dotnet ef dbcontext scaffold "YourConnectionString" Microsoft.EntityFrameworkCore.SqlServer \
  --output-dir Entities \
  --context AppDbContext \
  --tables Orders Products Customers

I also worked on projects that combined EF Core with stored procedures — particularly when integrating with legacy platforms where the business logic lived in the database. EF handles this well. You can call stored procedures directly through the DbContext while still using all of EF's query capabilities for everything else.

What I genuinely appreciate about EF Core is how it models relationships, manages migrations, and supports multiple DbContexts within the same application. That last point is more useful than it sounds — in large modular systems, having separate contexts per bounded domain keeps things clean and maintainable.

SQL Server, SSMS, and Visual Studio — A Consistent Ecosystem

One of .NET's biggest advantages is that the entire toolchain comes from a single publisher. SQL Server, SSMS, Entity Framework, Visual Studio, and Azure are all Microsoft products. They are designed to work together, and they do.

SQL Server 2022 brought substantial improvements — better performance, improved availability features, and enhanced Azure integration. SSMS continues to evolve as a database management tool, and Visual Studio remains one of the most capable IDEs in the industry: integrated testing UI, Git management, database connections, live debugging, refactoring tools, and profiling — all in one place.

When the entire stack comes from the same ecosystem, you spend less time troubleshooting compatibility issues and more time building.

Large-Scale SaaS Systems — .NET 9 and .NET 10

The most complex work I have done with .NET involves SaaS multi-tenant platforms built with .NET 9 and .NET 10. These are not small applications. We are talking about 30+ interconnected services within a single solution, each one a standalone application with its own architecture.

The architectural decisions at this scale matter enormously. Here is what we applied:

  • Clean Architecture per service — separating domain, application, infrastructure, and presentation layers
  • Vertical Slice Architecture — organizing code by feature rather than by layer, so each feature is self-contained
  • Multi-tenancy — a centralized tenancy system that routes requests and isolates data across tenants
  • Shared libraries — reusable packages for common concerns: authentication, logging, response formatting, validation
  • Centralized configuration — a single source of truth for settings shared across services
  • Reusable base controllers — standardized API responses and error handling across all services
  • Semantic versioning with Git — a strict branching strategy with documented workflows for teams

On the infrastructure side:

  • Docker for containerization — every service runs in its own container
  • GitLab CI/CD pipelines — automated build, test, and deployment workflows
  • SonarQube — static code analysis integrated into every pipeline
  • Unit and integration tests — enforced at the pipeline level before any merge

The scale of these systems is something that changes how you think about software. You stop thinking about individual features and start thinking about how services communicate, how failures propagate, how tenants are isolated, and how teams can work in parallel without breaking each other.

.NET's strong typing, compiled performance, and mature ecosystem make it genuinely suited for this kind of complexity.

.NET vs Node.js — Two Different Philosophies

Developers sometimes ask me whether they should choose .NET or Node.js. My honest answer is that they represent two different philosophies, and both are valid depending on the context.

Node.js is fast to start with. The ecosystem is vast, the iteration speed is high, and it excels at I/O-heavy workloads. Microsoft recognized this and introduced Minimal APIs in .NET 6, which brings a similar lightweight, low-ceremony development experience to the .NET world when you need it.

But .NET's strength is different. It is enterprise by design:

  • Everything is strongly typed — errors surface at compile time, not in production
  • C# is a fast, compiled language with consistent performance characteristics
  • Object-oriented principles are first-class citizens
  • The official packages — EF Core, ASP.NET Core, SignalR, gRPC — are all built and maintained by Microsoft
  • The IDE integration in Visual Studio is unmatched
  • The ecosystem is coherent — SQL Server, Azure, Entity Framework, and the runtime all speak the same language

When you work on a system that needs to scale, that needs to be maintained by a team for years, that needs audit trails, compliance requirements, and bulletproof reliability — .NET is the platform that was built for exactly that.

Closing Thoughts

From .NET Framework 4.6 on a university charity project to .NET 10 powering SaaS platforms with dozens of interconnected services — it has been a long journey, and I have enjoyed every step of it.

What keeps me motivated is that .NET never stands still. Every annual release brings real, meaningful improvements. The team listens to the community, addresses performance bottlenecks, and continuously improves the developer experience.

If you are a developer considering .NET, my advice is simple: start. Build something. You will quickly understand why it is the backbone of enterprise software around the world — and why, despite working with many technologies over the years, I keep coming back to it.

C# is an excellent language. The ecosystem is coherent. The tooling is exceptional. And the community is larger and more welcoming than most people expect.

That is more than enough reason to choose it as your main backend platform.