100 .NET Core Interview Questions & Answers
This covers the full ground a .NET Core interview loop tends to draw from — CLI and project mechanics, ASP.NET Core web fundamentals, EF Core and data access, testing, security, deployment, cloud/Kubernetes, design patterns, and where the platform is headed. Organized the way most interview question banks organize it, by topic, so jump to whichever section you need. Every answer is written to explain the reasoning, not just name-drop the term — with real code, a few diagrams, and a mock test at the end.
.NET Core Fundamentals
Q1. What is .NET Core and how does it differ from the .NET Framework?
.NET Core (renamed simply ".NET" from version 5 onward) is Microsoft's open-source, cross-platform rewrite of the .NET stack — runnable on Windows, Linux, and macOS, versioned and deployed side-by-side per application instead of one machine-wide install, and built from modular NuGet packages instead of one giant framework blob. .NET Framework, by contrast, is Windows-only, closed-source (until late in its life), ships one version per machine via Windows Update, and carries legacy technology — Web Forms, WCF services, System.Web — that .NET Core deliberately left behind in favor of leaner, faster equivalents (ASP.NET Core, gRPC/CoreWCF, Kestrel).
| .NET Framework | .NET Core / .NET 5+ | |
|---|---|---|
| Platform | Windows only | Windows, Linux, macOS |
| Source | Eventually open-sourced, Windows-centric | Open-source from day one (dotnet/runtime) |
| Deployment | One shared machine-wide install | Side-by-side per app; self-contained possible |
| Performance | Solid, but not the design priority | Rewritten CoreCLR + JIT/GC tuned for throughput |
| Web stack | Web Forms, WCF, System.Web | ASP.NET Core, Kestrel, minimal APIs, gRPC |
| Future | Maintenance mode — no new features | Active yearly release train |
Q2. Describe the cross-platform capabilities of .NET Core.
Cross-platform is a first-class design goal, not a porting afterthought: the same C#/F#/VB code, the same SDK, and the same dotnet CLI run identically on Windows, Linux, and macOS (x64 and ARM64). The runtime (CoreCLR), the base class library, and the JIT are all built to abstract over the OS, so a web API written and tested on Windows will run unmodified on a Linux container in production — which is exactly the deployment story most .NET Core apps use today: build once, ship a Linux container.
Q3. What are the main components of the .NET Core architecture?
Four pieces work together: CoreCLR is the runtime — the JIT compiler, the garbage collector, and the type system that actually executes your code. The Base Class Library (BCL) is the set of fundamental types (collections, I/O, string handling, LINQ) every app builds on. The SDK bundles the compilers (Roslyn for C#/VB, F# compiler), MSBuild, and the dotnet CLI used to create, build, and publish projects. And on top of all of that sit the application frameworks — ASP.NET Core for web, EF Core for data, WinForms/WPF/MAUI for clients — which are just NuGet packages, not baked into the runtime.
- CoreCLR — the runtime: JIT compiler, garbage collector, type loader
- BCL (Base Class Library) — System.* fundamentals: collections, I/O, LINQ, threading
- SDK — compilers, MSBuild, and the dotnet CLI (installed separately from the runtime)
- Application frameworks — ASP.NET Core, EF Core, WinForms/WPF/MAUI — layered on top as NuGet packages
Q4. Explain the .NET Core CLI and its primary functions.
The dotnet CLI is the single entry point for the entire lifecycle of a .NET project — scaffolding, restoring dependencies, building, running, testing, and publishing — and it's the same command whether you're on Windows, Linux, or macOS, or inside CI. IDEs like Visual Studio or Rider are ultimately calling the same CLI underneath their UI.
| Command | What it does |
|---|---|
| dotnet new <template> | Scaffold a new project or file from a template |
| dotnet restore | Download NuGet dependencies for the project |
| dotnet build | Compile the project |
| dotnet run | Build (if needed) and run the app |
| dotnet test | Run the test project(s) |
| dotnet publish | Produce a deployable output (framework-dependent or self-contained) |
| dotnet watch | Run with hot reload on file changes |
| dotnet add package <name> | Add a NuGet package reference |
Q5. How do you create a new .NET Core project using the CLI?
dotnet new webapi -n MyApi -o MyApi
cd MyApi
dotnet run
# other common templates:
dotnet new console -n MyConsoleApp
dotnet new classlib -n MyLibrary
dotnet new xunit -n MyApi.Tests
dotnet new sln -n MySolution && dotnet sln add MyApi MyApi.TestsQ6. Discuss the purpose and use of a csproj file in a .NET Core project.
The .csproj file is the project's MSBuild manifest — the target framework, package references, build settings, and file inclusion rules. .NET Core's "SDK-style" csproj is dramatically smaller than the old .NET Framework version because it implicitly globs source files (every .cs file under the folder is included by default) instead of listing each one explicitly.
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="8.0.0" />
</ItemGroup>
</Project>Q7. What is the runtime and SDK in .NET Core?
The runtime is only what's needed to run an already-built app — CoreCLR plus the base libraries. The SDK is everything needed to build one: the runtime, plus the compilers, MSBuild, and the CLI. Production servers typically only need the (smaller) runtime installed; developer machines and CI build agents need the full SDK.
| Contains | Install where | |
|---|---|---|
| .NET Runtime | CoreCLR + base libraries | Servers running console/worker apps |
| ASP.NET Core Runtime | Runtime + ASP.NET Core libraries | Servers running web apps/APIs |
| .NET SDK | Runtime + compilers + MSBuild + CLI | Dev machines, CI build agents |
Q8. How would you manage different versions of the .NET Core SDK on the same machine?
Multiple SDK versions can be installed side-by-side with no conflict — dotnet --list-sdks shows what's present. Per-project (or per-repo) pinning is what global.json is for: it tells the CLI which SDK version this folder tree must build with, which is exactly what keeps a CI agent and a laptop from silently building against different compilers.
dotnet --list-sdks
dotnet --list-runtimes
dotnet --version # respects global.json if one is presentQ9. What is the purpose of the global.json file?
{
"sdk": {
"version": "8.0.100",
"rollForward": "latestMinor"
}
}Placed at a repo's root, this pins exactly which installed SDK the dotnet CLI must use for every project under that folder — critical for reproducible builds across a team and CI, since "works on my machine" is often just a different SDK minor version doing something subtly different.
Q10. Can you explain the directory structure of a typical .NET Core project?
- Program.cs — the entry point; in modern .NET this also configures services and the middleware pipeline (minimal hosting model)
- *.csproj — the MSBuild project file
- appsettings.json / appsettings.{Environment}.json — configuration, layered per environment
- wwwroot/ — static files served directly to the browser (CSS, JS, images)
- Controllers/, Pages/, or Components/ — MVC controllers, Razor Pages, or Blazor components
- Properties/launchSettings.json — local run profiles and environment variables for `dotnet run`
- bin/ and obj/ — build output and intermediate files (never checked into source control)
Enjoyed this?
Let's talk about building something together.