Discussion :

[llaffont]

Bonjour,

Je suis actullement sur un bout de code qui copie des fichiers d'un répertoire à un autre tout ça sur un poste distant.

J'ai remarqué que les traitement était devenu long depuis que la phase Copy a été mis en production.

Vu que je lance la procédure en local, qu'elle agit sur un poste distant et que j'utilise File.Copy()

Ma question est : Qu'elle est le poste qui travail (temp processeur) à la copie.

Merci

[SaumonAgile]

Ma question est : quel est le poste qui travaille (temps processeur) à la copie.

Les deux... Ce sont deux machines différentes qui communiquent par le réseau, il faut bien qu'elles fassent des traitements chacune de leur côté, une pour envoyer le fichier, l'autre pour le recevoir.

[llaffont]

Merci de ta réponse. (Et tes corrections orthographiques)

Mais je ne rapatrie pas le fichier en local. Je fais une copie du poste distant au poste distant.

[SaumonAgile]

Mais je ne rapatrie pas le fichier en local. Je fais une copie du poste distant au poste distant.

Si tu copies un fichier d'une machine vers une autre, le fichier passe forcément par la machine sur laquelle la commande de copie est exécutée.
Donc pour résumer, si tu exécutes à partir de A un programme qui copie un fichier de B vers C (ou même de B vers B), le fichier copié passe tout de même par A.

[llaffont]

Je m'en doutais.

Peux t'on y remédier ?

Faire en sorte que la copie soit exécutée par le poste distant afin de gagner du temps.
Car actuellement il s'agit d'un test et cela prend déjà 20 secondes mais mis en production le parc représente plus de 1000 machines....

[kinola]

Test de faire une copie de ton fichier en local, genre une sauvegarde et après tu fait un file.move ca sera peut être plus rapide

[Franckintosh]

Tu peux toujours faire un programme qui ne fait que copier, que tu installes sur tes postes distants, et en fait ton programme pricipal ne fais que lancer le programme de copie. Comme ça c'est bien le poste source qui envoie sur le poste destination sans passer par le poste qui ordonne la copie. Ce n'est pas tout à fait ce que tu cherches mais c'est une alternative intéressante.

[Graffito]

Bonjour,

On peut essayer de comparer les temps d'une série de copy() C# avec le temps d'éxécution d'un batch portant sur les mêmes fichiers (.bat avec commandes DOS "copy ficsource ficdest").

Si les temps sont comparables, c'est un problème de réseau.
Sinon, le programme c# peut générer le batch automatiquement et en demander l'exécution.

[llaffont]

Merci à vous tous de vos réponses.

Mais qu'en est il des WMI ?
Cela ne sert a pas à ça normalement ? A faire exécuter un traitement par le poste distant sur lui même.

[Kaidan]

Je crois que WMI sert plutôt à obtenir des informations sur un poste local ou sur le réseau.

Quelle est la taille du fichier ? les performances du réseau ?

A mon avis, la copie via réseau implique tout de même pas mal de contraintes et n'est pas, une solution viable pour un déploiement sûr et robuste sur un millier de machines.

[Franckintosh]

A mon avis, la copie via réseau implique tout de même pas mal de contraintes et n'est pas, une solution viable pour un déploiement sûr et robuste sur un millier de machines.

Ca me paraît beaucoup plus sûr et robuste que de passer sur chaque poste avec un cd.

[llaffont]

Merci pour la réponse des WMI. J'arrive mieux a cibler leur utilité.

Quand a mon problème de Temps de traitement ne vous prenez pas plus la tête, je me contenterais de mon File.Copy() après tout je suis là pour bosser et un traitement long c'est pas la mort non plus surtout quand c'est des secondes.

Merci a tous !

[Kaidan]

Ca me paraît beaucoup plus sûr et robuste que de passer sur chaque poste avec un cd.

Il a pas parler de déploiement de son programme sur les postes via copie. J'ai juste lu "copier des fichiers d'un répertoire vers un autre sur un poste distant".