This is great!

Aspire has a code-based application model that is used to represent your application (or a subset of your application) and its dependencies. This can be made up of containers, executables, cloud resources and you can even build your own custom resources.

During local development, we submit this object model to the local orchestrator and launch the dashboard. This orchestrator is optimized for development scenarios and integrates with debuggers from various IDEs (e.g. VS, VS code, Rider etc, it's an open protocol).

For deployment, we can take this application model to produce a manifest that (which is basically is a serialized version of the app model with references). Other tools can use this manifest to translate these aspire native assets into deployment environment specific assets. See https://learn.microsoft.com/en-us/dotnet/aspire/deployment/m...

This is how we support Kubernetes, azure, eventually AWS etc. Tools translate this model to their native lingua franca.

Longer term, we will also expose an in-process model for transforming and emitting whatever manifest format you like.

That's how innovation happens.

You can update dependencies on your own. The model is quite extensible and nuget is great. You can override container image tags, or any settings we default to. That's the great part about using code!

What stuff was that?

If I made mistakes feel free to file an issue or even send me a PR. It's open source! That said, you're right that I don't say how best to call sync from async methods (the latter is more difficult as there's no good way do it well).

Here’s the original NuGet source tree

https://github.com/NuGet/NuGet2/graphs/contributors

I don't think that's a complete view as nuget started on codeplex (!) and I think the commit history wasn't imported fully (mine is missing)

I stand corrected. Sorry.

Forgiven

Yes, I was one of the NuGet creators.

I was the O.G. NuGet developer, so yes, I was one of the creators.

Oh, TIL then !

ASP.NET Core does include those things you mentioned are not included.

We've been experimenting with NativeAOT for years with ASP.NET Core (which does runtime code generation all over the place). The most promising prototypes thus far are:

- https://github.com/davidfowl/FasterActions - https://github.com/davidfowl/uController

They are source generated version of what ASP.NET does today (in both MVC and minimal APIs). There are some ergonomic challenges with source generators that we'll likely be working through over the coming years so don't expect magic. Also its highly unlikely that ASP.NET Core will not depend on any form of reflection. Luckily, "statically described" reflection generally works fine with NativeAOT.

Things like configuration binding, DI, Logging, MVC, JSON serialization all rely on some form of reflection today and it will be non-trivial to remove all of it but we can get pretty far with NativeAOT if we accept some of the constraints.

As of right now, we're trying to make sure "motivated people" can play with it, but it's not something that is supported by ASP.NET Core or EF at the moment. https://github.com/dotnet/aspnetcore/pulls?q=is%3Apr+nativea...

PS: Some of the challenges https://github.com/dotnet/aspnetcore/issues/42221

Thanks for your hard work with the .NET community David.

Thanks for using .NET!

Actually system text json does work with source generators and di can work with source Generators aswell.

Thanks for telling me :). On a serious note though, anything can work with source generators but it doesn't match the style of coding that we'd like (moving everything to be declarative isn't the path we want to go down for certain APIs). Also source generators don't compose, so any source generation that we would want to use would need to take advantage of the JSON source generator (if we wanted to keep things NativeAOT safe). Right now most of the APIs you use in ASP.NET Core are imperative and source generators cannot change the callsite so you need to resort to method declarations and attributes everywhere.

That's not an optimization, that's a programming model change.

> Also source generators don't compose, so any source generation that we would want to use would need to take advantage of the JSON source generator

This is the biggest challenge I see, there are times where either Expression.Compile or T4 still 'feels' cleaner than sourcegen.

Well in system text json the api keeps the same and you „only“ need to pass an autogenerated meta object its basically the same api you just need to pass another object instead of an generic Parameter. But yeah its a change.

It’s incredibly exciting to follow your work and the teams!

Thank you!