Comment utiliser une assembly .Net ?

Bonjour,

je dois développer en C# et les assemblies réalisées doivent être utilisables en Java. Hors je ne connais pas bien Java et je dois faire un projet Java qui réutilisera une assembly .Net fort simple, mais je ne sais pas encore comment m'y prendre.
Et pour corser le tout, il faut aussi que ça ne fonctionne pas que sous Windows mais aussi sous linux. J'ai bien trouvé des tutos qui parlent de JNI et JNI4NET mais le premier passe par du code en C++ natif et le second n'est pas encore porté sous mono.

Merci pour vos conseils.

Si les données à faire transiter ne sont pas trop volumineuse, des Web Services pourraient t'offrir une solution relativement propre.

Utiliser un WebService ne veut pas dire qu'on doit installer un serveur web sur la machine ?
N'est-ce pas un peu lourd alors que le but n'est pas de faire communiquer les 2 applis sur 2 postes différents mais en local sur le même poste ?

Pas forcément besoin d'un servlet container. Il suffit juste d'avoir une socket à disposition. Donc les web services marchent bien en dehors d'un contexte web.

Cf: http://java.sun.com/developer/techni...J2SE/jax_ws_2/

Cela peut sembler un peu lourd, toutefois ce sera amplement plus simple à maintenir que N couches de code natif utilisant des API plus ou moins stables.

Ton article est un peu (beaucoup) compliqué pour quelqu'un qui ne s'y connait pas bien en Java. :roll:
Mais si je ne m'abuse, il ne faut pas faire les WebServices en Java mais en .Net et l'appli Java utiliserait ces WebServices.
Il faudrait donc que je trouve comment faire fonctionner des WebServices en .Net sur un serveur linux sans avoir à installer un serveur web ?
Bien que je sois d'accord que d'avoir une couche native intermédiaire entre une couche managée et la couche Java soit assez usine à gaz et source d'incompatibilités, ta solution est aussi assez complexe à mettre en oeuvre.

Je la garde sous le coude si besoin mais j'aimerais vraiment pouvoir trouver une solution où le déploiement entre autre serait plus simple.

J'ai entendu dire que JNI permettait d'utiliser du code natif soit windows, soit linux, soit mac sans avoir besoin de faire 3 versions du code.

Une solution simple:
Le java exécute ton programme .net (en fait la machine virtuelle via exec) et utilise les pipes d'entrée-sortie standard pour dialoguer.

Je ne m'y connais pas super bien, mais en faisant ainsi, on travaille bas niveau et du coup, ce n'est que du procédural, on na pas de typage fort de la POO, ni vérification des types à la compilation.

Je suis en train de faire des tests en utilisant JNI, j'arrive à utiliser du code C++ compilé sous linux, il faut encore que je trouve comment mapper l'assembly .Net avec le code natif C++.

Bonjour,

finalement la solution d'utiliser JNI sur linux n'aboutit pas. J'ai un problème sur le projet C++ natif intermédiaire, je n'arrive pas ré-utiliser une assembly .NET, on dirait que ce n'est pas encore implémenté dans mono/monodevelop.

Finalement, je me suis intéressé à la solution WebServices, mais je me demande si cela peut répondre au besoin car j'ai l'impression que les WebServices ne permettent que de faire du procédure avec des types primitifs comme string, int, ... et ne permet pas de faire de la POO, ce qui serait fort limitant.

Les webservices peuvent parfaitement correspondre à des données complexes sans le moindre problème.

En effet tu peux utiliser tes propres Objets qui seront mappés en tant qu'éléments XML.

