Concepts de ressources communes

On retrouve la plupart des aspects de programmation avec le .NET Framework pour tous les langages compatibles, parce que chaque compilateur de langage pris en charge produit du code MSIL (MicroSoft Intermediate Language) managé et auto-descriptif. L'exécution de tout le code MSIL managé avec le Common Language Runtime fournit une intégration interlangage, une gestion automatique de la mémoire, une gestion d'exception interlangage, un niveau élevé de sécurité et un modèle simplifié pour l'interaction des composants. En plus du runtime, le .NET Framework comprend la bibliothèque de classes .NET Framework, accessible par tout langage compatible avec .NET. Plusieurs aspects de ce processus de développement commun sont particulièrement importants lors de la génération d'applications utilisant des ressources.

Blocs de construction

Les bibliothèques de classes .NET Framework créées par vous ou d'autres personnes sont également organisées dans des espaces de noms hiérarchiques et stockées dans des fichiers exécutables portables (PE), généralement des fichiers DLL et EXE. Vous pouvez stocker plusieurs espaces de noms (y compris des espaces de noms imbriqués) dans un fichier PE ou fractionner un espace de noms sur plusieurs fichiers PE. Un ou plusieurs fichiers PE (et éventuellement d'autres types de fichiers tels que des ressources) sont combinés pour créer un assembly, qui est une unité physique qui peut être déployée, réutilisée et à laquelle un numéro de version peut être affecté. Le runtime utilise des assemblys pour trouver les types référencés et établir une liaison avec eux. Les ressources peuvent également être liées dans des assemblys ou empaquetées séparément dans plusieurs formats différents. Elles peuvent même, au besoin, être utilisées comme des fichiers individuels (comme des images JPEG). Les informations concernant les éléments présents dans un assembly, notamment les classes et les ressources, figurent dans le manifeste de l'assembly.

Cultures

Dans le .NET Framework, la culture fait référence à la langue de l'utilisateur, éventuellement combinée à l'emplacement de cet utilisateur. En spécifiant une culture, il est possible d'utiliser un ensemble de préférences communes pour certaines informations — telles que les chaînes, les formats de date et de nombres — qui correspondent à la langue de l'utilisateur et aux conventions de l'emplacement.

L'emplacement peut être un pays ou une région. La région peut être le terme géopolitiquement correct d'un emplacement où un pays n'est pas officiellement reconnu. La langue et l'emplacement peuvent être spécifiés par code défini dans le document Internet RFC (Requests For Comments) 1766, intitulé « Tags for the Identification of Languages ». Les codes sont eux-mêmes définis par deux normes ISO : ISO 639, « Code for the representation of names of languages » et ISO 3166, « Codes for the representation of names of countries ». Consultez la rubrique, « Balises de langue et de région/pays » de l'annexe A : Informations supplémentaires sur les ressources pour obtenir des informations de référence supplémentaires sur ces normes.

Des préférences de culture détaillées sont accessibles à l'aide d'instances de la classe CultureInfo, elles-mêmes accessibles à l'aide de balises de culture. Les balises de culture utilisent le format primaire[-secondaire], où la balise primaire représente la langue et la balise secondaire, facultative, représente le code du pays ou de la région. Par convention, la balise de langue se compose de deux lettres en minuscules, et la balise du pays ou de la région de deux lettres en majuscules. Le tableau suivant donne des exemples de balises de culture.

Dans le .NET Framework, les balises de deux lettres indiquent des cultures neutres de langue uniquement, comme de pour l'allemand. Les balises de quatre lettres indiquent des cultures spécifiques, comme fr-CA pour le français parlé au Canada. Dans la plupart des cas, l'interface utilisateur est spécifiée comme culture spécifique. Cependant, dans certains cas, comme ja-JP pour le japonais du Japon, il n'existe qu'une seule culture spécifique pour une culture neutre particulière. Dans ce cas, les deux balises sont souvent utilisées indifféremment. S'il est nécessaire qu'une application puisse attribuer à une culture la valeur d'une culture spécifique — en réponse à un paramètre de navigateur Internet, par exemple — l'application doit mapper toutes les cultures neutres aux cultures spécifiques correspondantes à l'aide de la méthode CreateSpecificCulture.

Dans le .NET Framework la culture remplace le paramètre régional NSL (National Language Support), qui utilisait un système de codes d'ID de paramètres régionaux (LCID, LoCal ID). La propriété LCID de la classe CultureInfo offre une interopérabilité et facilite l'intégration avec les logiciels basés sur NLS.

Classes de ressources .NET

La bibliothèque de classes du .NET Framework offre plusieurs classes qui aident les développeurs à utiliser les ressources avec leurs applications et outils.

ResourceManager, classe

