Addressing .Net EOL installations for Windows Admins

TL; DR:

Installing the latest .NET runtime on a server does not upgrade existing applications that are built on unsupported versions (for example, anything older than .NET 8 as of Nov 2025). Applications must be explicitly upgraded through a full development lifecycle—retargeting the project to a supported framework, updating dependencies, rebuilding, testing, and redeploying.

This is not something a Windows administrator can safely perform alone. However, admins can and should identify which applications are running on EOL .NET versions and coordinate with development teams to ensure they are upgraded to a supported release.

.NET vs .NET Framework: Understanding the Difference

Unlike the classic .NET Framework, modern .NET (formerly .NET Core) is not an integral part of the Windows operating system. It is typically installed on-demand when an application requires it. This means multiple .NET versions can coexist on the same system without automatically affecting each other.

Modern .NET is:

• Cross-platform (Windows, Linux, macOS)
• Open source
• Designed for rapid evolution and cloud-native development

Because of these design goals, modern .NET follows a fixed annual release cadence with defined support timelines.

Official documentation:

• .NET and .NET Core official support policy | .NET
• .NET Framework official support policy | .NET
• Download .NET (Linux, macOS, and Windows) | .NET

End of Life (EOL)

As a .NET version approaches End of Life (EOL), Microsoft recommends upgrading to a supported version and reducing dependency on the expiring runtime. After EOL:

• Security updates stop
• Bug fixes stop
• Microsoft technical support ends
• Compliance and audit risks increase

Microsoft strongly discourages continued use of unsupported runtimes:

Using out-of-support .NET versions may expose your applications, data, and environment to security vulnerabilities and operational failures.

EOL is also referred to as End of Support (EOS).

Why Security Tools Flag EOL .NET Installations

Once a .NET runtime reaches EOL, vulnerability scanners and endpoint security software often flag it as a risk and recommend removal. Even if your tools do not explicitly report it, proactive removal and upgrade is still best practice.

Before uninstalling, however, administrators typically ask:

• What will break if I remove this version?
• Can I just install the latest .NET to replace it?
• Which applications are dependent on this runtime?
• Can I safely remove it if nothing appears to use it?

Here is a general workflow that can be used to address the above questions:

Step 1 – Identify Applications Using EOL ASP.NET / .NET Runtimes

Important: The steps below identify only the applications actively running at the time of execution. Any dormant services, scheduled tasks, or rarely used applications may still depend on EOL .NET but will not appear until they are executed.

• To identify currently running applications that are using the .NET runtime, you can use Sysinternals ListDLLs from Microsoft.

• Download ListDLLs - Sysinternals | Microsoft Learn and run the following command from an elevated (Administrator) CMD prompt:

listdlls.exe -d coreclr.dll -accepteula -v

Sample output of listdll command

This will show all the dotnet processes (with versions 6/7 or 8 or previous) along with version of .Net runtime loaded (coreclr). Make a note of processes that are loading EOL .Net versions - .NET and .NET Core official support policy. 

Note - coreclr is the Dotnet runtime dll which will be loaded in a .Net process. The listdll shows a specific version loaded by respective process, that would help identify processes using EOL .Net runtime.

• Reference - CoreCLR is now Open Source - .NET Blog

Step 2 - Reach to the developers to upgrade the Application to supported version: 

• Applications do not automatically upgrade to a newer .NET version simply because a supported runtime is installed on the server. Each application must be rebuilt and retargeted to explicitly use the newer framework version.

• The upgrade process typically follows a full software development lifecycle (SDLC), including:

  • Retargeting the project to the latest supported .NET version

  •  

    Updating NuGet packages and dependencies

  • Fixing breaking changes
  • Rebuilding the application
  • Functional and regression testing
  • Deployment to production

•  

  This process is not something a Windows administrator can safely perform alone. It requires access to the application source code and ownership from the development or product team. Administrators should focus on identifying incompatible or EOL runtimes and coordinating with application owners to plan upgrades.

• Reference:
  • Upgrade to a new .NET version - .NET | Microsoft Learn

Step 3 – Confirm No Applications Are Using EOL .NET Runtimes

After application owners have upgraded and deployments are completed, you must verify that no processes are still running on unsupported .NET runtimes.

Repeat the same process from Step 1 to re-scan the system:

Step 4 – Uninstall / Remove EOL .NET Runtimes

• Once you confirmed no dependency on the EOL products you can proceed with uninstall.
• Note that .Net apps can be self-contained or framework-dependent:
  • .NET application publishing overview - .NET | Microsoft Learn
  • Publish self-contained
    This mode produces a publishing folder that includes a platform-specific executable used to start the app, a compiled binary containing app code, any app dependencies, and the .NET runtime required to run the app. The environment that runs the app doesn't need to have the .NET runtime preinstalled.
  • Publish framework-dependent
    This mode produces a publishing folder that includes an optional platform-specific executable used to start the app, a compiled binary containing app code, and any app dependencies. The environment that runs the app must have a version of the .NET runtime installed that the app can use.
    • Framework dependant apps will use the shared runtimes that you may have installed from Download .NET (Linux, macOS, and Windows) | .NET.
  •  For self-contained apps, the developer must provide a latest package with supported runtimes. 
• Of course, to anticipate failure, please have back up/recovery plans and execute the actions during a downtime as per your company policies.

I hope this helps.