Please note that I’m not an expert. This article is purely based on my personal experience and knowledge from reading tons of blog posts, release announcements, doing personal experiments, and sneaking through the dotnet repo’s issues, pull requests, etc.

Let’s dive in.

Publish Size

First, I wanted to see the publish size, as it’s one of the main areas of focus for the .NET team. I checked the published executable size for the default console app template which just has one line:

Console.WriteLine("Hello, World!");

Here’s the result in the last 4 versions:

As you can see, much of the size reduction comes in .NET 8, and it has reduced even further in subsequent releases. Now, it’s sitting around 1 MB, which is really impressive.

I examined the published executable using sizoscope to see what has changed between .NET 7 & 10.

As we can see, each assembly shown here was trimmed down massively.

Enough of the “Hello World” project. Let’s move on to a real-world project.

Aspire CLI

Aspire CLI is a native CLI executable compiled using .NET Native AOT. The latest daily(Aspire 13) build is ~15 MB in size and the CLI invocation is almost instantaneous. To my knowledge, this is the first major officially supported CLI tool from Microsoft published using Native AOT, demonstrating the viability of AOT for real-world CLI scenarios. There’s more to come (dotnet CLI 👀)

Minimal API

Minimal API announced support for NativeAOT back in .NET 8. At the time, the ecosystem was not mature enough to deploy realistic workloads on NativeAOT. While I recognize that a lot of NuGet packages still lack NativeAOT support, it’s in a much more favorable position than it was a few years ago. If you’re developing and maintaining APIs that handle a large volume of traffic with strict SLA requirements, it’s worth exploring minimal APIs in AOT publish mode. This way, you can benefit from fast startup time, reduced memory usage, smaller app size.

However, note that JIT tends to achieve higher peak performance in the long run as it optimizes code at runtime. In some environments, you may trade some Requests Per Second (RPS) in AOT for deterministic startup and memory profiles. So, it’s worth running benchmarks for your own APIs and seeing how it works in your case.

AWS Lambda Functions

AWS Lambda functions have supported Native AOT since .NET 8. In their announcement blog post:

“Benchmarks show up to 86% improvement in cold start times by eliminating the JIT compilation”

Azure Functions

Azure Functions supports NativeAOT, but the functions team recommends Ready to Run (R2R) mode to mitigate the cold start problem, as they see better results.

“Although Functions does have the ability to run NativeAOT compiled apps, we have a more efficient approach for cold start mitigation that is automaitcally applied (which actually leverages a combination of NativeAOT, custom .NET hosting and other technologies). That, combined with ready-to-run, yields better results in our environment than NativeAOT.”

Avalonia UI

Avalonia, the popular cross-platform desktop framework, also now supports NativeAOT deployment.

Windows App SDK

Windows App SDK 1.6 shipped with Native AOT support. From their release notes:

“In our sample Contoso Camera app, we measured a 50% reduction in start time, an ~8x reduction in package size when using a framework package, and a ~2x reduction in package size when using Windows App SDK in self-contained mode.”

I personally tried the WinUI Gallery App, which was compiled with Native AOT. The app launched almost instantly and felt snappier.

.NET MAUI

Windows

.NET MAUI on Windows uses the Windows App SDK under the hood, and is going to get support for Native AOT publish as well. From this issue, I understand it’s going to be released slightly after .NET 10, maybe as part of servicing.

Android

Loads of work went into NativeAOT for Android in the .NET 10 release cycle and in previous releases, and it’s almost ready. Vyacheslav Volkov tested it in .NET 10 RC2 and here’s what he has to say:

“I rebuilt my test app for .NET 10 RC2 (net10.0-android, PublishAot=true) and the results are very encouraging: Galaxy Note 10+ Startup (with heavy initialization): 271–331 ms
MonoAOT comparison: 1s27-1s41ms on the same project
Everything launches and runs, and the startup speed improvement is substantial. Thank you to everyone involved for pushing this forward”

