Have to admit that MS really seems serious about this and is making a lot of the right sounds and saying a lot of the right things
With recent implementations they have even been matching up what they say with what they do pretty darned well
ExportingAssemblyNE.dll for Windows and ExportingAssemblyNE.dylib for MacOS
(NE stands for Native Exports)
If you look at the code it should be easy enough to understand how to call the functions, the ones named Unmanagedxxx are the ones you would use.
Declare Function UnmanagedVoidInt Lib "ExportingAssemblyNE.dll" As Integer
TextField1.Text = Str(UnmanagedVoidInt)
Trouble is, they don’t work with Xojo. Perhaps one of you much more knowledgable folks can determine why Xojo chokes on them?
Or perhaps see if they can be called from another app, like a C++ app maybe?
What version of VS are you using on Windows ?
Just for reference more than anything
edit - nm VS 2019 Community edition seems fine
That said there is a lot of stuff in the dylib that could be causing issues
There is a bunch of code in there that looks like its a runtime start up for managed code etc
I wonder if stripping everything down to just ONE unmanaged function and nothing else would be a better starting point
Possibly in this project just comment everything out except one unmanaged item to see if what lands in the dylib/dll is a LOT less and maybe that will help
Its a guess at this point
I can take a kick at this after I get some other work done so it might be a lot later tonight or tomorrow
My understanding is that the way these Native Exports functions work is that they include all the managed code. Couldn’t care less if it’s managed or not, as long as I can call it from Xojo. SO many things that just work better in C#. Xojo for the X-Plat UI, C# for the “work”.
Helpers (which I presume you mean console apps?) aren’t that interesting to me - I want libraries that can manipulate large chunks of data at high speed (and multi-threaded) while the main app has access to all of it, passing pointers back and forth to data that both sides can manipulate.
Then Xojo might not be the right tool
Its not safe to do a LOT of stuff in a pre-emptive way with Xojo
And the things that it CALLS have to carefully mange what ever they start IF they intend to run pre-emptively
With helpers they can do anything and be fully preemptively threaded etc - Xojo just cant reach into them and grab whatever they want
It has to be well defined across an API
The other way a helper might be useful is using shared memory which then Xojo can access from code that runs within its threading model and a helper can access using whatever threading model it uses
I do know people using this kind of set up for image analysis - monster sized images where they spin up lots of helper apps and via shared memory they can have as many helpers analysing a portion o the image. Its complicated but its really one of the few safe way to use preemptively threaded code with Xojo
You met the fellow doing this the night we all got together =- Dr Stys
I’ve been accused many times of forcing the use of the wrong tool, just because I’m stubborn!
I’m all over multi-threading in .NET, was doing it 10 years ago or more, so I’m not concerned about that.
Need a X-Plat UI creator and Xojo is it for the conceivable future. It’s UI generation is perfect for my needs, but it’s just too slow without proper multi-threading, and I’m not really interested in learning C++ if there’s any way around it. I’m much more confortable with .NET (VB first, then C#)
I understand I’m making it hard on myself, but I really thought/think that .NET is heading in the direction of being able to create native-callable libraries. We know it can be done for Windows, MacOS/Linux are the final hurdles.
My issue is I don’t know enough about how the data for Xojo needs to be formatted, or why it claims that it can’t find the function - my guess is that it’s calling method is incorrect? If I can just conform the calling method to make it the same as Windows libraries and MacOS libraries, I feel like that’s the missing link.
Dr. Stys was using C++ I think, and also only working on Windows? I don’t remember.
But if I wanted to work on Windows only, I’d never have bought Xojo, I’d still be using .NET!
So… If the C# libraries are able to be called by C++ and Xojo can call C++, maybe a simple solution is a little “bridge” app written in C++ that translates the parameters back and forth between the languages.
If someone here knows how to make a C++ app, and can see if it can call these .NET5.0 C# functions, that might be a quicker solution!
OK trying to slim down that package to something where only a single item is expected isnt building anything now
I just commented a bunch of the code out but that doesnt help
That trying to load any of the built DLL’s results in a FunctionNotFound suggests that whatever it IS exporting is not done in a way Xojo understands
It may not be x86 calling conventions - although that doesnt seem right since the names show when I look at the dylib using nm
Thank you, @eugenedakin. Do you know how to create a C++ or other “native” app that can call a function in the .dll? It would be good to know if the issue is just in the way Xojo expects to see the function or if the .dll is not exposing the function at all!