Bonjour,
J'aimerai avoir votre avis sur une approche technique.
Au boulot, nous avons plusieurs processus automatisés qui s'effectuent
sur une base de fichier. En gros, nous exécutons des opérations de
copie, d'effacement, de création de répertoires, de compression, gestion
d'archives..(appel des applications en ligne de commande), sur plusieurs
milliers de fichiers.
Initialement toutes les opérations etaients effactés a partir de
fichiers de commandes .bat (nous sommes sous windows).
Ensuite, un developpement d'un langage de script interne dédié a ce
genre d'opérations a été effectué, la solution bien que moyennement
pratique a été fonctionnelle pendant plusieurs années.
Evidemment, nous avons ecarté l'ecriture de programmes binaires pour
executer ces opérations tout simplement car nous voulons pouvoir
modifier nos fichiers de commandes avec un simple editeur texte, et ne
pas avoir a recompiler une application systématiquement a chaque
modification d'un fichier de commandes.
D'autres solutions, marginales dans la société ont été testées,
principalement a base de fichiers de commande "rubis" et autres langages
de scripts.
Je me demande si il ne serait pas possible d'implementer une solution a
base de scripts C#, tout simplement en utilisant la compilation
dynamique de nos scripts.
Voila comment je verrai le truc:
Pour les scripts, on met en place une interface unique, ils devrons
fournir une classe qui implémente une méthode "Run".
On developpe un programme résident en C# (service ?) qui se lance au
démarrage de la machine, ce sera le gestionnaire global de l'ensemble
des scripts.
a chaque script de commande qui devra être exécuté, on informe le
gestionaire de la demande d'execution du script, et il l'execute via
compilation dynamique (avec une creation de thread indépendante pour
chaque script).
Pour que cela soit jouable, il faudrait que je puisse assigner dans
windows une opération qui consisterai a faire parvenir au gestionaire
l'information qui lui indique qu'il doit executer ce script, et avoir la
possibilité de bloquer le deroulement de l'application appelante tans
que le script n'est pas totalement exécuté.
(je pourrait utiliser une instance de gestionnaire par script a
exécuter, mais je préfère eviter cette aproche plus couteuse en
mémoire/temps d'execution).
Peut etre une possibilité serait d'untiliser un programme win32 en ligne
de commande qui se chargerai lui même de la communication entre le
script et le gestionaire..
( en gros, j'affecte sous windows l'execution de mon type de fichiers de
scritps a un petit exécutable win32, et ce petit exécutable s'occupe
d'informer le gestionaire du boulot a faire, et bloque tant que le
gestionaire ne lui dit pas que l'execution est terminée).
Il faudrait aussi qu'un script puisse demander l'execution d'un autre
script dans son code.
Il serait préférable que les scritps puissent être débugués sous le
debugueur de visual studio pendant leur exécution..
J'ai en gros réfléchi au problème a peu prés une heure, et voila la ou
ça m'a mené.
Pensez vous que cette approche soit viable? efficasse ?, ou alors il
vaut mieux que j'oublie tout ça ?
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
Olivier
Bonjour,
J'ai retrouvé quelque chose qui pourrait t'intéresser : http://www.members.optusnet.com.au/~olegshilo/index.html.
Les taches planifiées doivent répondre à ton besoin, il est peut-être inutile de faire un service.
Olivier
On 21 jan, 22:21, David Alloza <dalloza@[pasdespam]edengames.com> wrote:
Bonjour, J'aimerai avoir votre avis sur une approche technique. Au boulot, nous avons plusieurs processus automatisés qui s'effectuent sur une base de fichier. En gros, nous exécutons des opérations de copie, d'effacement, de création de répertoires, de compression, gest ion d'archives..(appel des applications en ligne de commande), sur plusieurs milliers de fichiers. Initialement toutes les opérations etaients effactés a partir de fichiers de commandes .bat (nous sommes sous windows). Ensuite, un developpement d'un langage de script interne dédié a ce genre d'opérations a été effectué, la solution bien que moyenneme nt pratique a été fonctionnelle pendant plusieurs années. Evidemment, nous avons ecarté l'ecriture de programmes binaires pour executer ces opérations tout simplement car nous voulons pouvoir modifier nos fichiers de commandes avec un simple editeur texte, et ne pas avoir a recompiler une application systématiquement a chaque modification d'un fichier de commandes. D'autres solutions, marginales dans la société ont été testées, principalement a base de fichiers de commande "rubis" et autres langages de scripts.
Je me demande si il ne serait pas possible d'implementer une solution a base de scripts C#, tout simplement en utilisant la compilation dynamique de nos scripts. Voila comment je verrai le truc:
Pour les scripts, on met en place une interface unique, ils devrons fournir une classe qui implémente une méthode "Run".
On developpe un programme résident en C# (service ?) qui se lance au démarrage de la machine, ce sera le gestionnaire global de l'ensemble des scripts. a chaque script de commande qui devra être exécuté, on informe le gestionaire de la demande d'execution du script, et il l'execute via compilation dynamique (avec une creation de thread indépendante pour chaque script). Pour que cela soit jouable, il faudrait que je puisse assigner dans windows une opération qui consisterai a faire parvenir au gestionaire l'information qui lui indique qu'il doit executer ce script, et avoir la possibilité de bloquer le deroulement de l'application appelante tans que le script n'est pas totalement exécuté. (je pourrait utiliser une instance de gestionnaire par script a exécuter, mais je préfère eviter cette aproche plus couteuse en mémoire/temps d'execution). Peut etre une possibilité serait d'untiliser un programme win32 en ligne de commande qui se chargerai lui même de la communication entre le script et le gestionaire.. ( en gros, j'affecte sous windows l'execution de mon type de fichiers de scritps a un petit exécutable win32, et ce petit exécutable s'occupe d'informer le gestionaire du boulot a faire, et bloque tant que le gestionaire ne lui dit pas que l'execution est terminée). Il faudrait aussi qu'un script puisse demander l'execution d'un autre script dans son code. Il serait préférable que les scritps puissent être débugués sou s le debugueur de visual studio pendant leur exécution..
J'ai en gros réfléchi au problème a peu prés une heure, et voila la ou ça m'a mené. Pensez vous que cette approche soit viable? efficasse ?, ou alors il vaut mieux que j'oublie tout ça ?
Cordialement, David Alloza.
Bonjour,
J'ai retrouvé quelque chose qui pourrait t'intéresser :
http://www.members.optusnet.com.au/~olegshilo/index.html.
Les taches planifiées doivent répondre à ton besoin, il est
peut-être inutile de faire un service.
Olivier
On 21 jan, 22:21, David Alloza <dalloza@[pasdespam]edengames.com>
wrote:
Bonjour,
J'aimerai avoir votre avis sur une approche technique.
Au boulot, nous avons plusieurs processus automatisés qui s'effectuent
sur une base de fichier. En gros, nous exécutons des opérations de
copie, d'effacement, de création de répertoires, de compression, gest ion
d'archives..(appel des applications en ligne de commande), sur plusieurs
milliers de fichiers.
Initialement toutes les opérations etaients effactés a partir de
fichiers de commandes .bat (nous sommes sous windows).
Ensuite, un developpement d'un langage de script interne dédié a ce
genre d'opérations a été effectué, la solution bien que moyenneme nt
pratique a été fonctionnelle pendant plusieurs années.
Evidemment, nous avons ecarté l'ecriture de programmes binaires pour
executer ces opérations tout simplement car nous voulons pouvoir
modifier nos fichiers de commandes avec un simple editeur texte, et ne
pas avoir a recompiler une application systématiquement a chaque
modification d'un fichier de commandes.
D'autres solutions, marginales dans la société ont été testées,
principalement a base de fichiers de commande "rubis" et autres langages
de scripts.
Je me demande si il ne serait pas possible d'implementer une solution a
base de scripts C#, tout simplement en utilisant la compilation
dynamique de nos scripts.
Voila comment je verrai le truc:
Pour les scripts, on met en place une interface unique, ils devrons
fournir une classe qui implémente une méthode "Run".
On developpe un programme résident en C# (service ?) qui se lance au
démarrage de la machine, ce sera le gestionnaire global de l'ensemble
des scripts.
a chaque script de commande qui devra être exécuté, on informe le
gestionaire de la demande d'execution du script, et il l'execute via
compilation dynamique (avec une creation de thread indépendante pour
chaque script).
Pour que cela soit jouable, il faudrait que je puisse assigner dans
windows une opération qui consisterai a faire parvenir au gestionaire
l'information qui lui indique qu'il doit executer ce script, et avoir la
possibilité de bloquer le deroulement de l'application appelante tans
que le script n'est pas totalement exécuté.
(je pourrait utiliser une instance de gestionnaire par script a
exécuter, mais je préfère eviter cette aproche plus couteuse en
mémoire/temps d'execution).
Peut etre une possibilité serait d'untiliser un programme win32 en ligne
de commande qui se chargerai lui même de la communication entre le
script et le gestionaire..
( en gros, j'affecte sous windows l'execution de mon type de fichiers de
scritps a un petit exécutable win32, et ce petit exécutable s'occupe
d'informer le gestionaire du boulot a faire, et bloque tant que le
gestionaire ne lui dit pas que l'execution est terminée).
Il faudrait aussi qu'un script puisse demander l'execution d'un autre
script dans son code.
Il serait préférable que les scritps puissent être débugués sou s le
debugueur de visual studio pendant leur exécution..
J'ai en gros réfléchi au problème a peu prés une heure, et voila la ou
ça m'a mené.
Pensez vous que cette approche soit viable? efficasse ?, ou alors il
vaut mieux que j'oublie tout ça ?
J'ai retrouvé quelque chose qui pourrait t'intéresser : http://www.members.optusnet.com.au/~olegshilo/index.html.
Les taches planifiées doivent répondre à ton besoin, il est peut-être inutile de faire un service.
Olivier
On 21 jan, 22:21, David Alloza <dalloza@[pasdespam]edengames.com> wrote:
Bonjour, J'aimerai avoir votre avis sur une approche technique. Au boulot, nous avons plusieurs processus automatisés qui s'effectuent sur une base de fichier. En gros, nous exécutons des opérations de copie, d'effacement, de création de répertoires, de compression, gest ion d'archives..(appel des applications en ligne de commande), sur plusieurs milliers de fichiers. Initialement toutes les opérations etaients effactés a partir de fichiers de commandes .bat (nous sommes sous windows). Ensuite, un developpement d'un langage de script interne dédié a ce genre d'opérations a été effectué, la solution bien que moyenneme nt pratique a été fonctionnelle pendant plusieurs années. Evidemment, nous avons ecarté l'ecriture de programmes binaires pour executer ces opérations tout simplement car nous voulons pouvoir modifier nos fichiers de commandes avec un simple editeur texte, et ne pas avoir a recompiler une application systématiquement a chaque modification d'un fichier de commandes. D'autres solutions, marginales dans la société ont été testées, principalement a base de fichiers de commande "rubis" et autres langages de scripts.
Je me demande si il ne serait pas possible d'implementer une solution a base de scripts C#, tout simplement en utilisant la compilation dynamique de nos scripts. Voila comment je verrai le truc:
Pour les scripts, on met en place une interface unique, ils devrons fournir une classe qui implémente une méthode "Run".
On developpe un programme résident en C# (service ?) qui se lance au démarrage de la machine, ce sera le gestionnaire global de l'ensemble des scripts. a chaque script de commande qui devra être exécuté, on informe le gestionaire de la demande d'execution du script, et il l'execute via compilation dynamique (avec une creation de thread indépendante pour chaque script). Pour que cela soit jouable, il faudrait que je puisse assigner dans windows une opération qui consisterai a faire parvenir au gestionaire l'information qui lui indique qu'il doit executer ce script, et avoir la possibilité de bloquer le deroulement de l'application appelante tans que le script n'est pas totalement exécuté. (je pourrait utiliser une instance de gestionnaire par script a exécuter, mais je préfère eviter cette aproche plus couteuse en mémoire/temps d'execution). Peut etre une possibilité serait d'untiliser un programme win32 en ligne de commande qui se chargerai lui même de la communication entre le script et le gestionaire.. ( en gros, j'affecte sous windows l'execution de mon type de fichiers de scritps a un petit exécutable win32, et ce petit exécutable s'occupe d'informer le gestionaire du boulot a faire, et bloque tant que le gestionaire ne lui dit pas que l'execution est terminée). Il faudrait aussi qu'un script puisse demander l'execution d'un autre script dans son code. Il serait préférable que les scritps puissent être débugués sou s le debugueur de visual studio pendant leur exécution..
J'ai en gros réfléchi au problème a peu prés une heure, et voila la ou ça m'a mené. Pensez vous que cette approche soit viable? efficasse ?, ou alors il vaut mieux que j'oublie tout ça ?
Cordialement, David Alloza.
David Alloza
Merci Olivier, C'est en gros la solution a laquelle je réfléchissait, je vais regarder ceci en profondeur. Cordialement, David Alloza.
"Olivier" a écrit dans le message de news:
Bonjour,
J'ai retrouvé quelque chose qui pourrait t'intéresser : http://www.members.optusnet.com.au/~olegshilo/index.html.
Les taches planifiées doivent répondre à ton besoin, il est peut-être inutile de faire un service.
Olivier
On 21 jan, 22:21, David Alloza <dalloza@[pasdespam]edengames.com> wrote:
Bonjour, J'aimerai avoir votre avis sur une approche technique. Au boulot, nous avons plusieurs processus automatisés qui s'effectuent sur une base de fichier. En gros, nous exécutons des opérations de copie, d'effacement, de création de répertoires, de compression, gestion d'archives..(appel des applications en ligne de commande), sur plusieurs milliers de fichiers. Initialement toutes les opérations etaients effactés a partir de fichiers de commandes .bat (nous sommes sous windows). Ensuite, un developpement d'un langage de script interne dédié a ce genre d'opérations a été effectué, la solution bien que moyennement pratique a été fonctionnelle pendant plusieurs années. Evidemment, nous avons ecarté l'ecriture de programmes binaires pour executer ces opérations tout simplement car nous voulons pouvoir modifier nos fichiers de commandes avec un simple editeur texte, et ne pas avoir a recompiler une application systématiquement a chaque modification d'un fichier de commandes. D'autres solutions, marginales dans la société ont été testées, principalement a base de fichiers de commande "rubis" et autres langages de scripts.
Je me demande si il ne serait pas possible d'implementer une solution a base de scripts C#, tout simplement en utilisant la compilation dynamique de nos scripts. Voila comment je verrai le truc:
Pour les scripts, on met en place une interface unique, ils devrons fournir une classe qui implémente une méthode "Run".
On developpe un programme résident en C# (service ?) qui se lance au démarrage de la machine, ce sera le gestionnaire global de l'ensemble des scripts. a chaque script de commande qui devra être exécuté, on informe le gestionaire de la demande d'execution du script, et il l'execute via compilation dynamique (avec une creation de thread indépendante pour chaque script). Pour que cela soit jouable, il faudrait que je puisse assigner dans windows une opération qui consisterai a faire parvenir au gestionaire l'information qui lui indique qu'il doit executer ce script, et avoir la possibilité de bloquer le deroulement de l'application appelante tans que le script n'est pas totalement exécuté. (je pourrait utiliser une instance de gestionnaire par script a exécuter, mais je préfère eviter cette aproche plus couteuse en mémoire/temps d'execution). Peut etre une possibilité serait d'untiliser un programme win32 en ligne de commande qui se chargerai lui même de la communication entre le script et le gestionaire.. ( en gros, j'affecte sous windows l'execution de mon type de fichiers de scritps a un petit exécutable win32, et ce petit exécutable s'occupe d'informer le gestionaire du boulot a faire, et bloque tant que le gestionaire ne lui dit pas que l'execution est terminée). Il faudrait aussi qu'un script puisse demander l'execution d'un autre script dans son code. Il serait préférable que les scritps puissent être débugués sous le debugueur de visual studio pendant leur exécution..
J'ai en gros réfléchi au problème a peu prés une heure, et voila la ou ça m'a mené. Pensez vous que cette approche soit viable? efficasse ?, ou alors il vaut mieux que j'oublie tout ça ?
Cordialement, David Alloza.
Merci Olivier,
C'est en gros la solution a laquelle je réfléchissait, je vais regarder ceci
en profondeur.
Cordialement,
David Alloza.
"Olivier" <olivier.jaby@gmail.com> a écrit dans le message de news:
1169470099.960656.112310@l53g2000cwa.googlegroups.com...
Bonjour,
J'ai retrouvé quelque chose qui pourrait t'intéresser :
http://www.members.optusnet.com.au/~olegshilo/index.html.
Les taches planifiées doivent répondre à ton besoin, il est
peut-être inutile de faire un service.
Olivier
On 21 jan, 22:21, David Alloza <dalloza@[pasdespam]edengames.com>
wrote:
Bonjour,
J'aimerai avoir votre avis sur une approche technique.
Au boulot, nous avons plusieurs processus automatisés qui s'effectuent
sur une base de fichier. En gros, nous exécutons des opérations de
copie, d'effacement, de création de répertoires, de compression, gestion
d'archives..(appel des applications en ligne de commande), sur plusieurs
milliers de fichiers.
Initialement toutes les opérations etaients effactés a partir de
fichiers de commandes .bat (nous sommes sous windows).
Ensuite, un developpement d'un langage de script interne dédié a ce
genre d'opérations a été effectué, la solution bien que moyennement
pratique a été fonctionnelle pendant plusieurs années.
Evidemment, nous avons ecarté l'ecriture de programmes binaires pour
executer ces opérations tout simplement car nous voulons pouvoir
modifier nos fichiers de commandes avec un simple editeur texte, et ne
pas avoir a recompiler une application systématiquement a chaque
modification d'un fichier de commandes.
D'autres solutions, marginales dans la société ont été testées,
principalement a base de fichiers de commande "rubis" et autres langages
de scripts.
Je me demande si il ne serait pas possible d'implementer une solution a
base de scripts C#, tout simplement en utilisant la compilation
dynamique de nos scripts.
Voila comment je verrai le truc:
Pour les scripts, on met en place une interface unique, ils devrons
fournir une classe qui implémente une méthode "Run".
On developpe un programme résident en C# (service ?) qui se lance au
démarrage de la machine, ce sera le gestionnaire global de l'ensemble
des scripts.
a chaque script de commande qui devra être exécuté, on informe le
gestionaire de la demande d'execution du script, et il l'execute via
compilation dynamique (avec une creation de thread indépendante pour
chaque script).
Pour que cela soit jouable, il faudrait que je puisse assigner dans
windows une opération qui consisterai a faire parvenir au gestionaire
l'information qui lui indique qu'il doit executer ce script, et avoir la
possibilité de bloquer le deroulement de l'application appelante tans
que le script n'est pas totalement exécuté.
(je pourrait utiliser une instance de gestionnaire par script a
exécuter, mais je préfère eviter cette aproche plus couteuse en
mémoire/temps d'execution).
Peut etre une possibilité serait d'untiliser un programme win32 en ligne
de commande qui se chargerai lui même de la communication entre le
script et le gestionaire..
( en gros, j'affecte sous windows l'execution de mon type de fichiers de
scritps a un petit exécutable win32, et ce petit exécutable s'occupe
d'informer le gestionaire du boulot a faire, et bloque tant que le
gestionaire ne lui dit pas que l'execution est terminée).
Il faudrait aussi qu'un script puisse demander l'execution d'un autre
script dans son code.
Il serait préférable que les scritps puissent être débugués sous le
debugueur de visual studio pendant leur exécution..
J'ai en gros réfléchi au problème a peu prés une heure, et voila la ou
ça m'a mené.
Pensez vous que cette approche soit viable? efficasse ?, ou alors il
vaut mieux que j'oublie tout ça ?
Merci Olivier, C'est en gros la solution a laquelle je réfléchissait, je vais regarder ceci en profondeur. Cordialement, David Alloza.
"Olivier" a écrit dans le message de news:
Bonjour,
J'ai retrouvé quelque chose qui pourrait t'intéresser : http://www.members.optusnet.com.au/~olegshilo/index.html.
Les taches planifiées doivent répondre à ton besoin, il est peut-être inutile de faire un service.
Olivier
On 21 jan, 22:21, David Alloza <dalloza@[pasdespam]edengames.com> wrote:
Bonjour, J'aimerai avoir votre avis sur une approche technique. Au boulot, nous avons plusieurs processus automatisés qui s'effectuent sur une base de fichier. En gros, nous exécutons des opérations de copie, d'effacement, de création de répertoires, de compression, gestion d'archives..(appel des applications en ligne de commande), sur plusieurs milliers de fichiers. Initialement toutes les opérations etaients effactés a partir de fichiers de commandes .bat (nous sommes sous windows). Ensuite, un developpement d'un langage de script interne dédié a ce genre d'opérations a été effectué, la solution bien que moyennement pratique a été fonctionnelle pendant plusieurs années. Evidemment, nous avons ecarté l'ecriture de programmes binaires pour executer ces opérations tout simplement car nous voulons pouvoir modifier nos fichiers de commandes avec un simple editeur texte, et ne pas avoir a recompiler une application systématiquement a chaque modification d'un fichier de commandes. D'autres solutions, marginales dans la société ont été testées, principalement a base de fichiers de commande "rubis" et autres langages de scripts.
Je me demande si il ne serait pas possible d'implementer une solution a base de scripts C#, tout simplement en utilisant la compilation dynamique de nos scripts. Voila comment je verrai le truc:
Pour les scripts, on met en place une interface unique, ils devrons fournir une classe qui implémente une méthode "Run".
On developpe un programme résident en C# (service ?) qui se lance au démarrage de la machine, ce sera le gestionnaire global de l'ensemble des scripts. a chaque script de commande qui devra être exécuté, on informe le gestionaire de la demande d'execution du script, et il l'execute via compilation dynamique (avec une creation de thread indépendante pour chaque script). Pour que cela soit jouable, il faudrait que je puisse assigner dans windows une opération qui consisterai a faire parvenir au gestionaire l'information qui lui indique qu'il doit executer ce script, et avoir la possibilité de bloquer le deroulement de l'application appelante tans que le script n'est pas totalement exécuté. (je pourrait utiliser une instance de gestionnaire par script a exécuter, mais je préfère eviter cette aproche plus couteuse en mémoire/temps d'execution). Peut etre une possibilité serait d'untiliser un programme win32 en ligne de commande qui se chargerai lui même de la communication entre le script et le gestionaire.. ( en gros, j'affecte sous windows l'execution de mon type de fichiers de scritps a un petit exécutable win32, et ce petit exécutable s'occupe d'informer le gestionaire du boulot a faire, et bloque tant que le gestionaire ne lui dit pas que l'execution est terminée). Il faudrait aussi qu'un script puisse demander l'execution d'un autre script dans son code. Il serait préférable que les scritps puissent être débugués sous le debugueur de visual studio pendant leur exécution..
J'ai en gros réfléchi au problème a peu prés une heure, et voila la ou ça m'a mené. Pensez vous que cette approche soit viable? efficasse ?, ou alors il vaut mieux que j'oublie tout ça ?
