2023-01-18 10:00:00
Libraries
This is part of a series on Native AOT.
Previous -- Top -- Next
Native AOT is not just limited to executables. It can also generate libraries, either static or dynamic, compatible with the native code tooling on each platform.
| Platform | Static | Dynamic |
|---|---|---|
| Windows | .lib |
.dll |
| Linux | .a |
.so |
| macOS | .a |
.dylib |
Functions exported by Native AOT libraries use the same conventions as C, so they are usable from any language and platform that can call C, which means ... almost everything.
This opens new opportunities for .NET code to be integrated with other languages and ecosystems.
Many software projects are composed of components written in a variety of languages. With the traditional .NET compilation model (IL + JIT), the impedance mismatch is a significant obstacle. Native AOT offers an opportunity to change that.
Limitations
Using Native AOT to build a library involves all the general limitations of Native AOT, plus some new ones.
Suppose you take your existing C# library and compile it with Native AOT. Even if there no AOT compatibility problems, the resulting native library will contain nothing. This is because Native AOT requires us to explicitly specify what functions should be exported by the library we are building.
And those functions must follow the rules of C. In a nutshell, that means that:
The return type and parameter types must be primitive types (or structs that are carefully designed). Reference types are not allowed.
Exceptions cannot be thrown.
Function names must be unique (no overloading).
Note that we are free to use all [AOT-compatible] .NET features within a Native AOT library, just not in the signature of the exported functions. Inside the library, objects and strings are exceptions are fine, but the Grail cannot pass beyond the Great Seal. That is the boundary, and the price of interoperability.
Native AOT might look bleak at this point, but try not to despair. There are techniques for dealing with these limitations, but they involve effort. If you were hoping to just click one "Native AOT" checkbox and immediately begin calling your C# library from Haskell, you will be disappointed.
Nonetheless, despite the conspicuous absence of a free lunch, there is a lot of cool stuff here to be explored.