-
Notifications
You must be signed in to change notification settings - Fork 511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using ObjCRuntime from custom .NET runtime host (or outside a Xamarin app bundle in general) #18437
Comments
I also stumbled upon https://github.com/veldrid/veldrid/blob/367f3ec52f92ffe65681cafd16cb65d9f89e0af0/src/Veldrid.MetalBindings/ObjectiveCRuntime.cs which seems to be the only other way to interact with the ObjectiveC runtime and seems to work fine so far. It would still be nice to have easily accessible (and more complete) official bindings though. |
We might be able to ship as only two separate files: a native dylib and the managed Microsoft.macOS.dll assembly, and then the consumer would need to some API to load/initialize the native library and/or Microsoft.macOS.dll before being able to use any other API in Microsoft.macOS.dll. However, this is a rather big undertaking, and is unlikely to happen any time soon. There are thus two options:
In any case I'm leaving this issue open, since it's a totally valid request. |
Could you kindly give a general breakdown of what tasks would be required to make this happen? I'd love to know where to start experimenting with stuff. Does NativeAOT impact this, now that it's supported? Would you be able to statically link against the native code (built as a dylib) and have it "just work" without needing a new API to initialize said library? |
No, unfortunately NativeAOT does not make things simpler at the moment. In order to make NativeAOT work we currently we require the trimmer to run with some custom linker steps that transforms our existing codebase into something that works with NativeAOT, and that would not be easy to implement outside our app bundling logic.
The first step would be to define exactly what you want to do (from a developer/user perspective). From the top of my head here are a few ideas, with the immediate drawbacks I can think of:
Personally I feel that option 2 and 3 are what people are most likely to want, and I believe it's also much easier to implement. I think I'd go for making something like this work: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net8.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.macOS.Console" Version="1.2.3.4" />
</ItemGroup>
</Project> Features that would have to be dropped:
This would be my way to create a proof-of-concept:
|
I'm looking for a way to use the Xamarin bindings for MacOS without having a fully fledged AppBundle. Our software is just a (unmanaged) plugin to another software and hosts the .NET runtime itself (as described in https://learn.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting). I tried switching the TargetFramework to net8.0-macos, but that doesn't work. I'm stuck with using net8.0. So if there was a way to reference Microsoft.macOS.dll, and a way to initialize things correctly, that would be great. Right now we write bindings to every ObjC type that we want to use manually, and that gets tedious. |
How is the problem now? Do you have a plan to fix it? |
There has been no progress, and it's not on the roadmap at the moment either. |
I am attempting to use the ObjCRuntime from a custom .NET runtime host on macOS, specifically targeting
net8.0-macos
(same issue for net7 as well). However, I encounter the following exception when executing a DLL directly:The error message suggests that the
__Internal
library or its dependencies cannot be loaded. I understand that currently, the only way to run the application is through the executable in the generated app bundle which provides these exported functions.For my use case it would be helpful if the initialization process performed by the Xamarin wrapper could be replicated in a custom .NET runtime host, or even better all necessary bindings moved to a native portable dylib. This would enable the use of ObjCRuntime and other Xamarin bindings outside of the generated app bundle.
There seems to be a similar issue here ForNeVeR/AvaloniaRider#237 (comment).
Steps to Reproduce
dotnet new macos
.dotnet build
.dotnet MyApp.dll
.Expected Behavior
Runs the application.
Actual Behavior
Exception described above.
Environment
Version information
Build Logs
N/A
Example Project (If Possible)
Described in steps to reproduce
The text was updated successfully, but these errors were encountered: