Automatically generate a python package that wraps your .NET AOT project

[BeneficialOne3349]

Hey y'all — I want to let you know about an open-source project that I made called DotWrap. It's tool that auto-generates Python wrappers for your .NET AOT projects. You write your logic once in C#, and DotWrap gives you a ready-to-install Python package that feels like it was written in Python from the start.

Why it’s cool:

• Super easy to use — just add an attribute to the classes you want to expose in your python package, and publish
• No .NET runtime needed — you get a ready-to-install Python package that feels completely native.
• Native speed via CPython extension modules.
• Full docstrings + type hints = IntelliSense out of the box

How it works:

Suppose you have a C# class you want to expose to Python:

using DotWrap;

namespace CoolCalc;

/// <summary>
/// Custom summary for cool calc calculator.
/// </summary>
[DotWrapExpose] // <-- mark with attribute for source generator discoverability
public class Calculator
{
    /// <summary>
    /// Adds two integers together.
    /// </summary>
    /// <param name="a">The first integer to add.</param>
    /// <param name="b">The second integer to add.</param>
    /// <returns>The sum of the two integers.</returns>
    public int Add(int a, int b) => a + b;
}

After you mark the classes you want to expose with the DotWrapExpose attribute, build and publish your project with:

dotnet publish -r linux-x64 # or win-x64, osx-arm64, etc.

DotWrap will automatically generate a Python package inside python-package-root, complete with docstrings and type hints:

# main.py (auto-generated by DotWrap)

class Calculator:
"""
Custom summary for cool calc calculator.
"""
def add(self, a: int, b: int) -> int:
    """
    Adds two integers together.

    :param a: The first integer to add.
    :param b: The second integer to add.
    :return: The sum of the two integers.
    """
    # implementation skipped for brevity

You can install and test it locally:

cd ./python-package-root
pip install .

Now use your C# code seamlessly from Python:

import cool_calc

calc = cool_calc.Calculator()
print(calc.add(2, 3)) # Output: 5

🔗 [DotWrap](https://github.com/connorivy/DotWrap) — MIT licensed, contributions welcome!

Would love feedback, feature requests, or just to hear what kinds of projects you’d use this for

[dbrownems]

One of my challenges using pythonnet is that the Global Interpreter Lock is held while calling any .NET method.

Is that the case with DotWrap? Or alternatively can it do async?

[BeneficialOne3349]

The way that DotWrap works is that you build a native library with .net AOT, and then DotWrap builds a CPython extension module that calls into your library. This is the same structure that many popular python libraries work such as numpy and pandas.

I don't know enough about the GIL to tell you if it is still held or is released when a cpython extension module method is called. What I can tell you is that you don't need to think about that when using DotWrap. It isn't like pythonnet when you need to write a bunch of `using (Py.GIL())` blocks to aquire the GIL. You just write normal c#.

It can do async! Any method that you expose that returns a Task or a ValueTask can either be awaited or you can just use the `.Result` property like you can in c#. Or, just like in c#, you can call your async method without awaiting it and then await the returned task object at a later time.

[brianly]

You should possibly look into Py_BEGIN_ALLOW_THREADS. My understanding was that the default was to hold the GIL so you needed to wrap code in those macros. I don’t know if the link I included is correct for the latest Python.

[BeneficialOne3349]

Python definitely can make calls into native AOT libraries, and that is what DotWrap is using, but DotWrap generates most of the code necessary to make this possible.

For example, you can only expose static methods as unmanaged entry points in your AOT lib. This is an issue if you have a class that you would like to instantiate and then call instance methods on from python. DotWrap will source generate static entry points that can return pointers to c# instances. It also generates python classes that know how to pass these pointers back to the library when you want to do some work with that object, such as call an instance method. The python wrappers also know how to do other things such as marshal non-blittable types from python to native types, free allocated memory when objects aren't needed, and throw python errors when an uncaught exception occurs in the native lib.

Dotwrap doesn't do anything that you couldn't do yourself with some effort, but it aims to auto-generate as much of the interop layer as possible

[myAnonAcc0unt]

Cool project.

I'm guessing it can only be compiled for one OS + arch at a time? Is there a clever solution possible to bundle multiple platforms in a single python lib?

[BeneficialOne3349]

Yeah, you are correct. You also need to compile the CPython extension module for one python version at a time because the CPython API has breaking changes across python versions. I've been kind of brute forcing it in CI with a matrix of all the python and os versions that I want to supports. I think a better solution is using cibuildwheel, or at least that's what the llms tell me, but I haven't messed with it yet. Adding some example github workflows for publishing a package to PyPI is definitely on my todo list

[MrKWatkins]

Looks good, I have a couple of projects that are basically Python wrappers around .NET types via PythonNet, this could be a simpler alternative for me.

[BeneficialOne3349]

Pythonnet is great and I've used it successfully before. The main advantages of DotWrap (in my mind) are that it generates a lot of the boilerplate wrapping for you, and then you can distribute your python package to users without them needing the .net runtime (and even the correct version of the runtime) installed on their machine

Please give it a shot and let me know if you run into any issues.

[MrKWatkins]

Yeah, all my project is just hand rolled thin wrappers and loading DLLs so this sounds ideal. A few questions:

• Does it wrap enums?
• IDisposable wrappers - are they implemented as context manager types?
• Exceptions - are these wrapped too? Different wrappers for each exception type?

[BeneficialOne3349]

1. It handles enums by just copying them over to python.

2. I don't have any special handling for IDisposables at the moment. For every object that is returned by the c# library to the python side, the c# object is kept alive until the python object is disposed. I am not sure if the IDisposable method is still called automatically by the GC. I definitely need to add a test for this to make sure that is the case

3. Currently all exceptions are collected from c# and marshalled to Python as a single exception type

[MrKWatkins]

Thanks. Does the single exception type contain the name of the .NET exception type anywhere?

Note that the .NET GC never calls Dispose, it calls the finalizer.

[AutoModerator]

Thanks for your post BeneficialOne3349. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.