70 votes

Utilisation efficace des propriétés de projet Visual Studio pour plusieurs projets et configurations

J'ai toujours utilisé Visual Studios construit en support de l'IHM graphique pour la configuration de mes projets, souvent à l'aide de feuilles de propriétés, de sorte que plusieurs projets d'utilisation d'un ensemble commun.

L'un de mes principaux problèmes avec c'est la gestion de plusieurs projets, les configurations et les plates-formes. Si vous venez de tout faire avec l'interface graphique principale (clic droit sur le projet -> propriétés), il devient rapidement un gâchis, difficile à maintenir et sujettes à des bugs (comme le défaut de correctement définir une macro, ou l'utilisation de la mauvaise exécution de la bibliothèque, etc). Traiter avec le fait que des personnes différentes y mettre les bibliothèques de dépendances à des endroits différents (par exemple le mien vivons tous "C:\Libs\[C,C++]\[lib-nom]\") et puis souvent de gérer les différentes versions de ces bibliothèques différemment (libération, le débogage, le x86, x64, etc) est également un gros problème car elle complique considérablement le temps de le mettre en place sur un nouveau système, et puis il y a des problèmes avec le contrôle de version et de garder tout le monde de chemins séparés...

Les feuilles de propriétés font un peu mieux, mais je ne peux pas avoir une feuille d'avoir des paramètres distincts pour les différentes configurations et les plates-formes (les menus déroulants, un grisé), résultant en moi avoir beaucoup de feuilles qui, si elle a hérité dans le bon ordre, faire ce que je veux ("x86", "x 64", "debug", "libération", "commun", "répertoires" (traite de l'été mentionné précédemment problème de dépendance par la définition de l'utilisateur macros comme BoostX86LibDir), etc) et si hérité dans le mauvais ordre (par exemple, "commune" avant "x64" et "debug") conduisent à des questions comme essayer de lier une mauvaise version de bibliothèque, ou mal de nommage de la sortie...

Ce que je veux, c'est un moyen de traiter avec toutes ces éparpillés dépendances et de la définition d'un ensemble de "règles", qui sont utilisés par tous mes projets dans la solution, comme les noms de la sortie de la bibliothèque comme "mylib-[vc90,vc100]-[x86,x64][-d].lib", sans avoir à faire tous ce que pour chaque projet, la configuration et la plate-forme, puis de les garder tous correctement synchronisés.

Je suis conscient de déplacement tout à fait différents systèmes comme CMake que de créer les fichiers nécessaires, cependant, ensuite, cela complique les choses d'ailleurs, en la rendant alors même que des tâches simples comme l'ajout d'un nouveau fichier au projet nécessite des modifications supplémentaires ailleurs, ce qui n'est pas quelque chose que je suis tout à fait heureux avec soit, à moins qu'il y est certains avec VS2010 intégration qui peut garder une trace de ces sortes de modifications.

82voto

Fire Lancer Points 8934

Je viens de découvrir quelque chose, je ne pense pas que a été possible (il n'est pas exposé par le GUI) qui permet de faire de la propriété de feuille de beaucoup plus utile. La "Condition" de l'attribut de la plupart des balises dans le projet de la propriété des fichiers et il peut être utilisé dans le .accessoires de fichiers!

Je viens de mettre ensemble ce qui suit comme un test et il a très bien fonctionné et a la tâche de 5 (commune,x64,x86,debug,release) séparer les feuilles de propriétés!

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Label="UserMacros">
    <!--debug suffix-->
    <DebugSuffix Condition="'$(Configuration)'=='Debug'">-d</DebugSuffix>
    <DebugSuffix Condition="'$(Configuration)'!='Debug'"></DebugSuffix>
    <!--platform-->
    <ShortPlatform Condition="'$(Platform)' == 'Win32'">x86</ShortPlatform>
    <ShortPlatform Condition="'$(Platform)' == 'x64'">x64</ShortPlatform>
    <!--toolset-->
    <Toolset Condition="'$(PlatformToolset)' == 'v90'">vc90</Toolset>
    <Toolset Condition="'$(PlatformToolset)' == 'v100'">vc100</Toolset>
  </PropertyGroup>
  <!--target-->
  <PropertyGroup>
    <TargetName>$(ProjectName)-$(Toolset)-$(ShortPlatform)$(DebugSuffix)</TargetName>
  </PropertyGroup>
</Project>

Seul problème est les propriétés de l'interface graphique cant handle, un projet qui utilise les biens ci-dessus la feuille de rapports simplement par défaut hérité de valeurs comme "$(ProjectName)" pour la cible.

28voto

lunicon Points 141

J'ai apporté des améliorations, peut être utile pour quelqu'un

 <?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Label="UserMacros">
    <!--IsDebug: search for 'Debug' in Configuration-->
    <IsDebug>$([System.Convert]::ToString( $([System.Text.RegularExpressions.Regex]::IsMatch($(Configuration), '[Dd]ebug'))))</IsDebug>

    <!--ShortPlatform-->
    <ShortPlatform Condition="'$(Platform)' == 'Win32'">x86</ShortPlatform>
    <ShortPlatform Condition="'$(Platform)' == 'x64'">x64</ShortPlatform>

    <!--build parameters-->
    <BUILD_DIR>$(registry:HKEY_CURRENT_USER\Software\MyCompany\@BUILD_DIR)</BUILD_DIR>
  </PropertyGroup>

  <Choose>
    <When Condition="$([System.Convert]::ToBoolean($(IsDebug)))">
      <!-- debug macroses -->
      <PropertyGroup Label="UserMacros">
        <MyOutDirBase>Debug</MyOutDirBase>
        <DebugSuffix>-d</DebugSuffix>
      </PropertyGroup>
    </When>
    <Otherwise>
      <!-- other/release macroses -->
      <PropertyGroup Label="UserMacros">
        <MyOutDirBase>Release</MyOutDirBase>
        <DebugSuffix></DebugSuffix>
      </PropertyGroup>
    </Otherwise>
  </Choose>

  <Choose>
    <When Condition="Exists($(BUILD_DIR))">
      <PropertyGroup Label="UserMacros">
        <MyOutDir>$(BUILD_DIR)\Bin\$(MyOutDirBase)_$(ShortPlatform)\</MyOutDir>
        <MyIntDir>$(BUILD_DIR)\Build\$(Configuration)_$(ShortPlatform)_$(PlatformToolset)\$(ProjectGuid)\</MyIntDir>
      </PropertyGroup>
    </When>
    <Otherwise>
      <PropertyGroup Label="UserMacros">
        <MyOutDir>$(SolutionDir)\Bin\$(MyOutDirBase)_$(ShortPlatform)\</MyOutDir>
        <MyIntDir>$(SolutionDir)\Build\$(Configuration)_$(ShortPlatform)_$(PlatformToolset)\$(ProjectGuid)\</MyIntDir>
      </PropertyGroup>
    </Otherwise>
  </Choose>

  <PropertyGroup>
    <OutDir>$(MyOutDir)</OutDir>
    <IntDir>$(MyIntDir)</IntDir>
<!-- some common for projects
    <CharacterSet>Unicode</CharacterSet>
    <LinkIncremental>false</LinkIncremental>
--> 
  </PropertyGroup>
</Project>
 

s'amuser!

12voto

Peon the Great Points 1069

J'ai eu la même douleur pour le produit de mon entreprise (+de 200 projets) avant. La façon dont je l'ai résolu est de construire une belle hiérarchie des feuilles de propriétés.

Les projets hérite de la propriété de feuille de par son type de sortie, dire x64.Debug.Dynamique.De la bibliothèque.vsprops. Cette vsprops fichier hérite simplement d'autres feuilles de propriétés à l'aide de l'attribut InheritedPropertySheets

<VisualStudioPropertySheet
    ProjectType="Visual C++"
    Version="8.00"
    Name="x64.Debug.Dynamic.Binary"
    InheritedPropertySheets=".\Common.vsprops;.\x64.vsprops;.\Debug.vsprops;.\Runtime.Debug.Dynamic.vsprops;.\Output.x64.Library.vsprops"
    >

Vous pouvez également utiliser des variables (c'est à dire UserMacro, dont la valeur peut être absolue ou même des variables d'environnement) dans les feuilles de propriétés pour personnaliser beaucoup de choses en fonction de votre besoin. Par exemple, la définition d'un BIN dans la variable Debug.vsprops

<UserMacro name="BIN" Value="Debug" />

ensuite, lorsque vous définissez le nom de la sortie de la série de vsprops, disons, de Sortie.x64.De la bibliothèque.vsprops

<VisualStudioPropertySheet
    ProjectType="Visual C++"
    Version="8.00"
    OutputDirectory="$(BIN)"
>

L' $(BIN) variable sera étendu à ce qui a été défini (dans ce cas, le Débogage). Utilisez cette technique, vous pouvez facilement construire une agréable hiérarchie des feuilles de propriétés pour répondre à votre demande.

Maintenant, il ya une chose que vous voulez faire: construire vos propres modèles de projet qui utilise votre feuille de propriétés définies. La vraie difficulté est de faire respecter la bonne utilisation des modèles et des feuilles de propriétés. Mon expérience personnelle est que, même si tout est configuré, quelqu'un va encore oublier d'utiliser le modèle pour créer de nouveaux projets ...

5voto

Haw-Bin Points 168

Je viens de déposer un bogue sur Connect pour rendre les conditions configurables via l'interface graphique. Votez pour ça!

https://connect.microsoft.com/VisualStudio/feedback/details/634614

4voto

ngoozeff Points 2360

Aussi loin que la sortie de la bibliothèque, vous pouvez sélectionner l'ensemble de vos projets, puis afficher les pages de propriétés, sélectionnez Toutes les Configurations, Toutes les plates-formes et ensuite définir le Nom de la Cible:

$(ProjectName)-$(PlatformToolset)-$(PlatformShortName)-$(Configuration)

qui donnerait une sortie comme mylib-v100-x86-Debug.lib

Nous faisons quelque chose de semblable pour plus d'Bibliothèque des Répertoires ainsi, à l'aide de $(PlatformName) et #(Configuration) de choisir le droit de la bibliothèque des chemins, même si cela signifie que certains de déconner avec la configuration initiale de bibliothèques. par exemple, nous avons boost installer les libs d' boost/lib.Win32 ou boost/lib.x64.


En ce qui concerne les bibliothèques, et les gens de l'installer dans des endroits différents, il ya un couple d'options. Si vous avez une très solide système de contrôle de source, vous pouvez juste mettre tout dans le contrôle de code source, vivant dans un dossier libs à côté de votre source. Qui probablement ne fonctionnera pas si vous utilisez plus d'un peu de bibliothèques, ou si elles sont particulièrement grandes.

L'autre option qui vient à l'esprit est de définir une variable d'environnement sur chaque ordinateur de l'utilisateur qui pointe à la racine de leurs bibliothèques de dossier, par exemple, LIB_ROOT=c:\libraries, et vous pouvez ensuite y accéder que dans Visual Studio $(LIB_ROOT).

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X