24

How can I find the current directory for a .NET application running under the Visual Studio debugger?

Update 1. To be clear: I don't want to change the code or get information in the program itself - I just want to get information about the application currently being debugged.

While debugging a .NET Windows Forms application (mixed VB.NET and C#) I was not sure from which location a XML file was being read from. I expected the current directory to be the application's directory. However, using Process Explorer, properties for the process result in:

D:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\

(right click on process/Properties/tab Image/Current Directory).

Hovering the cursor over the process in the main view of Process Explorer revealed a different result (see below for a screenshot):

D:\dproj\DTASCall\DTASuperCharge\bin\

What is correct?

Starting the application standalone displays the expected current directory,

D:\dproj\DTASCall\DTASuperCharge\bin\

in the Process Explorer process properties window.

Annotated screen-shot of Process Explorer:

Alt text http://www.pil.sdu.dk/1/until2039-12-31/PEdiscrepancy_2009-09-02.png

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131

3 Answers3

32

In Visual Studio, under the project's settings in the debug tab, you can set the "Working Directory" if you want.

To determine the current working directory in code or in the immediate window in a breakpoint, try

System.IO.Directory.GetCurrentDirectory()
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Philip Rieck
  • 32,368
  • 11
  • 87
  • 99
  • 1
    For the Immediate Window: isn't it "Debug.Print (System.IO.Directory.GetCurrentDirectory() )"? – Peter Mortensen Sep 02 '09 at 14:10
  • 2
    Alternative to Immediate Window: menu Debug/Quickwatch//Press Reevaluate. Or enter in the last row of the Name column of a regular Watch window, followed by the Return key. – Peter Mortensen Sep 02 '09 at 14:14
  • 4
    or in the immediate window, you can always do "? System.IO.Directory.GetCurrentDirectory()" – Philip Rieck Sep 02 '09 at 22:14
  • 1
    I used this answer, but modified it to "? System::IO::Directory::GetCurrentDirectory()" to debug CLI\C++. – Alex Nov 01 '17 at 13:55
4

Within your code, call the function 

System.IO.Directory.GetCurrentDirectory()

By default, unless you've changed the Debug properties of your project, the current directory will start as the bin\Debug directory of your project (where the .exe runs from).

Richard
  • 29,854
  • 11
  • 77
  • 120
  • What do you mean by the actual program not running? The program was stopped at a breakpoint when the screenshot was taken. – Peter Mortensen Sep 02 '09 at 13:57
  • Hmmm, I see what you mean. I was wrong about the .vshost - I've just checked the same thing and procexp tracks my current working directory with no problems. Try comparing the output of System.IO.Directory.GetCurrentDirectory() - with the default project settings this should be the bin\Debug directory of your application. If the XML file you are trying to read is a project item, be sure to set the Build Action property to "Content", and the Copy to Output Directory property appropriately. It might also be worth you reading from your application's root directory rather than the current dir. – Richard Sep 02 '09 at 14:07
  • 1
    Field "Working directory" on the Debug page is empty. But on the Compile page the field "Build output path" contains "bin\". Should it be empty?. This project was created by Visual Studio in 2003 and has been through two Visual Studio updates since then. Currently the application starts from the bin directory, not bin/Debug – Peter Mortensen Sep 02 '09 at 14:36
  • That sounds fine. For a default C# project, the output path will be bin\Debug, and the working directory field is empty. – Richard Sep 02 '09 at 14:49
  • The startup project is a VB.NET project (and from which I listed the settings above). – Peter Mortensen Sep 02 '09 at 14:55
-3

The best way is to run the application in WinDbg (the Windows debugger), then attach to the process and run the !handle command. Each open file will have an associated handle. By dumping all the handles for the corresponding process, you will see the corresponding file path.

Here is an example:

!handle 0 f process-id

Replace the process-id with the value of your process id. In place of the process id you can also use the process address. If this does not show the file object, then file handle has already been closed. In this case you need to trace the handles. This can be done with the !htrace command.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
steve
  • 5,870
  • 1
  • 21
  • 22