Genre un truc dans le style

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class Maclasse { private int toto; private String machin; private BigDecimal duTexte;     public int getToto() { return toto; }   public void setToto(int toto) { this.toto = toto; }   //et ainsi de suite pour les autres accesseurs get/set machin et duTexte }

---

Avec une classe englobante du genre

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public class MaClasseEnglobante { private MaClasse maClasse; private String autreChaine;   public MaClasse getMaClasse() { return maClasse; }   //et ainsi de suite pour les autres accesseurs get/set maClasse et autreChaine   }

---

Sera mappée en xml sous la forme:

Code:

---

1 2 3 4 5 6 7 8 9

<MaClasseEnglobante> <MaClasse> <toto>0</toto> <machin>truc</machin> <duTexte>azertyuiop</duTexte> </MaClasse> <autreChaine>poiuytreza</autreChaine> </MaClasseEnglobante>

---

Ce qui correspond bien aux notions d'objets. Tu peux également mapper des collections ou tout autres choses de cette façon.

Mais cela implique que celui qui consomme le WebService sera obligé de redéclarer toutes les classes pour qu'il puisse lui aussi faire de la POO ?

Je n'arrive pas à voir comment côté client, on peut récupérer un objet et les propriétés d'un objet, il devra forcément désérialiser l'objet depuis le noeud XML ? Comment pourra-t-il appeler la méthode d'un de ces objets ?

Les WebServices sont bien basés sur les concepts de sérialisation/désérialisation.
Ensuite il te faut te renseigner sur le concept de descripteur de web services (le fichier wsdl) qui permet à des outils du framework utilisé de générer dynamiquement les classes correspondant à la sérialisation/désérialisation que tu pourras utiliser dans tes devs.

pour être clair, le client java ne va faire que consommer ou il va appeler des méthodes, interagir avec ces objets. Si oui, je "craint" que les seuls protocoles standard entre tes deux soient au choix:
un webservice bien concu, avec du SOAP
un export CORBA de ton objet .net, avec des descripteurs .IDL pour les récupérer dans d'autre language (comme java).


Dans tout les cas, c'est un gros boulot.

En fait j'ai besoin de trouver une solution afin qu'un programmeur Java puisse réutiliser ce que je réalise en .NET et le tout sous windows et sous linux.

Sous windows, j'ai trouvé la solution avec JNI, ce n'est pas (trop) lourd et fonctionne pas mal.
Malheureusement, je n'ai pas réussi à le faire fonctionner sous linux et cherche une solution de contournement donc pas forcément WebServices et ce que tu me dis ne me rends guère optimiste.

Bah sinon quel est ton problème avec JNI sous linux?

Mon problème n'est pas côté Java. Avec NetBeans, j'ai réussi à utiliser une classe faite en C++, mon problème est plutôt d'arriver à faire une application en C++ qui va réutiliser un assembly .NET.
Le projet de test trouvé dans le tuto possède :

• un projet Java qui fonctionne avec netbeans windows et linux.
• un projet C# qui génère l'assembly fait avec VisualStudio pour Windows mais tourne bien avec MonoDevelop sous linux.
• le projet intermédiaire en C++ fait avec VisualStudio mais pas accepté par MonoDevelop.

J'ai trouvé ceci sur le site de mono :

Citation:

---

Once this stage is done, there are two extra stages that are fairly complex:
Add Managed C++ support to the C++ front-end (this is required if you want to share objects between .NET and C++)

---

Et donc à priori, ce n'est pas possible pour le moment.

Par exemple, j'ai ce bout de code en C++ :

Code:

---

1 2 3 4 5 6 7 8 9

using namespace System; using namespace System::Runtime::InteropServices; using namespace HelloWorldDotNet;   #include <string>   std::wstring assemblyPath;   System::Reflection::Assembly ^ MyResolveEventHandler( Object^ sender, ResolveEventArgs^ args )

---

J'ai une erreur sur using namespace System; car 'System' n'est pas un namespace-name et donc je ne peux pas avoir de type Assembly, ce qui est assez bloquant.

Là il n'est pas grand chose que les gens du forum java puisse faire pour toi ;).

Essaie de voir dans le forum .net s'ils n'auraient pas une solution sous la main.

Mais bon après une recherche rapide, dans la FAQ de mono, il existe tout de même des solutions à priori:

Citation:

---

I have a C++ library that I would like to call from Mono, what can I do?
There are a few possible approaches:

• Use a code generator such as SWIG that parses the C++ code and generates C wrapper functions and C# code which DllImports the C wrappers.

Pro: This permits use of C++ code from C# Con: Not terribly elegant; Extra layer of C code may impact performance.

• There was work on a WHIRL-to-IL compiler, which would compile C (and probably C++) into CIL which Mono could execute.

Long term solutions that require a lot of work might be possible:

• Modify GCC's to produce CIL.

---

j'ai surtout l'impression que vous êtes occupé de vous orienter vers une solution qui va être une belle s*** a maintenir. Il serait plus sage, je pense, de faire comme suggérer plus haut: invoquer l'application .net depuis java et utiliser les input/output stream pour dialoguer.

Citation:

---

Envoyé par sinok

Mais bon après une recherche rapide, dans la FAQ de mono, il existe tout de même des solutions à priori:
I have a C++ library that I would like to call from Mono, what can I do?

---

En fait, c'est l'inverse, j'ai une bibliothèque faite en C# que je voudrais pouvoir accéder en C++.
Mais je vais toujours demander sur le forum .NET pour voir s'ils ont une solution, j'avais juste écrit ce code car tu me demandais pourquoi je bloquais.

Citation:

---

Envoyé par tchize_

j'ai surtout l'impression que vous êtes occupé de vous orienter vers une solution qui va être une belle s*** a maintenir. Il serait plus sage, je pense, de faire comme suggérer plus haut: invoquer l'application .net depuis java et utiliser les input/output stream pour dialoguer.

---

Je suis désolé mais je ne vois pas du tout pourquoi ce serait plus simple, il faudrait que j'implémente une sorte de serveur qui pourrait communiquer par exemple en TCP/IP avec une application cliente et devrais gérer l'ensemble des possiblités d'accès aux objets, propriétés et méthodes, sans parler que côté client, ils n'auraient pas de POO car en TCP/IP, ce n'est que du string.
Vraiment, je n'ai pas l'impression que ce soit plus adapté à mon besoin, mais peut-être que je me trompe.

ce n'est pas "facile". En voulant absolument faire interagier une application .net avec une application mono, vous n'avez clairement pas choisi la voie facile. La voie facile et raisonnable aurait, a mon avis, été de tout faire en .net ou tout en java. Déjà, vouloir utiliser du .net en multiplateforme, vous êtes fortement dépendant de l'implémentation mono, qui n'est pas complète de toutes façons.

L'utilisation de compilation native, de librairie native .NET + de librairie natives java + de C entre les deux, vous êtes bien conscient qu'à chaque mise à jour de mono, à chaque mise à jour de la JVM, vous serez probablement bon pour devoir recompiler? Vous allez vous retrouver avec un quirielle de .dll / .so pour vos clients, avec une installation qui sera loin d'être facile. Sans compter que vous allez vous retrouver dans une même espace mémoire avec deux machine virtuelles, deux garbage collector, etc. Et, de toutes façons, ne vous leurrez pas. Vos objet vous devrez les coder, au final, 2 ou 3 fois. Vous allez devoir coder une structure qui récupère en C les donnée .NET + une classe native en JAVA qui va utiliser ces structure pour exposer un objet java. Donc pour tout objet .NET que vous désirerez exposer à java, il y aura une classe java correspondante et un code C correspondant. Trois fois le travail. Je ne vois pas en quoi c'est plus facile que d'avoir en .NET une classe qui dialogue sur les inpout/outputstream standard, et d'utiliser ce canal poru dialoguer avec l'application java (qui aura de toutes facon son objet propre de son coté). Au mois, là, vous n'avez aucune compilation native, un simplification de l'interaction, et quelque chose de standard (ca fait des année qu'on fait dialoguer des applications sur cette base). Et non, vous n'avez pas besoin de TCP/IP là dessus.

Salut, mon but n'est pas de faire une application hybride a moitié faite en .NET et à moitié en Java, je dois réaliser des applis en .NET mais valider qu'on peut diffuser une sorte de "SDK" qui soit réutilisable par des partenaires qui utilisent d'autres langages dont le Java, c'est pour ça que j'essaie de valider cette partie là.
Ce n'est pas qqch qui sera systématiquement fait, mais il faut que ce soit possible et que j'apporte la solution pour que ça marche.

tchize_ pour que je comprenne mieux ce que tu veux dire, tu aurais un lien vers un tuto qui présenterait ta solution ?

j'en ai pas sous la main, mais c'est pas compliqué

en .NET tu écrit dans la sortie standard, tu lit depuis l'entrée standard
en java, tu fais pareil sur les input/ouputStream de l'objet Process que tu obtien en lançant l'application .NET

Et c'est parti, t'as un flux binaire à double sens entre les deux application, reste plus qu'à l'utiliser

C'est quelque chose de très courant en tout cas sous linux de faire ce genre de chose pour réutiliser une application existante

Citation:

---

Envoyé par tchize_

j'en ai pas sous la main, mais c'est pas compliqué

en .NET tu écrit dans la sortie standard, tu lit depuis l'entrée standard
en java, tu fais pareil sur les input/ouputStream de l'objet Process que tu obtien en lançant l'application .NET

Et c'est parti, t'as un flux binaire à double sens entre les deux application, reste plus qu'à l'utiliser

C'est quelque chose de très courant en tout cas sous linux de faire ce genre de chose pour réutiliser une application existante

---

Si tu utilises les entrées/sorties standards, tu ne risques pas d'avoir des conflits avec d'autres applications qui les utilisent aussi ?

Dans ce cas là, il faudrait que la partie .NET fasse le rôle de serveur et ne saurait pas quand elle doit lire l'entrée standard car elle ne sait pas quand une appli va se connecter à elle.

houlà:

la partie .net est lancée par chaque application java qui en a besoin (tu nous a clairement dit que tu ne voulais pas que ce soit un serveur), donc je vois pas ce que cette histoire de serveur viens faire là dedans.

Tu application .net va effectivement avoir un Thread qui lit sur l'inputstream, traite le message, et renvoie la réponse vers l'outputstream.

Chaque application a sa propre entrée standard, donc non tu n'aura pas de conflit avec les autres applications puisqu'elles ne rentrent pas dans ce système.

Quand sous linux, je faire un

Code:

---

ls *.java | grep Impl

---

C'est exactement ce que je fais, je prend la sortie standard de ls, et je l'envoie dans l'entrée standard de grep. Dans ton cas, tu va juste avoir ça en double sens.


http://java.developpez.com/faq/java/...icationExterne

Citation:

---

Envoyé par tchize_

houlà:

la partie .net est lancée par chaque application java qui en a besoin (tu nous a clairement dit que tu ne voulais pas que ce soit un serveur), donc je vois pas ce que cette histoire de serveur viens faire là dedans.

---

Je voulais dire que la partie .NET devrait dans ce cas comme un serveur, en attente qu'un client se connecte dessus. On a donc le problème du fait qu'on ne sait pas quand on doit lire l'entrée standard, à moins de faire une attente active qui lit ce qui se passe toutes les secondes par exemple, mais ce n'est pas forcément conseillé.
A moins que la lecture attende que qqch arrive.

Citation:

---

Envoyé par tchize_

Chaque application a sa propre entrée standard, donc non tu n'aura pas de conflit avec les autres applications puisqu'elles ne rentrent pas dans ce système.

Quand sous linux, je faire un

Code:

---

ls *.java | grep Impl

---

C'est exactement ce que je fais, je prend la sortie standard de ls, et je l'envoie dans l'entrée standard de grep. Dans ton cas, tu va juste avoir ça en double sens.


http://java.developpez.com/faq/java/...icationExterne

---

Ce qui veut dire que je dois relier la partie .NET à l'entrée/sortie standard de l'application Java pour que ça fonctionne ?

comme je l'ai dit, ton .net n'est pas un serveur mais une application à part entière, lancée en soutien de l'application java. Ce n'est pas bien différente que si l'application java, tout d'un coup, lancait les processus "ls" poru récupérer le contenu d'un dossier ou "cdrdao" pour graver un disque. La seul particularité c'est que l'application .net lira sur l'entrée standard jusuqu'à ce qu'on la tue. Il y aura donc une application .net par application java qui l'utilise, lancée par l'application java, tuée par l'application java ;)

Petit tutoriel:

http://ydisanto.developpez.com/tutoriels/j2se/runtime/

Merci pour votre aide, je suis en train de faire des tests sur cette solution pour voir si ça fonctionne bien. :ccool:

Bonjour,

en fait cette solution est difficilement viable car tout ne passe qu'en string entre les 2 applications sans pouvoir définir de protocole de communication.

En effet, cela signifie qu'il faut recréer les classes en Java, on peut imaginer qu'on a une désérialisation/sérialisation des objets en string, mais ensuite, il faut tout de même synchroniser toutes les propriétés de chaque objet.

Je m'explique, on a par exemple un objet a du type A et un objet b du type B (qui possède une propriété Taille), chacun possède une référence vers l'autre.
On appelle une méthode de l'objet a qui va incrémenter la taille de l'objet b, puis on souhaite afficher la taille de l'objet b.
On ne doit pas pouvoir la valeur stockée en local mais bien récupérer la valeur dynamiquement via la communication en stream entre les 2 applications.

Il faut donc que les propriétés ne soient pas stockées dans l'application Java mais aient des get et set qui communiquent en streaming avec l'autre application. Donc utiliser un identifiant unique par exemple afin que l'application distante sache quel objet demande la valeur d'une propriété.

Enfin, je pense que cette solution serait difficilement maintenable et viable, je suis donc toujours à la recherche d'une bonne solution.

Citation:

---

Envoyé par WebPac

Bonjour,

en fait cette solution est difficilement viable car tout ne passe qu'en string entre les 2 applications sans pouvoir définir de protocole de communication.

---

Les entrées sortie sont des streams, ca ne change rien par rapport à l'utilisation d'un socket, tu peux très bien faire du binaire dessus. Si tu te limite en String, c'est parce que tu l'a choisi

Citation:

---

En effet, cela signifie qu'il faut recréer les classes en Java, on peut imaginer qu'on a une désérialisation/sérialisation des objets en string, mais ensuite, il faut tout de même synchroniser toutes les propriétés de chaque objet.

---

Que tu le face là ou dans ton connecteur JNI qui ferait l'hypothétique interfaceage, tu devra le faire ;). Les objet .NEt ne sont pas des objet Java, quoi qu'il arrive. Ils ne sont par traités par la même VM ni par le même système de garbage collection.

Citation:

---

Enfin, je pense que cette solution serait difficilement maintenable et viable, je suis donc toujours à la recherche d'une bonne solution.

---

Il reste plus que le CORBA et deux application séparée, c'est le seul protocole objet que je connaisse qui soit indépendant du language.

Citation:

---

Envoyé par tchize_

Les entrées sortie sont des streams, ca ne change rien par rapport à l'utilisation d'un socket, tu peux très bien faire du binaire dessus. Si tu te limite en String, c'est parce que tu l'a choisi

---

En effet, mais ça reste qu'on n'utilise que des types primaires, string, int, float. Et il faut qu'on le gère à la main.

Citation:

---

Envoyé par tchize_

Que tu le face là ou dans ton connecteur JNI qui ferait l'hypothétique interfaceage, tu devra le faire ;). Les objet .NEt ne sont pas des objet Java, quoi qu'il arrive. Ils ne sont par traités par la même VM ni par le même système de garbage collection.

---

Tout à fait, mais dans ce cas, on n'a pas besoin de gérer comment la communication se fait.
En fait, j'ai une mauvaise expérience où il fallait faire communiquer 2 applications en TCP/IP, donc en string et autres types primaires et l'évolution des applications avec gestion de la compatibilité des versions précédentes était une véritable galère et je ne souhaite pas devoir le refaire.

Citation:

---

Envoyé par tchize_

Il reste plus que le CORBA et deux application séparée, c'est le seul protocole objet que je connaisse qui soit indépendant du language.

---

Je ne connais pas CORBA mais je vais me renseigner dessus quand j'aurai le temps.