[VS] partager un fichier de class ds plusieurs projets d'une solution

partager un fichier de class ds plusieurs projets d'une solution [VS] - C#/.NET managed - Programmation

Marsh Posté le 12-08-2008 à 12:07:35    

Bonjour  
 
Voici mon problème.
Dans VS 2005,  comment partager un fichier de class dans plusieurs projets d'une même sotution sans créer de DLL.
Le fichier est composé d'une seule classe qui permet l'interfacage à la DLL systèm rapi (pinvoke).  
J'ai plusieurs executables (= plusieurs projets) à générér qui utilisent cette class.  
Je ne souhaites pas créer une DLL (pas de nouveau projet librairie de class).
Mais je ne trouve pas comment empecher VS 2005 de faire plusieurs copies du fichier de class.
Evidement je ne souhaites pas avoir à me modifier toutes les copies dès que je modifie la class rapi.
 
Merci de votre aide
 
A+
 

Reply

Marsh Posté le 12-08-2008 à 12:07:35   

Reply

Marsh Posté le 12-08-2008 à 13:19:08    

Quand tu fais "ajouter élément existant" ça le recopie ?

Reply

Marsh Posté le 12-08-2008 à 15:06:30    

Oui exactement.
Excellent => XML is like violence. If it doesn't solve you problem, you didn't use it enough.

Reply

Marsh Posté le 13-08-2008 à 08:42:41    

Une idée  

Reply

Marsh Posté le 13-08-2008 à 12:37:30    

Absolument aucune.
Habituellement, je fait justement un projet dans ces cas, ce qui me crée une DLL avec tous les avantages liés à cette dernière.
 
En fait, pour quelle raison ne veux-tu pas d'une DLL ?

Reply

Marsh Posté le 13-08-2008 à 14:24:21    

MagicBuzz a écrit :

Quand tu fais "ajouter élément existant" ça le recopie ?


 
J'ai une solution visual C++ 2005 avec plusieurs projets. Ces projets ont des sources en commun, que j'ai ajouté en faisant "ajouter un élément existant". Ca ne fait pas une copie, je ne comprends pas pourquoi chez toi ca fait une copie.
 
Mais ce n'est pas forcément une bonne solution. Je te conseille plutot de partager tes sources communes via un projet supplémentaire dans ta solution (pas obligé de faire une "dll", une simple lib suffit), c'est encore la meilleure solution.  

Reply

Marsh Posté le 20-08-2008 à 15:21:11    

Désolé du retard et merci de vos réponses.
 

MagicBuzz a écrit :

Absolument aucune.


Super  :D  
 

MagicBuzz a écrit :


En fait, pour quelle raison ne veux-tu pas d'une DLL ?


Parce que les programmes sont distribués à des utilisateurs peu spéciailiste. Je prefere donc avoir une appli très compact qui tiens dans un seul fichier.
 
