Consider function.proj or something similar for .NET Core Assembly Inclusion

[markekraus]

One key to success for csx functions is the ability to include a function.proj to added .NET Core assemblies to the runtime. I realize it would be possible to build a custom module that includes the desired assemblies and deploy it with the function, but I think that's probably not the right path.

One example usecase: I'm trying to port my StaticFileServer function to the ps runtime. I rely on Microsoft.AspNetCore.StaticFiles.FileExtensionContentTypeProvider to resolve the mime type of the file.

For a C# function, access to the AspNetCore assemblies via .csproj for compiled and function.proj for csx is essential and easy. PowerShell lacks many of the features in the default modules and runtime to make it an effective webserver language.

Another suggestion may be to include a large number of AspNetCore libraries in the PS function runtime.

[TylerLeonhardt]

This is something I've been thinking about.

In one of my Functions I needed to parse a multipart form data which, in most languages, is a solved problem because there already exists a library that does so...

PowerShell doesn't have as much experience being a web server so the proper modules are not available to do basic web server tasks.

I didn't want to include ASP.NET because of its size and "kitchen sink" mentality... but maybe we should revisit that thought.

[markekraus]

@TylerLeonhardt The Multipart form-data .NET APIs should already be in PS Core due to them being used in the web cmdlets. But yea.

Even the C# compiled and CSX runtime doesn't include all of ASP.NET. It does however, include a decent chunk of it by default and allows you to add what you want with the function.proj or project.csproj files.

Even if a bunch of modules started to be authored by the community for acting like a web server, I fear they would result in dependency hell as they may use conflicting versions of the ASP.NET assemblies. If we provide the assemblies then module authors can focus on just wrapping them and presenting PowerShell commands.

[SteveL-MSFT]

I wonder if this is something that should be part of PackageManagement which already has a Nuget provider?

[markekraus]

@SteveL-MSFT That works too. The idea would be whatever the analog is, it runs once on runtime init and the assemblies are available as long as the instance session persists.

[daxian-dbw]

dotnet is available in the sandbox, so we can adopt the same function.proj convention as C# script function does, and restore the package referenced in that file by dotnet restore funciton.proj --packages <package-store-path>.
We will have to duplicate the function-host code that handles function.proj in the PowerShell worker, for example InitializeAssemblyRegistry.

The flow would be:

1. Run dotnet restore on fucntion.proj to download the nuget packages.
2. Read the generated project.assets.json file (need NuGet.ProjectModel for this, so worker size will increase ~4mb) and get paths to the runtime assemblies of those packages.
3. Register AssemblyLoadContext.AssemblyResolve event to look for assembly in the paths generated from step 2.
4. For function authors, all they need is to add Add-Type -AssemblyName in profile.ps1 to load the needed assembly at the cold start. This would be similar to the #r directives used in C# script functions.

@markekraus I quickly looked at the related function-host code, it looks to me the function-host only care about package references declared under the netstandard2.0 framework. My question for you is, do you think the PS worker can do the same?
Like you said, the host already includes a decent chunk of ASP.Core, so it's probably OK for it to only consider netstandard2.0 framework, but I'm not sure if that's fine for PS worker too since we don't carry anything from ASP.Core. I would like your opinion on this, given your valuable experiences in this area :)

[daxian-dbw]

The unnatural part of supporting function.proj file is that, the PowerShell worker will have two deps configuration files: requirements.ps1 and function.proj.
This seems redundant, and it's feasible to support NuGet packages in requirements.ps1 -- we would need one more step in the flow above: extract the package name/version, and generate the .proj file by dotnet add.
However, I see two problems of doing that:

1. Generate a dependency config file from another config file -- that basically make our slow cold start even slower.
2. It means the user has to enable the dependency management feature (have "dependencyManagement": true in host.json) to get the NuGet package support in PS worker. This seems unreasonable to me.

I personally prefer to directly support function.proj file. But the dependency management feature could be updated to automatically update the versions of the referenced NuGet packages, if the user chooses to.