Pourquoi ne pas utiliser la version de l'assembly, et son numéro de build en particulier ? -- Paul Bacelar
"hell" wrote in message news:
Bonjour,
Savez-vous comment faire pour savoir dans le code si la date de modification d'une assembly referencée est plus ancienne qu'une autre
date.
Existe-t-il un truc dans le genre Assembly.GetModificationDate()?
Merci a+
hell
"Paul Bacelar" a écrit dans le message de news:%
Pourquoi ne pas utiliser la version de l'assembly, et son numéro de build
en
particulier ? --
J'avais pensé au numero de version mais ca veux dire que tous les gens qui update cette assembly doivent mettre a jour le num de version et je n'ai acune garantie la-dessus.
D'autre part le principe est que mon assembly cree un fichier particulier, je ne veux pas qu'elle le cree a chaque appel (pb perf) mais uniquement qu'elle le mette a jour quand on a modifié le code de l'assembly. Donc je voulais dire qqch dans le genre : SI date_assembly > date_modification_fichier ALORS creer_fichier SINON rien.
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le message
de news:%23yu2GpGxFHA.2076@TK2MSFTNGP14.phx.gbl...
Pourquoi ne pas utiliser la version de l'assembly, et son numéro de build
en
particulier ?
--
J'avais pensé au numero de version mais ca veux dire que tous les gens qui
update cette assembly doivent mettre a jour le num de version et je n'ai
acune garantie la-dessus.
D'autre part le principe est que mon assembly cree un fichier particulier,
je ne veux pas qu'elle le cree a chaque appel (pb perf) mais uniquement
qu'elle le mette a jour quand on a modifié le code de l'assembly. Donc je
voulais dire qqch dans le genre : SI date_assembly >
date_modification_fichier ALORS creer_fichier SINON rien.
Pourquoi ne pas utiliser la version de l'assembly, et son numéro de build
en
particulier ? --
J'avais pensé au numero de version mais ca veux dire que tous les gens qui update cette assembly doivent mettre a jour le num de version et je n'ai acune garantie la-dessus.
D'autre part le principe est que mon assembly cree un fichier particulier, je ne veux pas qu'elle le cree a chaque appel (pb perf) mais uniquement qu'elle le mette a jour quand on a modifié le code de l'assembly. Donc je voulais dire qqch dans le genre : SI date_assembly > date_modification_fichier ALORS creer_fichier SINON rien.
Paul Bacelar
Pourquoi ne pas utiliser la classe FileSystemWatcher, si votre problème n'est pas lié à la modification du code mais à la mise à jour d'un fichier.
Si vous n'avez pas la garantie que les numéros de build soient correctement gérés, vous avez un très gros problème de méthodologie qui se répercutera sur la traçabilité de votre solution.
Un grand nombre d'outils de génération gèrent ceux-ci de manière transparente. -- Paul Bacelar
"hell" wrote in message news:
"Paul Bacelar" a écrit dans le message de news:% > Pourquoi ne pas utiliser la version de l'assembly, et son numéro de
build
en > particulier ? > -- J'avais pensé au numero de version mais ca veux dire que tous les gens qui update cette assembly doivent mettre a jour le num de version et je n'ai acune garantie la-dessus.
D'autre part le principe est que mon assembly cree un fichier particulier, je ne veux pas qu'elle le cree a chaque appel (pb perf) mais uniquement qu'elle le mette a jour quand on a modifié le code de l'assembly. Donc je voulais dire qqch dans le genre : SI date_assembly > date_modification_fichier ALORS creer_fichier SINON rien.
Pourquoi ne pas utiliser la classe FileSystemWatcher, si votre problème
n'est pas lié à la modification du code mais à la mise à jour d'un fichier.
Si vous n'avez pas la garantie que les numéros de build soient correctement
gérés, vous avez un très gros problème de méthodologie qui se répercutera
sur la traçabilité de votre solution.
Un grand nombre d'outils de génération gèrent ceux-ci de manière
transparente.
--
Paul Bacelar
"hell" <hell.paradise_nospam@laposte.nospam.net> wrote in message
news:eiH6pENxFHA.3860@TK2MSFTNGP09.phx.gbl...
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le message
de news:%23yu2GpGxFHA.2076@TK2MSFTNGP14.phx.gbl...
> Pourquoi ne pas utiliser la version de l'assembly, et son numéro de
build
en
> particulier ?
> --
J'avais pensé au numero de version mais ca veux dire que tous les gens qui
update cette assembly doivent mettre a jour le num de version et je n'ai
acune garantie la-dessus.
D'autre part le principe est que mon assembly cree un fichier particulier,
je ne veux pas qu'elle le cree a chaque appel (pb perf) mais uniquement
qu'elle le mette a jour quand on a modifié le code de l'assembly. Donc je
voulais dire qqch dans le genre : SI date_assembly >
date_modification_fichier ALORS creer_fichier SINON rien.
Pourquoi ne pas utiliser la classe FileSystemWatcher, si votre problème n'est pas lié à la modification du code mais à la mise à jour d'un fichier.
Si vous n'avez pas la garantie que les numéros de build soient correctement gérés, vous avez un très gros problème de méthodologie qui se répercutera sur la traçabilité de votre solution.
Un grand nombre d'outils de génération gèrent ceux-ci de manière transparente. -- Paul Bacelar
"hell" wrote in message news:
"Paul Bacelar" a écrit dans le message de news:% > Pourquoi ne pas utiliser la version de l'assembly, et son numéro de
build
en > particulier ? > -- J'avais pensé au numero de version mais ca veux dire que tous les gens qui update cette assembly doivent mettre a jour le num de version et je n'ai acune garantie la-dessus.
D'autre part le principe est que mon assembly cree un fichier particulier, je ne veux pas qu'elle le cree a chaque appel (pb perf) mais uniquement qu'elle le mette a jour quand on a modifié le code de l'assembly. Donc je voulais dire qqch dans le genre : SI date_assembly > date_modification_fichier ALORS creer_fichier SINON rien.
hell
"Paul Bacelar" a écrit dans le message de news:dhmccc$aef$
Pourquoi ne pas utiliser la classe FileSystemWatcher, si votre problème n'est pas lié à la modification du code mais à la mise à jour d'un
fichier.
Bel outil, je ne connaissais pas du tout cette classe. Mais justement dans mon cas c'est la le code de la dll qui change.
Si vous n'avez pas la garantie que les numéros de build soient
correctement
gérés, vous avez un très gros problème de méthodologie qui se répercutera sur la traçabilité de votre solution.
Entièrement d'accord, je n'ai hélas pas le pouvoir de changer les choses.
Je vais me debrouiller autrement, Merci a+
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le message
de news:dhmccc$aef$1@apollon.grec.isp.9tel.net...
Pourquoi ne pas utiliser la classe FileSystemWatcher, si votre problème
n'est pas lié à la modification du code mais à la mise à jour d'un
fichier.
Bel outil, je ne connaissais pas du tout cette classe.
Mais justement dans mon cas c'est la le code de la dll qui change.
Si vous n'avez pas la garantie que les numéros de build soient
correctement
gérés, vous avez un très gros problème de méthodologie qui se répercutera
sur la traçabilité de votre solution.
Entièrement d'accord, je n'ai hélas pas le pouvoir de changer les choses.
"Paul Bacelar" a écrit dans le message de news:dhmccc$aef$
Pourquoi ne pas utiliser la classe FileSystemWatcher, si votre problème n'est pas lié à la modification du code mais à la mise à jour d'un
fichier.
Bel outil, je ne connaissais pas du tout cette classe. Mais justement dans mon cas c'est la le code de la dll qui change.
Si vous n'avez pas la garantie que les numéros de build soient
correctement
gérés, vous avez un très gros problème de méthodologie qui se répercutera sur la traçabilité de votre solution.
Entièrement d'accord, je n'ai hélas pas le pouvoir de changer les choses.
Je vais me debrouiller autrement, Merci a+
Paul Bacelar
"hell" wrote in message news:eeRjf9$
"Paul Bacelar" a écrit dans le message de news:dhmccc$aef$ > Pourquoi ne pas utiliser la classe FileSystemWatcher, si votre problème > n'est pas lié à la modification du code mais à la mise à jour d'un fichier. > Bel outil, je ne connaissais pas du tout cette classe. Mais justement dans mon cas c'est la le code de la dll qui change.
S'il y a recompilation, le FileSystemWatcher sera prévenu.
> Si vous n'avez pas la garantie que les numéros de build soient correctement > gérés, vous avez un très gros problème de méthodologie qui se
répercutera
> sur la traçabilité de votre solution. > Entièrement d'accord, je n'ai hélas pas le pouvoir de changer les choses.
Je vais me debrouiller autrement, Merci a+
-- Paul Bacelar
"hell" <hell.paradise_nospam@laposte.nospam.net> wrote in message
news:eeRjf9$xFHA.2848@TK2MSFTNGP15.phx.gbl...
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le message
de news:dhmccc$aef$1@apollon.grec.isp.9tel.net...
> Pourquoi ne pas utiliser la classe FileSystemWatcher, si votre problème
> n'est pas lié à la modification du code mais à la mise à jour d'un
fichier.
>
Bel outil, je ne connaissais pas du tout cette classe.
Mais justement dans mon cas c'est la le code de la dll qui change.
S'il y a recompilation, le FileSystemWatcher sera prévenu.
> Si vous n'avez pas la garantie que les numéros de build soient
correctement
> gérés, vous avez un très gros problème de méthodologie qui se
répercutera
> sur la traçabilité de votre solution.
>
Entièrement d'accord, je n'ai hélas pas le pouvoir de changer les choses.
"Paul Bacelar" a écrit dans le message de news:dhmccc$aef$ > Pourquoi ne pas utiliser la classe FileSystemWatcher, si votre problème > n'est pas lié à la modification du code mais à la mise à jour d'un fichier. > Bel outil, je ne connaissais pas du tout cette classe. Mais justement dans mon cas c'est la le code de la dll qui change.
S'il y a recompilation, le FileSystemWatcher sera prévenu.
> Si vous n'avez pas la garantie que les numéros de build soient correctement > gérés, vous avez un très gros problème de méthodologie qui se
répercutera
> sur la traçabilité de votre solution. > Entièrement d'accord, je n'ai hélas pas le pouvoir de changer les choses.