Je confirme que sur mon install l'ajoute d'un élément existant fait une copie du source dans le projet :(
 

xilebo a écrit :


Mais ce n'est pas forcément une bonne solution. Je te conseille plutot de partager tes sources communes via un projet supplémentaire dans ta solution (pas obligé de faire une "dll", une simple lib suffit), c'est encore la meilleure solution.  


 
Oui c'est bien ce que je voudrais faire mais .... je n'y arrive pas: le projet "librairie de classe" génére une DLL. Impossible de lui faire générer une librairie statique.
Je travail en C# je ne sais pas si cela à une influence. As-tu une idée ?
 
 
Merci en tout cas de votre aide
 


Message édité par m3z le 20-08-2008 à 15:21:51
Reply

Marsh Posté le 24-08-2008 à 18:50:46    

A mon avis, oui, j'ai jamais vu de notion de "lib" en C#, c'est une notion C++ uniquement à priori. Si je ne m'abuse, une lib c'est justement ce qu'il te faudrait, c'est une sorte de DLL qui s'intègre dans le projet qui y fait appel (donc une DLL ou ton EXE)

Reply

Marsh Posté le 27-08-2008 à 09:56:34    

MagicBuzz a écrit :

A mon avis, oui, j'ai jamais vu de notion de "lib" en C#, c'est une notion C++ uniquement à priori. Si je ne m'abuse, une lib c'est justement ce qu'il te faudrait, c'est une sorte de DLL qui s'intègre dans le projet qui y fait appel (donc une DLL ou ton EXE)


 
Hello,  
 
Une lib c'est une notion qui dépasse largement C++ puisqu'elle arrive directement de l'assembleur en passant par tous les langages connus.  
il s'agit d'une librairie statique (=lie au projet de facon statique, c. a. d. ajouter au projet au moment de l'édition de lien DANS le code)   par opposition à une librairie dynamique ou DLL (=Dynamic Link Library) chez MS  qui est lié au moment de l'éxecution du code.
 
Cela dit je ne vois pas en quoi la génération d'un Byte Code plutout q'un code natif empêcherait la génération d'un libriairie statique.
A moins que la vérité ne soit ailleurs  :D  
 
A+

Reply

Marsh Posté le 27-08-2008 à 11:51:17    

Ben j'ai pas dit que ça empêchait quoi que ce soit.
 
Mais y'a pas de notion de lib en C#.
 
Et pour moi, oui, une "lib", c'est une sorte d'include non pas de code, mais d'assembleur déjà compilé.

Message cité 1 fois
Message édité par MagicBuzz le 27-08-2008 à 11:51:47
Reply

Marsh Posté le 27-08-2008 à 11:51:17   

Reply

Marsh Posté le 29-08-2008 à 14:12:02    

MagicBuzz a écrit :

Ben j'ai pas dit que ça empêchait quoi que ce soit.
.


 
 
La première parti de mon message réponds à ton post précédent (histoire d'étre précis), la seconde non (mais j'avoue que ce n'était pas évident ...  :ange: )
 

MagicBuzz a écrit :


Mais y'a pas de notion de lib en C#.


C'est bien l'objet de ce topic. Est-ce bien si sûr ? Je n'ai pas trouvé et xilebo semblais dire le contraire aussi j'aurais bien aimé avoir des confirmations supplementaires.
 

MagicBuzz a écrit :


Et pour moi, oui, une "lib", c'est une sorte d'include non pas de code, mais d'assembleur déjà compilé.


A force de faire de  l'a peu près, on fini par ne plus être clair.
La librairie est apparu pour 2 raisons. La première était la possibilité de groupé du code de même nature (code métier, interface spécifique, IHM etc).
La seconde était la possibilité de distribuer du code tier (pour un utilisateur final) sans donner le source. C'est évidement interessant pour les éditeurs désirant vendre librairie tout en conservant le lead.
Donc  

MagicBuzz a écrit :


Et pour moi, oui, une "lib", c'est une sorte d'include  


Je suis pas d'accord, même si je comprend l'analogie que veux faire.  
 
 
Cela dit :  
 
Est-ce que quelq'un sait faire une lib en C# ? ou m'expliquer pourquoi cela n'existe pas ?


Message édité par m3z le 29-08-2008 à 14:19:05
Reply

Marsh Posté le 30-08-2008 à 08:48:13    

Non ça n'existe pas.  
Pourquoi ça n'existe pas, car c'est complètement inutile et comme dit précédemment, une librairie est matérialisé sous forme de DLL (Class Library).


---------------
quand un homme raisonne mal c'est qu'il n'a pas les données pour raisonner mieux (diderot)
Reply

Marsh Posté le 18-09-2008 à 09:19:17    

Bonjour,  
 
Je recherche surtout des réponse positives (qui apportent quelque chose) ... Il y a d'autres réponse que celles convenus. Merci.
quand un homme raisonne mal c'est qu'il n'a pas les données pour raisonner mieux (diderot) => Effectivement !!!
 
 
 
Mon application doit etre contenu dans un seul fichier et être seulement dépendante de .NET (pas d'autres dll ). Ce n'est pas moi qui fixe les règles,  il  s'agit d'un impératif  issu du charge des charges !
 
Pour finir voici la solution de contournement que j'ai trouvé :
 
Il est possible d'ajouter un lien sur un fichier .cs plutôt que le fichier lui même. Cela permet d'inclure le même source dans chaque projet de la solution tout en centralisant la gestion du source de la librairie.
 
Dans l'explorateur de solution > Sur le projet > Ajouter > Un element existant.
 
Selectionner le fichier .cs et un menu apparait sur le bouton Ajouter. > Ajouter en tant que lien.
 
Et hop ! le tour est joué.
 
En espérant avoir été utile à d'autres. C'est le but d'un forum non ?
 
A+

Message cité 2 fois
Message édité par m3z le 18-09-2008 à 09:19:42
Reply

Marsh Posté le 18-09-2008 à 09:57:08    

Merci pour cette solution :jap:

Reply

Marsh Posté le 09-06-2009 à 14:30:09    

Hello,
 
Bravo M3Z pour ta ténacité.
 
Beaucoup ignorent que les DLL ont été inventées avant tout pour executer morceau par morceau un programme qui n'avait pas assez de place en mémoire, et qu'elles ont beaucoup d'inconvénient... :pfff:  
La plus grande qualité de C# est de contenir la quasi totalité des données dans un simple fichier source facilement éditable et modifiable. :D  
Je trouve la solution du lien excellente.
 
Merci M3Z ;)  
Je me suis inscrit à ce forum juste pour dire ca....

Reply

Marsh Posté le 10-06-2009 à 15:03:01    

m3z a écrit :

Bonjour,  
 
Je recherche surtout des réponse positives (qui apportent quelque chose) ... Il y a d'autres réponse que celles convenus. Merci.
quand un homme raisonne mal c'est qu'il n'a pas les données pour raisonner mieux (diderot) => Effectivement !!!
 
 
 
Mon application doit etre contenu dans un seul fichier et être seulement dépendante de .NET (pas d'autres dll ). Ce n'est pas moi qui fixe les règles,  il  s'agit d'un impératif  issu du charge des charges !
 
Pour finir voici la solution de contournement que j'ai trouvé :
 
Il est possible d'ajouter un lien sur un fichier .cs plutôt que le fichier lui même. Cela permet d'inclure le même source dans chaque projet de la solution tout en centralisant la gestion du source de la librairie.
 
Dans l'explorateur de solution > Sur le projet > Ajouter > Un element existant.
 
Selectionner le fichier .cs et un menu apparait sur le bouton Ajouter. > Ajouter en tant que lien.
 
Et hop ! le tour est joué.
 
En espérant avoir été utile à d'autres. C'est le but d'un forum non ?
 
A+


 
Une autre solution, serait de tout de même séparer les composant commun dans une (ou plusieurs) DLL et d'utiliser ILMerge en post compilation pour merger la DLL à l'exe finale. Resultat : un seul executable contenant toute tes assemblies ;)

Reply

Marsh Posté le 25-10-2009 à 12:50:00    

m3z a écrit :

Dans l'explorateur de solution > Sur le projet > Ajouter > Un element existant.
Selectionner le fichier .cs et un menu apparait sur le bouton Ajouter. > Ajouter en tant que lien.


Merci pour cette solution, j'avais exactement le même problème !
 

m3z a écrit :

En espérant avoir été utile à d'autres. C'est le but d'un forum non ?


:)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed