Refactor package structure for Azure Functions usage

[TylerLeonhardt]

This puts the worker.config.json and the Modules folder under the publish/workers/powershell directory.

The actual powershell worker dlls and dependency dlls will be dropped in the publish directory. I worked with @pragnagopa on this.

This means that all the core-tools has to do is reference the PowerShell Worker nuget package and everything works as expected.

This PR also addresses #18 by renaming everything from Azure.Functions.PowerShell.Worker to Microsoft.Azure.Functions.PowerShellWorker

[TylerLeonhardt]

I just realize that this change means I need to change the README

[daxian-dbw]

I sign off on this PR. However, having worker.dll and its dependency assemblies in publish while having worker.config.json and Modules in publish\powershell\worker feels hacky, and it makes the local testing harder -- consider copying the publish folder directly to azure-functions-core-tools\bin\workers\powershell currently vs. copying parts of the artifacts to azure-functions-core-tools\bin and parts to azure-functions-core-tools\bin\worker\powershell.

If we cannot get the assemblies copied to publish\worker\powershell by generating the nupkg along with dotnet publish, then we probably should consider doing the nuget pack in a different step, treating all the artifacts produced by dotnet publish as the content of the nuget package, so that all powershell worker related files can be placed together under worker\powershell. It doesn't hurt to have a build script to chain dotnet publish and dotnet pack.

On a second thought, we probably have to do the packaing in a different step anyway, because we need to sign the assemblies first, and the generated nupkg should contain the signed assemblies. By generating the nupkg along with dotnet publish, the nupkg contains the unsigned assemblies.

[TylerLeonhardt]

I can change it so that you do a nuget pack after a nuget publish but the biggest problem still remains.

It's not possible to have dlls and dependencies placed in another location than the publish dir. We would have to redistribute all dlls as content Files... Including the dependencies of the worker.

[daxian-dbw]

We would have to redistribute all dlls as content Files... Including the dependencies of the worker.

Yes, that's what I'm suggesting -- we treat all files under publish dir as content files.
This sole purpose of this nupkg is for the azure function host to consume. The Microsoft.Azure.Functions.PowreShellWorker.dll is actually an EXE. It won't be consumed by anything else as a library.

[TylerLeonhardt]

I'm fine with doing what you're mentioning, It's just kinda abusing NuGet though. At that point, we might as well grab a release from Github releases.

I've kinda had different conversations about this with @pragnagopa and @SteveL-MSFT. I'd appreciate your input here.

I'm fine with redistributing everything and at least that follows the Java worker at the moment.

[pragnagopa]

The Microsoft.Azure.Functions.PowreShellWorker.dll is actually an EXE. It won't be consumed by
anything else as a library.

@daxian-dbw has a good point. Shipping it as exe makes more sense. If you guys agree, I can look into functions host on adding support for running a language worker as exe

[daxian-dbw]

@tylerl0706 I wouldn't say it's abusing nuget package -- that's how Install-Package works. PowerShell release daily builds as nuget packages to powershell-core-daily feed on myget.org, and they are consumed by install-package, see https://github.com/PowerShell/PowerShell/blob/master/tools/install-powershell.ps1#L108-L127 in our Install-PowerShell.ps1.

@pragnagopa I don't think we should ship an EXE directly, because that means we create a self-contained application including all .NET Core framework assemblies, which will increate the package size greatly. We still want to keep the powershell worker a Fx dependent application, which means it's a dll, but essentially acts like an EXE with dotnet <worker-name>.dll. In this way, we can share the dotnet core runtime with the Azure Function Host on box and shrink the package size a lot.

[TylerLeonhardt]

Ok so now, there's a new folder called package at the root of the directory. It has a nuspec and a csproj in it. The only reason the csproj is there is because dotnet pack only works with csprojs

Here are the steps you would do:

cd azure-functions-powershell-worker
dotnet publish
cd package
dotnet pack

that will give you a nupkg in:

azure-functions-powershell-worker/package/bin/Debug

It pulls the contents of the publish folder in:

azure-functions-powershell-worker/src/bin/Debug/netcoreapp2.1/publish

if you specify a different Configuration or TargetFramework that will be honored.

[daxian-dbw]

Can we use a separate PR for the packaging changes? The existing changes in this PR are mainly renaming, and it can be merged already.

[TylerLeonhardt]

:(

[TylerLeonhardt]

@daxian-dbw I sent a rename PR out here:
#35

When that goes in, I'll rebase that to this.

[daxian-dbw]

@tylerl0706 I know that requests extra work 😄 but it makes the PR more scoped, and will also make it easier to review the packing changes you are making.

You can git stash save the second and third commits locally. Once the first commit gets merged, you can git stash pop to get back your changes.

New changes were pushed

[TylerLeonhardt]

closing in favor of #36