iOS & Mac Catalyst

iOS/Mac Catalyst had AOT since the beginning using Mono. iOS/Mac Catalyst now supports NativeAOT since .NET 9, whereas experimental support was added in .NET 8.

File-based Programs

File-based programs is a new feature in .NET 10 where we can directly create and run C# (.cs) files. By default, file-based apps are published in Native AOT mode because the PublishAot flag is set to true.

Hear from Damian Edwards (PM Architect in the .NET team):

“I’m considering changing my stance to be more bold on this now and say in this new world of file-based apps we could default them to publish native AOT. Be the change you want to see and all that. We likely won’t get another chance to change a default like this for a very long time.”

This is huge because they are pushing AOT in the normal publishing flow (only for file-based programs for now). This can lead to more awareness and adoption in the community.

.NET Tools

Before .NET 10, developers were able to publish only framework-dependent dotnet tools. From .NET 10, it is now possible to ship native binaries compiled using Native AOT as a dotnet tool.

This makes the distribution of native executables easier for those who are already shipping .NET tools, and we can expect them to have faster startup times when they start using this feature.

Console/CLI Frameworks

It’s now possible to build fully AOT-compiled native CLI executables using some of these popular libraries:

• System.CommandLine
• Spectre.Console
• ConsoleAppFramework
• Terminal.Gui

Package Ecosystem

Many popular libraries have enabled support for Native AOT. Some won’t ever support it unfortunately, but alternative new packages are evolving in the ecosystem. As Native AOT adoption grows, certain patterns are becoming common to tackle the limitations:

• Using C# Incremental Generators (v2 Source Generators) instead of reflection-based approaches.
• Using C# Interceptors to intercept existing code and replace it in an AOT-friendly way.
• Using trimming annotations, which are attributes and patterns that help the linker safely remove unused code during publish.

Some of the AOT-friendly packages that I’ve come across:

• Serilog
• Polly
• Kiota
• Octakit
• Sep
• SepEx
• MSTest
• StackExchange.Redis
• OpenTelemetry
• DapperAOT
• and the list goes on

Azure Packages

More Azure packages have added support for AOT. You can see from the changelog that every month there’s a mention of trimming and AOT support:

• https://azure.github.io/azure-sdk/releases/2025-05/dotnet.html
• https://azure.github.io/azure-sdk/releases/2025-07/dotnet.html
• https://azure.github.io/azure-sdk/releases/2025-08/dotnet.html
• https://azure.github.io/azure-sdk/releases/2025-09/dotnet.html

As far as I’m aware, many of the commonly used Azure SDK packages have been updated with AOT support. One exception that I know of is Microsoft.Azure.Cosmos, which may get AOT support in v4.

I came across an interesting blog post about a CLI tool azddns which uses some of the Azure SDKs, compiled and published as a Native AOT executable.

New Packages

Some of the newly announced packages come with AOT support out of the box. Here are some of them that come to mind:

• Microsoft.Extensions.OpenApi
• Microsoft.Extensions.Validation
• C# MCP SDK libraries
• Microsoft.Extensions.AI libraries
• Microsoft.Agents.AI

PowerToys

The ‘Command Palette’ utility in PowerToys started shipping in AOT compilation mode, and here’s what they say in release v0.93:

“Command Palette reduced its startup memory usage by ~15%, load time by ~40%, built-in extensions loading time by ~70%, and installation size by ~55%—all due to using the full Ahead-of-Time (AOT) compilation mode in Windows App SDK.”

Future

• dotnet CLI itself as a native executable? Highly likely in the next release https://github.com/dotnet/msbuild/issues/12141
• EF Core? Potentially in the future https://github.com/dotnet/efcore/issues/34446
• WinForms? Maybe in the future - https://github.com/dotnet/winforms/issues/4649
• There could be more! We’ll find out next time

