c++ - valido - uno o varios proyectos de la solucion no se cargaron correctamente visual studio

Usar las propiedades del proyecto de Visual Studio de manera efectiva para múltiples proyectos y configuraciones (6)

Siempre utilicé Visual Studios con soporte de GUI para configurar mis proyectos, a menudo usando hojas de propiedades para que varios proyectos usen un conjunto común.

Uno de mis problemas principales con esto es administrar múltiples proyectos, configuraciones y plataformas. Si solo hace todo con la GUI principal (haga clic derecho en el proyecto -> propiedades) rápidamente se convierte en un desastre, difícil de mantener y propenso a errores (como fallar al definir correctamente alguna macro, o usar la biblioteca de tiempo de ejecución incorrecta, etc.). Lidiar con el hecho de que diferentes personas colocan bibliotecas de dependencia en diferentes lugares (por ejemplo, las mías viven en "C: / Libs / [C, C ++] / [lib-name] /") y luego suelen administrar las diferentes versiones de esas bibliotecas de manera diferente también (versión, depuración, x86, x64, etc.) es también un gran problema, ya que complica enormemente el tiempo para configurarlo en un sistema nuevo, y luego hay problemas con el control de versiones y mantiene separadas las rutas de todos. .

Las hojas de propiedad lo hacen un poco mejor, pero no puedo tener una hoja con configuraciones separadas para diferentes configuraciones y plataformas (los cuadros desplegables aparecen en gris), lo que me da muchas hojas que si se heredan en el orden correcto hago lo que quiero ( "x86", "x64", "debug", "release", "common", "directories" (se ocupa del problema de dependencia mencionado anteriormente mediante la definición de macros de usuario como BoostX86LibDir), etc.) y si se heredan en el orden incorrecto (p. ej. "común" antes de "x64" y "depuración") conducen a problemas como intentar vincular una versión de biblioteca incorrecta o nombrar el resultado incorrectamente ...

Lo que quiero es una forma de lidiar con todas estas dependencias dispersas y configurar un conjunto de "reglas" que todos mis proyectos utilicen en la solución, como nombrar una biblioteca de salida como "mylib- [vc90, vc100] - [x86] , x64] [- d] .lib ", sin tener que hacer todo esto para cada proyecto individual, configuración y combinación de plataforma, y luego mantener todos sincronizados correctamente.

Soy consciente de cambiar a sistemas completamente diferentes como CMake que crean los archivos necesarios, sin embargo, esto complica las cosas en otros lugares, por lo que incluso tareas simples como agregar un nuevo archivo al proyecto requieren cambios adicionales en otro lugar, que no es algo que yo soy totalmente satisfecho con cualquiera de los dos, a menos que haya alguno con integración VS2010 que pueda realizar un seguimiento de este tipo de cambios.

Descubrí algo que no creía posible (no está expuesto por la GUI) que ayuda a que la hoja de propiedades sea mucho más útil. El atributo "Condición" de muchas de las etiquetas en los archivos de propiedades del proyecto y también se puede usar en los archivos .props.

Simplemente armé lo siguiente como una prueba y funcionó de maravilla e hice la tarea de 5 hojas de propiedades (comunes, x64, x86, depurar, liberar).

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

El único problema es que las propiedades GUI no pueden manejarlo, un proyecto que usa la hoja de propiedades anterior solo informa valores heredados predeterminados como "$ (ProjectName)" para el destino.

En cuanto a la biblioteca de salida, puede seleccionar todos sus proyectos, luego abrir las páginas de propiedades, seleccionar Todas las configuraciones, Todas las plataformas y luego establecer el Nombre de destino en:

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

que daría un resultado como mylib-v100-x86-Debug.lib

También hacemos algo similar a esto para los directorios de biblioteca adicional, usando $(PlatformName) y #(Configuration) para seleccionar las rutas de acceso de la biblioteca correctas, aunque eso significa un poco de confusión con la configuración inicial de las bibliotecas. Por ejemplo, hemos boost/lib.Win32 instalación de sus libs para boost/lib.Win32 o boost/lib.x64 .

