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

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.

[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.

[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 😃