Closing Thoughts

I can see a real push for Native AOT from Microsoft and growing adoption in the .NET ecosystem, which is great to see. When I see the PRs that made Native AOT possible in many of these cases, I notice that it requires deep technical understanding of the constraints and workarounds. In some cases, it won’t be possible to support at all due to the limitations.

At the end of the day, it comes down to your app and whether it works for you and you’ll benefit from it or not. In my opinion, it’s worth exploring this area if you are building CLIs, large-scale APIs, desktop or mobile applications.

If I have missed any other interesting project or if you’d like to share your personal experience in building AOT applications, please let me know in the comments.

Thanks for reading… Happy AOT’ing!

Sometimes, we want to use the date and time as is from the API without any local date time conversion, convert UTC time to the local time, or do any timezone-related logic. Since developers will be working in the local timezone of their system, it’s hard for them to simulate different timezones on the fly and do the testing.

But not until we know this shortcut 🤔

Yes! It’s possible to easily simulate different timezones right inside the browser. The change takes effect immediately.

How to Change Time Zone in Browser

If you are using a chromium-based browser, head on to the Dev Tools window and look for the Sensors tab.

We can enable the Sensors tool from the More Tools option:

And then from the list, we need to enable the Sensors tab:

We can see the option to choose the location from the dropdown:

By default, some locations come pre-loaded. We can select any of them or define our own:

Before going ahead, let’s look at the timezone information returned from the Date API in JavaScript. At this time, it returns my local timezone:

Now, let’s switch to another location in the sensors tab. I’m choosing London:

If we invoke the Date API again, we can see that the timezone is changed as per our setting in the Sensors tab:

Points to remember:

• We don’t need to refresh the page for this to take effect. But, if the app uses any logic on the page load time, then you may need to refresh the page.
• The change affects only the current tab.

How to Set Custom Timezone

In order to set any custom timezone, we need to know the Timezone ID from the IANA Time Zone Database. You can find the list of all the timezone IDs here.

Let’s say if we want to set the timezone of New York, we need to use America/New_York. The GMT is -05 or -04 based on daylight savings. Since we need only the timezone change, we can leave the Latitude and Longitude as 0:

If we invoke the Date API again, we can see that our required timezone is reflected:

In this way, we can easily change the timezone of the browser tab and test our web application.

Using Extension

Another option is to use a browser extension which is much easier if you don’t want to play around with timezone IDs back and forth. I’ve found one such extension here:

Change Timezone for Google Chrome Extension

Conclusion

In this article, we’ve learned how to change the browser time zone for quickly testing the web application without messing around with the system settings.

I have been following this for a very long time. So why not give it a spin?

Let’s get started.

For .NET 7, Native AOT mainly focuses on console applications. So, let’s create a simple console application:

dotnet new console -n HelloWorld

The Program.cs class contains a simple statement to print “Hello, World!”:

Console.WriteLine("Hello, World!");

Publishing as Single File

Before proceeding to publish using Native AOT, I wanted to know how the same app looks on a single file publish.

So, let’s publish this application as a single file using the .NET CLI command:

dotnet publish -c Release -r win-x64 -p:PublishSingleFile=true --self-contained true

Here if we look at the published output, the size is 64.75 MB. But this includes not just our program but also the runtime because of the use of --self-contained true flag:

Let’s add one more switch PublishTrimmed which will remove all the unnecessary code in our application (including all the Base Class Libraries(BCL) and package references):

dotnet publish -c Release -r win-x64 -p:PublishSingleFile=true -p:PublishTrimmed=true --self-contained true

Now, the PublishTrimmed option significantly reduces the size to 11.30 MB!

Single file publish includes all the assemblies in a single file. Therefore, it makes the app distribution easier.

But the published output contains Intermediate Language (IL). JIT compiler needs to convert it to native code at runtime. This works great for most scenarios. But it’s not ideal for resource-constrained environments and where the application startup time is crucial.

