Serverless-dotnet-packing NPM

Serverless DotNet

A Serverless v1.2 plugin to build your C# lambda functions on deploy.
Forked from fruffin/serverless-dotnet.

This plugin is for you if you don't want to have to run dotnet restore, dotnet lambda package and add the package will be placed under the package.artifact automatically.

Multiple lambda support (v1.2+)

The following properties can be used in lamdba scope or global scope. For each lambda that does not have a specific value for that property, the plugin will use the global value. The following properties are supported using lambda scope:

projectpath property now can be used also under a lambda scope
projectfile property now can be used also under a lambda scope
projectfilter property now can be used also under a lambda scope
projectruntime property now can be used also under a lambda scope
assemblyname property now can be used also under a lambda scope
namespace property now can be used also under a lambda scope
entrypointclass property now can be used also under a lambda scope
outputpackage property now can be used also under a lambda scope
configuration property now can be used also under a lambda scope
additionalpackagecommand property now can be used also under a lambda scope

Install

npm install serverless-dotnet-packing

Add the plugin to your serverless.yml file:

plugins:
  - serverless-dotnet-packing

Additionally you must have at least one of the following properties under your custom:

-projectpath

It will search recursively for the first .csproj inside of this path.
Must be a relative path to the .sln root folder.

custom:
  dotnetpacking:
    projectpath: ${opt:dotnet-project-path, ''}

It could be used combined with project file.
It will override the project filter.
It will be filled by the plugin if the value is empty or null.

-projectfile

It will search recursively for the first .csproj with this name under the .sln root path.
The extension .csproj is optional.

custom:
  dotnetpacking:
    projectfile: ${opt:dotnet-project-file, ''}

It could be used combined with project path.
It will override the project filter.
It will be filled by the plugin if the value is empty or null.

-projectfilter

It will search recursively for the first .csproj under the .sln root path with this word inside of the .csproj content.

custom:
  dotnetpacking:
    projectfilter: ${opt:dotnet-project-filter, 'AWSProjectType'}

This example is using the property based on AWS Lambda Global Tools.

Customizable properties

-configuration

The configuration to be used in the dotnet lambda package command.

custom:
  dotnetpacking:
    configuration: ${opt:dotnet-configuration, 'Release'}

If nothing is passed, it will use Release internally.

-slnabsolutepath

The absolute path for the .sln file.

custom:
  dotnetpacking:
    slnabsolutepath: ${opt:dotnet-sln-absolute-path, ''}

If nothing is passed, it will consider the serverless path (serverless.yml folder).
It overrides relative path.

-slnrelativepath

The relative path from the serverless path to the .sln root folder.

custom:
  dotnetpacking:
    slnrelativepath: ${opt:dotnet-sln-relative-path, '..'}

If nothing is passed, it will consider the serverless path (serverless.yml folder).

-outputpackage

The absolute, or relative path, to be used as the output for the package created by dotnet lambda package.
Must include the package name with the zip extension.

custom:
  dotnetpacking:
    outputpackage: ${opt:dotnet-outputpackage, 'package.zip'}

If nothing is passed, it will use the default parameters from the command (<PROJECT_FOLDER>/bin/<CONFIGURATION>/<DOTNET_RUNTIME>/<PROJECT_FOLDER>.zip).

-skippacking

This boolean argument will skip the steps of clean and packing (dotnet restore & dotnet lambda package) if true.

custom:
  dotnetpacking:
    skippacking: true

If nothing is passed, it will consider false internally.

-uselambdanamefromproject

This boolean argument will enable the plugin to match lambda by projectfilter value.

custom:
  dotnetpacking:
    projectfilter: ${opt:dotnet-project-filter, 'AWSLambdaFunction'}
    uselambdanamefromproject: true
    my_dotnet_lambda:
      <specific settings>

On the .csproj

<PropertyGroup>
  <TargetFramework>netcoreapp3.1</TargetFramework>
  <AWSLambdaFunction>my_dotnet_lambda</AWSLambdaFunction>
</PropertyGroup>

-additionalpackagecommand

Property to be able to add more parameters on dotnet lambda package command.

custom:
  dotnetpacking:
    additionalpackagecommand: "/p:DebugSymbols=false /p:DebugType=None"

-stdoutlimit

This integer argument will limit the size of internal process outputs. It represents the last 'n' lines.

custom:
  dotnetpacking:
    stdoutlimit: 10

If nothing is passed, it will consider 200 internally.

-maxoutputbuffersize

This integer argument will change the max output buffer size of the internal process.
The value is expected in KB.

custom:
  dotnetpacking:
    maxoutputbuffersize: 1024 # 1MB

If nothing is passed, it will consider 100MB internally.

Properties filled by this plugin

The following properties will be filled by the plugin automacally following the respective steps to get the value for each one ONLY if the property is empty. The plugin will use the filled value otherwise.

-projectruntime

Currently getting this information from <TargetFramework> property in the .csproj file.

functions:
  api:
    <omitting the runtime will filled it automatically>

custom:
  dotnetpacking:
    # It does not required if the value is empty
    projectruntime: ${opt:dotnet-project-runtime, 'dotnetcore3.1'}

It should be used manually $dotnetpacking.projectruntime.
It just works over function runtime scope.

-assemblyname

Currently using the project file without the .csproj.

functions:
  api:
    handler: $dotnetpacking.assemblyname::<namespace>.<class>::FunctionHandlerAsync

custom:
  dotnetpacking:
    # It does not required if the value is empty
    assemblyname: ${opt:dotnet-assembly-name, 'MyAssemblyName.Custom'}

It should be used manually $dotnetpacking.assemblyname.
It just works over function handler scope.

-namespace

Currently using the namespace extracted from entrypoint class file.

functions:
  api:
    handler: <assemblyname>::$dotnetpacking.namespace.<class>::FunctionHandlerAsync
  
custom:
  dotnetpacking:
    # It does not required if the value is empty
    namespace: ${opt:dotnet-namespace, 'MyNamespace.Custom'}

It should be used manually $dotnetpacking.namespace.
It just works over function handler scope.

-entrypointclass

Currently using the class name of the first .cs file that has a reference for Amazon.Lambda.AspNetCoreServer under the project path.

functions:
  api:
    handler: <assemblyname>::<namespace>.$dotnetpacking.entrypointclass::FunctionHandlerAsync

custom:
  dotnetpacking:
    # It does not required if the value is empty
    entrypointclass: ${opt:dotnet-entrypoint-class, 'EntryPoint'}

It should be used manually $dotnetpacking.entrypointclass.
It just works over function handler scope.