16 questions found
What is the fundamental difference between .NET (formerly .NET Core) and .NET Framework?
Beginner
.NET Framework is the original, Windows-only implementation of .NET dating back to 2002, tightly coupled to Windows and installed as a shared system component. .NET (unified since .NET 5, evolving from .NET Core) is the modern, open-source, cross-platform reimplementation that runs on Windows, Linux, and macOS, and is the platform Microsoft actively develops going forward -- .NET Framework is now in maintenance-only mode.
// .NET Framework: Windows-only, ships with Windows or as a separate installer
// .NET 8: cross-platform, side-by-side installable, open source
dotnet --list-sdks // shows modern .NET SDKs, not Framework
Real-world example
A company running a legacy WCF service on .NET Framework 4.8 plans a migration to .NET 8 to gain Linux container support and better performance, while acknowledging some Framework-only APIs (like WCF server-side) require workarounds.
Common follow-ups: Why did Microsoft unify the numbering starting at .NET 5 (skipping 4)?;What is .NET Standard and how did it bridge Framework and Core?
.NET CLI
SDK & Project Structure (csproj);CLR & Runtime
Why did Microsoft skip version 4 and name the unified platform '.NET 5' instead of '.NET Core 4'?
Intermediate
Microsoft skipped .NET 4 specifically to avoid confusion with .NET Framework 4.x, since the new unified platform was meant to signal a clean break as the singular future of .NET -- dropping the 'Core' branding entirely starting with .NET 5, with .NET Framework remaining a separate, legacy product line receiving only security and critical fixes.
// Naming timeline:
// .NET Framework 4.8 (legacy, Windows-only)
// .NET Core 1.0, 2.0, 3.0, 3.1 (cross-platform, transitional)
// .NET 5, 6, 7, 8, 9... (unified platform, 'Core' dropped)
Real-world example
New developers researching .NET online must learn to distinguish '.NET Framework 4.8' from '.NET 8' since both use similar naming but represent entirely different, non-interchangeable platforms with different capabilities.
Common follow-ups: Is .NET Framework receiving new features going forward?;How long will .NET Framework continue to be supported?
.NET vs .NET Framework;CLR & Runtime
What is .NET Standard, and why is it less relevant now compared to a few years ago?
Intermediate
.NET Standard was a formal specification of APIs that both .NET Framework and .NET Core (and Xamarin, Mono, etc.) committed to implementing, letting library authors target one .NET Standard version to support multiple runtime flavors simultaneously. Since .NET 5+ unified the platform and .NET Framework is no longer receiving new .NET Standard version support, most new libraries now target modern TFMs (like net8.0) directly instead of .NET Standard, unless they specifically still need to support .NET Framework consumers.
<!-- Older library approach -->
<TargetFramework>netstandard2.0</TargetFramework>
<!-- Modern approach, unless Framework compatibility still needed -->
<TargetFramework>net8.0</TargetFramework>
Real-world example
A widely-used open-source logging library still targets netstandard2.0 specifically because many enterprise consumers remain on .NET Framework 4.8 and need compatibility, even though newer consumers use net8.0 directly.
Common follow-ups: What's the highest .NET Standard version, and what does it guarantee?;When should a new library still target netstandard2.0 in 2026?
.NET CLI
SDK & Project Structure (csproj);Assemblies & NuGet
What major APIs or features exist in .NET Framework but are unavailable or different in modern .NET?
Advanced
Notable gaps include: WCF server-side hosting (client-side exists via a community package, CoreWCF is a separate reimplementation), ASP.NET Web Forms (no equivalent, replaced conceptually by Blazor/Razor Pages), full System.Drawing.Common Windows GDI+ support (deprecated cross-platform, use ImageSharp/SkiaSharp instead), and certain remoting and AppDomain APIs (AppDomains are largely unsupported in modern .NET in favor of AssemblyLoadContext).
// .NET Framework only (no direct modern equivalent):
// System.ServiceModel (WCF server hosting)
// System.Web.UI (Web Forms)
// AppDomain.CreateDomain() -- use AssemblyLoadContext instead in modern .NET
Real-world example
A team migrating a Web Forms application to .NET 8 discovers there's no direct migration path and instead has to rewrite the UI layer entirely using Blazor or Razor Pages, a significant scope addition to the migration project.
Common follow-ups: What is CoreWCF and how does it help with WCF migration?;How does AssemblyLoadContext replace AppDomain isolation use cases?
CLR & Runtime;Assemblies & NuGet
How does performance typically compare between .NET Framework and modern .NET (e.g., .NET 8)?
Intermediate
Modern .NET has received years of dedicated, continuous performance investment (documented in Microsoft's annual 'Performance Improvements in .NET' posts) covering JIT compilation, garbage collection, ASP.NET Core request handling, JSON serialization, and more -- generally significantly outperforming .NET Framework on equivalent workloads, often by multiples for web request throughput, with lower memory usage too.
// Benchmarks consistently show modern .NET's ASP.NET Core
// handling multiples more requests/second than ASP.NET (Framework)
// under equivalent hardware, largely due to Kestrel + async pipeline improvements
Real-world example
A company migrating a high-traffic API from ASP.NET (Framework) to ASP.NET Core on .NET 8 reduces server instance count significantly after benchmarking shows the same hardware now handles several times more requests per second.
Common follow-ups: What specific ASP.NET Core changes drove the biggest throughput gains?;How do GC improvements differ between Framework and modern .NET?
Diagnostics & Performance;CLR & Runtime
What tools does Microsoft provide to help analyze and migrate a .NET Framework project to modern .NET?
Advanced
.NET Upgrade Assistant is a CLI/VS Code tool that automates much of the migration process (updating TFMs, converting packages.config to PackageReference, flagging incompatible APIs). The .NET Portability Analyzer and try-convert tool help assess API compatibility before committing to a migration, identifying which APIs used in the codebase have no direct modern .NET equivalent.
dotnet tool install -g upgrade-assistant
upgrade-assistant upgrade MyLegacyApp.sln
Real-world example
Before committing engineering time to a migration, a team runs the .NET Upgrade Assistant in analyze-only mode against their Framework 4.8 solution to get a report estimating migration effort and flagging blocking incompatible APIs.
Common follow-ups: What percentage of typical migrations does Upgrade Assistant fully automate?;How do you handle third-party dependencies with no modern .NET version?
CI/CD
Publishing & Deployment;Assemblies & NuGet
Why is .NET Framework considered to be in 'maintenance mode', and what does that mean practically for teams still using it?
Intermediate
.NET Framework 4.8 (released 2019) is the final version -- Microsoft has committed to supporting it for the lifetime of Windows itself (it ships as a Windows component) with security and reliability fixes, but it will never receive new language features, performance improvements, or new APIs, all of which are exclusively going into modern .NET going forward. Teams on .NET Framework should expect long-term stability but no forward feature investment.
// .NET Framework 4.8: final version, security-fix-only going forward
// vs .NET 8, 9, 10...: annual releases with new features, perf work, LTS every other year
Real-world example
A team maintaining a stable internal Framework 4.8 line-of-business application decides not to migrate immediately since it's low-risk and stable, but plans a migration roadmap anyway to eventually access modern language features like pattern matching improvements.
Common follow-ups: How does Windows's own lifecycle affect Framework's support timeline?;What's the risk of staying on Framework long-term for a growing application?
.NET vs .NET Framework;CI/CD
Publishing & Deployment
How does cross-platform support differ between .NET Framework and modern .NET?
Intermediate
.NET Framework runs only on Windows (there was a limited, largely abandoned open-source cross-platform effort called Mono for some scenarios, but Framework itself is Windows-bound). Modern .NET is natively cross-platform by design, officially supporting Windows, Linux (multiple distros), and macOS, including full support for Linux-based Docker containers -- a major driver for cloud-native and containerized deployment scenarios.
# Framework: Windows only
# Modern .NET: runs identically across platforms
docker run mcr.microsoft.com/dotnet/aspnet:8.0 # Linux container, same app code
Real-world example
A company standardizing on Kubernetes for all backend services requires every application to run in Linux containers, making a migration from .NET Framework to modern .NET a prerequisite rather than optional for any Framework-based service.
Common follow-ups: What was Mono and how does it relate to modern .NET's cross-platform story?;How does this affect hosting cost given Linux VMs are often cheaper than Windows?
Docker & Containerization;CLR & Runtime
What is the release cadence and Long-Term Support (LTS) model for modern .NET, and how does it differ from Framework's release history?
Advanced
Modern .NET ships a new major version annually every November; even-numbered versions (6, 8, 10...) are Long-Term Support releases supported for 3 years, while odd-numbered versions (7, 9...) are Standard Term Support, supported for 18 months, aimed at developers wanting the newest features sooner. .NET Framework, by contrast, had an irregular, much slower release cadence historically (years between major versions) and now receives no new versions at all, only patches to 4.8.x.
// LTS: .NET 6 (Nov 2021), .NET 8 (Nov 2023), .NET 10 (Nov 2025) -- 3 years support each
// STS: .NET 7 (Nov 2022), .NET 9 (Nov 2024) -- 18 months support each
Real-world example
An enterprise with strict change-management policies always targets even-numbered LTS releases (.NET 8, then .NET 10) for production systems, skipping odd-numbered STS releases to minimize the frequency of mandatory upgrades.
Common follow-ups: Why might a team deliberately choose an STS release despite the shorter support window?;What happens if you run an app on a version past its support end date?
CI/CD
Publishing & Deployment;.NET CLI
SDK & Project Structure (csproj)
How does packages.config differ from PackageReference, and which is used in Framework versus modern .NET projects?
Intermediate
packages.config is the older NuGet dependency format used in classic .NET Framework projects, storing package references in a separate XML file and physically copying package assemblies into a packages folder. PackageReference, used by default in modern SDK-style .csproj files (and adoptable in newer Framework projects too), declares dependencies directly inside the project file and uses a global NuGet cache instead of per-project copies, simplifying dependency management and enabling transitive dependency resolution.
<!-- packages.config (legacy) -->
<packages>
<package id="Newtonsoft.Json" version="13.0.3" targetFramework="net48" />
</packages>
<!-- PackageReference (modern, in .csproj) -->
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
</ItemGroup>
Real-world example
A legacy Framework project migrating dependency management converts from packages.config to PackageReference using Visual Studio's built-in migration tool, immediately reducing repository size since packages are no longer copied locally.
Common follow-ups: How does the global NuGet cache reduce disk usage across projects?;Can packages.config and PackageReference coexist during a transition?
Assemblies & NuGet;.NET CLI
SDK & Project Structure (csproj)