Let’s add one more switch PublishReadyToRun. R2R improves the startup performance by compiling the code on the startup path directly to native code. R2R places the native code alongside the IL. Hence, there is a slight increase in the published application size (14.76 MB):

Publishing as Native AOT

Unlike R2R, Native AOT complies entire application to native code just like C++, Go, Rust, and similar others.

Now, let’s go ahead and publish the same console application as Native AOT using the PublishAot MSBuild property:

dotnet publish -c Release -r win-x64 -p:PublishAot=true

Alternatively, we can specify the property in .csproj file as well:

<PropertyGroup>
    <PublishAot>true</PublishAot>
</PropertyGroup>

After running the command, with obj and bin folders removed, it took me under 9 seconds to produce the native binary. But later, it took me under 3 seconds:

Impressive! the application size is only 3.65 MB! The published output is purely native. No Intermediate Language (IL) is present. But why 3.65 MB for a simple “Hello, World!” application you might ask? Well, these results are for good defaults. But, we can further reduce this size. Please look for optimizations here.

What about something more than just a “Hello, World!” project? Well, here’s a tweet from @MStrehovsky:

The best part of this? `PublishTrimmed` now actually means "publish the whole app trimmed". Here's size numbers for a sample app that uses ImageSharp to save a PNG file before and after Preview 7. The NativeAOT numbers are especially nice. https://t.co/hNw0nanFVd pic.twitter.com/lYxkQUuMXU

— Michal Strehovský (@MStrehovsky) August 10, 2022

We know this is just the beginning and there’s more to come. I just can’t wait to see more real-world projects making use of Native AOT and show us their results. Are you building a cool project using Native AOT? Please let everyone know in the comments!

Also, let’s take a moment to appreciate all the people who were involved in getting this feature out for all of us!

If you wish to read more on publishing using Native AOT, Microsoft has detailed documentation here.

Happy Coding 🙂

PDF can be designed & generated using popular libraries like iTextSharp. But they are quite complicated and time-consuming to achieve the expected design. But if you are a web developer already, you will find it easy and quick to design with HTML & CSS and later convert it to PDF.

Let’s move on to see how to generate PDF from HTML in ASP.NET Core running on .NET 5.

There are two parts to this.

• Generating dynamic HTML string —  using Razor.Templating.Core. (With the power of Razor language which is already being used in MVC views)
• Converting HTML to PDF  — using jsreport

Generating HTML

Let’s create a new solution using the .NET CLI command. One can use Visual Studio as well.

dotnet new sln -n HtmlToPdf

I’ve added a new ASP.NET Core Web API project to the solution as below

I removed the default files Weatherforcast.cs & WeatherForecastController.cs

and added PdfController.cs with one Get action method which looks like this.

Next, I added a Razor Class Library(RCL) project named HtmlToPdf.Template to create HTML template for our pdf.

HtmlToPdf.Template.csproj file should look like the below. If not please change as below.

I grabbed some HTML from here created by Daryl Shannon and added it to PdfTemplate.cshtml file under the Views folder.

I’ll add a reference to the HtmlToPdf.Template project to HtmlToPdf.Api

Also, I’ll install Razor.Templating.Core NuGet package to HtmlToPdf.Api project to render the PdfTemplate.cshtml file to a string. One good thing about this package is that we can even pass the view model to render the HTML string dynamically. For complete guidance on using this package, refer to this article. For simplicity’s sake, I’ll simply render the static HTML.

