I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

davidfowl commented 2 days ago •

I think we can get really far with ASP.NET if user code isn't trimmed but framework code is.

I don't see EF in scope either. How do people do data things? ADO.NET?

agocke commented 2 days ago

At the moment we're sticking with user code not being trimmed by default.

As for EF, I think it strongly depends on what people use. My impression is that grpc is more important for microservice-type apps, but this really isn't my area of expertise. My hope is we can use apps like YARP to drive some of this investigation.

hez2010 commented 2 days ago •

I don't see EF in scope either.

I used to build a demo for using EF with NativeAOT, it requires a bit heavy manual written runtime directives but it works without any problem. However, EF can definitely annotated itself for better trimming support and get rid of the need of runtime directives.

See https://github.com/hez2010/EFCore.NativeAOT

davidfowl commented 2 days ago

but this really isn't my area of expertise

Luckily, this is my area of expertise .

I'd like to manifest a document that describes the patterns that are AOT unfriendly. I've spent quite some time with native AOT and ASP.NET Core and it would be nice to have a doc for library authors that want to enable trimming to better understand the rules of the game

davidfowl commented 2 days ago

@agocke any reason to keep this a package? Why not have it be first class like the other publish experiences?

snickler commented 2 days ago

Awesome! Does this also have a line item for ensuring it works well in regards to modern Desktop application support? This is a huge want for those migrating from UWP and .NET Native.

agocke commented 2 days ago •

@davidfowl Thanks for the feedback, much appreciated. So I take it EF is really common? In that case, I think it would be useful to find a representative app to flush out problems. As you know, serializers are probably the most common problem with trimming, so let's see what we can bring into scope.

I'd like to manifest a document that describes the patterns that are AOT unfriendly. I've spent quite some time with native AOT and ASP.NET Core and it would be nice to have a doc for library authors that want to enable trimming to better understand the rules of the game

We've added some documentation for this at https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming/fixing-warnings. Feedback welcome!

Any reason to keep this a package? Why not have it be first class like the other publish experiences?

That's more a technical description in that we need a "package" to ship it in. It seems like we could integrate this with the publish experience, although we might need a workload for additional dependencies. One thing to also keep in mind is that we have a dependency on certain native toolchain pieces as well, like link.exe or an equivalent linker.

agocke commented 2 days ago

@snickler No plans for GUI apps yet. There's been some success experimenting with WinForms -- it's very close to trimmable once ComWrappers is integrated. We'll just need to see how much bandwidth we have for .NET 7 and how difficult it is to make some of these things trimmable/AOT compatible.

jkotas commented 2 days ago

migrating from UWP and .NET Native.

This depends on microsoft/CsWinRT#373

lukemcdo commented 2 days ago •

Is there any way a NativeAOT UWP target could be officially supported (or even experimental/beta status) for app services only? This would be a positive tool to help keep modern tools available for UWP while WinUI goes through its teething issues. It would also give a way to build code against .NET 7 and shuffle things out from a UWP code base in-place.

Obviously this wouldn't include official UI support or anything revolutionary.

davidfowl commented 2 days ago

Will the AOT compiler support the trimming attributes without configuration OOTB, that is, will it only trim assemblies marked as trimmable by default?

hez2010 commented 2 days ago •

will it only trim assemblies marked as trimmable by default?

That's not how NativeAOT work. The NativeAOT compiler generates code at compile-time instead of run-time, and there're no IL code and JIT compiler in compiled artifacts so even if the compiler doesn't trim anything, you still may encounter exception due to missing code at runtime.

For example, for a generic type Foo<T> the compiler need to figure out what Ts are being substituted into before it can generate code for it, so below pattern will results in no code generated for Foo<int>:

private Type innerType;

void Boom(Type t)
{
    typeof(Foo<>).MakeGenericType(new [] { t }); // no generated code for `Foo<int>`
}

void Test()
{
    innerType = typeof(int);
    Test(innerType);
}

Besides, there're lot of even complex patterns that cannot be statically analyzed during compile-time so the compiler can only rely on trimming attributes and runtime directives (rd.xml) and it's hard to be made out-of-the-box.

Will the AOT compiler support the trimming attributes without configuration OOTB, that is, will it only trim assemblies marked as trimmable by default?

If we ignore nuances related to AOT and generics that @hez2010 mentions above for a moment, the trimming experience should match PublishTrimmed in .NET 6 - by default only assemblies marked IsTrimmable are trimmed (pretty much just the framework at this point) and further configuration is possible through MSBuild properties. That configuration will do the same things wrt trimming irrespective of whether trimming is done by IL Linker or the NativeAOT compiler. It should already be like this in the latest NativeAOT packages from runtimelab. Any behavior difference between a JIT-based world and AOT-based world in trimming would be a bug.

davidfowl commented 2 days ago •

@hez2010 thanks for the explain (I know how it works ).

@MichalStrehovsky great!

filipnavara commented 2 days ago

Are there any plans to port generics sharing from ProjectN?

Are there any plans to port generics sharing from ProjectN?

If you mean universal shared code, it's not in scope for now. We want to lean into having predictable performance characteristics as opposed to wider compatibility at the cost of unpredictable perf for now.

