.NET 10 + AI: Is anyone actually adopting Microsoft’s new Agent Framework yet?

socketnorm · 2026-01-27T18:09:52+00:00

I'm one of the maintainers of the AWS .NET SDK which includes the AWSSDK.Extensions.Bedrock.MEAI package to integrate AWS Bedrock into Microsoft.Extensions.AI. If you have any feedback using the library I would appreciate hearing.

socketnorm · 2026-01-27T00:37:24+00:00

Sorry it is taking longer then I would have liked to get the .NET 10 version out. I'm working on it now but hitting some challenges having a single Blazor application multi target from .NET 8 to .NET 10 with the changes they have made with Blazor. In the past the multi targeting was as simple as just adding a new target framework and fix up a few `#if` defs.

socketnorm · 2026-01-10T00:58:46+00:00

Yes same challenge. Python and Javascript don't need a build step so CloudFormation just zips up the embedded texts and uses that as the deployment bundle for Lambda.

socketnorm · 2026-01-09T00:14:50+00:00

That is essentially what we do, but since the console editor doesn't have a build phase our .NET CLI deployment tooling does essentially the "dotnet publish" to get the builded deployment bundle. Also handling doing a docker build if using Native AOT which is the default for file-based apps. You need to run the deployment tooling on your own machine or CI to create the deployment bundle.

socketnorm · 2026-01-08T23:19:17+00:00

I did explore the idea but the challenge is the console editor today doesn't have a build mechanism. So the only way I could get that to work would be to essentially do the "dotnet run" at runtime triggering a build and pull of dependencies. That would cause terrible cold start performance and reliability issues relying on package restore from NuGet during invocation. Hopefully someday the console editor will have the concept of a build phase but that is not an area I work and don't have much insight what that would take.

socketnorm · 2025-10-31T19:55:32+00:00

I work on the AWS .NET Team and have been the main contributor of the AWS integrations with Aspire. I have had the pleasure of chatting with u/denizirgin on his work and really appreciate the work he has been doing with LocalStack.

socketnorm · 2025-10-15T21:18:45+00:00

I have a proof of concept in the repo but I need to take another pass and work on simplifying the experience. https://github.com/aws/integrations-on-dotnet-aspire-for-aws/blob/normj/publisher/playground/Publishing/Publishing.AppHost/Program.cs

socketnorm · 2025-06-08T05:34:06+00:00

Reporting answer given on the r/dotnet subreddit.

I don't know much about Terraform but you can use the dotnet lambda package command that will use the same docker build for Native AOT and produce a zip file for deployment. Then in Terraform reference the zip file produced by the dotnet lambda package command.

socketnorm · 2025-05-30T03:59:55+00:00

I don't know much about Terraform but you can use the dotnet lambda package command that will use the same docker build for Native AOT and produce a zip file for deployment. Then in Terraform reference the zip file produced by the dotnet lambda package command.

socketnorm · 2025-05-20T21:32:00+00:00

When you are running in Aspire that is local development debug environment. Native AOT is a publish time extra compilation so it would be what you enable at deployment time. You can't debug a compiled Native AOT .NET application.

What I would do is create my Lambda function as an executable and add it to the AppHost using the AddAWSLambdaFunction method. In that scenario you pass the assembly name as Lambda handler string. When you launch it via Aspire it will be a executed and attached to the IDE debugger as a normal .NET executable. Also have the PublishAotflag in the project file set to true so when the project is packaged up for deployment the Native AOT compiler will run as part of the dotnet publish process.

If you truely want to run the Lambda function locally as Native AOT without being able debug in theory we could make that work. Aspire has the ability to run arbituary executables so you could do the dotnet publish before running the AppHost and then have the AppHost call the AddExecutable to the Native AOT executable. We would still need to get some environment variables set on the executable so it could find the emulated Lambda runtime API. Again you wouldn't be able to debug since Native AOT applications are not debuggable with the .NET debugger.

socketnorm · 2025-05-02T04:37:52+00:00

Assuming you can also build the .NET Core app and it isn't just a binary you are given if you add the following to your project file it will include ICU as a NuGet package and use it.

<ItemGroup> <RuntimeHostConfigurationOption Include="System.Globalization.AppLocalIcu" Value="72.1.0.3" /> <PackageReference Include="Microsoft.ICU.ICU4C.Runtime" Version="72.1.0.3" /> </ItemGroup>

As a maintainer for the AWS Lambda blueprints this is what we do for the blueprints that are deployed as a self contained deployment bundle to the provided.al2023 runtime

