Program works in VS 2013 but not the .exe

Question

I have made a test program in Visual Studio 2013 using Direct X 11. It consists of a simple sprite which rotates slowly based on a timer implementation. The program loads and runs fine using F5 or Ctrl-F5, but when I try to open the actual created .exe (in my \Debug folder) it just shows the window then closes instantly.

Most of the answers I have read on this issue correspond to loading the .exe from inside visual studio. I have also tried Release mode but the same thing happens.

Jacquelinejacquelyn

Couldn't it be that the exe can't find the sprite in the same directory or something like that? – Fustanella

Yes, almost certainly this is caused by the 'current working directory' being different in the two different ways of launching the program. – Gerfalcon

From my experience, this kind of issue comes from a path being project relative instead of application relative. – Cleocleobulus

Spot on Krister! Thanks. My first time doing anything other than console applications where everything is neatly wrapped up in the .exe. Not sure how to accept comment answers... – Jacquelinejacquelyn

Someone has to post the comment as an answer. I like this question because people run into this problem a lot – Mendelson

You should compile in Release profile to run exe. – Lothario

You can set the debugging directory (run from F5) to be the same as where the .exe lives to find/avoid these issues by setting project properties/Configuration Properties/Debugging/Working Directory to $(OutDir) (or an explicit path). – Bosanquet

Answer 1

Sprite files are kept in your project folder. The default run-location from the Visual Studio IDE is the project folder of the project which you're executing. That is, normally it executes from the directory where your .vcproj or .vcprojx file is kept (and that is often one folder below your solution directory folder, where your .sln file is kept).

If your project runs correctly from the IDE, but fails to run directly from the debug folder, it is highly likely you are relying on project data files that are kept along side your source files in the project folder. When run from the Debug folder, those files are no longer visible because Debug folder is your working directory; not the project folder.

There are a number of ways to solve this problem, each with its own merits. A few options are:

Post Build Step

Make a post-build step for your project that copies your data files to the $(TargetDir) location with your project. These files will then be visible in the same directory as your executable.

Benefit: Its easy.
Drawback: It will always run if you click "build solution" even if the data files are "up-to-date."

Custom Build Targets

Add your data files to the project and write a Custom Build script that performs the same copy, but also establishes an output dependency file(s).

Benefit: Almost as easy as #1, but a little more tedious.
Drawback: You may have a lot of data files and each will require its own custom build step. (Note: you can multi-select all the data files in your project, and if you're creative with the built-in macros you can have them all use the "same" build rules and commands).

Embedded Resources

Add the data files as custom resources to your executable.

Benefit: Your project no longer requires data files side-by-side with the executable since they are embedded in the resource table of your EXE module.
Drawback: Custom code is required to dynamically load the custom resources from your executable's resource table rather than off-disk. It isn't difficult at all to do, but is additional work.

There are other options as well, but I hope this gives you some ideas to start with.

Saito

Very nice, that Embedded resources sounds lovely I will give that a go. – Jacquelinejacquelyn

@Steve Hatcher You can just change working folder in project settings under "debugging". Usually you want to change it to $(TargetDir) (e.g. target binary folder). Then, in code, use file paths relative to your binary folder (\Debug in your case). Ex: ../resources/sprite.jpg instead of sprite.jpg. (.. moves one level up in a directory tree, so sprite.jpg will be always searched in resources folder one level up from binary folder). Doesn't it simplest and "right" way to do things? =) @Imran Rizvi can you please add this option to your answer? – Getz

Excellent, hopefully this saves other people such grief. Thanks – Jacquelinejacquelyn