(Universal shared code turns the generic problem @hez2010 mentioned above into a non-issue because the compiler pregenerates a universal native method body that works for any T. This comes with costs in terms of runtime performance of such method. It works great if such code runs as rarely as possible. But it fills me with dread if such code were to be in a hot path, such as SixLabors/ImageSharp#1703 where the T represents a pixel in a bitmap and the code is going to do hundreds of millions of operations with it.)

Good to see that .NET is the programming platform for Azure developers only.

I mean the majority of the world runs on AWS but the AWS SDK or GCP SDK is nowhere mentioned here.

This is complete bullshit and I'm sick of being treated like some second class peasant by Microsoft if I'm not using Visual Studio + Azure:

I mean the majority of the world runs on AWS but the AWS SDK or GCP SDK is nowhere mentioned here.

@dustinmoris I understand where you're coming from given the past couple of weeks, but to be 100% clear on what that bullet means - we are not going to special case Azure SDK in .NET or NativeAOT. It came to our attention (or my attention, really because I dealt with the bug) that if someone references a lot of the Azure SDK NuGet packages combined with a bunch of other NuGet packages, the app becomes so big that NativeAOT fails to compile it (Azure/azure-sdk-for-net#24238). Azure libraries really stand out with their size. Trimming needs to be enabled for them using the publicly available mechanism. This just tracks the Azure SDK issue on our side. I've updated the top post to link the issue. I hope that clears it up. The mechanism is public, documented, and anyone can use it.

@MichalStrehovsky Thanks for the clarification. From the issue it sounded like "let's focus primarily on ASP.NET Core + Azure SDK apps being super efficiently trimmed first".

It came to our attention (or my attention, really because I dealt with the bug) that if someone references a lot of the Azure SDK NuGet packages combined with a bunch of other NuGet packages, the app becomes so big that NativeAOT fails to compile it

Hopefully the team will test this with other SDKs as well so other issues don't go unnoticed for AWS or GCP users.

En3Tho commented 2 days ago •

Annotating or refactoring all other possible SDKs to be AOT-friendly is not in scope of this issue tbh.

I guess when .Net 7 and native AOT lands MS will have to deal with another wave of "Why Azure works but my beloved XXX SDK not"?

Surely MS have to provide a very careful and thorough guide of how to make libraries AOT friendly. But 1) in a general case this is a library maintainer's duty, not MS. 2) Not all libraries can be refactored to be AOT friendly, especially if they are heavy run-time codegen based.

hez2010 commented 2 days ago •

Hopefully the team will test this with other SDKs as well so other issues don't go unnoticed for AWS or GCP users.

The trimming support is done by annotating the library itself for trimming compatibility. AWS and GCP sdk authors should annotate their own libraries for better trimming support and make sure they're AOT-friendly. That's not something can be done on .NET NativeAOT or ILLinker toolchain side.

However, EF can definitely annotated itself for better trimming support and get rid of the need of runtime directives.

@hez2010 thanks a lot for the link to that repo. For others curious about how DB access may work in AOT case, Dapper AOT may also be worth keeping an eye on. https://github.com/DapperLib/DapperAOT/

roji commented 2 days ago

Re EF, we do intend to work on trimming friendliness for 7.0, and ideally make EF fully compatible (tracked by dotnet/efcore#21894). I'll take a look at going beyond that and looking into NativeAOT compat as well, though no promises as of yet...

yekanchi commented 2 days ago

Does nativeAOT remove IL from the published output?
so the C# code will be compiled(exported) to machine-specific code somehow like what GO, C++ compilers build?

hez2010 commented 2 days ago

Does nativeAOT remove IL from the published output? so the C# code will be compiled(exported) to machine-specific code somehow like what GO, C++ compilers build?

galvesribeiro commented 2 days ago •

This is complete bullshit and I'm sick of being treated like some second class peasant by Microsoft if I'm not using Visual Studio + Azure:
Hopefully the team will test this with other SDKs as well so other issues don't go unnoticed for AWS or GCP users.

@dustinmoris the tools for trimming are/will be available. Any package author can leverage it. It is not reasonable that the team has to run it across all NuGet.org packages. I believe it would be more productive if you open an issue on their SDK repos asking to play the ball and use the tools that allow trimming.

I understand that we're all upset (with real reasons to be!) with all the drama that happened recently, but that doesn't sounds a reasonable approach to have to test all against every possible package.

If the package authors will have/are having issues with the tools, they should just jump in here and report why the trimming isn't working for them.

Most of us is quite aware for how long both AWS and GCP SDKs are far from optimal, with poorly generated code and tons of memory leaks. They are the ones who were treating .Net as second class peasants. It is just a matter of how other languages were well supported there, while .Net never was. Now it seems that AWS has a dedicated team working on making their SDKs better, so hopefully it will come to a point to treat .Net community the same way as the other ones.

Does going with NativeAOT mean that there is no CLR, nor any other runtime?

Does going with NativeAOT mean that there is no CLR, nor any other runtime?

By itself NativeAOT is a runtime but in compilation process combines it with the application.

normj commented 2 days ago

Happy to help test scenarios with the AWS .NET SDK. We don't do a lot of reflection in the SDK but I'm sure there are areas we need to add the trimming attributes.

@galvesribeiro Sorry your experience with the SDK hasn't been positive. I don't want to derail this thread but you can reach out to me about your issues via email at normj@ and I'm guessing you can figure out the domain part (hint: amazon.com).

Hopefully the team will test this with other SDKs as well so other issues don't go unnoticed for AWS or GCP users.

So what would the Amazon team and Google team be doing when Microsoft annotates their own SDKs for them?

agocke commented 2 days ago

@normj Happy to hear it! Trimming compatibility is a .NET 6 scenario, so please feel free to give it a try and reach out with any questions. Instructions and documentation for library authors is available at https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming/prepare-libraries-for-trimming

robloo commented yesterday

Best news I've heard in months!

ShreyasJejurkar commented yesterday

Please keep this thread technical oriented only and discuss AOT stuff here instead of ranting.

Thank you.