Astuce pour projet multiples ayant des fichiers en commun
10 réponses
alexandre jenny
Voila le soucis :
J'ai une solution c# qui est composée de 2 project c#, pour l'illustration
disons que l'un genere un software qui marche en commande de line et l'autre
est en windows forms.
Les deux projets partagent des fichiers en commun.(Un ensemble de fichiers
qu je vais appeler kernel ...).
Le soucis, c'est les repertoires et l'acces aux fichiers communs.
Solution 1:
Folder_masoluce
---> Folder_Projet1 (qui contient les fichiers kernel)
---> Folder_Projet2 (dans le project, on crée un repertoire
..\folder_projet1\ ou l'on insert les fichiers precedant)
Soucis : On ne peut pas faire pointer un repertoire ..\
Solution 2 :
Folder_masoluce
On met dans ce repertoire les .csproj et les fichiers commun
---> Folder_Projet1 (contient juste les fichiers specifiques au project 1)
---> Folder_Projet2 (contient juste les fichiers specifiques au project 2)
Soucis : Le repertoire de la soluce est vite un gros bordel
Solution 3 ( comment la mettre en place ? )
Folder_masoluce
---> Folder_Projet1 (contient juste les fichiers specifiques au project 1)
---> Folder_Projet2 (contient juste les fichiers specifiques au project 2)
---> Common (fichiers commun)
Comment on met cela en place ? Chaque fois qu'on insert des fichiers d'un
autres repertoires, ils sont copier en local dans le project courant.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
alexandre jenny
Tient, une solution :
Quant on fait "Add Existing", au lieu de faire ouvrir, on clique sur un Drop Down à coté et on selectionne "Link File". Fallait connaitre le truc ...
"alexandre jenny" <alexandre.jenny(a_virer)@kolor.com> a écrit dans le message de news:O%23m6G$
Voila le soucis : J'ai une solution c# qui est composée de 2 project c#, pour l'illustration disons que l'un genere un software qui marche en commande de line et
l'autre
est en windows forms. Les deux projets partagent des fichiers en commun.(Un ensemble de fichiers qu je vais appeler kernel ...).
Le soucis, c'est les repertoires et l'acces aux fichiers communs.
Solution 1: Folder_masoluce ---> Folder_Projet1 (qui contient les fichiers kernel) ---> Folder_Projet2 (dans le project, on crée un repertoire ..folder_projet1 ou l'on insert les fichiers precedant)
Soucis : On ne peut pas faire pointer un repertoire ..
Solution 2 : Folder_masoluce On met dans ce repertoire les .csproj et les fichiers commun ---> Folder_Projet1 (contient juste les fichiers specifiques au project 1) ---> Folder_Projet2 (contient juste les fichiers specifiques au project 2)
Soucis : Le repertoire de la soluce est vite un gros bordel
Solution 3 ( comment la mettre en place ? ) Folder_masoluce ---> Folder_Projet1 (contient juste les fichiers specifiques au project 1) ---> Folder_Projet2 (contient juste les fichiers specifiques au project 2) ---> Common (fichiers commun)
Comment on met cela en place ? Chaque fois qu'on insert des fichiers d'un autres repertoires, ils sont copier en local dans le project courant.
Tient, une solution :
Quant on fait "Add Existing", au lieu de faire ouvrir, on clique sur un Drop
Down à coté et on selectionne "Link File".
Fallait connaitre le truc ...
"alexandre jenny" <alexandre.jenny(a_virer)@kolor.com> a écrit dans le
message de news:O%23m6G$ehEHA.3912@TK2MSFTNGP11.phx.gbl...
Voila le soucis :
J'ai une solution c# qui est composée de 2 project c#, pour l'illustration
disons que l'un genere un software qui marche en commande de line et
l'autre
est en windows forms.
Les deux projets partagent des fichiers en commun.(Un ensemble de fichiers
qu je vais appeler kernel ...).
Le soucis, c'est les repertoires et l'acces aux fichiers communs.
Solution 1:
Folder_masoluce
---> Folder_Projet1 (qui contient les fichiers kernel)
---> Folder_Projet2 (dans le project, on crée un repertoire
..folder_projet1 ou l'on insert les fichiers precedant)
Soucis : On ne peut pas faire pointer un repertoire ..
Solution 2 :
Folder_masoluce
On met dans ce repertoire les .csproj et les fichiers commun
---> Folder_Projet1 (contient juste les fichiers specifiques au project 1)
---> Folder_Projet2 (contient juste les fichiers specifiques au project 2)
Soucis : Le repertoire de la soluce est vite un gros bordel
Solution 3 ( comment la mettre en place ? )
Folder_masoluce
---> Folder_Projet1 (contient juste les fichiers specifiques au project 1)
---> Folder_Projet2 (contient juste les fichiers specifiques au project 2)
---> Common (fichiers commun)
Comment on met cela en place ? Chaque fois qu'on insert des fichiers d'un
autres repertoires, ils sont copier en local dans le project courant.
Quant on fait "Add Existing", au lieu de faire ouvrir, on clique sur un Drop Down à coté et on selectionne "Link File". Fallait connaitre le truc ...
"alexandre jenny" <alexandre.jenny(a_virer)@kolor.com> a écrit dans le message de news:O%23m6G$
Voila le soucis : J'ai une solution c# qui est composée de 2 project c#, pour l'illustration disons que l'un genere un software qui marche en commande de line et
l'autre
est en windows forms. Les deux projets partagent des fichiers en commun.(Un ensemble de fichiers qu je vais appeler kernel ...).
Le soucis, c'est les repertoires et l'acces aux fichiers communs.
Solution 1: Folder_masoluce ---> Folder_Projet1 (qui contient les fichiers kernel) ---> Folder_Projet2 (dans le project, on crée un repertoire ..folder_projet1 ou l'on insert les fichiers precedant)
Soucis : On ne peut pas faire pointer un repertoire ..
Solution 2 : Folder_masoluce On met dans ce repertoire les .csproj et les fichiers commun ---> Folder_Projet1 (contient juste les fichiers specifiques au project 1) ---> Folder_Projet2 (contient juste les fichiers specifiques au project 2)
Soucis : Le repertoire de la soluce est vite un gros bordel
Solution 3 ( comment la mettre en place ? ) Folder_masoluce ---> Folder_Projet1 (contient juste les fichiers specifiques au project 1) ---> Folder_Projet2 (contient juste les fichiers specifiques au project 2) ---> Common (fichiers commun)
Comment on met cela en place ? Chaque fois qu'on insert des fichiers d'un autres repertoires, ils sont copier en local dans le project courant.
Quentin Pouplard
Solution 4:
Un assembly contenant ton code commun. J'imagine que tu y as pensé, je me demande en fait les critères qui t'ont fait rejeter cette solution?
En fait, j'y ai pensé mais bon, voila ... j'ai pas cherché plus loin (surement des préjugés de mes années classes dans une dll sous win32 ...).
Alors tente cette solution, c'est le plus propre, les plus facile à maintenir, le déploiement n'est plus vraiment un problème. Et exposer une classe dans un assembly demande juste le mot clé publique. De plus si ton "kernel" peut servir à d'autre chose, tu gagnes en fonctionnalités.
Enfin beauté de .NET tu peux développer dans le langage que tu veux... (par ex: C++ pour ton kernel, et C# pour le reste).
En fait, j'y ai pensé mais bon, voila ... j'ai pas cherché plus loin
(surement des préjugés de mes années classes dans une dll sous win32
...).
Alors tente cette solution, c'est le plus propre, les plus facile à
maintenir, le déploiement n'est plus vraiment un problème. Et exposer
une classe dans un assembly demande juste le mot clé publique. De plus
si ton "kernel" peut servir à d'autre chose, tu gagnes en
fonctionnalités.
Enfin beauté de .NET tu peux développer dans le langage que tu veux...
(par ex: C++ pour ton kernel, et C# pour le reste).
En fait, j'y ai pensé mais bon, voila ... j'ai pas cherché plus loin (surement des préjugés de mes années classes dans une dll sous win32 ...).
Alors tente cette solution, c'est le plus propre, les plus facile à maintenir, le déploiement n'est plus vraiment un problème. Et exposer une classe dans un assembly demande juste le mot clé publique. De plus si ton "kernel" peut servir à d'autre chose, tu gagnes en fonctionnalités.
Enfin beauté de .NET tu peux développer dans le langage que tu veux... (par ex: C++ pour ton kernel, et C# pour le reste).
> Alors tente cette solution, c'est le plus propre, les plus facile à maintenir, le déploiement n'est plus vraiment un problème. Et exposer une classe dans un assembly demande juste le mot clé publique. De plus si ton "kernel" peut servir à d'autre chose, tu gagnes en fonctionnalités.
Enfin beauté de .NET tu peux développer dans le langage que tu veux... (par ex: C++ pour ton kernel, et C# pour le reste).
As tu un bon tutorial sous la main, ou un lien web pour commencer ?
Merci Alexandre
> Alors tente cette solution, c'est le plus propre, les plus facile à
maintenir, le déploiement n'est plus vraiment un problème. Et exposer
une classe dans un assembly demande juste le mot clé publique. De plus
si ton "kernel" peut servir à d'autre chose, tu gagnes en
fonctionnalités.
Enfin beauté de .NET tu peux développer dans le langage que tu veux...
(par ex: C++ pour ton kernel, et C# pour le reste).
As tu un bon tutorial sous la main, ou un lien web pour commencer ?
> Alors tente cette solution, c'est le plus propre, les plus facile à maintenir, le déploiement n'est plus vraiment un problème. Et exposer une classe dans un assembly demande juste le mot clé publique. De plus si ton "kernel" peut servir à d'autre chose, tu gagnes en fonctionnalités.
Enfin beauté de .NET tu peux développer dans le langage que tu veux... (par ex: C++ pour ton kernel, et C# pour le reste).
As tu un bon tutorial sous la main, ou un lien web pour commencer ?
Merci Alexandre
alexandre jenny
> Alors tente cette solution, c'est le plus propre, les plus facile à maintenir, le déploiement n'est plus vraiment un problème. Et exposer une classe dans un assembly demande juste le mot clé publique. De plus si ton "kernel" peut servir à d'autre chose, tu gagnes en fonctionnalités.
Enfin beauté de .NET tu peux développer dans le langage que tu veux... (par ex: C++ pour ton kernel, et C# pour le reste).
Est-ce que cela peut resoudre le problème que j'ai actuellement, ie : - j'ai dans le kernel des ressources localisée qui donne une dll, kernel.resource.dll en fr-FR, et en neutral. Pour y acceder, je procede comme suit : Je crée un ressource manager qui accede à la dll de ressource. res = new ResourceManager("Kernel.KernelMessages", System.Reflection.Assembly.GetExecutingAssembly()); puis je fais res.GetString( txtRes ) pour retrouver le string chercher.
Le pb, c'est que si je compile les .resx dans le kernel, cela va donner une dll qui s'appelle kernel.ressource.dll qui devra etre accedée par "Kernel.KernelMessages". Mais si je le compile dans le GUI, l'acces devrait etre "GUI.KernelMessages". Est-ce que cela ressoudra mon problème (A priori oui, car la compilation se faisant que dans le kernel, l'acces devrait etre unique ... hum ...
> Alors tente cette solution, c'est le plus propre, les plus facile à
maintenir, le déploiement n'est plus vraiment un problème. Et exposer
une classe dans un assembly demande juste le mot clé publique. De plus
si ton "kernel" peut servir à d'autre chose, tu gagnes en
fonctionnalités.
Enfin beauté de .NET tu peux développer dans le langage que tu veux...
(par ex: C++ pour ton kernel, et C# pour le reste).
Est-ce que cela peut resoudre le problème que j'ai actuellement, ie :
- j'ai dans le kernel des ressources localisée qui donne une dll,
kernel.resource.dll
en fr-FR, et en neutral.
Pour y acceder, je procede comme suit :
Je crée un ressource manager qui accede à la dll de ressource.
res = new ResourceManager("Kernel.KernelMessages",
System.Reflection.Assembly.GetExecutingAssembly());
puis je fais res.GetString( txtRes ) pour retrouver le string chercher.
Le pb, c'est que si je compile les .resx dans le kernel, cela va donner une
dll qui s'appelle kernel.ressource.dll qui devra etre accedée par
"Kernel.KernelMessages". Mais si je le compile dans le GUI, l'acces devrait
etre "GUI.KernelMessages".
Est-ce que cela ressoudra mon problème (A priori oui, car la compilation se
faisant que dans le kernel, l'acces devrait etre unique ... hum ...
> Alors tente cette solution, c'est le plus propre, les plus facile à maintenir, le déploiement n'est plus vraiment un problème. Et exposer une classe dans un assembly demande juste le mot clé publique. De plus si ton "kernel" peut servir à d'autre chose, tu gagnes en fonctionnalités.
Enfin beauté de .NET tu peux développer dans le langage que tu veux... (par ex: C++ pour ton kernel, et C# pour le reste).
Est-ce que cela peut resoudre le problème que j'ai actuellement, ie : - j'ai dans le kernel des ressources localisée qui donne une dll, kernel.resource.dll en fr-FR, et en neutral. Pour y acceder, je procede comme suit : Je crée un ressource manager qui accede à la dll de ressource. res = new ResourceManager("Kernel.KernelMessages", System.Reflection.Assembly.GetExecutingAssembly()); puis je fais res.GetString( txtRes ) pour retrouver le string chercher.
Le pb, c'est que si je compile les .resx dans le kernel, cela va donner une dll qui s'appelle kernel.ressource.dll qui devra etre accedée par "Kernel.KernelMessages". Mais si je le compile dans le GUI, l'acces devrait etre "GUI.KernelMessages". Est-ce que cela ressoudra mon problème (A priori oui, car la compilation se faisant que dans le kernel, l'acces devrait etre unique ... hum ...
Ambassadeur Kosh
> Le soucis, c'est les repertoires et l'acces aux fichiers communs.
tu isoles le code commun dans un 3° projet.
et tu ajoutes dans chacun de tes projets non pas un lien vers un repertoire, mais une reference à un projet (il y'a un onglet pour ça avec .Net et COM) en l'occurence, le kernel.
comme ça, ça rend tes deux outils independants de l'emplacement physique des sources. et même des sources tout court.
> Le soucis, c'est les repertoires et l'acces aux fichiers communs.
tu isoles le code commun dans un 3° projet.
et tu ajoutes dans chacun de tes projets non pas un lien vers un repertoire,
mais une reference à un projet (il y'a un onglet pour ça avec .Net et COM)
en l'occurence, le kernel.
comme ça, ça rend tes deux outils independants de l'emplacement physique des
sources. et même des sources tout court.
> Le soucis, c'est les repertoires et l'acces aux fichiers communs.
tu isoles le code commun dans un 3° projet.
et tu ajoutes dans chacun de tes projets non pas un lien vers un repertoire, mais une reference à un projet (il y'a un onglet pour ça avec .Net et COM) en l'occurence, le kernel.
comme ça, ça rend tes deux outils independants de l'emplacement physique des sources. et même des sources tout court.
alexandre jenny
> tu isoles le code commun dans un 3° projet.
et tu ajoutes dans chacun de tes projets non pas un lien vers un
repertoire,
mais une reference à un projet (il y'a un onglet pour ça avec .Net et COM) en l'occurence, le kernel.
comme ça, ça rend tes deux outils independants de l'emplacement physique
des
sources. et même des sources tout court.
Done ! Et ca marche du tonnerre. C'est vraiment plus simple qu'avant lorsqu'on ecrivait des dll de classes. Note que je ne sais pas comment fait le compilateur, mais la reference dans le kernel à un assembly de ressource est aussi directement utilisée par les deux projets ... (et meme copier en local avec les ressources localisées). Faut vraiment que j'inspecte un jour comme ca marche.
++ Merci à tous
> tu isoles le code commun dans un 3° projet.
et tu ajoutes dans chacun de tes projets non pas un lien vers un
repertoire,
mais une reference à un projet (il y'a un onglet pour ça avec .Net et COM)
en l'occurence, le kernel.
comme ça, ça rend tes deux outils independants de l'emplacement physique
des
sources. et même des sources tout court.
Done ! Et ca marche du tonnerre. C'est vraiment plus simple qu'avant
lorsqu'on ecrivait des dll de classes.
Note que je ne sais pas comment fait le compilateur, mais la reference dans
le kernel à un assembly de ressource est aussi directement utilisée par les
deux projets ... (et meme copier en local avec les ressources localisées).
Faut vraiment que j'inspecte un jour comme ca marche.
et tu ajoutes dans chacun de tes projets non pas un lien vers un
repertoire,
mais une reference à un projet (il y'a un onglet pour ça avec .Net et COM) en l'occurence, le kernel.
comme ça, ça rend tes deux outils independants de l'emplacement physique
des
sources. et même des sources tout court.
Done ! Et ca marche du tonnerre. C'est vraiment plus simple qu'avant lorsqu'on ecrivait des dll de classes. Note que je ne sais pas comment fait le compilateur, mais la reference dans le kernel à un assembly de ressource est aussi directement utilisée par les deux projets ... (et meme copier en local avec les ressources localisées). Faut vraiment que j'inspecte un jour comme ca marche.
++ Merci à tous
Ambassadeur Kosh
> Done ! Et ca marche du tonnerre. C'est vraiment plus simple qu'avant lorsqu'on écrivait des dll de classes.
c'est clair.
Note que je ne sais pas comment fait le compilateur, mais la reference
dans
le kernel à un assembly de ressource est aussi directement utilisée par
les
deux projets ... (et meme copier en local avec les ressources localisées). Faut vraiment que j'inspecte un jour comme ca marche.
je t'aurais suggeré d'enlever l'espace de nom par défaut dans les propriétés du projet, pour resoudre le probleme du "nomns.nomres", mais apparement, ça n'est pas utile.
> Done ! Et ca marche du tonnerre. C'est vraiment plus simple qu'avant
lorsqu'on écrivait des dll de classes.
c'est clair.
Note que je ne sais pas comment fait le compilateur, mais la reference
dans
le kernel à un assembly de ressource est aussi directement utilisée par
les
deux projets ... (et meme copier en local avec les ressources localisées).
Faut vraiment que j'inspecte un jour comme ca marche.
je t'aurais suggeré d'enlever l'espace de nom par défaut dans les propriétés
du projet, pour resoudre le probleme du "nomns.nomres", mais apparement, ça
n'est pas utile.
> Done ! Et ca marche du tonnerre. C'est vraiment plus simple qu'avant lorsqu'on écrivait des dll de classes.
c'est clair.
Note que je ne sais pas comment fait le compilateur, mais la reference
dans
le kernel à un assembly de ressource est aussi directement utilisée par
les
deux projets ... (et meme copier en local avec les ressources localisées). Faut vraiment que j'inspecte un jour comme ca marche.
je t'aurais suggeré d'enlever l'espace de nom par défaut dans les propriétés du projet, pour resoudre le probleme du "nomns.nomres", mais apparement, ça n'est pas utile.
Quentin Pouplard
alexandre jenny wrote:
> Alors tente cette solution, c'est le plus propre, les plus facile à > maintenir, le déploiement n'est plus vraiment un problème. Et > exposer une classe dans un assembly demande juste le mot clé > publique. De plus si ton "kernel" peut servir à d'autre chose, tu > gagnes en fonctionnalités. > > Enfin beauté de .NET tu peux développer dans le langage que tu > veux... > (par ex: C++ pour ton kernel, et C# pour le reste).
Est-ce que cela peut resoudre le problème que j'ai actuellement, ie : - j'ai dans le kernel des ressources localisée qui donne une dll, kernel.resource.dll en fr-FR, et en neutral. Pour y acceder, je procede comme suit : Je crée un ressource manager qui accede à la dll de ressource. res = new ResourceManager("Kernel.KernelMessages", System.Reflection.Assembly.GetExecutingAssembly()); puis je fais res.GetString( txtRes ) pour retrouver le string chercher.
Tu taperas ton kernel dans son namespace à lui (les namespace ne sont pas si lier aux assembly que cela en fait, mais soit). Il faudra évidemment que tu lui donnes le bon assembly, mais à priori, il n'y a pas de raison pour que le code utilisant l'assembly kernel doivent accéder au resource de l'assembly kernel.
Je ne comprends bien pourquoi tu me parle de Kernel.KernelMessages et de GUI.KernelMessages en fait... ce sont deux jeux de messages différent? ou c'est parce que tu compiles le même fichier dans deux assembly ayant un namespace par défaut?
ps: Concernant les resources, y'a en dehors de MSDN quelques articles pas trop mal fait sur codeproject.com.
> Alors tente cette solution, c'est le plus propre, les plus facile à
> maintenir, le déploiement n'est plus vraiment un problème. Et
> exposer une classe dans un assembly demande juste le mot clé
> publique. De plus si ton "kernel" peut servir à d'autre chose, tu
> gagnes en fonctionnalités.
>
> Enfin beauté de .NET tu peux développer dans le langage que tu
> veux...
> (par ex: C++ pour ton kernel, et C# pour le reste).
Est-ce que cela peut resoudre le problème que j'ai actuellement, ie :
- j'ai dans le kernel des ressources localisée qui donne une dll,
kernel.resource.dll en fr-FR, et en neutral.
Pour y acceder, je procede comme suit :
Je crée un ressource manager qui accede à la dll de ressource.
res = new ResourceManager("Kernel.KernelMessages",
System.Reflection.Assembly.GetExecutingAssembly());
puis je fais res.GetString( txtRes ) pour retrouver le string
chercher.
Tu taperas ton kernel dans son namespace à lui (les namespace ne sont
pas si lier aux assembly que cela en fait, mais soit). Il faudra
évidemment que tu lui donnes le bon assembly, mais à priori, il n'y a
pas de raison pour que le code utilisant l'assembly kernel doivent
accéder au resource de l'assembly kernel.
Je ne comprends bien pourquoi tu me parle de Kernel.KernelMessages et de
GUI.KernelMessages en fait... ce sont deux jeux de messages différent?
ou c'est parce que tu compiles le même fichier dans deux assembly ayant
un namespace par défaut?
ps: Concernant les resources, y'a en dehors de MSDN quelques articles
pas trop mal fait sur codeproject.com.
> Alors tente cette solution, c'est le plus propre, les plus facile à > maintenir, le déploiement n'est plus vraiment un problème. Et > exposer une classe dans un assembly demande juste le mot clé > publique. De plus si ton "kernel" peut servir à d'autre chose, tu > gagnes en fonctionnalités. > > Enfin beauté de .NET tu peux développer dans le langage que tu > veux... > (par ex: C++ pour ton kernel, et C# pour le reste).
Est-ce que cela peut resoudre le problème que j'ai actuellement, ie : - j'ai dans le kernel des ressources localisée qui donne une dll, kernel.resource.dll en fr-FR, et en neutral. Pour y acceder, je procede comme suit : Je crée un ressource manager qui accede à la dll de ressource. res = new ResourceManager("Kernel.KernelMessages", System.Reflection.Assembly.GetExecutingAssembly()); puis je fais res.GetString( txtRes ) pour retrouver le string chercher.
Tu taperas ton kernel dans son namespace à lui (les namespace ne sont pas si lier aux assembly que cela en fait, mais soit). Il faudra évidemment que tu lui donnes le bon assembly, mais à priori, il n'y a pas de raison pour que le code utilisant l'assembly kernel doivent accéder au resource de l'assembly kernel.
Je ne comprends bien pourquoi tu me parle de Kernel.KernelMessages et de GUI.KernelMessages en fait... ce sont deux jeux de messages différent? ou c'est parce que tu compiles le même fichier dans deux assembly ayant un namespace par défaut?
ps: Concernant les resources, y'a en dehors de MSDN quelques articles pas trop mal fait sur codeproject.com.
