AOT support for dotnet clients

[SamuelCox]

Is your feature request related to a problem? Please describe.
I work at a company that makes heavy use of the dotnet clients in our lambdas. Currently we are blocked from upgrading to AOT when dotnet 8 comes out because this library, as far as I am aware, does not support AOT.

Describe the solution you'd like
Dotnet clients, or at least a dotnet client library, to support AOT compilation.

Describe alternatives you've considered
Roll our own opensearch library. Move to rust or some other AOT compiled language.

Additional context
None that I can add in public.

[jeastham1993]

@SamuelCox you can exclude certain libraries from trimming when using native AOT. In your csproj file you can either set the TrimMode to partial, which will only trim libraries that are trim friendly. Or you can explicitally exclude a specific assembly using the TrimmerRootAssembly propery. Example csproj below:

<Project Sdk="Microsoft.NET.Sdk">

	<PropertyGroup>
		<OutputType>exe</OutputType>
		<TargetFramework>net8.0</TargetFramework>
		<!-- PublishAot tells the compiler to publish native AOT binaries. -->
		<PublishAot>true</PublishAot>
		<TriomMode>partial</TrimMode>

	</PropertyGroup>

	<ItemGroup>
		<TrimmerRootAssembly Include="OpenSearch.NET" />
	</ItemGroup>
</Project>

Use with care - If you are going to take this approach, I'd recommend testing pretty extensively. But it does give you the ability to simply exclude libraries that aren't yet AOT friendly from being trimmed.

Microsoft Docs on TrimOptions

[SamuelCox]

Hmm, that's a good workaround which we will have to investigate once dotnet 8 comes out.
However, I could be completely misremembering/misunderstanding, but aren't we conflating two (related) issues here?

Trimming stops code from being eliminated that the compiler thought was dead, but actually could have been called into dynamically by reflection. But if I remember correctly, aren't there whole reflection APIs that are just outright not supported in AOT as well? That presumably wouldn't be solved by trimming right? Am I misremembering how AOT works?

[Xtansia]

There's a related issue #370 regarding trimming and the use of reflection & dynamic assemblies in the client, that includes a workaround pending a fix in ILLink

[Xtansia]

I'd have to do some experimenting myself, but I believe the client's entire JSON (de)serialization stack (Utf8Json) is fundamentally incompatible with AOT due to its use of runtime dynamic code generation. Probably other reflection uses around the client relating to field inference and such that'll be incompatible too. So I don't believe this will be an easy shift.

[SamuelCox]

Yeah, that was my understanding, thanks. Agree that its not an easy shift, even if opensearch was compatible we'd have to rewrite significant parts of our stack. But for our company, we operate at scale and are all-in on serverless. So AOT represents both a massive cost saving in AWS billing, and a significantly better UX for customers

[SamuelCox]

Its interesting that you use Utf8Json, I note that the official ES library (from before OpenSearch forked it) has said that they are moving to System.Text.Json as Utf8Json is no longer actively maintained
https://github.com/elastic/elasticsearch-net/blob/c75fea62e7d05abf98304092ef43904beb7476a8/docs/migration-guide.asciidoc#L102

Is this not the case for this library? Would my company benefit from moving to the lower level opensearch driver, or does that also use Utf8Json under the hood?

[Xtansia]

Its interesting that you use Utf8Json, I note that the official ES library (from before OpenSearch forked it) has said that they are moving to System.Text.Json as Utf8Json is no longer actively maintained https://github.com/elastic/elasticsearch-net/blob/c75fea62e7d05abf98304092ef43904beb7476a8/docs/migration-guide.asciidoc#L102

Is this not the case for this library? Would my company benefit from moving to the lower level opensearch driver, or does that also use Utf8Json under the hood?

OpenSearch.Net was forked from the 7.12 branch (at https://github.com/elastic/elasticsearch-net/tree/8d64d4c026ff116eb45e83c05610b6ac430b4376) of ES rather than v8 or main, to mostly match up with the point at which the server was forked (~7.10). So those changes were not carried over, there was another issue regarding adding support for System.Text.Json #388, which we can change to be instead migrate from utf8json to system.text.