Partager via

Fichier de solution (.sln)

  • Article

Une solution est une structure permettant d’organiser des projets dans Visual Studio. La solution gère les informations d’état des projets dans deux fichiers :

  • .sln fichier (texte, partagé)

  • .suo fichier (options de solution spécifiques à l’utilisateur, binaires)

Pour plus d’informations sur les fichiers .suo, consultez Le fichier Options utilisateur de solution (.suo).

Si votre VSPackage est chargé en raison d’être référencé dans le .sln fichier, l’environnement appelle ReadSolutionProps à lire le .sln fichier.

Le .sln fichier contient des informations textuelles que l’environnement utilise pour rechercher et charger les paramètres nom-valeur pour les données persistantes et le projet VSPackages qu’il référence. Lorsqu’un utilisateur ouvre une solution, l’environnement passe par le preSolutionfichier , Projectet postSolution les informations dans le .sln fichier pour charger la solution, les projets au sein de la solution et toutes les informations persistantes attachées à la solution.

Le fichier de chaque projet contient des informations supplémentaires lues par l’environnement pour remplir la hiérarchie avec les éléments de ce projet. La persistance des données de hiérarchie est contrôlée par le projet. Les données ne sont normalement pas stockées dans le .sln fichier, bien que vous puissiez écrire intentionnellement des informations de projet dans le .sln fichier si vous choisissez de le faire. Pour plus d’informations sur la persistance, consultez Persistance du projet et ouverture et enregistrement d’éléments de projet.

En-tête de fichier

L’en-tête d’un .sln fichier ressemble à ceci :

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 16
VisualStudioVersion = 16.0.28701.123
MinimumVisualStudioVersion = 10.0.40219.1

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 17
VisualStudioVersion = 17.2.32505.173
MinimumVisualStudioVersion = 10.0.40219.1

Définitions

Microsoft Visual Studio Solution File, Format Version 12.00
En-tête standard qui définit la version du format de fichier.

# Visual Studio Version 16
La version principale de Visual Studio qui (récemment) a enregistré ce fichier de solution. Ces informations contrôlent le numéro de version dans l’icône de solution.

VisualStudioVersion = 16.0.28701.123
Version complète de Visual Studio qui (la plus récemment) a enregistré le fichier de solution. Si le fichier de solution est enregistré par une version plus récente de Visual Studio qui a la même version principale. Cette valeur n’est pas mise à jour afin de réduire l’activité dans le fichier.

MinimumVisualStudioVersion = 10.0.40219.1
Version minimale (la plus ancienne) de Visual Studio qui peut ouvrir ce fichier de solution.

Microsoft Visual Studio Solution File, Format Version 12.00
En-tête standard qui définit la version du format de fichier.

# Visual Studio Version 17
La version principale de Visual Studio qui (récemment) a enregistré ce fichier de solution. Ces informations contrôlent le numéro de version dans l’icône de solution.

VisualStudioVersion = 17.2.32505.173
Version complète de Visual Studio qui (la plus récemment) a enregistré le fichier de solution. Si le fichier de solution est enregistré par une version plus récente de Visual Studio qui a la même version principale. Cette valeur n’est pas mise à jour afin de réduire l’activité dans le fichier.

MinimumVisualStudioVersion = 10.0.40219.1
Version minimale (la plus ancienne) de Visual Studio qui peut ouvrir ce fichier de solution.

Corps du fichier

Le corps d’un .sln fichier se compose de plusieurs sections étiquetées GlobalSection, comme suit :

Project("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}") = "Project1", "Project1.vbproj", "{8CDD8387-B905-44A8-B5D5-07BB50E05BEA}"
EndProject
Global
  GlobalSection(SolutionNotes) = postSolution
  EndGlobalSection
  GlobalSection(SolutionConfiguration) = preSolution
       ConfigName.0 = Debug
       ConfigName.1 = Release
  EndGlobalSection
  GlobalSection(ProjectDependencies) = postSolution
  EndGlobalSection
  GlobalSection(ProjectConfiguration) = postSolution
   {8CDD8387-B905-44A8-B5D5-07BB50E05BEA}.Debug.ActiveCfg = Debug|x86
   {8CDD8387-B905-44A8-B5D5-07BB50E05BEA}.Debug.Build.0 = Debug|x86
   {8CDD8387-B905-44A8-B5D5-07BB50E05BEA}.Release.ActiveCfg = Release|x86
   {8CDD8387-B905-44A8-B5D5-07BB50E05BEA}.Release.Build.0 = Release|x86
  EndGlobalSection
  GlobalSection(ExtensibilityGlobals) = postSolution
  EndGlobalSection
  GlobalSection(ExtensibilityAddIns) = postSolution
  EndGlobalSection
EndGlobal

