Is it possible to use .NET 6 runtime with SST? I know it is supported by Lambda now, and I see it is supported by the CDK itself, but I haven’t been able to get it working with an SST project. Let me know if someone can clarify this isn’t supported or if I’m just doing something wrong? The same project setup works with a .NET 3.1 project

Hey @Austin yeah

.NET 6

is not yet supported.

We can move forward without it, but it would be awesome to have in the near future. For context we’ve been a heavy .NET shop and deploying in containers but my specific team is really trying to get the overall team more exposed to serverless. Using C# functions is a good way for us to bridge the gap in the short term to help devs use something familiar where we can, and most of our new stuff is being built with .NET 6 as it is the next LTS version of the framework and .NET 3.1 will be end of support later this year I believe. Hope that helps!

Got it! Just curious, are you using Live Lambda Dev (ie.

sst start

) with the .NET functions currently?

We’re actively experimenting with that currently. We don’t have any production projects using SST and C# lambdas yet. We’re prototyping a project with 3.1 lambdas right now, and we have successfully used Live Lambda Dev to build/invoke the .NET function. I think maybe there is a limitation on debugging though, is that correct?

limitation on debugging

Could u expand on that a bit more?

Like attaching IDE debugger / doing breakpoint debugging of C# functions with Live Lambda Dev. Haven’t tried that yet but wasn’t sure if it supported

Ah, gotcha. I was recently talking to @Kevin Baker about getting breakpoint debugging to work with Python.

I’ll definitely try and let you know. One other question, do you know if I can overwrite the dotnet executable SST uses? I have a weird scenario because I’m on an M1 Macbook Pro and .NET 3.1 is not officially supported on M1 Macs, so it has to be installed in a non-standard way with a different path to the dotnet sdk / executable. I can’t get SST to build it because it isn’t using the correct dotnet executable.

Yes, Although I’m more focused on getting breakpoints working for Golang than Python. Let me know if you make any progress, I’m guessing the patterns would be similar.

@Frank does SST use

dotnet watch

under the hood for .NET Live Lambda reloading? I’ve got a project working with .NET 6 (which is awesome) and Live Lambda Dev is working fine. I see it is rebuilding the assembly when files are modified. I’m looking into trying to get VS Code debugging working with it. The challenge might be that the

dotnet

process isn’t actually started until the Lambda is invoked, so there isn’t a way to attach to it that I have found. But if

dotnet watch

is being used, it might be possible.

super keen to learn about debugging support for C# also.

After using SST with C# a bit more and looking at how SST bootstraps C# functions, i think it will not really be possible without doing the bootstrapping differently. Because the dotnet process is not actually running until the Lambda function is invoked, and it shuts down after each invocation. This makes it really hard to manually attach a debugger to if there is no persistent dotnet process. Each individual function invocation is a different dotnet process. This definitely works like the real Lambda runtime, so that is good, but it isn’t the greatest for debugging.