2010-06-20 10 views
11

Tengo una solución C++ en VS2008 con múltiples proyectos. Esta solución contiene archivos que se necesitan en el tiempo de ejecución, que se cargan de acuerdo con una ruta relativa al directorio de la solución (por ejemplo, "Testing/data/" + "dataN.bin").Cambiar el "directorio de depuración/trabajo" globalmente (no por usuario) en VS2008

Para que esta solución funcione, debo establecer el directorio de trabajo establecer en el proyecto (s) de manera que se haga referencia al directorio solución (por ejemplo Configuration Properties >> Debugging >> Working Directory = $(SolutionDir)). Esto funciona bien cuando estoy depurando en mi propia PC. Sin embargo, cuando un usuario diferente carga mi solución, sus proyectos no tienen esta propiedad establecida correctamente.

He rastreado esta configuración para no almacenarla en el archivo de proyecto (PROJECT.vcproj), sino en el archivo específico del usuario creado para él (PROJECT.vcproj.DOMAIN.USER.user).

Me gustaría una forma de almacenar esta configuración para TODOS los usuarios, sin tener que configurarla una y otra vez.

Mis pensamientos fueron:

  • encontrar una manera de tienda esta en el archivo .vcproj (no el específico del usuario) o el archivo de solución.
  • Busque la manera de crear un "archivo predeterminado específico del usuario", desde el cual se iniciarán todas las configuraciones específicas del usuario (y se pueden modificar posteriormente).

Sin embargo, no encontré la manera de hacer ninguno de estos.

Un poco más notas/restricciones:

  • tengo que trabajar con muchos archivos de gran tamaño, ya que estos recursos, por lo tanto, me gustaría evitar la realización de copias a diferentes directorios.
  • Las soluciones deben admitir varias configuraciones de compilación (depuración, lanzamiento, etc.).
  • Me gustaría evitar los scripts de compilación pre/post si es posible, para mantener las cosas claras (baja prioridad).

Cualquier ayuda será apreciada ... gracias de antemano.

Respuesta

4

No existe tal propiedad. Hay problemas mayores, esto también debe funcionar después de implementar su solución. El directorio de trabajo no será un directorio de "solución", no hay uno en la máquina de destino.

Es mucho mejor que trabaje asumiendo que el directorio de trabajo es el mismo que el directorio EXE. Ese será el valor predeterminado tanto durante la depuración como en la máquina de destino. Usted tiene control total sobre la ubicación del archivo EXE con una configuración de enlazador. Y puede protegerse de un atajo ejecutando su programa con otro directorio de trabajo obteniendo el directorio EXE en su código para que pueda generar una ruta absoluta. Use GetModuleFileName(), pase NULL para obtener la ruta al archivo EXE.

Otra solución estándar es copiar cualquier tipo de recursos que el EXE necesita a una carpeta que es relativa desde la carpeta de salida de compilación. Esto se hace con un evento Pre-Construcción, hacen que la línea de comandos un aspecto similar a este:

if not exist "$(OutDir)\Testing" md "$(OutDir)\Testing" 
xcopy /d /s "$(SolutionDir)\Testing\*.*" "$(OutDir)\Testing 

Nota cómo la opción/d asegura que la copia se realiza sólo si el contenido de la carpeta de pruebas cambió.

+0

Copiando recursos: Esto podría hacer el truco, sin embargo, tengo cantidades masivas de recursos para copiar (en este caso, vectores de prueba grandes), y sería una pérdida de tiempo y memoria para copiarlos cada vez. Además, tengo varias configuraciones de compilación (versión, depuración, ...), lo que provocará una mayor duplicación que deseo evitar. Tiene sentido que estos vectores estén en el directorio raíz "solución", ya que estos datos son utilizados por múltiples proyectos (de diferentes maneras). Además, me gustaría mantener el orden en la lista de archivos de la solución (con respecto a la estructura del directorio). – scooz

+0

Por otro lado, copiar el resultado ejecutable en el directorio raíz de la solución no solo causará un problema en el directorio raíz, sino que no admitirá adecuadamente varias configuraciones de compilación (mantendrá los archivos con el mismo nombre, etc.). Parece que para fines de depuración, lo más lógico es cambiar el directorio de trabajo. En cuanto a los problemas de implementación que mencionaste (con los que estoy de acuerdo), prefiero complicar las cosas allí que al depurar (ya que utilizo menos veces que la depuración) – scooz

