| ||
auteurs : abelman, tomlev | ||
Cette définition est tirée de MSDN.
.NET (lire dotnet) Framework est le modèle de programmation de la plateforme .NET. Les principaux composants de .NET Framework sont le Common Language Runtime et la bibliothèque de classes .NET Framework, qui contient ADO.NET, ASP.NET et Windows Forms. .NET Framework fournit un environnement d'exécution managé, un développement et un déploiement simplifiés et l'intégration à une grande variété de langages de programmation. La version courante est la 3.5 SP1. La prochaine version, .NET 4.0, est actuellement disponible en beta 2, et la version finale devrait sortir le 12 avril 2010. | ||
lien : Microsoft .NET Framework |
| ||
auteurs : abelman, tomlev | ||
Pour obtenir la version de l'application courante, on utilise la classe System.Reflection.Assembly
Pour obtenir la version d'un fichier (EXE, DLL, OCX, etc..) quelconque, il suffit de passer le chemin du fichier à la fonction GetVersionInfo | ||
lien : System.Diagnostics.FileVersionInfo (MSDN) lien : System.Environment (MSDN) |
| |||
auteurs : abelman, tomlev | |||
La classe System.Convert permet de convertir des objets entre les principaux types de base du framework : d'un double vers un entier,
d'une chaine de caractères vers un décimal, d'un entier vers un booléen... Contrairement à un cast, la classe Convert est capable d'utiliser differentes techniques pour effectuer la conversion : un cast quand c'est possible, un appel de méthode (Parse, ToString), l'utilisation de l'interface IConvertible... Il est ainsi possible de convertir un objet dans le type voulu sans savoir quel est son type de départ. La classe Convert peut aussi effectuer des conversions d'entiers en base 2, 8 ou 16, ou de convertir un tableau d'octets en base64.
Voici quelques exemples :
Il est aussi possible d'utiliser la méthode Parse de chaque type de base.
Une autre possibilité est d'utiliser la méthode TryParse, qui évite de lever une exception si
la conversion échoue. Cette méthode renvoie true si la conversion réussit, false sinon.
| |||
lien : System.Convert (MSDN) |
| ||
auteurs : Thomas Lebrun, abelman | ||
Il vous faut utiliser la classe System.Console et les méthodes qui la compose.
Console.Writeline écrit par défaut sur :
| ||
lien : System.Console (MSDN) |
| ||
auteur : cardi | ||
Pour ce qui est d'une application console, il faut passer par la classe Console avec la propriété Title :
|
| ||
auteurs : Keihilin, tomlev | ||
Le garbage collector (aussi appelé ramasse-miettes) est le composant du framework chargé de gérer la mémoire utilisée par le programme. Il garde la trace des objets créés et des références à ces objets. Quand la mémoire occupée par le programme devient trop importante, le garbage collector effectue un cycle de collecte : il examine les objets en mémoire pour voir s'ils sont encore référencés. Si ce n'est pas le cas, ils sont inaccessibles et ne seront donc plus utilisés. Le garbage collector peut donc libérer la mémoire occupée par ces objets, ainsi que les autres ressources qu'ils utilisent (fichiers, connexions réseau, mémoire non managée...), en appelant le finaliseur (méthode Finalize, implémentée en C# sous la forme d'un destructeur).
Le garbage collector du .NET framework est de type "générationel" : cela signifie qu'il gère plusieurs générations d'objets. La première génération est constituée des objets récemment créés, qui sont susceptibles d'avoir une faible durée de vie ; c'est donc sur cette génération que la collecte est effectuée le plus souvent. Les objets qui "survivent" à un premier cycle de collecte sont promus à la deuxième génération, qui est collectée moins souvent. Les objets qui survivent à une deuxième collecte sont promus à la troisième et dernière génération, plus rarement collectée. Ce sont des objets qui ont une longue durée de vie, par exemple la fenêtre principale d'un programme. Ce mécanisme de générations permet de réduire le travail du garbage collector, qui est coûteux en ressources.
On croit souvent à tort que le garbage collector empêche les fuites mémoires : c'est faux ! Il facilite le travail du développeur car celui-ci n'a plus à se préoccuper de libérer la mémoire allouée, mais il faut garder à l'esprit qu'un objet ne sera pas collecté tant qu'il restera des références vers cet objet. Il faut donc bien penser à supprimer les références aux objets qu'on n'utilise plus, sinon ils resteront en mémoire jusqu'à la fin du programme.
Notez qu'il n'est pas possible de prévoir quand le garbage collector appelera le destructeur d'un objet qui n'est plus référencé : si un objet utilise des ressources systèmes critiques, il est donc préférable de libérer explicitement ces ressources le plus tôt possible. La technique recommandée pour gérer ces cas est d'implémenter l'interface IDisposable.
| ||
lien : Garbage collection (MSDN) lien : Destructeur et méthode Finalize (MSDN) lien : Implémentation d'une méthode Dispose (MSDN) |
| ||
auteur : Thomas Lebrun | ||
Pour forcer le Garbage Collector à libérer la mémoire inutilisée par le .NET Framework, on peut appeler la méthode Collect de la classe GC.
Par contre, pour des raisons qui justifieraient à elles seules un article, il n'est pas conseillé d'appeler GC.Collect() directement. Par conséquent, ne le faites pas à moins d'être un expert du garbage collector. |
| ||
auteur : Thomas Lebrun | ||
Pour appeler une fonction présente dans une DLL, vous devez utiliser DllImport et vous devez toujours faire précéder le type de la méthode
du mot-clé extern (cela permet de spécifier que la méthode est appelée dans un fichier externe à l'application). Vous devez aussi connaître :
Ces informations vous sont généralement fournies avec la documentation de la méthode désirée. Voici un exemple de DllImport :
Cette méthode, extraite du fichier user32.dll, renvoie un entier et prend en paramètre 2 autres entiers. |
| |||
auteurs : abelman, freegreg, tomlev | |||
Il y a différentes méthodes possibles :
- à l'aide de la méthode Environment.GetCommandLineArgs :
- avec Assembly.GetEntryAssembly() :
- en Windows Forms, on peut aussi utiliser Application.StartupPath :
| |||
lien : System.Environment.GetCommandLineArgs (MSDN) lien : System.Reflection.Assembly.GetEntryAssembly (MSDN) lien : System.Windows.Forms.Application.StartupPath (MSDN) |
| ||
auteurs : nico-pyright(c), dev01 | ||
Il faut pour cela récupérer le chemin de l'assembly contenant le code de démarrage de l'application :
Attention à ne pas confondre avec :
qui donne le répertoire courant qui n'est pas forcément celui de démarrage. (C'est modifié par exemple lors de l'utilisation des boites de dialogue "Ouvrir", "Enregistrer"... ) |
| ||
auteur : abelman | ||
On utilise la propriété CurrentDirectory de la classe Environment
| ||
lien : System.Environment (MSDN) |
| ||
auteur : abelman | ||
On utilise la propriété CommandLine de la classe Environment pour avoir la ligne entière dans une chaine de caractères :
On utilise GetCommandLineArgs pour obtenir un tableau de chaines de caractères contenant chaque argument.
| ||
lien : System.Environment (MSDN) |
| ||
auteurs : abelman, tomlev | ||
On utilise les méthodes GetEnvironmentVariable et GetEnvironmentVariables de la classe Environment.
| ||
lien : System.Environment (MSDN) lien : System.Collections.IDictionnary (MSDN) |
| ||
auteur : abelman | ||
Il arrive souvent de souhaiter interdire à une application d'avoir plusieurs instances lancées. Voici une petite classe qui lors du démarrage de l'application, s'assure qu'elle n'est pas déjà en cours d'exécution. Elle utilise un objet mutex nommé, donc potentiellement visible par tous les autres processus.
Pour utiliser notre classe, il suffit de procéder ainsi dans le Main de notre application.
Important :
Si une application lambda en cours d'exécution crée un mutex ayant le même nom que celui de notre application, cette dernière ne pourra plus se lancer. Elle se comportera comme si une autre instance de l'application était déjà en cours. Il existe une technique pour l'éviter mais cela sort de notre sujet. Veuillez donc à choisir un nom assez compliqué pour votre mutex. |
| ||
auteur : cardi | ||
Lorsque l'application se lance, il suffit de récupérer le processus courant et ensuite de parcourir la liste des processus en cours d'exécution sur la machine. Si le nom du processus courant correspond au nom d'un processus lancé sur la machine, l'application est déjà lancée et on peut donc l'arrêter directement.
Tout cela sera possible grâce à la classe Process.
|
| ||
auteurs : abelman, tomlev | ||
La classe System.Random nous permet de générer des nombres aléatoires. Il s'agit en fait de nombres pseudo-aléatoires, car la séquence générée dépend de l'initialisation.
Remarque importante : le générateur de nombres aléatoires se base sur une valeur initiale appelée seed ("graine"). Si on utilise toujours la même
seed, on obtiendra toujours la même séquence. Par défaut, le générateur de nombres aléatoires est initialisé par rapport à l'heure courante
(la propriété Environment.TickCount pour être exact). Autrement dit, si vous créez plusieurs instances de Random sans préciser la seed à intervalle très rapproché,
le TickCount (nombre de millisecondes depuis le démarrage) n'aura pas eu le temps de changer, et les différentes instances de Random renverront toutes la même séquence...
Si vous générez des nombres aléatoires en boucle, il faut donc toujours utiliser la même instance de Random et non en créer une nouvelle à chaque itération.
| ||
lien : System.Random (MSDN) |
| ||
auteurs : ThomasB, tomlev | ||
Le plus simple est d'utiliser un fichier de ressources (.resx). Le fichier de ressources principal
de l'assembly peut être créé et modifié à partir de la page de propriétés du projet, dans l'onglet Ressources.
Pour ajouter un fichier existant dans le fichier de ressources, ouvrez le fichier de ressources, cliquez
"Ajouter une ressource", "Ajouter un fichier existant", et sélectionnez le fichier voulu. Il sera ensuite
accessible dans le code via Properties.Ressources.NomDuFichierSansExtension.
On peut aussi utiliser un fichier en tant que ressource sans l'ajouter à un fichier .resx :
Ensuite, pour utiliser la ressource dans le code (dans l'exemple c'est un fichier texte nommé fichier.txt) :
| ||
lien : Méthode GetManifestResourceStream (MSDN) |
| ||
auteur : cardi | ||
Avec la version 2 du Framework, il est apparu la classe StopWatch qui permet de mesurer un intervalle de temps avec grande précision :
| ||
lien : Article de Webman lien : System.Diagnostics.StopWatch (MSDN) |
Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2010 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.