views:

35

answers:

3

I have a C++ solution in VS2008 with multiple projects. This solution contains files that are needed at runtime, which are loaded according to a path relative to the solution directory (e.g. "Testing/data/" + "dataN.bin").

In order for this solution to work, I must set the working directory setting in the project(s) so that it will point to the solution directory (e.g. Configuration Properties >> Debugging >> Working Directory = $(SolutionDir) ). This works fine when i'm debugging on my own PC. However, when a different user loads my solution, his projects does not have this property set properly.

I have traced this setting to be stored not in the project file (PROJECT.vcproj), but in the user-specific file created for it (PROJECT.vcproj.DOMAIN.USER.user).

I would like a way for this setting to be stored for ALL users, without having to set it manually again and again.

My thoughts were:

  • Find a way to store this in the .vcproj file (not the user-specific one) or the solution file.
  • Find a way to create a "default-user-specific file", from which all user-specific settings will start out (and can modify at will later).

However, I did not find a way to do either of these.

A few more notes / constraints:

  • I need to work with many big files as these resources, therefore I would like to avoid performing copies to different directories.
  • The solutions needs to support multiple build configurations (debug, release, etc.).
  • I would like to avoid pre/post build scripts if possible, to keep things straightforward (low priority).

Any help will be appreciated... thanks in advance.

A: 

I wonder whether this would be possible since a user might not have enough rights to access and read/write to the directory, I suppose VS checks if a user has access to a directory when you choose it that is probably why there is only an account based option.

Mervin
A: 

You might consider using either 'Configuration Properties/ General/ Output Directory', or 'Configuration Properties/ Linker/ Output file', instead of the 'Debugger/ working directory' setting. These settings are per-project and not per-user, and if you leave the working directory intact this is the default value for the app working directory.

Ofek Shilon
If things don't go my way, I might have to go this way despite my will to avoid this (see my comment at Hans Passant's answer). Wasn't this behavior different in previous versions of Visual Studio (e.g. 2005)?
scooz
+2  A: 

No such property exists. There are bigger issues, this also needs to work after you deploy your solution. The working directory then is not going to be a "solution" directory, there isn't one on the target machine.

You are much better off working from the assumption that the working directory is the same as the EXE directory. That will be the default both while debugging and on the target machine. You have full control over the location of the EXE file with a linker setting. And you can protect yourself from a shortcut running your program with another working directory by obtaining the EXE directory in your code so you can generate an absolute path. Use GetModuleFileName(), pass NULL to get the path to the EXE file.

Another standard solution is to copy any kind of resources the EXE needs to a folder that's relative from the build output folder. You do this with a Pre-Build event, make the command line look similar to this:

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

Note how the /d option ensures that copying is only done if the Testing folder content changed.

Hans Passant
Copying resources: This would do the trick, however I have massive amounts of resources to copy (in this case, large test vectors), and it would be a waste of time and memory to copy these every time. In addition, I have multiple build configurations (release, debug, ...), which will cause further duplication which I wish to avoid. It makes sense that these vectors are at the root "solution" directory, since this data is used by multiple projects (in different ways). Also, I would like to maintain order in the files list of the solution (regarding directory structure).
scooz
On the flip side, copying the executable result to the root solution directory will not only cause a mess on the root directory, but it will not properly support multiple build configurations (will keep overriding files of the same name, etc.). It seems that for debugging purposes, the most logical thing to do is change the working directory. Regarding the deployment issues you brought up (which I agree with), i'd rather complicate things there than when debugging (since I deploy less often than I debug)
scooz
This is why I pointed out the behavior of the xcopy /d option. You are only paying for the copy once.
Hans Passant
True, but it still requires me to copy stuff around. We're talking about Gigabytes of data here... :)
scooz
Put the data into a directory that is on the same level as the per-configuration directories for the executables. Then reference your data using a path like ..\data relative to your executable.
oefe
It's not EXACTLY what I wanted, but I guess i'll go with oefe's suggestion... Thanks everyone.
scooz

related questions