How to get absolute trusted path to dotnet.exe that is installed with Visual Studio installation?

Question

How to get absolute trusted path to dotnet.exe that is installed with Visual Studio installation?

Sajith 86

I have a requirement of launching dotnet.exe with absolute path from a Visual Studio extension. Absolute path is required to avoid CWE-427 risk.

In my machine dotnet.exe is at 'C:\Program Files\dotnet\dotnet.exe' but this location is not always guaranteed and could not find a definite way to get location of dotnet.exe from the extension.

There is a dotnet.exe in 'C:\Program Files\Microsoft Visual Studio\2022\Professional\dotnet\net8.0\runtime\dotnet.exe' in my VS 2022 installation. Can I use this to launch the process? But for this also, how to get absolute trusted path to this? Is there an environment variable that is available to Visual Studio extension that can be used to get the absolute path of dotnet.exe?

Viorel 127.3K Reputation points

2026-05-15T07:22:17.08+00:00

Even if the trusted path is established, it does not necessarily mean that the application is trustworthy.

2 answers

Your answer

Viorel 127.3K Reputation points

2026-05-15T07:22:17.08+00:00

Even if the trusted path is established, it does not necessarily mean that the application is trustworthy.

Answer 1

Varsha Dundigalla(INFOSYS LIMITED) 5,185 Microsoft External Staff

Thank you for reaching out.

From my understanding, the recommendation is based on how Visual Studio and .NET are designed.

Visual Studio installs and manages its own copy of .NET, separate from the system-wide installation. Because of this, multiple dotnet.exe locations can exist on a machine.

However, the path of dotnet.exe inside the Visual Studio installation is not a documented or stable contract for extensions. It can vary depending on Visual Studio version, edition, or custom install path, and there is no supported API or environment variable that exposes this path.

Because of this, relying on the Visual Studio internal dotnet.exe or hardcoding that path is not considered reliable.

So instead, I suggest avoiding Visual Studio-specific paths and using a known trusted installation (like system-wide .NET) or a proper discovery mechanism. This aligns better with your requirement to use an absolute path while also avoiding CWE‑427 risks.

Please let us know if you require any further assistance, we’re happy to help. If you found this information useful, kindly mark this as "Accept Answer". So that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

Sajith 86 Reputation points

2026-05-14T16:58:34.7333333+00:00

Hi @Varsha Dundigalla(INFOSYS LIMITED) Thanks a lot for looking into this.

Regarding following suggestion -

So instead, I suggest avoiding Visual Studio-specific paths and using a known trusted installation (like system-wide .NET) or a proper discovery mechanism.

Could you please advise how to reliably get absolute path to dotnet.exe from system-wide .NET installation?

I have dotnet.exe in my machine at 'C:\Program Files\dotnet\dotnet.exe' but this location is not always guaranteed. dotnet.exe may be installed to other locations as well. So I could not find a definite way to get location of dotnet.exe and use absolute path to this so that CWE‑427 risks can be avoided. Please advise how to proceed on this.
Varsha Dundigalla(INFOSYS LIMITED) 5,185 Reputation points Microsoft External Staff

2026-05-15T10:58:44.74+00:00
Thank you for reaching out.

I understand your concern.

In this case, there is no single fixed or guaranteed location for dotnet.exe. .NET can be installed in different locations (machine-wide, per-user, or custom path), so the path can vary across machines.

Also, there is no supported API or environment variable that always gives the exact dotnet.exe path. Variables like DOTNET_ROOT may help in some cases, but they are not always set, so they cannot be fully relied on.

Because of this, there is no completely automatic way to always get a trusted absolute path in every environment.

What you can do in practice is:

If your scenario requires a strict and trusted path (to avoid CWE‑427), then the safest approach is to use a known path that you control, for example by taking it from configuration or letting the user specify it.

If configuration is not possible, then you need to resolve the path from the system at runtime (like checking standard install locations or using system lookup), and then use that resolved full path.

In short, since the install location is not fixed, the solution has to be either explicitly configured or discovered at runtime based on the machine setup.

Please let us know if you require any further assistance, we’re happy to help. If you found this information useful, kindly mark this as "Accept Answer". So that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.
Varsha Dundigalla(INFOSYS LIMITED) 5,185 Reputation points Microsoft External Staff

2026-05-20T07:47:18.23+00:00

Hope you're doing well. Could you please let us know if the issue still persists or if it has been resolved? If everything is working fine now, we’d appreciate it if you could mark the response as "Accepted Answer". We will proceed with the thread closure by 22 May, so we are hoping for your reply before that.
Varsha Dundigalla(INFOSYS LIMITED) 5,185 Reputation points Microsoft External Staff

2026-05-22T07:41:13.3066667+00:00

We are closing this thread at this moment since we are unable to investigate this issue further without the requested information. If the issue still occurs, please collect the requested information and share it with us. Upon receipt of the additional information, we will reopen this thread and continue to investigate this issue. Thank you.

Answer 2

As you don’t know where the user installed the official dot sdk, you would need to do a path search.

public static string FindDotNetPath()
{
    // Search for 'dotnet.exe' in the directories listed in the PATH environment variable
    var pathEnv = Environment.GetEnvironmentVariable("PATH");
    var paths = pathEnv?.Split(Path.PathSeparator);

    return paths?.Select(p => Path.Combine(p, "dotnet.exe"))
                 .FirstOrDefault(File.Exists);
}

But this is no better than letting the os find the .exe. If you really need to know the users official install, then your extension needs a setting that the user enters the path to sdk.