Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions without reflection ?

I have tried to compile my .NET 5 bare http server project with Native AOT without reflection. This is possible for a normal http connection, but not for a https connection because in Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions the line of code:

var loggerFactory = listenOptions.KestrelServerOptions?.ApplicationServices.GetRequiredService<ILoggerFactory>() ?? NullLoggerFactory.Instance;

that appears twice in this class requires reflection. Could it be changed to:

var loggerFactory = listenOptions.KestrelServerOptions?.ApplicationServices?.GetRequiredService<ILoggerFactory>() ?? NullLoggerFactory.Instance;

so that it has the ? after ApplicationServices. In this way I believe the reflection can be avoided.

[LLT21]

David, Michal,

I went around the iceberg in the last 2 weeks. Here are the results of my testing.

There were 2 types of aspnetcore issues with the native compilation of my test project in https://github.com/LLT21/NativeAOT5:

1. I had to change the lines https://github.com/dotnet/aspnetcore/blob/af981028f48078eaa42b1cc66658424abcb296e1/src/Servers/Kestrel/Core/src/Middleware/HttpsConnectionMiddleware.cs#L74 and https://github.com/dotnet/aspnetcore/blob/af981028f48078eaa42b1cc66658424abcb296e1/src/Servers/Kestrel/Core/src/Middleware/HttpsConnectionMiddleware.cs#L130 to:

_logger = new NativeLogger<HttpsConnectionMiddleware>(loggerFactory, “Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware”);

like in https://github.com/LLT21/NativeAOT5/blob/24cc92d1fb47489e05a2b0c19b0ebec40b088026/kestrel/HttpsConnectionMiddleware.cs#L123 ; the new logger class is in the same file https://github.com/LLT21/NativeAOT5/blob/24cc92d1fb47489e05a2b0c19b0ebec40b088026/kestrel/HttpsConnectionMiddleware.cs#L46.

1. As of line https://github.com/dotnet/aspnetcore/blob/af981028f48078eaa42b1cc66658424abcb296e1/src/Servers/Kestrel/Core/src/Middleware/HttpsConnectionMiddleware.cs#L513 I also had to replace the CoreStrings with a NativeCoreStrings alternative as in: https://github.com/LLT21/NativeAOT5/blob/24cc92d1fb47489e05a2b0c19b0ebec40b088026/kestrel/HttpsConnectionMiddleware.cs#L30 and https://github.com/LLT21/NativeAOT5/blob/24cc92d1fb47489e05a2b0c19b0ebec40b088026/kestrel/HttpsConnectionMiddleware.cs#L555

One more CoreStrings value I had to replace in https://github.com/dotnet/aspnetcore/blob/af981028f48078eaa42b1cc66658424abcb296e1/src/Servers/Kestrel/Core/src/Internal/Infrastructure/TransportConnectionManager.cs#L82 (similar issue). These CoreStrings are used even without generating an exception.

For the CoreStrings I tried with the parameterized compilation proposal of Michal, but that didn’t work on my side. Maybe because sometimes there are values inserted in the strings ?

By making these 2 types of changes, I can now run Kestrel https natively compiled. Great !

Then I wanted to fetch some data from a SQL Server database, also native. Unfortunately the native compiled program gave up:

1. With System.Data.SqlClient at the Open of the SqlConnection
2. With Microsoft.Data.SqlClient at the creation of the SqlConnection

What worked for me was to switch to System.Data.Odbc. That natively runs and I can read records from SQL Server with the DataReader. At the moment, the SQL Server ODBC driver does not yet exist for my OSX ARM, but it does work on my Intel one. I have also seen on the internet that the ARM ODBC driver is planned for July.

Finally I wanted to convert the result from SQL Server to Json. For reading the following code works natively: https://github.com/LLT21/NativeAOT5/blob/24cc92d1fb47489e05a2b0c19b0ebec40b088026/Program.cs#L109 ; for writing: https://github.com/LLT21/NativeAOT5/blob/24cc92d1fb47489e05a2b0c19b0ebec40b088026/Program.cs#L150 ; I also included what did not work in comments: https://github.com/LLT21/NativeAOT5/blob/24cc92d1fb47489e05a2b0c19b0ebec40b088026/Program.cs#L90

So basically with 2 types of changes in aspnetcore, switching to ODBC and some low level Json handling, I can do what I was looking for.

If you could include the 2 types of changes (probably there are better implementations than mine) in aspnetcore in your future plans, that would really help me and I guess many others. I am belonging to the 20% of developers who are looking at native AOT technology to obfuscate the code (https://github.com/dotnet/runtime/issues/41522). Even if there is a tendency to more open source, some developers still would like to make a living from writing specialized code and protecting this.

In that respect I have 2 more general questions:

1. It would be ideal if there would be a list of some “special use cases” - like the one I am trying to achieve (web api connecting to SQL Server and returning json) - for which Microsoft offers a native AOT solution. For my use case, besides the 2 types of changes in aspnetcore, a SqlConnection with special overload that also natively runs would certainly help. And with some simple changes, I believe the higher level Json functions are not far from native support. I fully understand it will not be for all functionality, so a subset on which we can build if we like, is probably the best case.

2. Being pleasantly surprised that it actually works, I would like to ask Michal even if you make more native compilation options in the future, that you also keep the one without reflection: this is the best guarantee to protect the code we would like to protect. In some cases this can be important.

Hope the above helps. It has deviated from the original request for the better. Finally, let me say “thank you” for what we already can achieve in this area today and for the help building my trust.

Luc

On 24 Apr 2021, at 19:41, David Fowler @.***> wrote:

I would just use the DLL and do <Reference Include="PathToAssembly" />

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/aspnetcore/issues/31561#issuecomment-826127769, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKO6WGDNGMODICQML5H3SO3TKL7FRANCNFSM42O4F65Q.

[davidfowl]

@LLT21 Excellent work!

For the CoreStrings I tried with the parameterized compilation proposal of Michal, but that didn’t work on my side. Maybe because sometimes there are values inserted in the strings ?

@MichalStrehovsky are there any guides on how to add support for “System.Globalization.Invariant” mode? Are you saying we would need to have a switch in our code to check for the AppContext setting and skip resource manager when that was set? Seems like something we could just bake into Resgen. How does the runtime implement this? Are there any pointers?

@LLT21

The logger changes look easy to fix here without NativeLogger, so that’s not a big deal but I fear that pattern is used pervasively and I would prefer if it were possible to fix the Logger<T> implementation. Though I’m not sure if that’s possible (any ideas here @MichalStrehovsky ?) without runtime or compiler changes. The I could see an intrinsic like nameof(T) that would allow resolving the full name of the T at AOT/JIT time.

That said, I don’t have a problem making this change in Kestrel with a comment specifying that there’s a narrow “no reflection” scenario for AOT here that this enables to keep it from regressing.

As for JSON, we have a new source generator that you’ll want to try out here that will allow you to keep using the JSON serializer but doesn’t depend on reflection based metadata. (cc @layomia)

I don’t have any comments about SQL or ODBC but I’ll cc @roji as an FYI.

Finally, we don’t have any tests for this scenario so it’ll likely regress in strange ways until we have some basic scenario checked in that we run (this is similar to how we do handling linking managed code today).

In the end, this is a very cool experiment and one that I’m happy to make changes (within reason) to keep it working for your scenarios. It’ll also teach us more about AOT 😄

PS: There’s some code clean up you can do, I’ll send a pull request.