Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Using dll from a C# code

111 views
Skip to first unread message

Rego, P.

unread,
Feb 29, 2012, 6:52:48 AM2/29/12
to
Hello,

I have a method in C# which I need to export to Ada using a dll. Maybe

// simple.cs
// compile with csc /t:library simple.cs
using System;
public class VerifyClass{
public bool Verify(){
return true;
}
}

In order to use the function Verify() in Ada, I need to import this to something like
-- simple.ads
package Simple is
function Verify return Boolean;
pragma Import
(Convention => dll,
Entity => Verify,
External_Name => "Verify");
end Simple;

And I could use with
-- main.adb
-- build with gnatmake main -largs -lsimple
with Text_IO; use Text_IO;
with Simple; use Simple;
procedure Main is
begin
Put_Line (Boolean'Image (Verify));
end Main;


When I build the Ada with
gnatmake main -largs -lsimple

the compiler returns me
./main.o(.text+0xd6):main.adb: undefined reference to `Verify@0'

So what have I missed? Maybe the C# code structure should be changed?

Shark8

unread,
Feb 29, 2012, 3:00:39 PM2/29/12
to
You have to be sure you are using the compiler for .NET; I think
there's something about qualifying names too, but I don't remember
what. You may want to check out the import pragma on page 16 in this
pdf: http://www.usafa.edu/df/dfe/dfer/centers/accr/docs/carlisle2006b.pdf

Message has been deleted

Rego, P.

unread,
Feb 29, 2012, 9:26:25 PM2/29/12
to
> You have to be sure you are using the compiler for .NET; I think
> there's something about qualifying names too, but I don't remember
> what. You may want to check out the import pragma on page 16 in this
> pdf: http://www.usafa.edu/df/dfe/dfer/centers/accr/docs/carlisle2006b.pdf

Quite interesting this paper. But I still could not import the function with success. Actually I changed the simple.cs to
// simple.cs
// compile with csc /t:library simple.cs
namespace Simple{
public class VerifyClass{
public static bool Verify(){
return true;
}
}
}

So when I make gnatmake main -largs -lsimple, it returns me
gcc -c main.adb
gcc -c simple.ads
gnatbind -x main.ali
gnatlink main.ali -lsimple
.\main.o:main.adb:(.text+0x21): undefined reference to `Verify@0'
collect2: ld returned 1 exit status
gnatlink: error when calling C:\GNAT\2011\bin\gcc.exe
gnatmake: *** link failed.

I sense that the problem is a tiny mistake (but where?)

Gautier write-only

unread,
Mar 1, 2012, 12:38:09 AM3/1/12
to
On 1 mar, 03:26, "Rego, P." <pvr...@gmail.com> wrote:

> So when I make gnatmake main -largs -lsimple, it returns me
> gcc -c main.adb
> gcc -c simple.ads
> gnatbind -x main.ali
> gnatlink main.ali -lsimple
> .\main.o:main.adb:(.text+0x21): undefined reference to `Verify@0'
> collect2: ld returned 1 exit status
> gnatlink: error when calling C:\GNAT\2011\bin\gcc.exe
> gnatmake: *** link failed.
>
> I sense that the problem is a tiny mistake (but where?)

Are actually using the .NET-targetting GNAT ?
I have the impression you are using the plain Windows one, it should
be something like dotnetgnatmake.exe - look into your C:\GNAT\2011\bin
directory.
I suppose you also installed GNAT for .NET ?
_________________________
Gautier's Ada programming
http://sf.net/users/gdemont

Rego, P.

unread,
Mar 1, 2012, 6:41:55 AM3/1/12
to
> Are actually using the .NET-targetting GNAT ?
Actually no. I am using native .NET for generating the dll. So I just run C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319 /t:library simple.cs
And soon after I run gnatmake main -largs -lsimple

> I have the impression you are using the plain Windows one, it should
> be something like dotnetgnatmake.exe - look into your C:\GNAT\2011\bin
> directory.
> I suppose you also installed GNAT for .NET ?
I don't have it installed. Should I use it to create the dll?

Georg Bauhaus

unread,
Mar 1, 2012, 8:16:08 AM3/1/12
to
Isn't a .NET DLL actually different from a more traditional
DLL, i.e., a thing to be JIT compiled into executable code?

gautier...@hotmail.com

unread,
Mar 1, 2012, 9:38:52 AM3/1/12
to
Le jeudi 1 mars 2012 12:41:55 UTC+1, Rego, P. a écrit :

> Actually no. I am using native .NET for generating the dll. So I just run C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319 /t:library simple.cs

A .NET DLL is not a traditional DLL and has not Intel machine code in it.
It was called DLL just to avoid disturbing some people (and confusing other).

See here, under ".NET assembly" for more infos:
http://support.microsoft.com/kb/815065/en-us

HTH
_________________________
Gautier's Ada programming
http://freecode.com/users/gdemont

Rego, P.

unread,
Mar 1, 2012, 10:15:14 AM3/1/12
to
Em quinta-feira, 1 de março de 2012 11h38min52s UTC-3, gautier...@hotmail.com escreveu:
> Le jeudi 1 mars 2012 12:41:55 UTC+1, Rego, P. a écrit :
>
> > Actually no. I am using native .NET for generating the dll. So I just run C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319 /t:library simple.cs
>
> A .NET DLL is not a traditional DLL and has not Intel machine code in it.
> It was called DLL just to avoid disturbing some people (and confusing other).

I don't get it. So is not possible to import a C#/.NET method in dll in an Ada code?

Gautier write-only

unread,
Mar 1, 2012, 11:24:23 AM3/1/12
to
Yes, you can :-).
What you can't is mixing different machines.

Your PC with an Intel processor and Windows is a different machine
than the .NET virtual platform, with MSIL as machine code.
If you compile a module with language X into machine code for machine
A, and another module with language Y into another machine code,
machine B/=A, you won't be able to make both work together.
For instance you won't make a Commodore 64 machine code and a PC
machine code work together.
Perhaps if you think to a Commodore 64 emulator instead of the .NET
platform, it will be clearer.
So you need to find a common machine for compiling both languages.
For C#, only one choice: MSIL
For Ada, you have plenty of choices: Windows&Intel32/64,
Linux&Intel32/64/..., MacOSX&PowerPC/Intel, JVM, MSIL, UNIX,
OpenVMS, ...
And, hurray, you realize there is one common target machine in the
list: MSIL.
So you have to use the GNAT-for-.NET, not the GNAT-for-Windows.

Got it ?

Georg Bauhaus

unread,
Mar 1, 2012, 11:25:36 AM3/1/12
to
It is possible to import a method of a .NET type into a native
Ada program if it is possible to import a method of a .NET type
into a native C++ program, i.e. not into a C++/CLI program,
but into a C++ program that is compiled with a C++ compiler
that generates processor instructions, not .NET byte code.

Similar possibilities exist for importing methods of a compiled
Java class (JVM byte code) into an Ada program that is compiled
into Intel/AMD processor instructions.

IINM, DLL in
- .NET means libraries of O-O types with methods, in byte code.
- Win32 means libraries of functions, processor instructions.

The Windows(TM) platforms are many. It is necessary to pick
compilers for compatible targets. For example, A# (GNAT for .NET)
with one of the .NET compilers by Microsoft.

But then, using .NET types from A# programs means with-ing
packages of .NET types, not importing single methods.

public class VerifyClass { ... }

will become a tagged type on the Ada side, and you use
this Ada type almost as usual in O-O Ada. There will a pointer to
the reference handling objects of imported type VerifyClass.

mjamesb

unread,
Mar 1, 2012, 10:37:25 PM3/1/12
to
> I have a method in C# which I need to export to Ada using a dll. Maybe

If you're willing to try some MS C++ then the following item might
be useful:

http://stackoverflow.com/questions/1823466/how-to-call-a-net-dll-from-a-win32-process

the comment portion of which is mostly (it has a code example):

"Another option is to use C++/CLI as a bridge. People are mostly
familiar with using it to wrap unmanaged APIs to expose to managed
code, but it actually works both ways - it is possible to compile
with /clr, and yet produce a .dll assembly with plain unmanaged
exports, which can be called from unmanaged code as usual.
...
In practice it will load CLR runtime into the calling process
(unless it's already loaded there) and dispatch from native code
to managed code transparently - all the magic is done by C++/CLI
compiler."

Have fun.

- mjamesb

Rego, P.

unread,
Mar 2, 2012, 3:03:48 PM3/2/12
to
> Your PC with an Intel processor and Windows is a different machine
> than the .NET virtual platform, with MSIL as machine code.
> If you compile a module with language X into machine code for machine
> A, and another module with language Y into another machine code,
> machine B/=A, you won't be able to make both work together.
> For instance you won't make a Commodore 64 machine code and a PC
> machine code work together.
> Perhaps if you think to a Commodore 64 emulator instead of the .NET
> platform, it will be clearer.
> So you need to find a common machine for compiling both languages.
> For C#, only one choice: MSIL
> For Ada, you have plenty of choices: Windows&Intel32/64,
> Linux&Intel32/64/..., MacOSX&PowerPC/Intel, JVM, MSIL, UNIX,
> OpenVMS, ...
> And, hurray, you realize there is one common target machine in the
> list: MSIL.
> So you have to use the GNAT-for-.NET, not the GNAT-for-Windows.
>
> Got it ?

Got it. So the target application would have to be recompiled using gnat-for-.net.

Rego, P.

unread,
Mar 2, 2012, 4:15:51 PM3/2/12
to
I understand. Thanks.

Rego, P.

unread,
Mar 2, 2012, 4:17:13 PM3/2/12
to
The idea of the bridge is interesting.
0 new messages