+0

Es por eso que señalé el comportamiento de la opción xcopy/d. Solo está pagando por la copia una vez. –

0

Me pregunto si esto sería posible ya que un usuario podría no tener suficientes derechos para acceder y leer/escribir en el directorio, supongo que VS verifica si un usuario tiene acceso a un directorio cuando lo eliges. es solo una opción basada en la cuenta.

1

Puede considerar el uso de 'Propiedades de configuración/General/Output Directory', o 'Propiedades de configuración/Linker/Output file', en lugar de la configuración 'Depurador/directorio de trabajo'. Estas configuraciones son por proyecto y no por usuario, y si deja intacto el directorio de trabajo , este es el valor predeterminado para el directorio de trabajo de la aplicación.

+0

Si las cosas no salen a mi manera, voy a tener que ir por este camino a pesar de mi voluntad para evitar esto (ver mi comentario a la respuesta de Hans Passant). ¿No fue este comportamiento diferente en versiones anteriores de Visual Studio (por ejemplo, 2005)? – scooz

10
  1. Configurar la configuración de depuración como de costumbre (configurar el directorio de trabajo, los parámetros establecidos etc ...), pero usar sólo rutas relativas, las variables. NO use rutas absolutas como D: \ MyProject \ libs
  2. Guarde su solución y luego cierre Visual Studio.
  3. ir a su directorio del proyecto y encontrar PROJECT.vcproj.COMPUTERNAME.USER.user
  4. Cambiar nombre de a PROJECT.vcproj.user (Este archivo será la configuración de depuración genérica, es posible que lo cometen para controlar el origen)
  5. Abra Visual Studio, realice las adiciones adicionales a la configuración de depuración si es necesario. (Mas información se almacenará en el archivo PROJECT.vcproj.COMPUTERNAME.USER.user que es específico para usted. Tenga en cuenta que PROJECT.vcproj.COMPUTERNAME.USER.user anulará configuración heredada)

proyecto de ejemplo. vcproj.user archivo se proporciona a continuación

<?xml version="1.0" encoding="Windows-1252"?> 
<VisualStudioUserFile 
    ProjectType="Visual C++" 
    Version="9,00" 
    ShowAllFiles="false" 
    > 
    <Configurations> 
     <Configuration 
      Name="Release|Win32" 
      > 
      <DebugSettings 
       Command="$(ProjectDir)..\Deploy\$(ConfigurationName)\$(TargetFileName)" 
       WorkingDirectory="$(ProjectDir)..\Deploy\$(ConfigurationName)\" 
       CommandArguments="" 
       Attach="false" 
       DebuggerType="3" 
       Remote="1" 
       RemoteMachine="LOCALHOST" 
       RemoteCommand="" 
       HttpUrl="" 
       PDBPath="" 
       SQLDebugging="" 
       Environment="" 
       EnvironmentMerge="true" 
       DebuggerFlavor="0" 
       MPIRunCommand="" 
       MPIRunArguments="" 
       MPIRunWorkingDirectory="" 
       ApplicationCommand="" 
       ApplicationArguments="" 
       ShimCommand="" 
       MPIAcceptMode="" 
       MPIAcceptFilter="" 
      /> 
     </Configuration> 
     <Configuration 
      Name="Debug|Win32" 
      > 
      <DebugSettings 
       Command="$(ProjectDir)..\Deploy\$(ConfigurationName)\$(TargetFileName)" 
       WorkingDirectory="$(ProjectDir)..\Deploy\$(ConfigurationName)\" 
       CommandArguments="" 
       Attach="false" 
       DebuggerType="3" 
       Remote="1" 
       RemoteMachine="LOCALHOST" 
       RemoteCommand="" 
       HttpUrl="" 
       PDBPath="" 
       SQLDebugging="" 
       Environment="" 
       EnvironmentMerge="true" 
       DebuggerFlavor="0" 
       MPIRunCommand="" 
       MPIRunArguments="" 
       MPIRunWorkingDirectory="" 
       ApplicationCommand="" 
       ApplicationArguments="" 
       ShimCommand="" 
       MPIAcceptMode="" 
       MPIAcceptFilter="" 
      /> 
     </Configuration> 
    </Configurations> 
</VisualStudioUserFile> 
+2

Parece que puede eliminar todos las propiedades excepto WorkingDirectory si ese es el único que desea establecer un valor predeterminado para – Joe

Cuestiones relacionadas