Now, all I need to do is to call the await RazorTemplateEngine.RenderAsync("~/Views/PdfTemplate.cshtml")` method to render the string out of .cshtml file

Let’s quickly run the API project & see if the .cshtml to string works.

YES! Now we have the html string in hand.

HTML To PDF

I’ll be using JsReport library to convert HTML to PDF. Add the following references to your HtmlToPdf.Api.csproj

Use the following code to generate the PDF out of HTML string & return the file in the API.

[HttpGet()]
public async Task<IActionResult> Get()
{
    var html = await RazorTemplateEngine.RenderAsync("~/Views/PdfTemplate.cshtml");
    var rs = new LocalReporting()
                .KillRunningJsReportProcesses()
                .UseBinary(RuntimeInformation.IsOSPlatform(OSPlatform.Windows) ? JsReportBinary.GetBinary() : jsreport.Binary.Linux.JsReportBinary.GetBinary())
                .Configure(cfg => cfg.AllowedLocalFilesAccess().FileSystemStore().BaseUrlAsWorkingDirectory())
                .AsUtility()
                .Create();
    var generatedPdf = await rs.RenderAsync(new RenderRequest
    {
        Template = new Template
        {
            Recipe = Recipe.ChromePdf,
            Engine = Engine.None,
            Content = html,
            Chrome = new Chrome
            {
                MarginTop = "10",
                MarginBottom = "10",
                MarginLeft = "50",
                MarginRight = "50"
            }
        }
    });
    return File(generatedPdf.Content, generatedPdf.Meta.ContentType, "GeneratedPdfFile.pdf");
}

If we run the api & hit https://localhost:5001/pdf, we can notice that the pdf file is downloaded!

Let’s look how does the pdf file look like

Voila!! Now we’ve rendered the HTML string into PDF.

Running on Linux using Docker

As we know, ASP.NET Core & JsReport are cross-platform, one might want to host it on a Linux server. Initially, it was a pain for me to write the Dockerfile to install the required dependencies for jsreport. Though, there were some examples. I had to face some rough edges. After googling & installing the required dependencies, I was able to successfully host it on a Linux machine(I used Ubuntu 20.04 here)

Here’s the Dockerfile.

FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base
RUN apt-get update
# for jsreport
# install chrome with deps, see https://github.com/jsreport/jsreport/blob/master/docker/full/Dockerfile
RUN apt-get install -y --no-install-recommends libgconf-2-4 gnupg git curl wget ca-certificates libgconf-2-4 && \
wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - && \
sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' && \
apt-get update && \
apt-get install -y lsb-release google-chrome-stable fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst libxtst6 libxss1 --no-install-recommends
RUN apt-get install -y gconf-service libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0 libgtk-3-0 libnspr4 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxss1 libxtst6 libappindicator1 libnss3 libasound2 libatk1.0-0 libc6 ca-certificates fonts-liberation lsb-release xdg-utils wget
ENV chrome_launchOptions_executablePath google-chrome-stable
ENV chrome_launchOptions_args --no-sandbox,--disable-dev-shm-usage,--single-process,--no-zygote
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY ["HtmlToPdf.Api/HtmlToPdf.Api.csproj", "HtmlToPdf.Api/"]
RUN dotnet restore "HtmlToPdf.Api/HtmlToPdf.Api.csproj"
COPY . .
WORKDIR "/src/HtmlToPdf.Api"
RUN dotnet build "HtmlToPdf.Api.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "HtmlToPdf.Api.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "HtmlToPdf.Api.dll"]

Key Takeaways

If you want to generate the PDF in a background service or console application, that can also be done. Instead of ASP.NET Core, one needs to create the Worker Service or Console application and use the same project reference and code. You might notice that it takes 1 or more seconds to generate the PDF as jsreport is using a headless chrome browser on the server to generate the PDF from HTML. Generally, that should be ok. You might be surprised to see that the Docker image size is around 1GB when you add jsreport whereas the normal size is around 100MB. It’s because the image needs to have chrome dependencies. I believe this can be optimized. Full code available here: RazorTemplating/examples/_RealWorldSamples/HtmlToPdf at master · soundaranbu/RazorTemplating (github.com)

Hope this article is helpful. Let’s meet in another one. Thanks!

Happy Coding 🙂