Créer une dll utilisant System::XML

Bonjour,

Utilisateur de VS6 je viens de basculer sur VS9 (=VS2008) et je découvre depuis plusieurs les joies du C++/CLI.

Aujourd'hui je voudrais créer une dll utilisant le namespace System::XML mais je ne parvient pas à créer mon projet correctement. Les clients de cette dll seront des application MFC compilé sous VS6 et d'autre application compilé depuis un L4G.

Je ne sais pas si je doit créer un projet dll de type MFC (dans ce cas, je n'ai pas accés à System::XML) ou si je dois créer un projet de type CLR (dans ce cas j'arrive pas à déclarer mes fonctions en externe).

J'ai suivis cette faq tres interessante : http://dotnet.developpez.com/faq/cppcli/?page=sommaire

J'ai essayer de suivre cette doc mais il semble que cela concerne un autre IDE que VS9 : http://cpp.developpez.com/faq/vc/?page=DLL#MakeDynDll

J'ai essayer de suivre cette doc mais il semble que cela concerne l'utilisation de dll C/C++ dans des applications C++/CLI (alors que moi je veux faire l'inverse) :
http://nico-pyright.developpez.com/t...c2005/interop/

Pouvez vous me donner un petit coup de pouce svp ?

Merci.

Bon vu que j'ai pas de réponse, je me dis que je doit être "trop loin" pour qu'on puisse m'aider. Je vais être plus précis mais je ne sais pas si je suis dans le "vrai".

Je suis donc sous MS Visual C++ 2008 v9.0
J'ai fait un /nouveau/projet/CLR/Bibliotheque de classe/

J'ai pas écrit grand chose ...

InlXML4.cpp

Code:

---

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

// Il s'agit du fichier DLL principal.   #include "stdafx.h"   #include "InlXML4.h" using namespace System;   void TraiteXmlSimple(String ^ fileName) { // On ouvre le fichier XML et on cré le navigteur XPathDocument ^ doc = gcnew XPathDocument(fileName); }

---

InlXML4.h

Code:

---

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

// InlXML4.h   #pragma once   using namespace System; using namespace System::Xml; using namespace System::Xml::XPath;   namespace InlXML4 {   public ref class InlXML { void TraiteXmlSimple(String ^ fileName); }; }

---

La compilation se passe bien mais l'edition de liens me met une erreur LN2020 :

Citation:

---

------ Début de la génération*: Projet*: InlXML4, Configuration*: Debug Win32 ------
Compilation en cours...
AssemblyInfo.cpp
Édition des liens en cours...
InlXML4.obj : error LNK2020: jeton non résolu (06000001) InlXML4.InlXML::TraiteXmlSimple
C:\Sources Automates\DLL_CTD\InlXML4\Debug\InlXML4.dll : fatal error LNK1120: 1 externes non résolus
Le journal de génération a été enregistré à l'emplacement "file://c:\Sources Automates\DLL_CTD\InlXML4\InlXML4\Debug\BuildLog.htm"
InlXML4 - 2 erreur(s), 0 avertissement(s)
========== Génération*: 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

---

Je réexplique mon but : c'est de créer une dll sous VS C++ 2008 utilisant les bibliotheque du framework 3.5 (System::XML ...). Donc, si j'ai bien compris cette dll doit être compilée pour la CLR (donc avec l'option /clr).

Merci pour votre aide

Je me demande en fait si j'aurais pas du faire une dll MFC sur laquelle j'aurais ajouté l'option /clr pour pouvoir acceder au fonction du framework 3.5.
Qu'en pensez vous ?

Bon j'avance, pour compiler il faut que j'utilise ce cpp :

Code:

---

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

// Il s'agit du fichier DLL principal.   #include "stdafx.h"   #include "InlXML4.h" using namespace System;   void InlXML4::InlXML::TraiteXmlSimple(System::String ^fileName) { // On ouvre le fichier XML et on cré le navigteur XPathDocument ^ doc = gcnew XPathDocument(fileName); }

---

Mais vous pouvez me dire si je prat du bon pied ?

Bon j'avance dans ma dll et je pense que je vais pouvoir faire tout ce que je voulais faire au sein de ma dll maintenant.

Par contre je cherche a savoir comment je vais "exporter" mes fonctions aux applications clientes. J'ai essayé en créant un fichier .def

Code:

---

1 2 3 4 5

LIBRARY "InlXML4.dll"   EXPORTS ; Les exportations explicites peuvent être placées ici TraiteXmlSimple @1

---

Mais ca me donne

Citation:

---

------ Début de la génération*: Projet*: InlXML4, Configuration*: Debug Win32 ------
Édition des liens en cours...
InlXML4.def : error LNK2001: symbole externe non résolu TraiteXmlSimple
C:\Sources Automates\DLL_CTD\InlXML4\Debug\InlXML4.lib : fatal error LNK1120: 1 externes non résolus
Le journal de génération a été enregistré à l'emplacement "file://c:\Sources Automates\DLL_CTD\InlXML4\InlXML4\Debug\BuildLog.htm"
InlXML4 - 2 erreur(s), 0 avertissement(s)
========== Génération*: 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

---

Et si j'enleve le fichier .def pour déclarer ma fontion externe dans le .h de cette maniere :

Code:

---

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

// InlXML4.h   #pragma once   using namespace System; using namespace System::Xml; using namespace System::Xml::XPath;   namespace InlXML4 {   public ref class InlXML { void TraiteXmlSimple(String ^ fileName); __declspec(dllexport) void TraiteXml(String ^ fileName); }; }

---

Je me paye cette erreur :

Citation:

---

------ Début de la génération*: Projet*: InlXML4, Configuration*: Debug Win32 ------
Compilation en cours...
InlXML4.cpp
c:\sources automates\dll_ctd\inlxml4\inlxml4\InlXML4.h(14) : error C3387: 'TraiteXml'*: __declspec(dllexport)/__declspec(dllimport) ne peut pas être appliqué à un membre d'un type managé
c:\sources automates\dll_ctd\inlxml4\inlxml4\InlXML4.h(14) : error C3395: 'InlXML4::InlXML::TraiteXml'*: __declspec(dllexport) ne peut pas être appliqué à une fonction avec la convention d'appel __clrcall
Le journal de génération a été enregistré à l'emplacement "file://c:\Sources Automates\DLL_CTD\InlXML4\InlXML4\Debug\BuildLog.htm"
InlXML4 - 2 erreur(s), 0 avertissement(s)
========== Génération*: 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

---

Du coup je me demande si on peu faire une dll en utilisant les fonction disponible dans le framework 3.5 ?

Je pense que vous vous fourvoyez un peu (même beaucoup).

Il est facile d'exporter des fonctions mais c'est très loin d'être le cas pour des méthodes.

Comme vos pérégrinations montrent vos méconnaissances dans les mécanismes d'export de méthodes et qu'un L4G a très peu de chance de comprendre autre chose que des API C et ou COM, on va faire dans le simple.

En utilisant Reflector (http://www.red-gate.com/products/reflector/), on voit dans les propriétés de l'assembly System.Xml.dll l'attribut

Citation:

---

[assembly: ComVisible(false)]

---

donc pour l'accès à System.Xml depuis le L4G directement via COM, c'est râpé.

Il faudra donc soit faire une couche d'accès en C, soit une couche d'accès en COM.

Pour la couche d'accès en COM, je ne vois pas trop l'intérêt, vu que le composant MSXML de M$ existe déjà.

Pour une couche d'accès en C, il ne faut que des fonctions et pas de méthodes. Il faut donc concevoir une API C et ne pas se reposer sur un export "magique" de méthode.

Un client MFC VC++6 peut accéder à des méthodes de classe exportées depuis une Dll compilés avec VC++6, mais il n'y a pas garanties si la dll est compilé avec VS9 et surement pas si le code est compilé avec un autre compilateur (mangling des noms non standardisé).

Pour accéder à du code managé depuis du code non managé, il y a les CCW (http://msdn.microsoft.com/en-us/library/f07c8z1c.aspx) mais c'est du COM donc peut-être problématique pour un L4G et System.Xml n'est pas ouvert pour cela.
Il reste l'implémentation de Wrapper fait à la main en C++/CLI, mais tant qu'à faire, il est préférable que ce wrapper soit le plus utilisable possible donc avec une API C (en non C++ de VS).

Il y a plus d’option dans l’autre sens (managé vers non managé).

Tout d'abord merci pour ta réponse (je me sentais un peu "alone in the dark").

Je suis conscient que mes compétences en c++/cli et .Net sont trés mègre, je suis en pleine découverte de ce monde. Cela dis j'ai tout de meme un certains nombre de compétence en c et c++.

Je reprécise mon (mes) besoin actuel...

1. Utiliser System.XML dans mes projets VS6

J'ai des centaines de projets C/C++ compilés avec VS6.
J'ai besoin d'utiliser la bibliotheuqe System.XML (et d'autre) de M$ dans ces projets.
L'utilisation de ces bibliotheque XML me permettrons de developper des "fonctions XML".
Ces "fonction XML" doivent pouvoir être appelé depuis mes projets.
J'ai choisis de convertir mes projets VS6 en VS9.
j'ai choisis d'utiliser le framework 3.5 de M$.
Je pense convertir mes projets en code managé.

Je cherche une solution pour accéder aux librairies System.XML de M$.
Pour cela j'ai commencé par developper une application console avec toutes les "fonctions XML" qui je veux fournir à mes projets.
Maintenant je veux faire en sorte que ces "fonctions XML" soient appelable depuis mes projets converti en VS9.
Je vois actuellement 3 pistes :
1. Intégrer directement mes "fonctions XML" dans mes projets
--> Mais des que j'appel System::XML j'ai une erreur
2. Integrer mon projet comportant mes "fonctions XML" dans la meme solution ou se trouve mes projets converti en VS9
--> Mais pour le moment, j'arrive pas a appeler mes "fontions XML" depuis mes projets.
3. Faire une librairie (dynamique ou pas) pour mes "fonction XML" que j'intègrerais dans mes projets.
--> Mais je galere avec les exports des fonctions comme vous pouvez le voir plus haut.

2. Faire une dll appelable depuis le L4G Centura
J'ai déjà une API C me permmetant de réaliser des dll appelable depuis Centura. Ces dll sont developpées en c/c++. Ces dll exportes des methodes ET des fonctions. Ces dll sont en mesure de recevoir un pointeur sur un objet centura et de remplir cet objet.
Je compte utiliser cette API pour offrir mes "fonctions XML" à centura.
Etant donné que mes 2 besoins représente l'export des meme "fonction XML", je me dis que je peux faire un seul et unique projet. Mais si c'est pas possible c'est pas grave.
Si c'est pas possible de faire une dll pour centura, je trouverais une autre solution pour communiquer avec centura (via des fichiers ou des sockets par exemples).

J'espere avoir été plus claire.

Pouvez vous me donner votre avis sur les pistes a suivre et les différents avantage/inconveniant que représent les différents choix qui s'offre a moi ?

Merci pour votre aide.

Si la migration de VC++6 à VS2009 n'est pas un obstacle (je trouve cela assez dangereux pour un nombre aussi important de projets, d'où l'utilisation de MSXML pour VC++6), il ne reste plus qu'à convertir vos projets natifs VS2008 en projet mixte managé/non managé VS2008.

Après cette opération, vous pourrez faire toutes les manipulations possibles, c'est tout l'intérêt du C++ managé par rapport aux autres langages .NET.

Click droit sur un projet migré -> Proprerties -> Configration Properties -> General -> (ligne du panel droit)Common Language Runtime support
Sur cette ligne, faire passer la valeur de "No Common Language Runtime support" à "Common Language Runtime support"

Clickez sur "Appliquer"

Vous êtes maintenant dans un projet mixte managé/non managé.

Il vous faut maintenant ajouter les assemblies dont vous avez besoin dans :
Click droit sur un projet migré -> Proprerties -> Common Properties -> Framework and References.
Dans le panel de droit, vous avez une IHM pour ajouter tous les assemblies nécessaire à l’exécution de votre code managé, comme System.Xml.

Après ces modifications, votre piste n°1 (la moins clean) devrait marcher directement.

La piste n°2 est bien meilleure. Une fois la manipulation de conversion des projets en projets mixtes, il vous suffira d'ajouter une dépendance de projet entre vos projets mixtes et le projet comportant vos "fonctions XML".
C'est comme avec les projets C++ non managés, cela permet de se servir du résultat de compilation d'un projet dans un autre projet. En non managé, c'est des lib et des dll que l'on récupère, en managé c'est un assembly.
Comme en non managé, rien ne vous oblige à utilisez les dépendances de projets. Vous pouvez compiler le projet comportant vos "fonctions XML" dans une assemnly puis ajouter cette assemblie aux dépendances de votre projet comme vous l'avez fait pour System.Xml.

La piste n°3 n'est pas la plus simple pour une utilité toute relative. Avec votre projet mixte, vous pouvez utiliser directement vos classes .NET sans aucun intermédiaire autre que l'ajout des références éventuelles et votre projet mixte est à même de pouvoir exporter des fonctions et méthodes selon la décoration de nom C et C++ de VS2008.

Pour les problèmes d'interface avec "L4G Centura", que je ne connais pas, votre projet mixte est en mesure d'exporter des fonctions et méthodes selon la décoration de nom C et C++ de VS2008. Pouvez-vous être plus précis sur les exigences de ce L4G en termes d'interface C/C++, si les appels directs aux fonctions exportées par le dll/assembly (miste) ne marchent pas ?

Je ne vous que des avantages à l’approche qui consiste à convertir vos projets en projets mixtes, donc attaquables par le L4G si c’est un projet de dll pour le L4G, et utilisant directement les assemblies .NET si c’est un projet d’exécutable. Je vous conseille de laisser vos "fonctions XML" dans votre assembly dédié permettant de factoriser le code pour tous vos projets (exécutables et dll).

Merci pour vos réponses précieuses...

Je decouvre quelquechose : il faut lier les références aux assembly que l'on veut utiliser avant de les utiliser. Lier le framework ne suffit pas ... C'est nouveau ca non (entre VS6 et VS9 ?).

Avec la piste 1, j'arrive à acceder à mes "fonctions XML" (projet que j'appel InlXML4).

Avec la piste 2, je n'y arrive pas...
J'arrive à faire un "using namespace InlXML4;".
Mais mes fonctions de InlXML4 ne sont pas accessible depuis le projet client. J'ai l'impression qu'il faut que je déclare ces fontions de type externe depuis la dll. Mais pour l'instant je n'y arrive pas. Est ce que c'est bien cela ou je suis sur une mauvaise piste ? Peut etre faut il ajouter un un .h, .lib, .exp à mon projet client ?

Avec la solution 3, je n'y arrive encore pas. Pourtant je vois bien que ma dll est bien intégré à mon projet.

Citation:

---

------ Début de la génération*: Projet*: XL_Dos, Configuration*: Debug Win32 ------
Copie de 'c:\Sources Automates\DLL_CTD\InlXML4\Release\InlXML4.dll' dans le répertoire cible en cours...
Copie de 'c:\Sources Automates\DLL_CTD\InlXML4\Release\InlXML4.pdb' dans le répertoire cible en cours...
Compilation en cours...
StdAfx.cpp
WINVER not defined. Defaulting to 0x0600 (Windows Vista)
Compilation en cours...
XL_Dos.cpp
Port_VS2008.cpp
Fct_VS2008.cpp
Commun_VS2008.cpp
cInl_VS2008.cpp
cExamAnt_VS2008.cpp
cDonneur_VS2008.cpp
cDon_VS2008.cpp
cAutovert_VS2008.cpp
Bidi_VS2008.cpp
Automate_VS2008.cpp
Génération de code en cours...
Édition des liens en cours...
Incorporation du manifeste en cours...
Création d'un fichier d'informations de consultation...
Microsoft Browse Information Maintenance Utility Version 9.00.21022
Copyright (C) Microsoft Corporation. All rights reserved.
Mise en cache des informations de métadonnées pour c:\sources automates\dll_ctd\inlxml4\release\inlxml4.dll...
Le journal de génération a été enregistré à l'emplacement "file://c:\Sources Automates\Automates VS2008\XL_Dos\Debug\BuildLog.htm"
XL_Dos - 0 erreur(s), 0 avertissement(s)
========== Génération*: 1 a réussi, 0 a échoué, 0 mis à jour, 0 a été ignoré ==========

---

j'ai le meme probleme que pour la piste 2

Citation:

---

Pour les problèmes d'interface avec "L4G Centura", que je ne connais pas, votre projet mixte est en mesure d'exporter des fonctions et méthodes selon la décoration de nom C et C++ de VS2008. Pouvez-vous être plus précis sur les exigences de ce L4G en termes d'interface C/C++, si les appels directs aux fonctions exportées par le dll/assembly (miste) ne marchent pas ?

---

Je comprend pas bien votre question... Vous voulez savoir comment le L4G devra utiliser la dll ou quels sont les autres solutions que l'on peut envisager si la passage par une dll n'est pas possible ?

Encore une fois, merci pour votre aide.

Piste n°1, copie direct du code marche OK ?

Piste n°2, Je viens de vérifier mes propos avec VS2008 et je me suis un peu emmêlé les pinceaux dans le tapis. :aie:
La méthode que j'avais décrite marche bien en code non managé. Il faut faire un peu différemment en code managé.

Le but de la piste n°2 et bien d'avoir un assembly en code managé (C++ ou autre langage .NET) contenant vos "fonctions XML". OK ?

Il faut juste ajouter une référence vers le projet de vos "fonctions XML" dans les projets mixtes. il faut juste aller dans l'onglet "Project" à la place de ".NET" dans
Click droit sur un projet migré -> Proprerties -> Common Properties -> Framework and References -> Add New Reference.

Une fois cette manipulation faite, vous aurez directement accès à toutes les classes publics de votre projet de vos "fonctions XML" et à toutes leurs méthodes publics.

Il n'y a rien à ajouter, pas .h, .lib, .exp RIEN. C’est toute la beauté de .NET. Juste référencé l'assembly (le projet générant l'assembly dans ce cas précis).


La solution 3, je ne vois pas où vous voulez allez avec. Elle compile mais c'est une dll Native, une Dll .NET, une Dll mixte ?

Citation:

---

Je comprend pas bien votre question... Vous voulez savoir comment le L4G devra utiliser la dll ou quels sont les autres solutions que l'on peut envisager si la passage par une dll n'est pas possible ?

---

Les deux.
Mais je pense qu'une dll mixte ne devrait pas poser de problème si vous avez réussi à communique sous forme d'une dll avec ce L4G.

Oui la piste 1 c'est ok

Je cherche a faire marcher la piste 2 ...

Dans propriete du projet InlXML / propriete de configuration / general / j'ai mis ...
type de configuraion : dll
utilisation des mfc : oui dans une dll partagé
ATL : n'utilisant pas les ATL
prise en charge CLR : oui /CLR

Dans propriete du projet TOTO (/ propriete de configuration / general / j'ai mis ...
type de configuraion : exe
utilisation des mfc : oui dans une dll partagé
ATL : n'utilisant pas les ATL
prise en charge CLR : oui /CLR

Dans les references du projet TOTO j'ai bien ajouté la référence sur InlXML4 dans l'onglet "Projet".

Les 2 projets TOTO et InlXML4 sont dans la meme solution VS9.

InlXML4.h

Code:

---

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

// InlXML4.h   #pragma once   using namespace System; using namespace System::Xml; using namespace System::Xml::XPath;   namespace InlXML4 { public ref class InlXML { int TraiteXmlSimple(String ^ fileName); int TraiteXml(String ^ fileName); }; }

---

InlXML4.cpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

// Il s'agit du fichier DLL principal.   #include "stdafx.h"   #include "InlXML4.h" #include "IterXML.h"   using namespace System;   int InlXML4::InlXML::TraiteXmlSimple(String ^fileName) { // On ouvre le fichier XML et on cré le navigteur XPathDocument ^ doc = gcnew XPathDocument(fileName); XPathNavigator ^ nav = doc->CreateNavigator();   // On récupère un Iterateur XPathNodeIterator ^ iter = nav->Select("Recordbook/Records/Record");   // Pour chaque Record while (iter->MoveNext()) { // On récupère l'info FirstValue String ^ firstValue = iter->Current->SelectSingleNode("FirstValue")->Value; // On récupère l'info SecondValue String ^ secondValue = iter->Current->SelectSingleNode("SecondValue")->Value; Console::WriteLine("{0},{1}", firstValue, secondValue); } return 0; }   int InlXML4::InlXML::TraiteXml(String ^fileName) { String ^ monNomFichier = ".\\Examples_XML\\25-08-2009A2-40059.5647569444_hml.xml"; IterXML ^ it = gcnew IterXML(monNomFichier, 3); if(it->Select("batch_submission/samples/sample", 0)) Console::WriteLine("<{0}>", it->Get("submitting_sample_id",0)); // Pour tous les samples while(it->SelectNext(0)) { Console::WriteLine("<{0}>", it->Get("typed_loci/typed_locus/locus/name",0)); it->Select("typed_loci/typed_locus/allele_call",1); while(it->SelectNext(1)) Console::WriteLine("<{0}>", it->Get("name",1)); } Console::ReadKey(); return 0; }

---

Mais je n'arrive toujours pas à acceder à mes fonctions depuis le projet TOTO : Quand je tape InlXML4::InlXML:: puis CTRL+ESPACE il me propose des methode herité de System me semble-t-il comme Equals, getType, ToString ... mais pas TraiteXML() ...

La piste 3 on laisse tomber pour le moment

L'intégration sur la L4G, j'y reviendrais plus tard ...

Encore un peu d'aide je deviens fous ...

Merci encore ...

InlXML devrait être un projet pure CLR.
prise en charge CLR : oui /CLR:pure

utilisation des mfc : oui dans une dll partagé
Depuis quand des dlls/assemblies utilitaires utilisent les MFC !?!?!?! ON VIRE.

Si le projet "InlXML" n'a pas été compilé, c'est normal qu'Intellisense ne trouve pas les méthodes, et après compilation ce n’est pas sûr à 100%.
Attention, vous n'avez accès qu'aux méthodes publics des classes.
"TraiteXmlSimple" et "TraiteXml" ne le sont pas publics. (Internal est le modifier par défaut, je crois).

Ca y est je parviens à compiler et a utiliser mes classes depuis le projet client. J'ai recré un projet de bibliotheque CLR sans MFC et j'ai passé mes classe de InlXML4 en public. Un grand merci a toi bacelar de m'avoir aidé dans ce brouillard ... épais ...

Par contre je comprend pas pourquoi le compilo me demande de déclarer mes fonction TraiteXML() en static ?
Aussi je me demnade quel est l'avantage de compiler le projet InlXML4 avec l'option clr:pure ?

Je vais pouvoir avancer dans mon dev... mon analyse pardon...

louf9

Citation:

---

Je comprend pas bien votre question... Vous voulez savoir comment le L4G devra utiliser la dll ou quels sont les autres solutions que l'on peut envisager si la passage par une dll n'est pas possible ?

---

La "meilleur" solution envisagée par le L4G est la suivante :
Pouvoir intégrer une dll (et non appeler un programme annexe).
Le volume de fichier XML à traiter par le L4G via la dll est de l'ordre de plusieurs centaines par minute pour des fichiers de plusieurs milliers de ligne.
Donc la L4G aura besoin de faire un grand nombre d'appel à la dll.
Plusieurs "instance" de ce L4G seront exécute en parallèle. Dans la plupart des cas, une seul exe (de l'application via le L4G) sera présent sur le poste (PC Windows XP minimum). Plusieurs instances devront pouvoir accéder aux fonctions XML de la dll.

Une solution au pire des cas peut être envisagée.
Ne pas faire de dll.
Faire une programme annexe qui tournerais en parrallèle du programme en L4G.
Ce programme annexe convertira les fichiers xml dans un format de fichier plus basique que le L4G sera traiter.

Merci pour votre aide.

louf

Citation:

---

Par contre je comprend pas pourquoi le compilo me demande de déclarer mes fonction TraiteXML() en static ?

---

Bizarre, je viens de faire le test avec une library de classe écrit en c# et une library de classe en C++ et aucune ne m'a posé ce problème ?

Code C# Class1.cs

Code:

---

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

using System; using System.Collections.Generic; using System.Linq; using System.Text;   namespace ClassLibrary1 { public class Class1 { public int toto() { return 0; } } }

---

Code C++ de la ClassLibrary (C++ managé)

InlXML4.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

// InlXML4.h   #pragma once   using namespace System;   namespace InlXML4 {   public ref class InlXML { public : int TraiteXmlSimple(String ^ fileName); int TraiteXml(String ^ fileName); };   private ref class IterXML { public: IterXML(String^ file, int num){}; bool Select(String^ path, int num){return false;}; String^ Get(String^ element, int num){return String::Empty;}; bool SelectNext(int num){return false;}; }; }

---

InlXML4.cpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

// This is the main DLL file.   #include "stdafx.h"   #include "InlXML4.h"   using namespace System;   using namespace System::Xml; using namespace System::Xml::XPath;   int InlXML4::InlXML::TraiteXmlSimple(String ^fileName) { // On ouvre le fichier XML et on cré le navigteur XPathDocument ^ doc = gcnew XPathDocument(fileName); XPathNavigator ^ nav = doc->CreateNavigator();   // On récupère un Iterateur XPathNodeIterator ^ iter = nav->Select("Recordbook/Records/Record");   // Pour chaque Record while (iter->MoveNext()) { // On récupère l'info FirstValue String ^ firstValue = iter->Current->SelectSingleNode("FirstValue")->Value; // On récupère l'info SecondValue String ^ secondValue = iter->Current->SelectSingleNode("SecondValue")->Value; Console::WriteLine("{0},{1}", firstValue, secondValue); } return 0; }   int InlXML4::InlXML::TraiteXml(String ^fileName) { String ^ monNomFichier = ".\\Examples_XML\\25-08-2009A2-40059.5647569444_hml.xml"; IterXML ^ it = gcnew IterXML(monNomFichier, 3); if(it->Select("batch_submission/samples/sample", 0)) Console::WriteLine("<{0}>", it->Get("submitting_sample_id",0)); // Pour tous les samples while(it->SelectNext(0)) { Console::WriteLine("<{0}>", it->Get("typed_loci/typed_locus/locus/name",0)); it->Select("typed_loci/typed_locus/allele_call",1); while(it->SelectNext(1)) Console::WriteLine("<{0}>", it->Get("name",1)); } Console::ReadKey(); return 0; }

---

Code client en C++ mixte

Code:

---

1 2 3 4 5 6 7 8 9 10 11

int main() { System::Xml::NameTable toto; ClassLibrary1::Class1 titi; titi.toto(); ClassLibrary1::Class1^ tutu; tutu = gcnew ClassLibrary1::Class1(); tutu->toto(); InlXML4::InlXML tata; tata.TraiteXml("tutu"); }

---

Citation:

---

Aussi je me demnade quel est l'avantage de compiler le projet InlXML4 avec l'option clr:pure ?

---

En faisant de vos composants réutilisables des composants "pure" .NET, vous disposez gratuitement des fonctionnalités .NET comme une vérification à la compilation et à l'exécution de la validité du code (vérification supérieure à celle d'un compilateur C++ natif), ou encore la possibilité d'exécuter vos composants dans des environnements extrêmement contraignant en terme de sécurité comme ASP.NET ou SQL Server 2005 et supérieur etc...
En mettant l'option "clr:pure", cela vous empêche de faire des choses comme de l'arithmétiques de pointeurs ou autres cochonneries. C'est donc plus un avantage qu'un inconvénient.

Avec vos anciennes dll migrées de VC++6 natif en VS2008 mixte, vous devez avoir exactement le même fonctionnement qu'avant, vis à vis du L4G.

Je ne vois de problème intrinsèque à l'utilisation d'une dll mixte à la place de l'ancienne dll native.

Bon bin je sais pas pourquoi alors ... Mais je doit garder mes classe static ...

Par contre j'ai converti un vieux projet de dll pour le L4G dans un projet totoL4G. totoL4G est de type CLR. J'ai mis les projets totoL4G et InlXML4 dans la meme solution. J'ai ajouté la référence de InlXML4 dans le projet totoL4G.

Ton compile comme il faut. Le L4G voit bien les fonctions de totoL4G (ces fonction font appels à des fonctions definie dans InlXML4). Mais que j'execute (depuis le L4G en "run" je clique sur le bouton qui fait appel à la dll totoL4G), j'ai une excepion. Il semble que le L4G ne trouve pas la dll InlXML4.

Ca ressemble a ca dans une fenetre popup

Citation:

---

Debogeur juste a temps VS
Une exception non géré (System.IO.FileNotFoundException s'est produit dan le appliL4G.exe
...
impossible de charger le fichier ou l'assembly 'InlXML4'

---

Du coup j'ai essayé de déplacer InlXML4.dll, j'ai essayé de chager mes variable $PATH ... mais rien y fait...

Si quelqu'un à une nouvelle piste je suis preneur...

Cela dis je suis quand meme super content car je suis à deux doigt de faire exactement ce que j'esperais même pas pouvoir faire. Pratique quand meme c++/cli ...

Merci encore pour ton aide bacelar...

Ca progresse. :ccool:

Pour le coup des statics, il n'y aurait pas une classe "static" ou "abstract" dans le scope ?
Pouvez-vous montrer le .h où les méthodes ne peuvent qu'être statiques ?

.NET, pour éviter le dllHell, n'utilise pas le Path, mais utilise plutôt soit le GAC, soit des sous-répertoires dans le répertoire de l'exécutable.

En mettant l'exécutable, la dll mixte et l'assembly InlXML4.dll (ça a la même extension qu'une dll mais c'est un assembly et pas une dll) dans le répertoire de travail, cela devrait marcher. Sinon, vérifiez avec dependancyWalker (http://www.dependencywalker.com/) que les dll soit bien accessibles. Si tout est OK au niveau dll, utiliser "Assembly Binding Log Viewer" (Fuslogvw.exe http://msdn.microsoft.com/en-us/libr...c4(VS.71).aspx) pour avoir plus d'info sur le problème.

Mais dans l'absolu, si vous utilisez le composant InlXML4 dans bon nombre de projets, la solution standard est de l'enregistrer dans le GAC (Global Assembly Cache)

C'est sympa mes recherches, a chaque que j'ai une nouvelle direction j'ai 3 pistes différentes ... qui finissent pas se croiser ... Je vais faire un point comme vous pourrez m'aider et moi je vais avoir les idées plus claire apres ... Merci pour cette assistance généreuse bacelar.

L'histoire des statics
C'est par ce que j'appelais mes methode de cette maniere :

Code:

---

InlXML21::InlXML::TraiteXml(".\\Examples_XML\\25-08-2009A2-40059.5647569444_hml.xml");

---

Ca fait un moment que je fais plus d'objet à vrai dire, je fait du c depuis un moment et j'ai la mémoire qui flanche ...
--> Comme je ne compte pas instancier mes objet par la suite, j'ai laissé la déclaration de mes fonctions en statique.

Tout dans le meme rep

Citation:

---

En mettant l'exécutable, la dll mixte et l'assembly InlXML4.dll (ça a la même extension qu'une dll mais c'est un assembly et pas une dll) dans le répertoire de travail, cela devrait marcher.

---

Bin c'est pourtant ce que j'avais fait. J'ai mis tout le contenu du repertoire release de dllMixte (ex totoL4G dans le post précédent). Ce repertoire contient la dll dllMixte.dll et l'assembly testXML4.dll (j'ai bien compris :ccool:).
--> Et j'avais la meme erreur (decrite dans le post précédent) de cette maniere.

dependencywalker
Quand j'ouvre dllMixte avec cette appli j'ai l'erreur suivante :

Citation:

---

Error: At least one required implicit or forwarded dependency was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

---

Pas trés etonnant en fait, vu ce que me faisait l'execution de MonProgL4G.

Fuslogvw.exe
Bin j'ai pas bien compris comment il s'utilise, je l'ai lancé et j'ai reproduit le bug. J'esperais qu'il se passerais un truc dans la fenetre de Fuslogvw.exe mais ... rien ... J'ai changé les différents paramètres possibles de ce programme mais ... rien ...

GAC

Citation:

---

Mais dans l'absolu, si vous utilisez le composant InlXML4 dans bon nombre de projets, la solution standard est de l'enregistrer dans le GAC (Global Assembly Cache)

---

Cette piste ma pas mal plus :) ...
J'ai donc installé le "Kit de développement .NET Framework SDK" puis j'ai appris à "généré une paire de clé publique" pour "signer mon assembly InlXML4 avec un nom fort" (j'ai du convetir au passage mon assembly en CLR pure) pour "ajouter un assembly dans le GAC" en utilisant "Assembly Cache Viewer (Shfusion.dll)". Ca m'a pris 5mn tout ca (à quelques heures prés :))
--> Ca change rien quand j'excecute MonProgL4G.exe !

Bref
Je crois que j'en suis la donc ... Pas loin du tout, mais il me manque un petit truc encore. Si je peux avoir encore quelques coup de pouces ... Cela dis, j'ai pas mal d'application installé maintenant pour qu'on y arrive ...

Merci encore !

L'histoire des statics
Si vous n'instanciez pas les objets, c'est normal de n'avoir accès qu'aux méthodes statiques.
Si vos classes ont une sémantique ne nécessitant pas d'instanciation, pensez à marquer ces classes avec "static".

Code:

---

public static class InlXML {...}

---

Cela empêchera de déclarer par inadvertances des méthodes non statiques ou des constructeurs.

Tout dans le meme rep

dllMixte.dll et testXML4.dll sont-elles dans le répertoire de l'exécutable ?

Si oui, pouvez-vous m'envoyer ces 2 dll ? Je m'occupe de faire une exe qui appel une des fonctions exportées par dllMixte.dll et qui pose problème.

On verra plus tard pour le GAC.

Je sais pour le static mais sur le coup ca m'ettais sortie de la tete ...

Je t'ai envoyé un lien via mp. Si tu peux jeter un oeil ce serait vraiment sympa.

J'ai réintégré le projet InlXML21 dans l'arborescence de la solution testCo.
J'ai ajouté un projet pour la création d'une application MFC appelant la fonction "Connect" de la dll testCo.dll et en lançant cette exe, j'ai bien une exception dans le code de InlXML21 à cause d'une chaîne en dure dans le code.
Je n'ai pas les répertoires qui vont bien, mais l'assemby "System.Xml.dll" est bien chargé.

Le fait d'avoir à créer un exe MFC me plait que très moyennement.
J'y ai été contraint par le ligne "extern cInl oConn;" dans commun.h.
Elle m'oblige à faire

Code:

---

1 2	#include "cinl.h" #include "commun.h"

---

dans cet ordre.
"cinl.h" contient des types "String", donc c'était intégré ou ATL ou MFC et comme j'ai vu une "CWinApp" dans testCo, ça sentait déjà le sapin avec les MFC. D'où une application MFC pour tester juste le problème d'interOp avec System.Xml.dll.
La "msado20.tlb" utilisé est vieille de plusieurs dizaines d'années, ou presque, est-ce vraiment utile ?

Donc, chez moi, avec un exe dans le même répertoire que tous les dll et manifest ça plante sur un fichier inexistant et pas sur un problème de chargement.

Le truc, c'est que le librairie testCo n'est vraiment, mais vraiment pas clean au niveau API C.

Oui l'exemple donné n'est pas le mieux choisis mais j'en utiliserais d'autre en pratique. Cela dis c'est étrange que tu n'es pas la meme erreur de chargement de dll qui moi ...
Je vérifie ca et je te tiens au jus. Probablement demain, car je suis un peu charrette niveau timing ces jours ci ...

Merci encore pour ton aide.
A bientot.

Voila j'ai trouver un peu de temps et surtout un peu d'energie pour continuer dans ma quete...

Perso, j'ai l'impression que c'est l'assembly InlXML21.dll qui n'est pas trouvé par le CLR.

Je rappel que j'ai une application L4G "AppliL4G.exe" (écrite dans un langage non compatible .Net et non compilé avec .Net). Cette application utilise la dll "TestCo.dll". Et "TestCo.dll" utilise l'assembly "InlXML21.dll".

Quand, je supprime la ligne dans "TestCo.dll" qui fait appel à une methode de "InlXML21.dll", je n'ai aucune erreur, "AppliL4G.exe" me renvois bien le résultat d'une fonction ecrite dans "TestCo.dll".
Par contre quand j'ajoute la ligne qui fait appel à une methode de "InlXML21.dll", j'ai l'erreur suivante.

Citation:

---

Une exception non gérée du type 'System.IO.FileNotFoundException' s'est produite dans Module inconnu.

Informations supplémentaires*: Impossible de charger le fichier ou l'assembly 'InlXML21, Version=1.0.3588.27018, Culture=neutral, PublicKeyToken=null' ou une de ses dépendances. Le fichier spécifié est introuvable.

---

J'ai 3 idées :

1. La PublicKeyToken n'est pas bonne
En effet l'erreur que j'ai donne : "PublicKeyToken=null", alors que j'ai ajouté mon assembly au gac avec un clé public. Extrait de "Gacutil -l" --> "InlXML21, Version=1.0.3588.27018, Culture=neutral, PublicKeyToken=443033e8de111be8, processorArchitecture=x86"

J'ai ajouté InlXML21 (de type clr:pure) au gac de la maniere suivante :

Code:

---

1 2 3 4 5 6

sn -k keyPair.snk ildasm InlXML21.dll /out:InlXML21.il ren InlXML21.dll InlXML21.dll.orig ilasm InlXML21.il /dll /key=keyPair.snk gacutil -i InlXML21.dll

---

2. Peut etre que c'est une dépendance de InlXML21.dll qui n'est pas trouvé[/LIST]

System::XML::XPath .. ?

3. Peux etre qu'il ne faut pas toucher au GAC

Et que le CLR ne trouve pas mon assembly pour une autre raison ...


Bref si vous avez des idées ... je suis plus que jamais, preneur ...

Merci encore.

louf

Moi, j'ai tendance à utiliser FileMon
http://technet.microsoft.com/fr-fr/s.../bb896642.aspx

Cela permet de voir quels fichiers sont cherchés.

Ca y est !!! :ccool:
Merci encore bacelar. FileMon m'a permis de comprendre que mon appliL4G cherchait InlXML21.dll dans le repertoire ou se trouve l'exe qui run mon appliL4G (non encore compilé) et non dans le repertoire ou se trouve le source de appliL4G...

Puré j'en pouvais plus ...

MERCI BACELAR 8-)

Mes prochains posts seront plus interessant ... je l'espere ...
++