Make PowerShell language worker process match the bitness of the host #5011
Conversation
AnatoliB
requested review from
pragnagopa,
Francisco-Gamino and
amamounelsayed
There was a problem hiding this comment.
Thanks for the PR. @maiqbal11 recently added support to specify a format for defaultWorkerPath Please see changes in the PR##4985
We should follow similar approach and add a format string %bitness% for defaultExecutablePath. Let's sync up offline if you need more details.
ghost
added
the
|
@pragnagopa Thank you. This approach (if I understood it correctly) may not be applicable in situations when we are not in control of the directory structure, and the dotnet.exe case seems to be one of them. Let's discuss offline. |
|
@pragnagopa I've also realized that this change would probably not work on Linux, so I'm not going to merge this as is in any case, but let's discuss the proper way. |
| const string DotNetExecutableName = "dotnet"; | ||
| const string DotNetFolderName = "dotnet"; | ||
|
|
||
| if (DefaultExecutablePath == DotNetExecutableName && RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) |
There was a problem hiding this comment.
Use case insensitive comparison
|
|
||
| private void ResolveDotNetDefaultExecutablePath() | ||
| { | ||
| const string DotNetExecutableName = "dotnet"; |
There was a problem hiding this comment.
move these to LanguageWorkerConstants file
| @@ -65,6 +65,7 @@ public IList<WorkerConfig> GetConfigs() | |||
| { | |||
| arguments.ExecutablePath = GetExecutablePathForJava(description.DefaultExecutablePath); | |||
| } | |||
|
|
|||
|
|
||
| [Theory] | ||
| [InlineData("DotNet")] | ||
| [InlineData("dotnet.exe")] |
There was a problem hiding this comment.
we should allow dotnet.exe as running dotnet.exe is same as running dotnet on windows
|
As per our discussion:
See also: #5073 |
…Azure#5011) Make out-of-proc dotnet-based language worker processes match the bitness of the host process
…#5011) Make out-of-proc dotnet-based language worker processes match the bitness of the host process
Addressing Azure/azure-functions-powershell-worker#232
Currently, Functions Host starts the PowerShell language worker by using the
dotnetcommand without specifying the full path. As a result, it always starts the 32-bit version ofdotneton Consumption, simply becauseD:\Program Files (x86)\dotnethappens to be on the PATH environment variable configured on the sandbox. The platform setting on the app is completely ignored.This fix makes the Host invoke
dotnetfrom the ProgramFiles folder (e.g.D:\Program Files\dotnetorD:\Program Files (x86)\dotnet, depending on the current process), so that the bitness of the PowerShell worker process matches the bitness of the Host.The fix is intentionally applied to PowerShell only. Performing the same for other dotnet-based languages may be desirable, but needs to be considered carefully.