docs icon indicating copy to clipboard operation
docs copied to clipboard

Published 20 hours ago • verified publisher icon dotnet

Programmatic way to check for newer installations of .net runtime

Open Saurbaum opened this issue 3 years ago • 2 comments

I was searching for a way to detect the installation of a newer version of the .net runtime.

All I found was this. https://docs.microsoft.com/en-us/dotnet/core/install/windows?tabs=net60

That is much more targeted at a human searching their machine but there's no good guide I can see on how a program should detect it.

Normally I'd use the upgradecode and productcode which doesn't work here. I've raised that as a separate issue.

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

Saurbaum avatar Sep 19 '22 09:09 Saurbaum

Environment.Version gives you the version of the CLR.

gewarren avatar Nov 10 '22 21:11 gewarren

That requires a version to be installed already. I was looking for a way to check at install time.

Seems such a thing isn't possible.

Saurbaum avatar Nov 10 '22 21:11 Saurbaum

Hi @Saurbaum I just discovered this issue, sorry it's been lost. I don't think there really is a TRUE way besides checking if the folders exist, or checking if one of the environment variables is set that can help you locate the DOTNET folder root and then checking for the existence of some sub folders.

I would think the best way would be to see if the dotnet.exe command resolves to anything, if so, something is setup to be "the" .NET on the machine, then shell out to it with the --runtimes parameter and manually parse the results. There are probably some trail markers left behind depending on how the .NET runtime was installed, like when a user uses the install MSI/EXE, there's something there indicating it's installed so you can uninstall it via Add or remove programs.

.NET isn't installed globally, like .NET Framework was. You can install as many copies as you want as long as the dotnet.exe command is resolved and the executable finds child folders of runtimes/sdks (simplification of how it works, I assume). But if someone simply unzips the binaries, puts it in the %PATH% variable, .NET becomes alive and works, no trace as to how it was installed or what is actually installed.

I don't think there's anything we'll do at this moment to this article to add information on how to do that.

adegeo avatar May 22 '24 20:05 adegeo