sdk: Running dotnet sdk command from unit tests is not possible without using full path
Steps to reproduce
- Create unit test project
- Add following code into test
var startInfo = new ProcessStartInfo
{
FileName = "dotnet",
Arguments = "--version",
UseShellExecute = false,
CreateNoWindow = true,
RedirectStandardError = true,
RedirectStandardOutput = true,
WorkingDirectory = AppContext.BaseDirectory
};
var hostProcess = new Process() { StartInfo = startInfo };
hostProcess.ErrorDataReceived += (sender, dataArgs) => { Console.WriteLine(dataArgs.Data ?? string.Empty); };
hostProcess.OutputDataReceived += (sender, dataArgs) => { Console.WriteLine(dataArgs.Data ?? string.Empty); };
hostProcess.Start();
Console.WriteLine(hostProcess.MainModule.FileName);
hostProcess.BeginErrorReadLine();
hostProcess.BeginOutputReadLine();
hostProcess.WaitForExit();
- dotnet test
Expected behavior
Current dotnet version gets displayed along with muxer dotnet.exe path.
Actual behavior
dotnet.exe from shared runtime directory is resolved and it throws an error.
C:\Users\pakrym\AppData\Local\Microsoft\dotnet\shared\Microsoft.NETCore.App\1.0.0-rc2-23929\dotnet.exe
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly '--version' or one of its dependencies. The system cannot find the file specified.
Cause
When dotnet test runs it uses corehost from shared host directory to run xunit runner, and when test tries to start dotnet publish dotnet.exe gets resolved to one inside shared runtime folder because of rules below.
Resolution order:
The directory from which the application loaded.
The current directory for the parent process.
The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable. Note that this function does not search the per-application path specified by the App Paths registry key. To include this per-application path in the search sequence, use the ShellExecute function.
Environment data
dotnet --version output:
1.0.0-beta-002115
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 17 (16 by maintainers)
Commits related to this issue
- Remove dotnet.exe from shared direcotry to workaround https://github.com/dotnet/cli/issues/2143 — committed to aspnet/KoreBuild by pakrym 8 years ago
- Remove dotnet.exe from shared direcotry to workaround https://github.com/dotnet/cli/issues/2143 — committed to aspnet/KoreBuild by pakrym 8 years ago
- Remove dotnet.exe from shared direcotry to workaround https://github.com/dotnet/cli/issues/2143 — committed to aspnet/KoreBuild by pakrym 8 years ago
- Remove dotnet.exe from shared direcotry to workaround https://github.com/dotnet/cli/issues/2143 — committed to aspnet/KoreBuild by pakrym 8 years ago
- Merge pull request #2143 from dotnet/nuget.client.release-5096-4-1 Insert NuGet Build 4.7.0-rtm.5096 into sdk — committed to wli3/cli by johnbeisner 6 years ago
I don’t love this solution. If we’re saying that the Muxer should always win then we shouldn’t call the thing in the Shared FX dir dotnet.exe. We should call it dotnet.{version}.exe so there is no opportunity for ambiguity.