J'ai une solution C ++ dans VS2008 avec plusieurs projets. Cette solution contient des fichiers nécessaires au moment de l'exécution, qui sont chargés en fonction d'un chemin Pour que cette solution fonctionne, je dois définir le paramètre de répertoire de travail dans le (s) projet (s) de sorte qu'il indique le répertoire de solution (par exemple, J'ai tracé ce paramètre à enregistrer non pas dans le fichier de projet ( Mes pensées étaient:
Cependant, je n'ai pas trouvé de moyen de faire l'un ou l'autre.
Quelques notes / contraintes supplémentaires:
Toute aide sera appréciée ... Merci d'avance. "test / données /" + "datan.bin" ).
Propriétés de configuration >> Débogage >> Répertoire de travail = $ (solutiondir) ). Cela fonctionne bien lorsque je débrouge sur mon propre PC. Cependant, lorsqu'un utilisateur différent charge ma solution, ses projets ne disposent pas de cette propriété correctement.
projet.vcproj ), mais dans le fichier spécifique à l'utilisateur créé pour celui-ci ( projet.vcproj.domain.utilisateur .User ).
4 Réponses :
Je me demande si cela serait possible, car un utilisateur pourrait ne pas avoir suffisamment de droits d'accès et de lecture / écriture dans le répertoire, je suppose que VS vérifie si un utilisateur a accès à un répertoire lorsque vous le choisirez probablement pourquoi il y a probablement pourquoi il y a probablement pourquoi il y a seule une option basée sur un compte.
Vous pouvez envisager d'utiliser l'utilisation de «propriétés de configuration / répertoire général / de sortie» ou «fichier de configuration / fichier de liaison / de sortie», au lieu du paramètre 'Debugger / The Directory' '. Ces paramètres sont Per-Project et non par utilisateur, et si vous quittez le répertoire de travail INTACT Ceci est la valeur par défaut du répertoire de travail de l'application.
Si les choses ne vont pas mon chemin, je devrais peut-être aller de cette façon malgré ma volonté d'éviter cela (voir mon commentaire à la réponse de Hans Passant). Ce comportement n'a-t-il pas été différent dans les versions précédentes de Visual Studio (par exemple 2005)?
Aucune propriété de ce type n'existe. Il y a de plus grandes questions, cela doit également fonctionner après avoir déployé votre solution. Le répertoire de travail ne va pas être un répertoire "solution", il n'y en a pas sur la machine cible.
Vous êtes bien mieux de travailler à partir de l'hypothèse que le répertoire de travail est identique au répertoire EXE. Ce sera la valeur par défaut tout en débogage et sur la machine cible. Vous avez le contrôle total sur l'emplacement du fichier EXE avec un paramètre de lieur. Et vous pouvez vous protéger d'un raccourci exécutant votre programme avec un autre répertoire de travail en obtenant le répertoire EXE dans votre code afin que vous puissiez générer un chemin absolu. Utilisez GetModuleFileName (), Pass NULL pour obtenir le chemin d'accès au fichier EXE.
Une autre solution standard consiste à copier tout type de ressources dont l'EXE a besoin dans un dossier qui est relatif du dossier de sortie. Vous faites cela avec un événement de pré-construction, rendez la ligne de commande similaire à celle-ci: notez comment l'option / D garantise que la copie n'est effectuée que si le dossier de test Contenu a changé.
Copier les ressources: Cela ferait l'affaire, mais j'ai des quantités massives de ressources à copier (dans ce cas, de grands vecteurs de test), et ce serait une perte de temps et de mémoire pour les copier à chaque fois. De plus, j'ai plusieurs configurations de construction (version, débogage, ...), ce qui entraînera une nouvelle duplication que je souhaite éviter. Il est logique que ces vecteurs soient dans le répertoire "Solution" de la racine, car ces données sont utilisées par plusieurs projets (de différentes manières). De plus, j'aimerais maintenir l'ordre dans la liste des fichiers de la solution (concernant la structure de répertoire).
Sur le côté bascule, la copie du résultat exécutable au répertoire de solution racine ne causera pas seulement un gâchis sur le répertoire racine, mais il ne prendra pas correctement en charge plusieurs configurations de construction (conservera des fichiers de la même nom, etc.). Il semble que, à des fins de débogage, la chose la plus logique à faire est de modifier le répertoire de travail. En ce qui concerne les problèmes de déploiement que vous avez soulevés (que je suis d'accord avec), je préférerais compliquer les choses que lors du débogage (depuis que je déploie moins souvent que je débogène)
C'est pourquoi j'ai souligné le comportement de l'option XCopy / D. Vous ne payez qu'une seule fois pour la copie.
Vrai, mais cela me demande toujours de copier des trucs. Nous parlons de gigaoctets de données ici ... :)
Placez les données dans un répertoire situé au même niveau que les répertoires par configuration pour les exécutables. Ensuite, faites-vous référence à vos données à l'aide d'un chemin comme .. \ Data relatif à votre exécutable.
Ce n'est pas exactement ce que je voulais, mais je suppose que je vais aller avec la suggestion d'Oefe ... merci à tout le monde.
@Hanspassant ce que vous suggère est absolument important car la construction d'un répertoire de déploiement de temps de développement résout de nombreux problèmes de ressources avant de se produire. Cependant, dans un très gros projet, cela devient lourd. (Dans notre projet, vérifiez même si XCopy est requis coûte 5 secondes). Mais il y a une solution à ce que @scooz a demandé existe. S'il vous plaît mettre à jour votre message.
@Vah - non. Postez votre propre réponse à cette question.
Configurez les paramètres de débogage, fermer vs2008, renommez project.vcproj.domain.user.user to projet.vcproj.user . project.vcproj.domain.user.user et projet.vcproj.user peut coexister et project.vcproj.domain.user.user remplace < B> Project.vcproj.user
exemple de projet.vcproj.user est fourni ci-dessous P>
<?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>
Il semble que vous puissiez supprimer toutes les propriétés, sauf WorkingDirectory si c'est le seul que vous souhaitez définir une valeur par défaut pour