Bonjour,
Sur mes applications C++n j'utilise les macros _DATE_ et _TIME_ pour
marquer les executables en fonction du moment ou ils ont été buildé.
Existe il un équivalent en C# ?, peut on récupérér au runtime la
date/heure de build de l'executable ?
Cordialement,
David Alloza.
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
Paul Bacelar
Quelle est votre problématique.
Votre modus operandi n'a pas de sens en .NET car la construction du code machine se fait en au moins en 2 étapes, compilation lors de la création des assemblies, compilation JIT au moment de l'exécution. -- Paul Bacelar
"David Alloza" wrote in message news:41dbb511$0$3521$
Bonjour, Sur mes applications C++n j'utilise les macros _DATE_ et _TIME_ pour marquer les executables en fonction du moment ou ils ont été buildé. Existe il un équivalent en C# ?, peut on récupérér au runtime la date/heure de build de l'executable ? Cordialement, David Alloza.
Quelle est votre problématique.
Votre modus operandi n'a pas de sens en .NET car la construction du code
machine se fait en au moins en 2 étapes, compilation lors de la création des
assemblies, compilation JIT au moment de l'exécution.
--
Paul Bacelar
"David Alloza" <david.allozaVRAIMENT_PAS_DE_SPAM@wanadoo.fr> wrote in
message news:41dbb511$0$3521$8fcfb975@news.wanadoo.fr...
Bonjour,
Sur mes applications C++n j'utilise les macros _DATE_ et _TIME_ pour
marquer les executables en fonction du moment ou ils ont été buildé.
Existe il un équivalent en C# ?, peut on récupérér au runtime la
date/heure de build de l'executable ?
Cordialement,
David Alloza.
Votre modus operandi n'a pas de sens en .NET car la construction du code machine se fait en au moins en 2 étapes, compilation lors de la création des assemblies, compilation JIT au moment de l'exécution. -- Paul Bacelar
"David Alloza" wrote in message news:41dbb511$0$3521$
Bonjour, Sur mes applications C++n j'utilise les macros _DATE_ et _TIME_ pour marquer les executables en fonction du moment ou ils ont été buildé. Existe il un équivalent en C# ?, peut on récupérér au runtime la date/heure de build de l'executable ? Cordialement, David Alloza.
David Alloza
En gros.. Dans le secteur ou je travaille, et chez mon employeur actuel en particulier il existe une coutume qui veut, que pour chaque nouvelle version d'un executable que l'on fournis aux personnes travaillant sur la chaine de prod des ressources ( audio, 3d, physique..), l'on puisse avoir, sur le titre de la fenetre, ou dans un menu facilement accessible, la date et l'heure de build de la version actuellement utilisée. Ainsi, le graphiste, le game designer etc... etc.. peut indiquer, en cas de bug, la date et heure de build de la version qu'il utilise et lever ainsi tout doute sur une eventuelle version non a jour. Sour les projects C++, nous utilisions les macros du preprocesseur _DATE_ et _TIME_, pour marquer l'executable de la date/heure de build, je n'ai pas trouvé l'équivalent en C#. Cordialement, David Alloza.
Paul Bacelar wrote:
Quelle est votre problématique.
Votre modus operandi n'a pas de sens en .NET car la construction du code machine se fait en au moins en 2 étapes, compilation lors de la création des assemblies, compilation JIT au moment de l'exécution.
En gros..
Dans le secteur ou je travaille, et chez mon employeur actuel en
particulier il existe une coutume qui veut, que pour chaque nouvelle
version d'un executable que l'on fournis aux personnes travaillant sur
la chaine de prod des ressources ( audio, 3d, physique..), l'on puisse
avoir, sur le titre de la fenetre, ou dans un menu facilement
accessible, la date et l'heure de build de la version actuellement utilisée.
Ainsi, le graphiste, le game designer etc... etc.. peut indiquer, en cas
de bug, la date et heure de build de la version qu'il utilise et lever
ainsi tout doute sur une eventuelle version non a jour.
Sour les projects C++, nous utilisions les macros du preprocesseur
_DATE_ et _TIME_, pour marquer l'executable de la date/heure de build,
je n'ai pas trouvé l'équivalent en C#.
Cordialement,
David Alloza.
Paul Bacelar wrote:
Quelle est votre problématique.
Votre modus operandi n'a pas de sens en .NET car la construction du code
machine se fait en au moins en 2 étapes, compilation lors de la création des
assemblies, compilation JIT au moment de l'exécution.
En gros.. Dans le secteur ou je travaille, et chez mon employeur actuel en particulier il existe une coutume qui veut, que pour chaque nouvelle version d'un executable que l'on fournis aux personnes travaillant sur la chaine de prod des ressources ( audio, 3d, physique..), l'on puisse avoir, sur le titre de la fenetre, ou dans un menu facilement accessible, la date et l'heure de build de la version actuellement utilisée. Ainsi, le graphiste, le game designer etc... etc.. peut indiquer, en cas de bug, la date et heure de build de la version qu'il utilise et lever ainsi tout doute sur une eventuelle version non a jour. Sour les projects C++, nous utilisions les macros du preprocesseur _DATE_ et _TIME_, pour marquer l'executable de la date/heure de build, je n'ai pas trouvé l'équivalent en C#. Cordialement, David Alloza.
Paul Bacelar wrote:
Quelle est votre problématique.
Votre modus operandi n'a pas de sens en .NET car la construction du code machine se fait en au moins en 2 étapes, compilation lors de la création des assemblies, compilation JIT au moment de l'exécution.
Paul Bacelar
Un Assembly .NET généré avec VS.NET a un numéro de build différent à chaque compilation pour l'unicité, pour une machine de build donné. Cela permet de faire le tracking avec un outil de gestion de conf, type SourceSafe. Rien ne vous empêche de faire un petit utilitaire lisant le fichier AssemblyInfo.xx et modifiant l'attribut AssemblyDescription de l'assembly pour permettre à l'utilisateur final de regarder la valeur dans le champ Comment des propriétés de l'assembly dans les propriétés affichées par l'explorer. Avec VS, il suffit de mettre cette utilitaire comme command de pré-build et aussi en commande de post-build avec d'autres paramètres pour l'intégrer dans votre chaîne de compilations standard. L'utilitaire na qu'a chercher une chaîne très simple: [assembly: AssemblyDescription("")]
C'est le plus rapide. Si cette approche vous semble légère, utilisé en plus FxCop avec une règle supplémentaire qui vérifiera le format des AssemblyDescription de chaque assembly créé. Vous serez ainsi prévenu d'une anomalie si votre utilitaire déraille, ou qu'un programmeur facétieux change l'AssemblyInfo de manière à invalider l'exécution de votre pre-processeur maison.
A la rigueur, le pré-processeur de VC++ peu servir d'utilitaire avec les bonnes lignes de commandes et les bonnes redirections des fichiers (à vos fichiers bat :-) ) -- Paul Bacelar
"David Alloza" wrote in message news:41dd0fed$0$29764$
En gros.. Dans le secteur ou je travaille, et chez mon employeur actuel en particulier il existe une coutume qui veut, que pour chaque nouvelle version d'un executable que l'on fournis aux personnes travaillant sur la chaine de prod des ressources ( audio, 3d, physique..), l'on puisse avoir, sur le titre de la fenetre, ou dans un menu facilement accessible, la date et l'heure de build de la version actuellement
utilisée.
Ainsi, le graphiste, le game designer etc... etc.. peut indiquer, en cas de bug, la date et heure de build de la version qu'il utilise et lever ainsi tout doute sur une eventuelle version non a jour. Sour les projects C++, nous utilisions les macros du preprocesseur _DATE_ et _TIME_, pour marquer l'executable de la date/heure de build, je n'ai pas trouvé l'équivalent en C#. Cordialement, David Alloza.
Paul Bacelar wrote: > Quelle est votre problématique. > > Votre modus operandi n'a pas de sens en .NET car la construction du code > machine se fait en au moins en 2 étapes, compilation lors de la création
des
> assemblies, compilation JIT au moment de l'exécution.
Un Assembly .NET généré avec VS.NET a un numéro de build différent à chaque
compilation pour l'unicité, pour une machine de build donné.
Cela permet de faire le tracking avec un outil de gestion de conf, type
SourceSafe.
Rien ne vous empêche de faire un petit utilitaire lisant le fichier
AssemblyInfo.xx et modifiant l'attribut AssemblyDescription de l'assembly
pour permettre à l'utilisateur final de regarder la valeur dans le champ
Comment des propriétés de l'assembly dans les propriétés affichées par
l'explorer.
Avec VS, il suffit de mettre cette utilitaire comme command de pré-build et
aussi en commande de post-build avec d'autres paramètres pour l'intégrer
dans votre chaîne de compilations standard.
L'utilitaire na qu'a chercher une chaîne très simple: [assembly:
AssemblyDescription("")]
C'est le plus rapide.
Si cette approche vous semble légère, utilisé en plus FxCop avec une règle
supplémentaire qui vérifiera le format des AssemblyDescription de chaque
assembly créé. Vous serez ainsi prévenu d'une anomalie si votre utilitaire
déraille, ou qu'un programmeur facétieux change l'AssemblyInfo de manière à
invalider l'exécution de votre pre-processeur maison.
A la rigueur, le pré-processeur de VC++ peu servir d'utilitaire avec les
bonnes lignes de commandes et les bonnes redirections des fichiers (à vos
fichiers bat :-) )
--
Paul Bacelar
"David Alloza" <david.allozaVRAIMENT_PAS_DE_SPAM@wanadoo.fr> wrote in
message news:41dd0fed$0$29764$8fcfb975@news.wanadoo.fr...
En gros..
Dans le secteur ou je travaille, et chez mon employeur actuel en
particulier il existe une coutume qui veut, que pour chaque nouvelle
version d'un executable que l'on fournis aux personnes travaillant sur
la chaine de prod des ressources ( audio, 3d, physique..), l'on puisse
avoir, sur le titre de la fenetre, ou dans un menu facilement
accessible, la date et l'heure de build de la version actuellement
utilisée.
Ainsi, le graphiste, le game designer etc... etc.. peut indiquer, en cas
de bug, la date et heure de build de la version qu'il utilise et lever
ainsi tout doute sur une eventuelle version non a jour.
Sour les projects C++, nous utilisions les macros du preprocesseur
_DATE_ et _TIME_, pour marquer l'executable de la date/heure de build,
je n'ai pas trouvé l'équivalent en C#.
Cordialement,
David Alloza.
Paul Bacelar wrote:
> Quelle est votre problématique.
>
> Votre modus operandi n'a pas de sens en .NET car la construction du code
> machine se fait en au moins en 2 étapes, compilation lors de la création
des
> assemblies, compilation JIT au moment de l'exécution.
Un Assembly .NET généré avec VS.NET a un numéro de build différent à chaque compilation pour l'unicité, pour une machine de build donné. Cela permet de faire le tracking avec un outil de gestion de conf, type SourceSafe. Rien ne vous empêche de faire un petit utilitaire lisant le fichier AssemblyInfo.xx et modifiant l'attribut AssemblyDescription de l'assembly pour permettre à l'utilisateur final de regarder la valeur dans le champ Comment des propriétés de l'assembly dans les propriétés affichées par l'explorer. Avec VS, il suffit de mettre cette utilitaire comme command de pré-build et aussi en commande de post-build avec d'autres paramètres pour l'intégrer dans votre chaîne de compilations standard. L'utilitaire na qu'a chercher une chaîne très simple: [assembly: AssemblyDescription("")]
C'est le plus rapide. Si cette approche vous semble légère, utilisé en plus FxCop avec une règle supplémentaire qui vérifiera le format des AssemblyDescription de chaque assembly créé. Vous serez ainsi prévenu d'une anomalie si votre utilitaire déraille, ou qu'un programmeur facétieux change l'AssemblyInfo de manière à invalider l'exécution de votre pre-processeur maison.
A la rigueur, le pré-processeur de VC++ peu servir d'utilitaire avec les bonnes lignes de commandes et les bonnes redirections des fichiers (à vos fichiers bat :-) ) -- Paul Bacelar
"David Alloza" wrote in message news:41dd0fed$0$29764$
En gros.. Dans le secteur ou je travaille, et chez mon employeur actuel en particulier il existe une coutume qui veut, que pour chaque nouvelle version d'un executable que l'on fournis aux personnes travaillant sur la chaine de prod des ressources ( audio, 3d, physique..), l'on puisse avoir, sur le titre de la fenetre, ou dans un menu facilement accessible, la date et l'heure de build de la version actuellement
utilisée.
Ainsi, le graphiste, le game designer etc... etc.. peut indiquer, en cas de bug, la date et heure de build de la version qu'il utilise et lever ainsi tout doute sur une eventuelle version non a jour. Sour les projects C++, nous utilisions les macros du preprocesseur _DATE_ et _TIME_, pour marquer l'executable de la date/heure de build, je n'ai pas trouvé l'équivalent en C#. Cordialement, David Alloza.
Paul Bacelar wrote: > Quelle est votre problématique. > > Votre modus operandi n'a pas de sens en .NET car la construction du code > machine se fait en au moins en 2 étapes, compilation lors de la création
des
> assemblies, compilation JIT au moment de l'exécution.
David Alloza
Merci pour cette réponse. L'avantage d'un marquage de version avec heure et date intégré est une plus grande lisibilité pour l'utilisateur ( il peut me dire qu'il utilise la version du XX/XX/200X buildée à 10h42mn), un système de notation de version automatisé tel qu'il est disponible sous .NET, de ce point de vue, est moins "naturel". L'idée de placer en prébuild un marqueur n'est pas mal du tout. Je vais y réflechir. Cordialement, David Alloza.
Paul Bacelar wrote:
Un Assembly .NET généré avec VS.NET a un numéro de build différent à chaque compilation pour l'unicité, pour une machine de build donné. Cela permet de faire le tracking avec un outil de gestion de conf, type SourceSafe. Rien ne vous empêche de faire un petit utilitaire lisant le fichier AssemblyInfo.xx et modifiant l'attribut AssemblyDescription de l'assembly pour permettre à l'utilisateur final de regarder la valeur dans le champ Comment des propriétés de l'assembly dans les propriétés affichées par l'explorer. Avec VS, il suffit de mettre cette utilitaire comme command de pré-build et aussi en commande de post-build avec d'autres paramètres pour l'intégrer dans votre chaîne de compilations standard. L'utilitaire na qu'a chercher une chaîne très simple: [assembly: AssemblyDescription("")]
C'est le plus rapide. Si cette approche vous semble légère, utilisé en plus FxCop avec une règle supplémentaire qui vérifiera le format des AssemblyDescription de chaque assembly créé. Vous serez ainsi prévenu d'une anomalie si votre utilitaire déraille, ou qu'un programmeur facétieux change l'AssemblyInfo de manière à invalider l'exécution de votre pre-processeur maison.
A la rigueur, le pré-processeur de VC++ peu servir d'utilitaire avec les bonnes lignes de commandes et les bonnes redirections des fichiers (à vos fichiers bat :-) )
Merci pour cette réponse.
L'avantage d'un marquage de version avec heure et date intégré est une
plus grande lisibilité pour l'utilisateur ( il peut me dire qu'il
utilise la version du XX/XX/200X buildée à 10h42mn), un système de
notation de version automatisé tel qu'il est disponible sous .NET, de ce
point de vue, est moins "naturel".
L'idée de placer en prébuild un marqueur n'est pas mal du tout. Je vais
y réflechir.
Cordialement,
David Alloza.
Paul Bacelar wrote:
Un Assembly .NET généré avec VS.NET a un numéro de build différent à chaque
compilation pour l'unicité, pour une machine de build donné.
Cela permet de faire le tracking avec un outil de gestion de conf, type
SourceSafe.
Rien ne vous empêche de faire un petit utilitaire lisant le fichier
AssemblyInfo.xx et modifiant l'attribut AssemblyDescription de l'assembly
pour permettre à l'utilisateur final de regarder la valeur dans le champ
Comment des propriétés de l'assembly dans les propriétés affichées par
l'explorer.
Avec VS, il suffit de mettre cette utilitaire comme command de pré-build et
aussi en commande de post-build avec d'autres paramètres pour l'intégrer
dans votre chaîne de compilations standard.
L'utilitaire na qu'a chercher une chaîne très simple: [assembly:
AssemblyDescription("")]
C'est le plus rapide.
Si cette approche vous semble légère, utilisé en plus FxCop avec une règle
supplémentaire qui vérifiera le format des AssemblyDescription de chaque
assembly créé. Vous serez ainsi prévenu d'une anomalie si votre utilitaire
déraille, ou qu'un programmeur facétieux change l'AssemblyInfo de manière à
invalider l'exécution de votre pre-processeur maison.
A la rigueur, le pré-processeur de VC++ peu servir d'utilitaire avec les
bonnes lignes de commandes et les bonnes redirections des fichiers (à vos
fichiers bat :-) )
Merci pour cette réponse. L'avantage d'un marquage de version avec heure et date intégré est une plus grande lisibilité pour l'utilisateur ( il peut me dire qu'il utilise la version du XX/XX/200X buildée à 10h42mn), un système de notation de version automatisé tel qu'il est disponible sous .NET, de ce point de vue, est moins "naturel". L'idée de placer en prébuild un marqueur n'est pas mal du tout. Je vais y réflechir. Cordialement, David Alloza.
Paul Bacelar wrote:
Un Assembly .NET généré avec VS.NET a un numéro de build différent à chaque compilation pour l'unicité, pour une machine de build donné. Cela permet de faire le tracking avec un outil de gestion de conf, type SourceSafe. Rien ne vous empêche de faire un petit utilitaire lisant le fichier AssemblyInfo.xx et modifiant l'attribut AssemblyDescription de l'assembly pour permettre à l'utilisateur final de regarder la valeur dans le champ Comment des propriétés de l'assembly dans les propriétés affichées par l'explorer. Avec VS, il suffit de mettre cette utilitaire comme command de pré-build et aussi en commande de post-build avec d'autres paramètres pour l'intégrer dans votre chaîne de compilations standard. L'utilitaire na qu'a chercher une chaîne très simple: [assembly: AssemblyDescription("")]
C'est le plus rapide. Si cette approche vous semble légère, utilisé en plus FxCop avec une règle supplémentaire qui vérifiera le format des AssemblyDescription de chaque assembly créé. Vous serez ainsi prévenu d'une anomalie si votre utilitaire déraille, ou qu'un programmeur facétieux change l'AssemblyInfo de manière à invalider l'exécution de votre pre-processeur maison.
A la rigueur, le pré-processeur de VC++ peu servir d'utilitaire avec les bonnes lignes de commandes et les bonnes redirections des fichiers (à vos fichiers bat :-) )
