J'ai une classe singleton definie dans un fichier.
Ce fichier est lie a plusieurs assembly. Lors de la compilation d'une
solution contenant ces assembly, le compilateur emet le warning:
Compiler Warning (level 1) CS1595 et affiche plusieurs messages tels
que celui-ci:
C:\xxx\AAA.cs: 'AAA' is defined in multiple places; using definition
from 'C:\yyy\AAA.cs'
Pourquoi affiche-t-il ce warning sachant que le repertoire AAA est
toujours le meme dans tous les messages du warning et que par
consequent le fichier est bien le meme de partout ?
Est-il possible de resoudre ce probleme sans avoir a creer une assembly
specifique a cette classe svp ?
Merci.
--
Michael
----
http://michael.moreno.free.fr/
http://port.cogolin.free.fr/
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
Merlin
si tu as compilé plusieurs assemblies qui intègre la classe en question, on peut supposer qu'il la retrouve donc définie dans chacun et qu'il ne sait plus laquelle prendre ?
si tu as compilé plusieurs assemblies qui intègre la classe en
question, on peut supposer qu'il la retrouve donc définie dans chacun
et qu'il ne sait plus laquelle prendre ?
si tu as compilé plusieurs assemblies qui intègre la classe en question, on peut supposer qu'il la retrouve donc définie dans chacun et qu'il ne sait plus laquelle prendre ?
> si tu as compilé plusieurs assemblies qui intègre la classe en question, on peut supposer qu'il la retrouve donc définie dans chacun et qu'il ne sait plus laquelle prendre ?
oui c'est bien ce qu'il se passe meme si pourtant le fichier et la classe sont bien uniques.
Chaque assembly se compile independamment sans probleme. C'est au niveau de la solution que y a ce probleme.
Merci.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
> si tu as compilé plusieurs assemblies qui intègre la classe en question, on
peut supposer qu'il la retrouve donc définie dans chacun et qu'il ne sait
plus laquelle prendre ?
oui c'est bien ce qu'il se passe meme si pourtant le fichier et la
classe sont bien uniques.
Chaque assembly se compile independamment sans probleme. C'est au
niveau de la solution que y a ce probleme.
Merci.
--
Michael
----
http://michael.moreno.free.fr/
http://port.cogolin.free.fr/
> si tu as compilé plusieurs assemblies qui intègre la classe en question, on peut supposer qu'il la retrouve donc définie dans chacun et qu'il ne sait plus laquelle prendre ?
oui c'est bien ce qu'il se passe meme si pourtant le fichier et la classe sont bien uniques.
Chaque assembly se compile independamment sans probleme. C'est au niveau de la solution que y a ce probleme.
Merci.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
Michael Moreno
Merlin,
J'ai un soucis avec COM et l'hyper-threading sous D7 (plus d'info sur borland.public.language.delphi.general) T'es au courant d'un bug de ce genre stp ?
Merci.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
Merlin,
J'ai un soucis avec COM et l'hyper-threading sous D7 (plus d'info sur
borland.public.language.delphi.general) T'es au courant d'un bug de ce
genre stp ?
Merci.
--
Michael
----
http://michael.moreno.free.fr/
http://port.cogolin.free.fr/
J'ai un soucis avec COM et l'hyper-threading sous D7 (plus d'info sur borland.public.language.delphi.general) T'es au courant d'un bug de ce genre stp ?
Merci.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
Merlin
Michael Moreno a écrit :
J'ai un soucis avec COM et l'hyper-threading sous D7 (plus d'info sur borland.public.language.delphi.general) T'es au courant d'un bug de ce genre stp ?
De tête non, ça ne me dit rien. Mais je pense que tu as cherché sur google aussi. On va voir s'il y a des réponses sur le forum borland..
J'ai un soucis avec COM et l'hyper-threading sous D7 (plus d'info sur
borland.public.language.delphi.general) T'es au courant d'un bug de ce genre
stp ?
De tête non, ça ne me dit rien. Mais je pense que tu as cherché sur
google aussi. On va voir s'il y a des réponses sur le forum borland..
J'ai un soucis avec COM et l'hyper-threading sous D7 (plus d'info sur borland.public.language.delphi.general) T'es au courant d'un bug de ce genre stp ?
De tête non, ça ne me dit rien. Mais je pense que tu as cherché sur google aussi. On va voir s'il y a des réponses sur le forum borland..
oui c'est bien ce qu'il se passe meme si pourtant le fichier et la classe sont bien uniques. Chaque assembly se compile independamment sans probleme. C'est au niveau de la solution que y a ce probleme.
Chaque assemby se compile, ça me semble normal. Mais la solution elle, elle se retrouve avec plusieurs assemblies qui contiennent déjà la classe en question. Et c'est là que le pb apparait, quelle version choisir. En mettant la classe dans un assemblage à part, ça devrait résoudre le pb, t'as essayé ?
oui c'est bien ce qu'il se passe meme si pourtant le fichier et la classe
sont bien uniques.
Chaque assembly se compile independamment sans probleme. C'est au niveau de
la solution que y a ce probleme.
Chaque assemby se compile, ça me semble normal. Mais la solution elle,
elle se retrouve avec plusieurs assemblies qui contiennent déjà la
classe en question. Et c'est là que le pb apparait, quelle version
choisir.
En mettant la classe dans un assemblage à part, ça devrait résoudre le
pb, t'as essayé ?
oui c'est bien ce qu'il se passe meme si pourtant le fichier et la classe sont bien uniques. Chaque assembly se compile independamment sans probleme. C'est au niveau de la solution que y a ce probleme.
Chaque assemby se compile, ça me semble normal. Mais la solution elle, elle se retrouve avec plusieurs assemblies qui contiennent déjà la classe en question. Et c'est là que le pb apparait, quelle version choisir. En mettant la classe dans un assemblage à part, ça devrait résoudre le pb, t'as essayé ?
> En mettant la classe dans un assemblage à part, ça devrait résoudre le pb, t'as essayé ?
oui c'est ce que j'ai fait au final mais cela ne me satisfait pas vraiment comme solution. Cela me force a avoir une dll de plus a gerer et des dlls j'en ai deja assez comme ca.
Merci bien.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
> En mettant la classe dans un assemblage à part, ça devrait résoudre le pb,
t'as essayé ?
oui c'est ce que j'ai fait au final mais cela ne me satisfait pas
vraiment comme solution. Cela me force a avoir une dll de plus a gerer
et des dlls j'en ai deja assez comme ca.
Merci bien.
--
Michael
----
http://michael.moreno.free.fr/
http://port.cogolin.free.fr/
> En mettant la classe dans un assemblage à part, ça devrait résoudre le pb, t'as essayé ?
oui c'est ce que j'ai fait au final mais cela ne me satisfait pas vraiment comme solution. Cela me force a avoir une dll de plus a gerer et des dlls j'en ai deja assez comme ca.
Merci bien.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
Simon Mourier
Il n'y a pas d'autre solution.
C'est normal d'avoir des warnings. Si la classe AAA évolue dans le fichier commun, et que tous les projets de sont pas recompilés avec cette dernière version, certaines assemblies peuvent se retrouver avec une version, et d'autres avec une autre, pour une même classe (même namespace, même nom). Hors ni la solution, ni visual studio ne peuvent gérer les dates des dernières compilations des projets les uns par rapport aux autres...
Un conseil: changer votre structure de classes ou d'assemblies. Vous courrez au devant de problèmes non seulement à la compilation mais aussi en terme de maintenance, et d'exécution.
Simon. www.softfluent.com
"Michael Moreno" a écrit dans le message de news:
En mettant la classe dans un assemblage à part, ça devrait résoudre le pb, t'as essayé ?
oui c'est ce que j'ai fait au final mais cela ne me satisfait pas vraiment comme solution. Cela me force a avoir une dll de plus a gerer et des dlls j'en ai deja assez comme ca.
Merci bien.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
Il n'y a pas d'autre solution.
C'est normal d'avoir des warnings. Si la classe AAA évolue dans le fichier
commun, et que tous les projets de sont pas recompilés avec cette dernière
version, certaines assemblies peuvent se retrouver avec une version, et
d'autres avec une autre, pour une même classe (même namespace, même nom).
Hors ni la solution, ni visual studio ne peuvent gérer les dates des
dernières compilations des projets les uns par rapport aux autres...
Un conseil: changer votre structure de classes ou d'assemblies. Vous courrez
au devant de problèmes non seulement à la compilation mais aussi en terme de
maintenance, et d'exécution.
Simon.
www.softfluent.com
"Michael Moreno" <michael.ToRemove.moreno@free.fr> a écrit dans le message
de news: mn.89f17d5858cc6eaf.21643@free.fr...
En mettant la classe dans un assemblage à part, ça devrait résoudre le
pb, t'as essayé ?
oui c'est ce que j'ai fait au final mais cela ne me satisfait pas vraiment
comme solution. Cela me force a avoir une dll de plus a gerer et des dlls
j'en ai deja assez comme ca.
Merci bien.
--
Michael
----
http://michael.moreno.free.fr/
http://port.cogolin.free.fr/
C'est normal d'avoir des warnings. Si la classe AAA évolue dans le fichier commun, et que tous les projets de sont pas recompilés avec cette dernière version, certaines assemblies peuvent se retrouver avec une version, et d'autres avec une autre, pour une même classe (même namespace, même nom). Hors ni la solution, ni visual studio ne peuvent gérer les dates des dernières compilations des projets les uns par rapport aux autres...
Un conseil: changer votre structure de classes ou d'assemblies. Vous courrez au devant de problèmes non seulement à la compilation mais aussi en terme de maintenance, et d'exécution.
Simon. www.softfluent.com
"Michael Moreno" a écrit dans le message de news:
En mettant la classe dans un assemblage à part, ça devrait résoudre le pb, t'as essayé ?
oui c'est ce que j'ai fait au final mais cela ne me satisfait pas vraiment comme solution. Cela me force a avoir une dll de plus a gerer et des dlls j'en ai deja assez comme ca.
Merci bien.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
Michael Moreno
> Il n'y a pas d'autre solution.
C'est normal d'avoir des warnings. Si la classe AAA évolue dans le fichier commun, et que tous les projets de sont pas recompilés avec cette dernière version, certaines assemblies peuvent se retrouver avec une version, et d'autres avec une autre, pour une même classe (même namespace, même nom). Hors ni la solution, ni visual studio ne peuvent gérer les dates des dernières compilations des projets les uns par rapport aux autres...
Un conseil: changer votre structure de classes ou d'assemblies. Vous courrez au devant de problèmes non seulement à la compilation mais aussi en terme de maintenance, et d'exécution.
oui c'est deja fait. Merci.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
> Il n'y a pas d'autre solution.
C'est normal d'avoir des warnings. Si la classe AAA évolue dans le fichier
commun, et que tous les projets de sont pas recompilés avec cette dernière
version, certaines assemblies peuvent se retrouver avec une version, et
d'autres avec une autre, pour une même classe (même namespace, même nom).
Hors ni la solution, ni visual studio ne peuvent gérer les dates des
dernières compilations des projets les uns par rapport aux autres...
Un conseil: changer votre structure de classes ou d'assemblies. Vous courrez
au devant de problèmes non seulement à la compilation mais aussi en terme de
maintenance, et d'exécution.
oui c'est deja fait. Merci.
--
Michael
----
http://michael.moreno.free.fr/
http://port.cogolin.free.fr/
C'est normal d'avoir des warnings. Si la classe AAA évolue dans le fichier commun, et que tous les projets de sont pas recompilés avec cette dernière version, certaines assemblies peuvent se retrouver avec une version, et d'autres avec une autre, pour une même classe (même namespace, même nom). Hors ni la solution, ni visual studio ne peuvent gérer les dates des dernières compilations des projets les uns par rapport aux autres...
Un conseil: changer votre structure de classes ou d'assemblies. Vous courrez au devant de problèmes non seulement à la compilation mais aussi en terme de maintenance, et d'exécution.
oui c'est deja fait. Merci.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
Merlin
Michael Moreno a écrit :
oui c'est ce que j'ai fait au final mais cela ne me satisfait pas vraiment comme solution. Cela me force a avoir une dll de plus a gerer et des dlls j'en ai deja assez comme ca.
oui mais ça me semble logique... ça serait le même problème avec des packages delphi qui intègrerait chacun la même Unit.
oui c'est ce que j'ai fait au final mais cela ne me satisfait pas vraiment
comme solution. Cela me force a avoir une dll de plus a gerer et des dlls
j'en ai deja assez comme ca.
oui mais ça me semble logique... ça serait le même problème avec des
packages delphi qui intègrerait chacun la même Unit.
oui c'est ce que j'ai fait au final mais cela ne me satisfait pas vraiment comme solution. Cela me force a avoir une dll de plus a gerer et des dlls j'en ai deja assez comme ca.
oui mais ça me semble logique... ça serait le même problème avec des packages delphi qui intègrerait chacun la même Unit.
