Cr�er une dll utilisant System::XML

Version imprimable

Voir 40 message(s) de cette discussion en une page

24/09/2009, 11h53
louf99

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

25/09/2009, 11h42
louf99

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 ?

25/09/2009, 18h38
bacelar

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�).
28/09/2009, 12h03
louf99

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.
28/09/2009, 14h17
bacelar

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).
28/09/2009, 16h26
louf99

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.
28/09/2009, 17h11
bacelar

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 ...

28/09/2009, 19h20
bacelar

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).
29/09/2009, 10h54
louf99

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.

29/09/2009, 17h56
louf99

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...
29/09/2009, 19h28
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)
30/09/2009, 15h46
louf99

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 !
30/09/2009, 20h00
bacelar

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.
02/10/2009, 09h20
louf99

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.
02/10/2009, 14h37
bacelar
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.

Voir 40 message(s) de cette discussion en une page