100 .NET Core Interview Questions & Answers

.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).

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.

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

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.

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>

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.

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 present

{
  "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.

• 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)