Comparison of .NET versions
Comparison of .NET versions Interview with follow-up questions
1. Can you explain the key differences between .NET Core, .NET Framework, and .NET Standard?
This is a foundational .NET ecosystem question. The full picture as of 2026:
.NET Framework
- Windows-only, closed-source (reference source available), versions 1.0 through 4.8.1.
- Final version is 4.8.1 — Microsoft will not add new features, only security and reliability fixes.
- Includes technologies with no modern equivalent path: Web Forms, WCF (server), Remoting, AppDomain isolation, the GAC.
- Still widely used in enterprise Windows applications that have not yet migrated.
.NET (modern — formerly .NET Core)
- Cross-platform (Windows, macOS, Linux), fully open-source (MIT on GitHub).
- Supersedes both .NET Framework and .NET Core. Versioned as .NET 5, 6, 7, 8, 9, 10...
- .NET 8 is the current LTS release (Nov 2023 — supported until Nov 2026).
- .NET 9 is the current STS (Standard-Term Support, Nov 2024 — supported 18 months).
- All new investment from Microsoft: Blazor, MAUI, Minimal APIs, NativeAOT, .NET Aspire, etc.
- Use this for all new development.
.NET Standard
- Not a runtime — a specification of a minimum API surface that any conforming .NET implementation must provide.
- Versions: 1.0 through 2.1. .NET Standard 2.0 is the most widely adopted.
- Purpose: write a single class library that works on both .NET Framework 4.6.1+ and modern .NET without separate builds.
- Status in 2026: No longer actively developed. New libraries targeting only modern .NET should use
net8.0(ornet9.0) target framework monikers directly. .NET Standard remains relevant only for libraries that must support both .NET Framework and modern .NET simultaneously.
Quick mental model:
- Building something new? → Target modern .NET (8 or 9).
- Maintaining a Windows-only enterprise app? → Likely .NET Framework 4.x; plan migration.
- Writing a shared library that must work everywhere? → .NET Standard 2.0 for maximum reach, or multi-target (
net8.0;net48).
Follow-up 1
What are the advantages of using .NET Core over .NET Framework?
There are several advantages of using .NET Core over .NET Framework:
Cross-platform support: .NET Core runs on Windows, macOS, and Linux, allowing you to build applications that can run on multiple operating systems.
Performance: .NET Core is optimized for performance and has a smaller footprint compared to .NET Framework. It provides faster startup times, better memory management, and improved scalability.
Modularity: .NET Core is designed with modularity in mind. It allows you to include only the necessary components in your application, resulting in smaller deployment packages and reduced dependencies.
Open-source and community-driven: .NET Core is open-source and has a large and active community. This means that you have access to a wide range of libraries, tools, and resources, and you can contribute to the framework's development.
Support for modern development practices: .NET Core supports modern development practices like containerization, microservices, and serverless computing.
Follow-up 2
Can you give a scenario where .NET Standard would be more suitable to use?
.NET Standard is more suitable to use in scenarios where you want to write portable code that can run on different platforms and implementations of .NET. Here are a few scenarios where .NET Standard would be a good choice:
Library development: If you are developing a library that you want to be consumed by different applications targeting different versions of .NET, you can use .NET Standard to ensure compatibility.
Cross-platform development: If you are building an application that needs to run on multiple platforms, such as Windows, macOS, and Linux, you can use .NET Standard to write code that can be shared across these platforms.
Migration from .NET Framework to .NET Core: If you have an existing application built on .NET Framework and you want to migrate it to .NET Core, you can use .NET Standard to gradually refactor and share code between the two frameworks.
Follow-up 3
What is the role of .NET Standard in the .NET ecosystem?
.NET Standard plays a crucial role in the .NET ecosystem as it provides a common set of APIs that are available across all .NET implementations, including .NET Core, .NET Framework, and Xamarin. It acts as a bridge between different implementations, allowing developers to write portable code that can run on different platforms and versions of .NET.
By targeting .NET Standard, developers can ensure that their code will work on any platform that supports that particular version of .NET Standard. This makes it easier to share code between different projects and reduces the effort required to maintain and update codebases.
.NET Standard versions are backward compatible, which means that if your code targets a higher version of .NET Standard, it will also work on platforms that support lower versions of .NET Standard.
Follow-up 4
How does the performance of .NET Core compare with .NET Framework?
In general, .NET Core offers better performance compared to .NET Framework. Here are a few reasons why:
Smaller footprint: .NET Core has a smaller runtime footprint compared to .NET Framework, which results in faster startup times and reduced memory usage.
Optimized for modern workloads: .NET Core is designed to be highly optimized for modern workloads like microservices, containerization, and cloud-based architectures. It provides better scalability and performance in these scenarios.
Improved JIT compiler: .NET Core includes an improved Just-In-Time (JIT) compiler, which can generate more efficient machine code compared to the JIT compiler used in .NET Framework.
Support for newer runtime features: .NET Core has support for newer runtime features like tiered compilation, which can further improve performance in certain scenarios.
However, it's important to note that the performance difference may vary depending on the specific workload and the version of .NET Core and .NET Framework being compared.
2. What are the different versions of .NET Framework that have been released so far?
.NET Framework release history (Windows-only runtime, now in maintenance):
| Version | Year | Key additions |
|---|---|---|
| 1.0 | 2002 | Initial release — CLR, BCL, ASP.NET Web Forms, WinForms |
| 1.1 | 2003 | ASP.NET improvements, ADO.NET updates |
| 2.0 | 2005 | Generics, nullable types, partial classes, anonymous methods |
| 3.0 | 2006 | WPF, WCF, WF (Workflow Foundation), CardSpace |
| 3.5 | 2007 | LINQ, C# 3.0, lambda expressions, extension methods |
| 4.0 | 2010 | TPL (Task Parallel Library), dynamic language support, MEF |
| 4.5 | 2012 | async/await, portable class libraries, HTTP client |
| 4.5.1 | 2013 | Edit and Continue 64-bit, ADO.NET idle connection resiliency |
| 4.5.2 | 2014 | High DPI enhancements, async transactions |
| 4.6 | 2015 | RyuJIT (64-bit JIT), HTTP/2 support |
| 4.6.1 | 2015 | EF6 improvements, crypto updates |
| 4.6.2 | 2016 | AES-CCM/GCM, TLS 1.2 for WCF |
| 4.7 | 2017 | High DPI WPF/WinForms improvements, TLS system defaults |
| 4.7.1 | 2017 | .NET Standard 2.0 support, accessibility improvements |
| 4.7.2 | 2018 | ASP.NET SameSite cookies, BCL improvements |
| 4.8 | 2019 | JIT improvements, FIPS compliance |
| 4.8.1 | 2022 | ARM64 support — final version of .NET Framework |
Important context for interviews: .NET Framework 4.8.1 is the last release. Microsoft will ship security and reliability fixes for the lifetime of Windows but will add no new features. All new features ship in modern .NET (8, 9, 10...).
The modern .NET lineage is separate: .NET Core 1.0 (2016) through .NET Core 3.1, then .NET 5 (unified), .NET 6 LTS, .NET 7, .NET 8 LTS, .NET 9, and .NET 10 LTS (due Nov 2025).
Follow-up 1
What are the key features introduced in each version?
Here are the key features introduced in each version of .NET Framework:
- .NET Framework 1.0: Initial release of .NET Framework.
- .NET Framework 1.1: Introduced support for mobile devices and ASP.NET improvements.
- .NET Framework 2.0: Introduced generics, partial types, and ClickOnce deployment.
- .NET Framework 3.0: Introduced Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), and CardSpace.
- .NET Framework 3.5: Introduced LINQ, ASP.NET AJAX, and improvements to WCF and WF.
- .NET Framework 4.0: Introduced support for dynamic languages, parallel programming, and improved performance.
- .NET Framework 4.5: Introduced async and await support, improved garbage collection, and performance improvements.
- .NET Framework 4.5.1: Introduced support for Windows 8.1 and Visual Studio 2013.
- .NET Framework 4.5.2: Introduced bug fixes and performance improvements.
- .NET Framework 4.6: Introduced support for Windows 10 and Visual Studio 2015.
- .NET Framework 4.6.1: Introduced performance improvements and bug fixes.
- .NET Framework 4.6.2: Introduced performance improvements and bug fixes.
- .NET Framework 4.7: Introduced support for .NET Standard 2.0 and performance improvements.
- .NET Framework 4.7.1: Introduced performance improvements and bug fixes.
- .NET Framework 4.7.2: Introduced performance improvements and bug fixes.
- .NET Framework 4.8: Introduced JIT and garbage collector improvements, and performance improvements.
Follow-up 2
Which version of .NET Framework introduced support for async and await?
The version of .NET Framework that introduced support for async and await is .NET Framework 4.5.
Follow-up 3
What improvements were made in .NET Framework 4.5 over its predecessor?
The improvements made in .NET Framework 4.5 over its predecessor include:
- Support for async and await.
- Improved garbage collection.
- Performance improvements.
- Support for Windows 8 and Visual Studio 2012.
- Improved support for HTML5 and CSS3 in ASP.NET.
- Enhanced support for parallel programming.
- Improved support for networking and web services.
- Improved support for Windows Presentation Foundation (WPF) and Windows Communication Foundation (WCF).
- Improved support for Entity Framework and LINQ.
- Various bug fixes and stability improvements.
3. How does the compatibility of .NET Core with different platforms compare to .NET Framework?
The key distinction interviewers want: .NET Framework is Windows-only; modern .NET is cross-platform by design.
.NET Framework platform support:
- Runs exclusively on Windows (x86 and x64; ARM64 added in 4.8.1).
- Tightly integrated with Windows — uses Win32 APIs, COM, the Windows Registry, and the GAC.
- Cannot run on macOS or Linux.
Modern .NET (8/9) platform support:
- Windows: x64, x86, ARM64 (Windows 10/11, Server 2016+)
- macOS: x64 and ARM64 (Apple Silicon M-series), macOS 12+
- Linux: x64 and ARM64 across Ubuntu, Debian, Alpine, RHEL, Fedora, SLES, and more
- WebAssembly: Blazor WebAssembly runs .NET in the browser via WASM
- Android / iOS / macCatalyst: via .NET MAUI for mobile and desktop apps
How cross-platform compatibility is achieved: CoreCLR abstracts OS-specific behavior behind a Platform Adaptation Layer (PAL). The BCL's file, networking, and threading APIs have platform-specific implementations behind common interfaces. The dotnet SDK builds and publishes for any supported Runtime Identifier (RID) via cross-compilation.
Practical implication: A team on macOS can write, build, and test a .NET 8 web API locally, then publish it as a Linux container image for deployment on Kubernetes — all with the same codebase and dotnet CLI. This was impossible with .NET Framework.
Follow-up 1
Can .NET Core applications run on Linux?
Yes, .NET Core applications can run on Linux. .NET Core provides a runtime environment that is compatible with Linux, allowing developers to build and deploy applications on Linux servers or desktops.
Follow-up 2
What is the process of porting a .NET Framework application to .NET Core?
Porting a .NET Framework application to .NET Core involves several steps:
- Assess the compatibility: Check if the application uses any APIs or features that are not available in .NET Core.
- Update the code: Modify the code to use equivalent APIs or features available in .NET Core.
- Test and debug: Test the application on .NET Core to ensure it functions correctly and debug any issues that arise.
- Build and deploy: Build the application using .NET Core and deploy it to the desired platform.
Follow-up 3
What challenges might one face when trying to run a .NET Framework application on a non-Windows platform?
Running a .NET Framework application on a non-Windows platform can be challenging due to the following reasons:
- Platform compatibility: .NET Framework is primarily designed for Windows, so it may not be compatible with non-Windows platforms.
- Missing APIs: Some APIs or features used in the .NET Framework application may not be available in the non-Windows platform.
- Performance issues: The performance of a .NET Framework application on a non-Windows platform may not be optimal due to differences in the underlying system.
- Dependency management: The application may have dependencies on Windows-specific libraries or components that are not available on the non-Windows platform.
4. What is the future of .NET Framework given the rise of .NET Core?
This is a settled question in 2026 — the future is modern .NET, and .NET Framework's trajectory is clearly defined.
What happened:
- .NET Framework is in maintenance mode. Version 4.8.1 (2022) is the final release. Microsoft will ship security and reliability fixes for the lifetime of Windows, but no new language features, performance improvements, or new APIs will be added.
- Modern .NET is the future. Starting with .NET 5 (2020), Microsoft unified .NET Core and .NET Framework into a single platform simply called ".NET". This is where all investment goes.
Current state (2026):
- .NET 8 — LTS (Long-Term Support), released November 2023, supported until November 2026.
- .NET 9 — STS (Standard-Term Support), released November 2024, supported until May 2026.
- .NET 10 — Next LTS, due November 2025.
- Annual release cadence: LTS every even-numbered version, STS every odd-numbered version.
Why new projects should not use .NET Framework:
- No new features — you are frozen at the 2019 API surface.
- Windows-only — no Linux containers, no macOS development.
- No performance improvements — none of the RyuJIT, GC, Span, or HTTP stack gains.
- Ecosystem drift — many popular NuGet packages no longer target .NET Framework.
Migration path: The .NET Upgrade Assistant automates much of the migration. The hardest pieces are Web Forms (rewrite to Razor Pages or Blazor), WCF server (use CoreWCF or switch to gRPC), and Windows-specific P/Invoke usage.
Interview framing: ".NET Framework is not going away — it ships with Windows — but it is a legacy platform. For any new development, modern .NET 8 or .NET 9 is the right choice."
Follow-up 1
Is Microsoft planning to phase out .NET Framework?
While Microsoft has not explicitly announced plans to phase out .NET Framework, they have been actively promoting .NET Core as the preferred framework for new development. This has led to speculation that .NET Framework may eventually be deprecated in favor of .NET Core. However, as of now, .NET Framework is still supported and widely used, and there is no official timeline for its retirement.
Follow-up 2
What is the migration path for existing .NET Framework applications?
The migration path for existing .NET Framework applications to .NET Core depends on the complexity and size of the application. Microsoft provides a tool called the .NET Portability Analyzer that can help identify any compatibility issues when migrating from .NET Framework to .NET Core. In general, the migration process involves updating the code to use the .NET Core APIs and resolving any dependencies on features that are not available in .NET Core. It is recommended to thoroughly test the migrated application to ensure it functions correctly in the new framework.
Follow-up 3
How does the support for .NET Framework compare with .NET Core?
In terms of support, .NET Framework has been around for a longer time and has a larger ecosystem of libraries and frameworks built on top of it. It is a mature and stable framework that is widely used in enterprise applications. On the other hand, .NET Core is a newer framework that is designed to be cross-platform and lightweight. While .NET Core has a smaller footprint and faster performance, it may not have the same level of support and compatibility as .NET Framework. It is important to consider the specific requirements of your application when choosing between .NET Framework and .NET Core.
5. What is the role of .NET Standard in ensuring code compatibility across different .NET versions?
.NET Standard is a formal specification — not a runtime — that defines a minimum set of APIs any conforming .NET implementation must provide. It exists to solve the library portability problem: before .NET Standard, a library author had to publish separate builds for .NET Framework, Xamarin, and .NET Core.
How it works:
- A library that targets
netstandard2.0can be consumed by any runtime that implements .NET Standard 2.0 or higher: .NET Framework 4.6.1+, .NET Core 2.0+, and all modern .NET versions (5, 6, 7, 8, 9). - The library author compiles against the .NET Standard API surface; the consuming runtime provides the actual implementation of those APIs.
Key versions:
| Version | Supports |
|---|---|
| netstandard1.x | Early .NET Core / Xamarin; very limited API set |
| netstandard2.0 | .NET Framework 4.6.1+, .NET Core 2.0+, modern .NET — most widely used |
| netstandard2.1 | .NET Core 3.x and modern .NET only (NOT .NET Framework 4.x) |
Current status (2026): .NET Standard is effectively frozen — no new versions are planned. Microsoft's guidance:
- If your library must support both .NET Framework and modern .NET — target
netstandard2.0. - If your library targets modern .NET only — target
net8.0directly to access all modern APIs unavailable in .NET Standard. - Use multi-targeting (
netstandard2.0;net8.0) when you need both maximum reach and modern API access with conditional compilation.
Interview gotcha: .NET Standard 2.1 is NOT supported by .NET Framework 4.x. If a library targets netstandard2.1, it cannot be consumed by .NET Framework applications. This surprises many developers.
Follow-up 1
Can you explain how .NET Standard works?
.NET Standard works by defining a set of APIs that are available across all .NET platforms. These APIs are a subset of the APIs provided by each specific .NET platform. When a library is built targeting .NET Standard, it can be used by any .NET application that supports that version of .NET Standard. This allows developers to create libraries that can be shared and used across different .NET platforms without having to rewrite the code for each platform.
Follow-up 2
What are the advantages of using .NET Standard libraries?
There are several advantages of using .NET Standard libraries:
Code Reusability: .NET Standard libraries can be used across different .NET platforms, allowing developers to write code once and use it in multiple applications.
Platform Independence: By targeting .NET Standard, developers can create libraries that are not tied to a specific .NET platform, making them more versatile and portable.
Ecosystem Compatibility: .NET Standard libraries can be easily integrated with other .NET libraries and frameworks, making it easier to leverage existing code and tools.
Future-proofing: By targeting .NET Standard, developers can ensure that their libraries will be compatible with future versions of .NET, reducing the need for frequent updates and maintenance.
Follow-up 3
How does .NET Standard help in code sharing across different .NET platforms?
.NET Standard helps in code sharing across different .NET platforms by providing a common set of APIs that are available on all platforms. Developers can build libraries targeting .NET Standard, and these libraries can be used by any .NET application that supports that version of .NET Standard. This allows for code reuse and sharing across different platforms, reducing the amount of duplicate code that needs to be written and maintained. It also simplifies the process of creating cross-platform applications, as developers can leverage existing .NET Standard libraries to implement common functionality.
Live mock interview
Mock interview: Comparison of .NET versions
- Read your scene and goals
- Talk it out; goals tick off live
- Get a score and stronger lines
Your voice and your AI key never touch our servers; the key stays in this browser and is sent only to Google. Only your round scores are saved to track progress.