Not sure what the issue is. I know it works for me and a few others here on the forum who have tried it. Did you register the dll with regasm? Also, if you can post a link to your project and c# solution! I’ll take a look at it.
Since your VS solution used 2012, I went ahead and installed it. In any case, the problem was that you needed to change the properties for your application to make the c# assembly com visible. In VS Right click on TestyVS go to properties->application->Assembly Information and click “Make Assembly COM-Visible”. Rebuild your solution in Visual Studio and in Xojo insert the class again. Run your Xojo application and enjoy.
P.S. Sorry if I didn’t make that step clear in my example.
You can do it either way. This really only becomes important if you need to change the physical location of the DLL on your hard drive (or end users hard drive). Most good installers will handle this registration for you as well.
I’ve been able to get this working using the Unmanaged Exports – which is HUGE for folks who need to create DLL’s and want to take advantage of .NET and the whole C# ecosystem.
This avoids the whole COM-Visible and COM-interop nightmare which can slow down a project, and also complicate things.
“Unmanaged Exports” a C# class library package by Robert Giesecke.
No more ActiveX wrapper! Excellent stuff!
Here’s what you do:
Get the NuGet packages for VS 2010 or better, install them in your VS 2012 system.
Create a VS C# Class Library Project
When you create a method make sure its “static”, and that you decorate it with [DllExport]
Compile the project, place the DLL in the runtime location of your Xojo project or make sure the Declare has a direct path
to that DLL
Voila! .NET DLL access from Xojo… no ActiveX wrapper, no COM-Interop.
Below is a code snippet.
C#
using System;
using RGiesecke.DllExport;
using System.Runtime.InteropServices;
public class TestExport
{
[DllExport]
public static int Test(string TestString)
{
return TestString;
}
}
Declare Function Test lib "TestExport.dll" (msg as CString) AS String
Msg ( Test ("Hello, .NET Class Library DLL!"))
This thread is fantastic! We’ve managed to get this working brilliantly. I do have a question about .dll’s though… Our .Net compiled dll calls a number of other dll’s. We’re finding that we need to manually add them to our debug build folder next to the application in order for the debug build to work correctly (i.e. before we call the function that access the ell).
Is there a way to add the dll’s to the build folder automatically at runtime or can I put them somewhere else so that my debug builds function properly? I’d like to say I’m an expert coder and don’t ever need to test a debug build…but I’m far from it
Just another vote for possibly the best forum thread of the year;) These methods of creating .NET dll’s have been very handy of late.
I do have a problem with deployment though. My newly created dll works fine on my development machine with ‘Register for com interop’ selected but on a client pc I’m having a lot of problems.
Even using REGASM, I’m finding that my dll isn’t working. It has some dependant dll’s and I’m sure this is the case, but to date, without installing visual studio on the clients machine I’m having problems registering. Is there a simple way to determine what isn’t being found as far as dependencies are concerned?
Cheers,
James
I gave up for now on the deployment of a Com Object (ActiveX) at around 2am. At 3am I had a fully working system using Robert Giesecke’s unmanaged exports (Thanks Gary!).
I did have a few problems with the classes having to be set as static but I got around that by having the externally visible classes set to static and then having these call my complex multi class internal routines. Happy to post code if anyone stumbles across this thread in the future and requires it. Just let me know.
So onto question 2:
I’m using soft declares to connect to my shiny new .dll. They work fine, but are not being released on app quit. If I try to build or run again, the app will not load unless I log out and back in again. Is there a way to force release the dll on app quit?
Question 3 is another curly one relating to thread safety. I’m hoping to call this dll from a few places in my program, but I’m finding that it isn’t thread safe and I’m getting unintended stuff happening. Do I need to make my dll thread safe of is there a way in Xojo to protect it? If I run two apps at the same time accessing the dll it works fine.
Thanks again guys. Hopefully this tread is adding some value to the body of knowledge. I know it’s been a steep learning curve for me!