C# and C++ need help

[TWitte]

Hi everyone,

I was wondering how a simple example of an exported function would look like in c# and c++.
I have made serveral tries, but I was not able to export a simple math function like c = a + b return c and import that in a naked apl.

Could anyone help me out?

Thank you in advance.

Timo

[isential]

Hello Timo!

The C or C++ interface is relatively well documented, even if parts of some manuals are from the last century.

What we did not manage to do in a stable way was to integrate C# via C++ (C++/CLI) into SAL:

SAL (TD Win 32) <==> C++ (C++/CLI) <==> C#

Has anyone succeeded in integrating self-made C#.NET libraries into SAL using C++/CLI?

[isential]

You can forget my previous mail.Sorry! It refers to the inclusion of .NET in the old version 1.1.2. We wanted to upgrade this old version a bit, but we finally gave up on that.

[thomas.uttendorfer]

Hi Timo,

with TD6 or newer (maybe also TD5) it is possible to write code in C# and call that from TD.
Here are the sample projects for VisualStudio and TD:

CSharp4Td.zip

In short I did the following:
1) Create a Class Library Project (.NET Framework) with a class and a method
2) Build the dll
3) With TD: Start the .NET-Explorer and create the wrapper .apl
4) Import the wrapper .apl into your TD-project
5) Instantiate the .NET-class and call the method

Regards
Thomas

[isential]

Reference to TD 6.2:

Yeah, that's it. But it gets funnier if you have different DLLs that you want to include with the .Net-Explorer... That can take a lot of work and nerves. There are several solutions for this, but none really satisfies you if you develop the DLLs yourself.

Also the way in which the DLLs are included is nothing else than the inclusion of a grave of methods... This has nothing to do with object-oriented programming.

You can use a TD wrapper to include the DLLs and then delete almost everything that the .Net-Explorer invented after the inclusion, so that the global part is only present once, or you can move everything to the C# side.

On the C# side, you can work with ILMerge, which we have discarded for various reasons, or you can make your own wrapper in C#, which includes the .Net DLLs and only shows the methods you want to make available to TD. This is what we finally decided to do.

However, everything still remains a grave of methods or functions - no trace of object-oriented programming. Better than pure C++ DLLs, but from the last century. So really big projects are not really feasible, let alone maintainable.

[TWitte]

Good morning Thomas,

that is what I was looking for. Thank you very much for your help.

Timo

[markus.essmayr]

Hi,

even you already found a solution I wanted to say, that I've successfully created a C++/CLR DLL that integrates well with TD and calls .NET components on the other side.
If you're still interested I could publish a blueprint on how to do that.

Max

[isential]

As I wrote before, we had tried this for version 1.1.2. But that would have been a grave of functions as well. With the newer versions this is not necessary, because you can directly integrate .NET. SAL <==> C++ <==> C# will surely work with today's versions, but it makes little sense.

Nevertheless, I would be very interested to know what your solution looks like.

Best regards and stay healthy!

René

[TWitte]

Hi,

I am now sitting here with a strange problem.
I build a simple dll which encodes a file to base64. Working fine.

But if I throw the built dll into the runtime folder it's not working because of (it looks like) missing dependencies.
It works only if I place my dll next to the exe AND the two following files aswell:
- Gupta.TD.DotNetExplorer.GAIL.dll
- Gupta.TD.Runtime.System.dll

My question now is: Why do i have to put the dll next to the exe (runtime folder is in the path var)?
Why the two Gupta-dlls have to be there aswell? (I think it is the same problem)

Any hint?

Thank you in advance.

Timo

[thomas.uttendorfer]

Hi Timo,
good question.

Unfortunately I can't answer it.
We place our programfiles, dll und runtimes in one directory - that works.
I also had big problems locating the c#-dll in another directory.

The only other thing that might work is to put the c#-dll in the global assembly cache (which is somewhere in the windows-directory I guess).
You have to put it in before using the .NET-Explorer for creating the apl.
But I have to say that I never tried that with self-written dll.

But I use some .NET-Dlls from Windows (like system.drawing) which are naturally located in the GAC.
Then I don't need to copy that one to our program-dir.

Regards Thomas

[Dave Rabelink]

My question now is: Why do i have to put the dll next to the exe (runtime folder is in the path var)?
Why the two Gupta-dlls have to be there aswell? (I think it is the same problem)

.NET assemblies (dll's) have a different search method. It does not follow the same methodology as "normal" dll's.
It will search for the assembly in the GAC, runtime folder (exe location) and you can specify a custom load paths based on assembly versions using config files.
In fact there is much info on this, search for "probing".

The two dll's are needed as you use the win32<->.NET bridge for TD (gail). This makes calling .NET dll's from Win32 TD version possible,

I guess if you install TD runtime, the needed gail dll's are registered in GAC and your application will work.
If you do not want to install and use a xcopy distribution method, you need to find the right probing method for you.

As Thomas already said, the easiest way is to put the TD runtime and your application files (exe's, dll's etc) in one folder.

[flor]

I'd also recommend that you hire software engineers in ukraine in case you're considering this option. I heard a lot of positive stuff about this company, so you can check them out, who knows.

[Michael Ehehalt]

Hi,

even you already found a solution I wanted to say, that I've successfully created a C++/CLR DLL that integrates well with TD and calls .NET components on the other side.
If you're still interested I could publish a blueprint on how to do that.

Max

Hi Max,

I'm interested in a blueprint.

We use a method, where the C# .NET Managed DLL would be modified after compiling (disassemble, modifiy IL code, assemble) to use static C# methods as external methods like C++ external methods from Win32 DLLs for example. It is not the object oriented way, but it works very stable since years. So it would be nice to see the C++/CLR DLL way.

Regards

Michael