La classe ResourceManager (dans l'espace de noms System.Resources) offre un accès pratique au ressources correctes de culture au moment de l'exécution. Cette classe fournit une solution de secours pour les ressources (généralement vers la culture neutre) lorsqu'une ressource localisée n'existe pas, prend en charge la sérialisation des ressources et fournit la méthode CreateFileBasedResourceManager permettant d'accéder à des ressources qui ne sont pas empaquetées dans votre assembly. Les développeurs peuvent bien sûr également dériver des classes de ResourceManager lors de la création de solutions de ressources personnalisées.

ResourceWriter, classe

La classe ResourceWriter (dans l'espace de noms System.Resources) écrit des ressources dans le format par défaut du système dans un flux ou un fichier de sortie. Les ressources sont spécifiées en tant que paires nom-valeur, à l'aide de la méthode AddResource. Les noms de ressources respectent la casse lorsqu'ils sont utilisés pour des recherches, mais ResourceWriter n'écrit pas de nom de ressource dans un fichier .resources si ce nom ne diffère que par la casse. La classe ResourceWriter fournit une implémentation par défaut de l'interface IResourceWriter. De plus, elle peut être substituée par le développeur.

**Remarque   **Les ressources ne sont pas forcément écrites dans l'ordre dans lequel elles ont été ajoutées par programme.

ResourceReader, classe

La classe ResourceReader (dans l'espace de noms System.Resources) énumère des flux et des fichiers .resources et lit les paires nom-valeur de ressources séquentielles. Cette classe fournit une implémentation par défaut de l'interface IResourceReader. De plus, elle peut être substituée par le développeur, comme la classe ResourceWriter.

ResourceSet, classe

La classe ResourceSet (dans l'espace de noms System.Resources) stocke toutes les ressources localisées pour une culture particulière. Toutes les ressources sont immédiatement chargées dans la mémoire. Contrairement à ResourceManager, ResourceSet n'effectue pas de secours. ResourceSet est donc avant tout utile lors de la création d'outils et d'utilitaires, mais pas dans des applications localisées. La classe ResourceSet peut également être utilisée pour contrôler la mise en cache des ressources (par exemple, pour éviter la mise en cache d'images).

CultureInfo, classe

La classe CultureInfo (dans l'espace de noms System.Globalization) ne contient qu'un ensemble d'informations sur les préférences de l'utilisateur, qui dépend de la langue, sous-langue, pays/région et conventions culturelles de l'utilisateur. Cette classe est utilisée pour mettre en forme les dates, l'heure et les nombres, trier les chaînes et déterminer le choix de la langue pour le texte.

RegionInfo, classe

La classe RegionInfo (dans l'espace de noms System.Globalization) est utilisée pour déterminer l'unité de mesure et mapper les codes de région aux noms de région.

Assembly.GetManifestResourceStream, méthode

La méthode Assembly.GetManifestResourceStream (dans l'espace de noms System.Reflection) charge directement les données de ressource de manifeste dans un flux. Ceci est particulièrement utile lorsque des ressources sont stockées dans des formats personnalisés que ResourceManager n'est pas capable de comprendre en mode natif.

**Remarque   **Pour utiliser la méthode Assembly.GetManifestResourceStream, les ressources doivent être dans un assembly.

Thread.CurrentUICulture, propriété

La propriété Thread.CurrentUICulture (dans l'espace de noms System.Threading) est utile lorsqu'il est nécessaire de déterminer la culture actuelle ou, plus important, pour définir la culture de façon à émuler l'exécution sur une version localisée différente de Windows. Ceci est nécessaire car le Panneau de configuration ne peut pas afficher plusieurs LCID d'interface utilisateur dans une version de Windows 2000 ne disposant pas d'interface utilisateur multilingue. En revanche, la culture peut être définie par programme au moment de l'exécution, par thread.

Déploiement

Dans le cas le plus simple, un fichier exécutable .NET Framework autonome peut être exécuté localement à partir de n'importe quel ordinateur sur lequel est installé le Common Language Runtime. Aucune autre action n'est nécessaire — Aucune entrée de Registre n'est effectuée ; rien ne peut bloquer une autre application ni la faire s'interrompre, et supprimer le fichier (si celui-ci est copié de façon locale) suffit à nettoyer l'application et à ne laisser aucune trace sur l'ordinateur. Les applications exécutées à partir d'une URL représentant un site Web ont un comportement légèrement différent. Dans de tels cas, les assemblys sont installés dans le cache de téléchargement et sont automatiquement nettoyés ultérieurement. Toutes les autres applications, y compris celles d'une URL représentant un fichier, sont exécutées à partir du code source et ne sont pas mises en cache sur l'ordinateur local.

Distribution

Bien évidemment, la plupart des applications clientes seront encore empaquetées dans un format de distribution courant, tel qu'un fichier .cab ou .msi, et un grand nombre d'entre elles seront installées à l'aide de mécanismes de distribution d'applications tels que Windows 2000 IntelliMirror ou SMS (Systems Management Server), qui utilisent tous les deux la technologie Microsoft Installer. Pour plus d'informations sur Microsoft Installer, consultez la section correspondante du Kit de développement Microsoft Win32 SDK.

Voir aussi

Création de ressources | Extraction de ressources à l'aide de code | Résumé des ressources | Annexe A : Informations supplémentaires sur les ressources | Annexe B : Outils pour les ressources