SourceGeneratorLambdaJsonSerializer documentation for AddAWSLambdaHosting is not clear

[petro2050]

Describe the issue

After turning on PublishTrimmed, I noticed this line is throwing an error:

builder.Services.AddAWSLambdaHosting(LambdaEventSource.HttpApi);

Using member 'Microsoft.Extensions.DependencyInjection.ServiceCollectionExtensions.AddAWSLambdaHosting(IServiceCollection, LambdaEventSource)' which has 'RequiresUnreferencedCodeAttribute' can break functionality when trimming application code. For Native AOT the overload passing in a SourceGeneratorLambdaJsonSerializer instance must be used to avoid reflection with JSON serialization.

In another case, the instructions were clear:

await LambdaBootstrapBuilder.Create(handler, new SourceGeneratorLambdaJsonSerializer<MyContext>()).Build().RunAsync();

See this summary. I was able to provide a custom context with the required request/response types.

So, in the first case, how should we provide a custom context?

• Is there a default context we can use?
• How should the serialization options be configured if we want backwards compatibility with the non-trimmed code?
• Do we need to register every request/response object (used in controllers) manually?

Links

SourceGeneratorLambdaJsonSerializer

[normj]

The error message is saying you need to use the overload of AddAWSLambdaHosting to pass in the context like the following. The name of the method isn't in the actual error message because the message is being given for that method call. Would it have helped if we did put AddAWSLambdaHosting explicitly in the error message?

builder.Services.AddAWSLambdaHosting(LambdaEventSource.HttpApi, new SourceGeneratorLambdaJsonSerializer<LambdaJsonContext>());

[petro2050]

@normj I understand we need to pass in the context. My question was more about the details of the context itself.

Is there a default context we can use? How should the serialization options be configured if we want backwards compatibility with the non-trimmed code? Do we need to register every request/response object (used in controllers) manually?

In your example, I don't think LambdaJsonContext is pre-defined?

In the case of this example, it was clear we needed to register APIGatewayHttpApiV2ProxyRequest and APIGatewayHttpApiV2ProxyResponse.

[ashishdhingra]

@normj I understand we need to pass in the context. My question was more about the details of the context itself.

Is there a default context we can use? How should the serialization options be configured if we want backwards compatibility with the non-trimmed code? Do we need to register every request/response object (used in controllers) manually?

In your example, I don't think LambdaJsonContext is pre-defined?

In the case of this example, it was clear we needed to register APIGatewayHttpApiV2ProxyRequest and APIGatewayHttpApiV2ProxyResponse.

@petro2050 Thanks for the reply. Please elaborate your use case with an example and if possible, propose the code documentation change to make it more clearer.

Thanks, Ashish

[Dreamescaper]

@petro2050
It's more related to Trimming support in System.Text.Json / AspNetCore than to lambdas per se. I suggest to to read this article: https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/source-generation

Answering your questions:

Is there a default context we can use?

No, if you have to support trimming.

Do we need to register every request/response object (used in controllers) manually?

Yes.

[github-actions[bot]]

This issue has not received a response in 5 days. If you want to keep this issue open, please just leave a comment below and auto-close will be canceled.