Con respecto a las bibliotecas, y las personas que las instalan en diferentes lugares, hay un par de opciones. Si tiene un sistema de control de fuente muy robusto, puede poner todo en control de fuente, viviendo en una carpeta libs al lado de su fuente. Eso probablemente no funcionará si usa más que algunas bibliotecas, o si son particularmente grandes.

La otra opción que me viene a la mente es establecer una variable de entorno en cada máquina de usuario que apunta a la raíz de la carpeta de las bibliotecas, por ejemplo LIB_ROOT=c:/libraries , y luego puede acceder a eso en Visual Studio como $(LIB_ROOT) .

Es posible crear una hoja de propiedades separada para cada configuración. Para hacer esto:

Crear una hoja de propiedades específica de la configuración
Abra el administrador de la propiedad
Haga clic con el botón derecho en la configuración (no en el proyecto) que desea modificar
Haga clic en "Agregar hoja de propiedades existente" y agregue su hoja

Esto lo alivia de insertar condiciones en una sola hoja para múltiples configuraciones. Si tiene algunos atributos comunes que le gustaría compartir entre las configuraciones, cree una jerarquía. La hoja superior se puede usar en todas las configuraciones y las hojas anidadas solo contendrán el atribut específico de la configuración

Hice algunas mejoras, puede ser útil para alguien

<?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup Label="UserMacros">  <IsDebug>$([System.Convert]::ToString( $([System.Text.RegularExpressions.Regex]::IsMatch($(Configuration), ''[Dd]ebug''))))</IsDebug>  <ShortPlatform Condition="''$(Platform)'' == ''Win32''">x86</ShortPlatform> <ShortPlatform Condition="''$(Platform)'' == ''x64''">x64</ShortPlatform>  <BUILD_DIR>$(registry:HKEY_CURRENT_USER/Software/MyCompany/@BUILD_DIR)</BUILD_DIR> </PropertyGroup> <Choose> <When Condition="$([System.Convert]::ToBoolean($(IsDebug)))">  <PropertyGroup Label="UserMacros"> <MyOutDirBase>Debug</MyOutDirBase> <DebugSuffix>-d</DebugSuffix> </PropertyGroup> </When> <Otherwise>  <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>  </PropertyGroup> </Project>

¡que te diviertas!

Parece que valdría la pena echarle un vistazo a una herramienta de compilación: en mi lugar, utilizamos una herramienta personalizada que mira archivos y proyectos para cambios y calcula las dependencias y el orden de compilación. Agregar un nuevo archivo no es gran cosa: la compilación se realiza con msbuild.

Si tuviera que compilar más que un montón de proyectos, usaría algo como nant: http://nant.sourceforge.net/

Ya tuve el mismo dolor por el producto de mi empresa (más de 200 proyectos). La forma en que lo resolví fue construir una buena jerarquía de las hojas de propiedades.

Los proyectos heredan la hoja de propiedades por su tipo de salida, digamos x64.Debug.Dynamic.Library.vsprops. Este archivo vsprops simplemente hereda otras hojas de propiedades utilizando el atributo 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" >

También puede usar variables (es decir, UserMacro, cuyo valor puede ser absoluto o incluso variables de entorno) en las hojas de propiedades para personalizar muchas cosas en función de sus necesidades. Por ejemplo, definir una variable BIN en Debug.vsprops

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

luego cuando configura el nombre de salida en la serie de vsprops, por ejemplo, Output.x64.Library.vsprops

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

La variable $ (BIN) se expandirá a lo que se ha establecido (en este caso, Depurar). Utilice esta técnica para construir fácilmente una buena jerarquía de hojas de propiedades para satisfacer su demanda.

Ahora hay una cosa más que podría desear hacer: crear sus propias plantillas de proyectos que utilicen su conjunto de planos de propiedades. La parte realmente difícil es hacer cumplir el uso adecuado de las plantillas y hojas de propiedades. Mi experiencia personal es que incluso si todo está configurado, alguien aún olvidará usar la plantilla para crear nuevos proyectos ...