Investigate removing dependency on `dotnet` executable in the path

[TylerLeonhardt]

Right now, because the Azure Functions host calls the worker using:

dotnet ./path/to/worker/Microsoft.Azure.Functions.PowerShellWorker.dll

dotnet has to be in the path... Ideally, we shouldn't have to do this and either bundle the runtime with the worker or share the runtime with Azure Functions Host.

Firstly, we need the host to give us a way to run single executables:

Today we have to specify an executable path and a worker path:

{
    "description":{
        "language":"powershell",
        "extensions":[".ps1", ".psm1"],
        "defaultExecutablePath":"dotnet",
        "defaultWorkerPath":"Microsoft.Azure.Functions.PowerShellWorker.dll"
    }
}

Ideally those would be the same thing:

{
    "description":{
        "language":"powershell",
        "extensions":[".ps1", ".psm1"],
        "defaultWorkerExecutablePath":"Microsoft.Azure.Functions.PowerShellWorker.exe"
    }
}

But, that would only work on Windows... so we'd need to be able to specify different executables on macOS and Linux so we can be cross platform:

{
    "description":{
        "language":"powershell",
        "extensions":[".ps1", ".psm1"],
        "defaultWorkerExecutablePath": {
            "windows":"Microsoft.Azure.Functions.PowerShellWorker.exe",
            "macos":"Microsoft.Azure.Functions.PowerShellWorker",
            "linux":"Microsoft.Azure.Functions.PowerShellWorker",
    }
}

I've already had to mention to a couple people that .NET SDK is required... and the Azure Functions Core Tools are moving away from the dependency on dotnet cli...

@pragnagopa @asavaritayal @fabiocav can you weigh in here?

(cc @SteveL-MSFT @joeyaiello @daxian-dbw)

[pragnagopa]

@TylerLeonhardt - following should work. Did you try it?

{
    "description":{
        "language":"powershell",
        "extensions":[".ps1", ".psm1"],
        "defaultWorkerExecutablePath":"Microsoft.Azure.Functions.PowerShellWorker.exe"
    }
}

Validation of worker config: https://github.com/Azure/azure-functions-host/blob/dev/src/WebJobs.Script.Grpc/Abstractions/WorkerDescriptionExtensions.cs does not impose requirement for defaultWorkerPath

To support various platform, you can use profiles. Please see profiles section here for an example: https://github.com/Azure/azure-functions-java-worker/blob/dev/worker.config.json

You can add platform specific profile. Let me know once you have a schema. I will figure out a generic way to support platform profiles on the host.

[daxian-dbw]

I'm afraid we cannot use an executable because that would mean we have to ship many more packages for each release of PowerShell worker -- windows (x64 and x86), macOS, Linux (different distros??). This will take huge disk space.

For microsoft/vscode-azurefunctions#1204 mentioned by @TylerLeonhardt, does it really remove the dependency of dotnet sdk? What will the azure function vscode do with funciton.proj that is used in C# script functions? dotnet sdk is needed to pull down the dependent nuget packages declared in function.proj ...

[pragnagopa]

microsoft/vscode-azurefunctions#1204 - improves extensions installation experience for non dotnet languages and avoid packaging extensions binaries as part of the user code. For debugging, you still need dotnet core.
@daxian-dbw is right. If you do decided to remove dotnet core dependency to run powershell worker, you need to figure out right packaging for all the platforms

[joeyaiello]

We agree that this isn't a GA blocker, but it would be nice to remove the dependency on .NET SDK for customers who don't need dotnet restore for Nuget dependencies (which I'd guesstimate at ~75% of PS customers, but that's really a guess).