C# dll i java

Kan du være lidt mere præcis med hvordan det ikke virker ?

Jeg har iøvrigt aldrig hørt om Java -> C#.

Java kan kun kalde "klassiske Win32 DLL'er".

Jeg er ikke sikker på at en C# DLL er en sådan. Den indeholder vel IL !?

Jeps :-)
Dette er min javadel:
class TestDll{
    public static void main(String args[]){
        System.out.println(Testing.get());
    }
}

class Testing{
    static{
        System.loadLibrary ("Test");
    }
    public static native int get();
}

min dll ligger i samme mappe.
Når jeg så kører programmet får jeg en Java.lang.UnsatisfiedLinkerror: get

Jeg har heller ikke hørt om det, men troede at det kunne lade sig gøre :)

Hvad har du skrevet i din C# kode ?

For C så får man jo genereret nogle funktion signaturer
(som er meget anderledes end det intuitive !).

Der er et eksempel på:
  http://developer.java.sun.com/developer/onlineTraining/Programming/JDCBook/jniexamp.html

for C, hvor man kan se at:

native byte[] loadFile(String name);

bliver til:

JNIEXPORT jbyteArray JNICALL Java_ReadFile_loadFile
  (JNIEnv * env, jobject jobj, jstring name)

namespace Test{
  public class Hej{
    public Hej(){
    System.Console.WriteLine("in constr");
    }

 
      public static int get(){
          System.Console.WriteLine("in dll");
        return 50;
      }
  }
}

En "normal" erklræing af:
  int get()
i C# vil næppe virke.

Og jeg tvivler som sagt på at det overhovedet kan lade sig gøre.

Jep.

Hvis du sammenligner din C# kode med det som javah genererer, så
er det ret indlysende at Java ikke kan finde get metoden.

Kan jeg konkludere at det ikke er muligt? :-)

Ikke endegyldigt.

Du kan godt konkludere at public static int get() i C# ikke virker.

Du skal nok have fat i nogle C# hajer og spørge dem om man kan lave
det jeg kalder en "klassisk Win32 DLL" i C#.

Hvis man kan det så skal du igang med at få metode signaturen rigtig
og få defineret det ekvivalente til jni.h for C#.

Jeg ville opgive ideen - masser af arbejde med minimal udsigt
til success !

Ok, men min idé var at jeg har en package som er skrevet i java som indeholder 128 hjemmelavede metoder. Det kunne så være nice hvis jeg kunne bruge disse metoder/algoritmer i både java og C#... Hvad med point? Fik ikke løst mit problem, men fik en masse svar ...? Hvad er etikken på eksperten?

Det er helt op til dig om du vil give point.

Der gives normalt point for "Det er ikke muligt, fordi ..." svar.

Men mit svar var jo mere "Jeg tror ikke at det er muligt, fordi ...",
så det er op til dig.

Jeg ville nok tage Java source og oversætte den med J# og bruge
det fra C# (C# -> J# bør være helt uproblematisk og J# og Java
skulel være 99% source kompatible).

J# ideen baserer sig selvfølgelig meget på at det er rimeligt
self contained algoritmer som ikek kræver diverse eksterne
packages, som muligvis ikek er i J#.

Og et svar hvis du vil give nogle point.

Jeg ved ikke om du har kigget på Regasm.exe som følger med .NET frameworket? Dette værktøj gør det muligt at snakke med .NET assemblies.....og kan man ikke fra Java snakke med COM komponenter ???

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrfassemblyregistrationtoolregasmexe.asp

Du kan da lave din C# kode som en webservice og så kalde den fra java. Proxyen stiller en række metoder til rådighed gennem http port 80.

Det er en udmærket metode til Java-.NET interoperability.

Men den er server orienteret. Uanset om det er .NET->Java
eller Java->.NET så skal der køre en server.

Ikke noget problem i mange sammenhænge.

Men ikke praktisk i andre sammenhænge.

Jeg har ikke arbejdet med c# endnu, men som jeg forstår det, kan man uden problemer kommunikere mellem C++ <> C# <> VB.
Så hvorfor ikke lave en dll i C som en link mellem Java og din C# dll ?

pollewop -> Du tænker da vist på at man kan kommunikere mellem C++.NET, C# og VB.NET eller hvad?

mmmm.... Der fik du mig viciodk, men siden Java, der kører på en VM, kan kommunikere med det underliggende platform, vil det være utænkeligt hvis MS produkterne ikke kunne snakke sammen, selvom de også kører på en VM.

Der er næppe problemer med:
  .NET -> gammeldags Win32
men det er jo:
  gammeldags Win32 -> .NET
vi skal bruge.