SIMPLE SHUTDOWN SCHEDULER : ARRÊTS PLANIFIÉS (LOCAL OU REMOTE)
violent_ken
Messages postés
1812
Date d'inscription
mardi 31 mai 2005
Statut
Membre
Dernière intervention
26 octobre 2010
-
14 juil. 2009 à 20:59
Londonic Messages postés 298 Date d'inscription jeudi 22 janvier 2009 Statut Membre Dernière intervention 26 septembre 2009 - 28 août 2009 à 13:02
Londonic Messages postés 298 Date d'inscription jeudi 22 janvier 2009 Statut Membre Dernière intervention 26 septembre 2009 - 28 août 2009 à 13:02
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/50306-simple-shutdown-scheduler-arrets-planifies-local-ou-remote
https://codes-sources.commentcamarche.net/source/50306-simple-shutdown-scheduler-arrets-planifies-local-ou-remote
28 août 2009 à 13:02
17 juil. 2009 à 18:44
@+
17 juil. 2009 à 11:27
NON, il n'existe aucun remplacement identique d'une constante comme vbNewLine (en tout cas j'ai pas trouvé sur la 30aine de site que j'ai visités).
Le seul moyen est d'utiliser ToChar, Environement.Newline ou autre, mais ce ne sont pas des constantes (mais des fonctions ou des properties de classes)
Et de même pour vbTab, vbNullChar...
Sinon certaines autres fonctions manquent également : par exemple AppActivate n'a aucun équivalent en .Net, et si on veut faire du 100% managé, même les codeurs C# doivent importer le namespace Microsoft.Visualbasic pour pouvoir l'utiliser car en managé c'est simplement irremplaçable...
De même, le comportement de Val() est pas le même que [type_num].Parse(), puisque la gestion d'erreurs est différente (en VB6 des fois on veut volontairement la valeur 0 si le paramètre n'est pas numérique, et en .Net çà lève une erreur).
Du coup plutôt que de prendre Microsoft.Visualbasic, on prend un namespace que l'on code soit même (ou une classe) parce que les "remplacer tout" dans le code par de l'équivalent .Net ne fonctionnera pas (gestion des erreurs différentes...etc)
Bref, pas sur que ce soit bien de l'enlever. Après tout, même si ce n'est qu'un héritage vieillot de VB6, c'est quand même du 100% managé et du 100% .Net derrière. Alors pourquoi devrait-on s'en priver ?
@+
17 juil. 2009 à 11:16
Sinon dans le même genre il y a les PerformanceCounter qui sont pratiques (mais plutôt orientés pour récupérer des informations numériques qui évoluent avec le temps, comme la charge CPU, la mémoire, les disques, le réseau, les bases de données, la file d'impression...)
Tout est également managé et çà fonctionne sur le réseau, cf ma source YAPM (remote) pour des exemples.
Il est même possible d'en créer soit même en respectant l'interface dédiée, j'ai jamais fait çà, mais çà montre comme c'est puissant et générique comme procédé (comme WMI).
Même si tout ceci n'est pas très performant en local, en réseau çà dépote !!!
Sinon concernant la source itself, j'ai viré Microsoft.VisualBasic, corrigé quelques bugs mineurs et ajouté quelques fonctionnalités, je mettrais à jour sur vbfrance ce soir que je rentrerais chez moi ^^
@+
16 juil. 2009 à 22:07
Sinon pour WMI, merci beaucoup de m'avoir fait decouvrir celà, c'est genial !!!!
Numéro de series en tout genre, imprimantes installées, defragmentation, reboot/shutdown, infos sur les disques, paritions, programmes installés, table de routage, ...
-> On peut tout faire ou savoir à distance :-D
Je crois que mes futurs developpements vont s'appuyer sur cette techno !!!
15 juil. 2009 à 22:27
effectivement System.Convert.ToChar(13) ou System.Environment.NewLine remplace vbNewline partout.... sauf dans les constantes.
En effet, ToChar est une fonction et Environment.NewLine n'est pas une constante :-(
Sinon je suis déjà tombé sur ton tuto us_30, très pratique !
@+
15 juil. 2009 à 22:05
Violent_Ken, il me semble qu'on peut remplacer vbNewLine par System.Environment.NewLine ou System.Convert.ToChar(13) en VB.NET... Bon, je sais que je ne suis pôs LA référence en la matière mais j'ai repêché cette info dans mon modeste tuto sur CS ou j'ai tenté de trouver les équivalences en pur .NET des instructions VB6... Voilà, c'est juste pour info...
Amicalement,
Us.
15 juil. 2009 à 16:39
Sinon t'as entièrement raison pour Microsoft.VisualBasic. Comme le code est pas grand, je vais dégager tout ce qui a rapport à çà.
Mais il n'empêche que certains trucs sont utiles ! Je me rappelle plus trop bien, mais il me semble pas que j'avais trouvé de constante .Net pour remplacer vbNewLine par exemple... (si tu connais, je suis preneur !!)
De même, certaines fonctions comme Len() (qui renvoie 0 pour une chaine qui est Nothing, contrairement à .Length qui foire si l'objet String est nul) sont très très pratiques ! Dur de s'en séparer mais pourtant il le fau(drai)t !
@+
15 juil. 2009 à 16:19
Sinon je parlais de bloquant au sens où les utilisateurs n'arrivent pas utiliser mes logiciels réseaux car ils sont bloqué à cause des droits.
15 juil. 2009 à 16:17
Exemple : MsgBox, vbNullChar, IsNumeric, Fix, vbNullString, InStr, Split, etc...
Faut que je me fasse soigner ?
15 juil. 2009 à 16:10
Sinon WMI est utile, mais principalement pour des requêtes réseau de mon humble avis. Localement, j'utilise personnellement que des fonctions de l'API Win32 (ou bien du Framework .Net, si c'est simple et que les perfs sont pas fondamentales).
J'ai déjà vu des codes avec des appels massifs à WMI (par exemple pour récupérer le nom du PC ou de l'user, la liste des processus ou des services...) -> je pense que c'est une mauvaise voie et que le framework devrait être privilégié.
Pour de la performance, API only mais il faut avoir à l'esprit que c'est non managé et ce n'est pas dans la philosophie de .Net (mais quand il faut il faut !!)
Ensuite pour le réseau, WMI est quand même très pratique car :
- sécurisé
- robuste
- managé avec le namespace Management (aucun rapport entre managé et le nom ^^)
Sinon, qu'entends-tu par "bloquante" ? Si c'est dans le sens d'un "appel bloquant", alors le namespace System.Threading est là pour çà :-) (ou plus léger via ThreadPool). Mais avec quel genre de fonction de l'API Win32 ?
@+
15 juil. 2009 à 15:54
Donc je viens de faire tourner ton soft, et c'est de l'excellent travail. Pour WMI je crois que je vais m'y mettre car l'utilisation d'API est souvent bloquante dans mes applis... çà me fera un bon exemple pour apprendre.
Désolé pour la fausse alerte, et bon code !
15 juil. 2009 à 15:22
bizarre, normalement le zip est complet (d'ailleurs je vois le dossier VistaMenu dans l'arborescence juste au dessus) ??
J'ai généré le zip avec un petit utilitaire que j'ai codé, qui vire tous les dossiers cachés .svn de subversion et tous les trucs inutiles pour une recompilation complète (dossier Obj, Bin...). C'est la première fois qu'il foire, zut ! Ben je vais checker çà ce soir en rentrant :)
A moins peut être que tu n'ait que le compilo VB.Net d'installé ? Si c'est le cas, c'est normal, il faut absolument avoir le compilo C# (VistaMenu et SecurePasswordTextbox sont en C#). Mais je pense pas que çà soit çà sinon la SecurePasswordTextbox aurait aussi foiré.
Je mettrais une solution qui utilise des dll précompilées pour ceux qui n'ont pas C#
Sinon pour PasswordChar, j'ai pas vérifié l'implémentation qui a été faite, mais il me semble que c'est uniquement l'affichage qui est modifié. L'intérêt de la SecurePasswordTextbox est d'utiliser les SecureString, ce qui a pour avantage de ne pas laisser trainer en mémoire le password en clair. (Au passage ce controle n'a pas été codé par moi-même et j'ai oublié de mettre le lien vers la page de l'auteur)
Dans le code que je propose, le password n'est jamais manipulé en clair, il est toujours soit sous forme de SecureString, soit sous forme de String encryptée (obligatoire pour la serialization en vue de la sauvegarde XML, puisqu'une SecureString n'est pas serializable).
Pour InitiateSystemShutdown, la fonction est intéressante mais ne permet pas de faire un simple logoff il me semble (juste poweroff ou reboot si j'ai bien lu). Et comme tu dis, il faut les droits requis sur la machine distante : du coup on ne peut pas shutdown si seulement un simple user (non admin) est loggué sur le PC distant... ce que permet WMI, puisque user+mdp sont rentrés sur le PC local.
Sinon pour le choix de WMI, c'est parce que j'avais déjà travaillé sur le bout de code utilisant WMI, donc je l'ai simplement réutilisé pour aller plus vite ^^
Ce soir le zip sera fonctionnel normalement (sinon le code et un setup sont dispos sur sourceforce.net en attendant)
@+
15 juil. 2009 à 14:43
je n'ai pas pu tester ton appli car il manque le control (=projet) VistaMenu :-s
Sinon a quoi sert SecurePasswordTextbox ? la propriété PasswordChar du control TextBox n'aurai pas fait l'affaire ?
Pour l'exctinction à distance il existe aussi l'API InitiateSystemShutdown qu'il faut utiliser avec le privilège SE_REMOTE_SHUTDOWN_NAME.
L'inconvenient étant d'avoir les droits suffisants sur la machine distante (plutot recommandé pour les domaines que les workgroups).
Je peux pas juger plus que çà, je n'arrive pas a faire tourner l'appli ...
14 juil. 2009 à 20:59
@+