We manage about 200 Windows laptops through Intune and want to prepare for .NET 8 and .NET 9 reaching end of support in November. Detecting machines with those runtimes installed is easy, but I need to determine which applications actually require them.
I'm considering an Intune PowerShell script that checks installed runtimes and desktop runtimes, searches for *.runtimeconfig.json files referencing .NET 8 or .NET 9, and looks for self-contained applications containing files such as coreclr.dll. I'm also wondering how reliably this can identify single-file applications that bundle their runtime inside an executable.
The main concern is third-party software. A computer may have .NET 8 installed even though no application uses it, while another application might ship its own .NET runtime and never appear in the normal runtime inventory. I'd also like to collect the endpoint results centrally so they can be analyzed across the fleet.
What approach have others used to identify these dependencies reliably?
2 Answers
For modern .NET applications, the most practical indicator is usually the runtimeconfig.json file beside the executable. A scheduled task can scan local drives for those files, read the target framework and runtime version, count the results, and write a summary to the registry. Intune can then run a compliance or inventory script that reports devices where the count for .NET 8 or .NET 9 is greater than zero. This won’t catch every bundled or single-file application, but it gives you a useful fleet-wide starting point.
Be careful not to treat the presence of a shared runtime as proof that it is being used. Vendor applications can also package a self-contained runtime, so checking application folders for runtimeconfig files and files such as coreclr.dll is worthwhile. Ultimately, testing or updating the vendor applications is still important—some products have specific runtime requirements, such as certain versions of Dell Command | Update, AutoCAD, or ArcGIS. A controlled removal test can reveal dependencies, but it’s safer to do that only on a pilot group because the resulting support tickets can arrive quickly.
The older .NET Framework versions are a separate consideration from modern .NET. Applications built for .NET Framework 3.5 or 4.8 should be inventoried and assessed separately rather than assumed to depend on .NET 8 or .NET 9.