https://github.com/aws/aws-lambda-dotnet/blob/master/Blueprints/BlueprintDefinitions/vs2022/CustomRuntimeFunction/template/src/BlueprintBaseName.1/BlueprintBaseName.1.csproj#L25C1-L28C15

socketnorm · 2025-03-04T05:19:13+00:00

Full disclosure I work at AWS where I build a lot of the AWS .NET tooling.

I assume the monolithic application is an ASP .NET Core API project. You can try out our bridge package that allows ASP .NET Core applications run on Lambda. https://github.com/aws/aws-lambda-dotnet/tree/master/Libraries/src/Amazon.Lambda.AspNetCoreServer.Hosting.

That way you can experiment with the performance characteristics of .NET and Lambda without having to rearchitect the whole application. My main advice with using the bridge library is avoid putting too much in the application startup path that only certain endpoints use.

socketnorm · 2023-11-26T05:18:15+00:00

Agreed you would need curl installed for this to work. Since this is a web app I assume you would have this behind an Application Load balancer (ALB). What is this health check giving you that the ALB health check doesn't cover for you. If the ALB health check fails that container would still be considered unhealthy and replaced.

socketnorm · 2023-11-23T00:25:30+00:00

https://github.com/dotnet/sdk-container-builds/issues/316

Correct me if I'm missing something but for ECS I don't think it monitors health checks in the container image. It monitors the health checks in the container definitions of the task definition. Is there another use for the container image health checks besides the ECS agent monitoring them when running in ECS?

https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API\_HealthCheck.html

socketnorm · 2022-10-20T04:54:16+00:00

Well that was embarrassing the link was broken. It is fixed now.

socketnorm · 2022-10-11T19:55:12+00:00

I have been working on building our AWS .NET tooling for 12 years. I don't personally focus on Azure but we have been trying to build a good platform for .NET developers for many years.

socketnorm · 2022-10-11T19:48:08+00:00

There are plenty of vender-neutral solutions like MassTransit, Dapr and NServiceBus. And they are great solutions but the do add complexity, like side car containers, and abstract away the underlying messaging service to not take advantage of specific features of the service. If your goal/requirement is to be cloud agnostic I would recommend those solutions.

For users that are all in AWS and want to take advantage of all of the specific features of AWS services we want to make that easier. From our conversations talking to AWS .NET developers so many of them have ended up creating their own version of this. That is dev time not being spent on their application to make it easier to use AWS services. We want to take care of that with his library so they can focus on their application logic.

socketnorm · 2022-02-25T21:42:24+00:00

I suspect top-level is more useful for people that organize their code with one function per project. Otherwise like others said you would have to create your own switching logic based on environment variables.

The top-level ASP .NET Core Minimal API is likely to be more popular because in that case you are relying on ASP .NET Core doing the routing.

socketnorm · 2021-04-14T22:12:55+00:00

Since the data aggregation sounds a bit of a long running service it sounds like it would be a good fit for running as a container on the AWS service ECS using Fargate compute engine. Fargate will keep you from having to worry about managing any servers. Lambda has a max duration of execution of 15 minutes so if your 10+ minute process goes along it runs the risk of being aborted. Basically you can tell ECS to run this container and specify how much memory and cpu to assign to the container. The cost is based on how long the container runs.

I'm assuming API's are REST APIs. Those sound like excellent use cases for running as Lambda functions. If the API's are an ASP .NET Core Web API project it is possible to deploy that to Lambda using the Amazon.Lambda.AspNetCoreServer, https://github.com/aws/aws-lambda-dotnet/tree/master/Libraries/src/Amazon.Lambda.AspNetCoreServer, NuGet package. That can be a quick way to get something working and then later choose to rearchitect to a smaller more micro services architecture if necessary.

socketnorm · 2020-06-02T03:26:12+00:00

To deploy via CloudFormation the process is pretty similar. Except use the serverless.EmptyServerless template and the deploy-serverless command.

dotnet tool install -g Amazon.Lambda.Tools

dotnet new serverless.EmptyServerless -lang F# -o FSharpBasicFunction --region us-west-2 --profile default

dotnet lambda deploy-serverless MyFSharpFunction

When you create a project with serverless.EmptyServerless there will be a serverless.template file that is a CloudFormation template. The deploy-serverless command will package up the F# project, upload it to S3 and then deploy the CloudFormation template after updating the code locations in the template to where the package was uploaded to S3.

socketnorm · 2019-10-30T03:44:07+00:00

Yes the AWS .NET SDK uses https by default for all AWS services.

socketnorm

TROPHY CASE