Pour charger une solution, l’environnement effectue la séquence de tâches suivante :

  1. L’environnement lit la section Globale du .sln fichier et traite toutes les sections marquées preSolution. Dans cet exemple de fichier, il existe une instruction de ce type :

    GlobalSection(SolutionConfiguration) = preSolution
     ConfigName.0 = Debug
     ConfigName.1 = Release

    Lorsque l’environnement lit la GlobalSection('name') balise, il mappe le nom à un VSPackage à l’aide du Registre. Le nom de clé doit exister dans le Registre sous [HKLM\\<Application ID Registry Root\>\SolutionPersistence\AggregateGUIDs]. La valeur par défaut des clés est le GUID de package (REG_SZ) du VSPackage qui a écrit les entrées.

  2. L’environnement charge vsPackage, appelle QueryInterface vsPackage pour l’interface IVsPersistSolutionProps et appelle la ReadSolutionProps méthode avec les données de la section afin que VSPackage puisse stocker les données. L’environnement répète ce processus pour chaque preSolution section.

  3. L’environnement effectue une itération au sein des blocs de persistance du projet. Dans ce cas, il y a un projet.

    Project("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}") = "Project1",
"Project1.vbproj", "{8CDD8387-B905-44A8-B5D5-07BB50E05BEA}"
EndProject

    Cette instruction contient le GUID de projet unique et le GUID de type de projet. Ces informations sont utilisées par l’environnement pour rechercher le fichier projet ou les fichiers appartenant à la solution, ainsi que le VSPackage requis pour chaque projet. Le GUID du projet est passé pour IVsProjectFactory charger le VSPackage spécifique lié au projet, puis le projet est chargé par VSPackage. Dans ce cas, le VSPackage chargé pour ce projet est Visual Basic.

    Chaque projet peut conserver un ID d’instance de projet unique afin qu’il soit accessible en fonction des besoins d’autres projets de la solution. Dans l’idéal, si la solution et les projets sont sous contrôle de code source, le chemin d’accès au projet doit être relatif au chemin de la solution. Lorsque la solution est chargée pour la première fois, les fichiers projet ne peuvent pas se trouver sur l’ordinateur de l’utilisateur. En ayant le fichier projet stocké sur le serveur par rapport au fichier solution, il est plus simple que le fichier projet soit trouvé et copié sur l’ordinateur de l’utilisateur. Il copie et charge ensuite le reste des fichiers nécessaires pour le projet.

  4. En fonction des informations contenues dans la section projet du .sln fichier, l’environnement charge chaque fichier projet. Le projet lui-même est ensuite chargé de remplir la hiérarchie de projet et de charger tous les projets imbriqués.

  5. Une fois que toutes les sections du .sln fichier sont traitées, la solution s’affiche dans Explorateur de solutions et est prête à être modifiée par l’utilisateur.

Si un projet dans la solution qui implémente VSPackage ne parvient pas à se charger, la OnProjectLoadFailure méthode est appelée et tous les projets de la solution ignorent les modifications qu’elle a apportées pendant le chargement. Pour toutes les erreurs d’analyse, autant d’informations que possible sont conservées avec les fichiers de solution. L’environnement affiche une boîte de dialogue indiquant à l’utilisateur que la solution est endommagée.

Lorsque la solution est enregistrée ou fermée, la QuerySaveSolutionProps méthode est appelée. Il est passé à la hiérarchie pour voir si des modifications ont été apportées à la solution qui doivent être entrées dans le .sln fichier. Une valeur Null, transmise à QuerySaveSolutionProps in VSQUERYSAVESLNPROPS, indique que les informations sont conservées pour la solution. Si la valeur n’est pas null, les informations persistantes concernent un projet spécifique, déterminée par le pointeur vers l’interface IVsHierarchy .

S’il existe des informations à enregistrer, l’interface IVsSolutionPersistence est appelée avec un pointeur vers la SaveSolutionProps méthode. La WriteSolutionProps méthode est ensuite appelée par l’environnement pour récupérer les paires nom-valeur à partir de IPropertyBag l’interface et écrire les informations dans le .sln fichier.

SaveSolutionProps et WriteSolutionProps les objets sont appelés de manière récursive par l’environnement pour récupérer les informations à enregistrer à partir de l’interface IPropertyBag jusqu’à ce que toutes les modifications aient été entrées dans le .sln fichier. De cette façon, vous pouvez vous assurer que les informations seront conservées avec la solution et disponibles la prochaine fois que la solution est ouverte.

Chaque VSPackage chargé est énuméré pour voir s’il a quelque chose à enregistrer dans le .sln fichier. Ce n’est qu’au moment du chargement que les clés de Registre sont interrogées. L’environnement connaît tous les packages chargés, car ils sont en mémoire au moment de l’enregistrement de la solution.

Seul le .sln fichier contient des entrées dans les sections et postSolution les preSolution sections. Il n’existe aucune section similaire dans le fichier .suo, car la solution a besoin de ces informations pour charger correctement. Le .suo fichier contient des options spécifiques à l’utilisateur, telles que des notes privées qui ne sont pas destinées à être partagées ou placées sous contrôle de code source.

Contenu connexe