Using C# classes in Xojo

Getting Started
29

Hi Simon,

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.

Thanks,

Jim

30

Hi Jim, thanks - I wasn’t using regasm, as I ticked “register for Interop”, but I just tried adding that step - still no joy.

Here’s a link to the project and c# solution!

https://www.dropbox.com/sh/aq4nb110thuje6a/tEvjNQNSW3

Also a screenshot in that folder, showing Xojo with the dll reference that doesn’t expand.

Thank you!

Simon

31

Simon,

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.

Have Fun!

Jim

32

Aha, it works! So there are 4 things to check in the VS project:

1 - run VS as admininstrator.
2 - make COM-visible
3 - register for COM interop
4 - platform target is x86

Maybe also use regasm - although you implied that doing check 3 above would make that not necessary. I haven’t tried though.

I have also tested it as a Xojo web app, not desktop app - it also works. That’s fantastic!

Thank you so much for helping, and the effort to install VS2012. I’m looking forward to seeing what Xojo can do.

Best wishes,
Simon

33

Hi Simon, glad that worked.

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.

Thanks,

Jim

34

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:

  1. Get the NuGet packages for VS 2010 or better, install them in your VS 2012 system.
  2. Create a VS C# Class Library Project
  3. When you create a method make sure its “static”, and that you decorate it with [DllExport]
  4. 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
  5. 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!"))
35

Hi Gary, could your solution be used for non-static classes?

36

It’s not really “my” solution. Its the solution proposed earlier using the Unmanaged Exports class.

And no, I believe your methods need to be static.

37

Thanks, it’s great that it works.

38

Hi all,

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 :wink:

Cheers,
James

39

Hi James,

I do this using the copy files build step feature of Xojo.

  • Jim
40

Hi Jim,

I’m unfamiliar with this. Can you point me to where I should be looking?

Thanks again,
James

41

Hi James,

A good place to start would be: http://www.xojo.com/blog/en/2013/12/build-automation.php

42

See the User Guide - Framework
http://www.xojo.com/download/extras.php

43

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

44

James,

Check out . This might give you some insight into what you are missing when you deploy.

  • jim
45

Thanks Jim,

I’ve tried DW, but didn’t have much success. I’ll revisit again!

J

46

James,

Just a thought, if your deployment target is XP, the .net framework itself may need to be installed.

  • jim
47

Hey Jim,

Yeah, I’m lucky enough that everything is Win7 now;)

48

Following on kind of on topic:)

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!