We Keep Coding

streamreader paths to file

While in a search to learn more about the streamreader, i came across this from
StreamReader path changes automatically
post #2 by
Hans Passant
var exedir = Path.GetDirectory(Assembly.GetEntryAssembly().Location);
var path = Path.Combine(exedir, #"Config\launcher.txt"); using (var
reader = new StreamReader(path)) {
//... }
Now I understand the "never hard code the file" part, In delphi, I am able to specify a custom file path based on the files in a directory ie.
Read all file names in a directory, user chooses a file name, and then I read the contents of the file
Delphi, I just used a string and added the file name to the end, how does that differ from the code above, and is there a different method to this above?
and btw. Could someone just explain in a bit more detail, the methods and variables used and why (i am still new to c#)

I think what Hans is saying here is that if you are expecting the files to be relative to your application code, then expliclty look relative to your application code. Don't rely on the current directory being the base location of your application, as that is not guaranteed (and can change during your application's execution). So what the code does is:
obtain the entry-point assembly (the assembly with the Main method that was executed at startup), and obtion the file location of that assembly: Assembly.GetEntryAssembly().Location
obtain the directory from this file path: var exedir = Path.GetDirectory(...);
construct a path relative to this directory: var path = Path.Combine(exedir, #"Config\launcher.txt");
create a reader based on the final path: using (var
reader = new StreamReader(path)) ...

GetEntryAssembly returns, according to the documentation:
The assembly that is the process executable in the default
application domain, or the first executable that was
executed by AppDomain.ExecuteAssembly.
And the Location property returns the full path of the assembly. So
Assembly.GetEntryAssembly().Location
is the full path of the executable. In Delphi you would write ParamStr(0) or Application.ExeFileName.
Path.GetDirectory strips off the file name and leaves the directory. In Delphi you'd use ExtractFilePath.
And Path.Combine simple joins two path components, adding a path separator if necessary. In Delphi you'd use TPath.Combine from the IOUtils unit.
So the code in the question constructs the full path to a file named
<exedir>\Config\launcher.txt
where is the directory containing the main executable assembly which is of course known only at runtime.
There's really nothing particularly different between the way things are done in Delphi and C#. To construct the same path in either language you take the exact same steps modulo syntax/method name differences.
Possibly you are in the habit of assuming that the working directory is the directory containing the executable assembly. If so, lose that habit. The working directory is meaningful for a console application and for such an application it can be considered an input to the program. But don't expect it to be stable in a GUI program. And never assume that the working directory contains the executable. That assumption is not valid.
On the other hand, perhaps you really do want a path relative to the working directory. In which case simply supply the filename and let the system take care of the rest.

C# File Handling: Create file in directory where executable exists

I am creating a standalone application that will be distributed to many users. Now each may place the executable in different places on their machines.
I wish to create a new file in the directory from where the executable was executed. So, if the user has his executable in :
C:\exefile\
The file is created there, however if the user stores the executable in:
C:\Users\%Username%\files\
the new file should be created there.
I do not wish to hard code the path in my application, but identify where the executable exists and create the file in that folder. How can I achieve this?

Never create a file into the directory where executable stays. Especially with the latest OSes available on the market, you can easily jump into the security issues, on file creation.
In order to gurantee the file creation process, so your data persistancy too, use this code:
var systemPath = System.Environment.
GetFolderPath(
Environment.SpecialFolder.CommonApplicationData
);
var complete = Path.Combine(systemPath , "files");
This will generate a path like C:\Documents and Settings\%USER NAME%\Application Data\files folder, where you guaranteed to have a permission to write.

Just use File.Create:
File.Create("fileName");
This will create file inside your executable program without specifying the full path.
Don't forget to add:
using System.IO;

You can get the full path to your new file with:
string path = Path.GetDirectoryName(Application.ExecutablePath) + "\\mynewfile.txt"

string path;
path = System.IO.Path.GetDirectoryName(
System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase );
MessageBox.Show( path );
http://msdn.microsoft.com/en-us/library/aa457089.aspx

In modern operating systems, the accepted answer of:
var systemPath = System.Environment.GetFolderPath(
Environment.SpecialFolder.CommonApplicationData
);
var complete = Path.Combine(systemPath , "files");
will produce a user agnostic path like: "C:\ProgramData\files"
To produce a user-based path similar to: "C:\Documents and Settings\%USER NAME%\Application Data\files"
You should use SpecialFolder.ApplicationData or SpecialFolder.LocalApplicationData instead.

I like to give the user the choice. I would default the directory to something like Environment.SpecialFolder.CommonApplicationData and let them read and edit the path at will. If in a console app display the path in help and allow them to pass it via command line argument.
This saves them the hassle of hunting for the folder. If they point to a path you cannot write to then you throw the error and let them decide what to do.

c# - where to place txt files

I'm working on a simple progam, and part of it populates a list from a txt file.
this probably is not a smart question but, I didn't find any info on this.
I was wondering where is the best place to put text files in the application directory.
O know about the Resouces but, I wasn't able to get the path of the file I stored there.
so 2 questions:
where is the best place to put a txt file? (or any other importent file to use in the application)
if I put files in the Resources how do I get its path ?
(sorry fo my English)

If these are files that you do not need to expose to the users and only serve an internal purpose, then you can embed them in your assembly as resources, and extract them when you need them.
To do this, create a new directory in your application. Let's call it 'Resources'. Then, add text files to it. Use the properties window of each text file to change the BuildAction setting to "Embedded Resource". Then, in your code once you need the contents of the file you can use code like this to extract it:
using System.Reflection;
// ...
using (Stream stream = Assembly.GetExecutingAssembly().GetManifestResourceStream("MyApplication.Resources.MyFile.txt")) {
using (StreamReader reader = new StreamReader(stream)) {
string contents = reader.ReadToEnd();
// Do stuff with the text here
}
}
If you don't want to do this, the correct location to place files is in a directory you create under the AppData directory. This is a known system path, which you can obtain like this:
string folderLocation = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
string myPath = Path.Combine(folderLocation, "MyAppName");
You can then use a StreamReader or other class in System.IO to find/enumerate and read the files.

When an application has associated/companion data files it sometimes makes sense to embed them as a Resource, because then there is less chance for them to be tampered with e.g. deleted, or the data modified.
And other times it makes sense to keep the file loose....so you have to decide the best place to store them....you can locate these in the place where the application is installed, or in the Application Data/AppData directory.
For embedding files in Resources have a look at this link:
http://support.microsoft.com/kb/319292
It has a step-by-step guide showing how to embed a file (e.g. a Text file into Resources), and then using a StreamReader to access it and read its contents.
To store the files and access them from a suitably located directory you can use:
System.Environment.SpecialFolder.ApplicationData
with
Environment.GetFolderPath()
to find out where the AppData directory is.
Then when you create your application Setup/Installer, you should get it to create a directory for your application underneath AppData, and then you can decide what files you want to be installed into that location.
See:
Saving a file to Application Data in c#
Note, ApplicationData "roams"...i.e. when you logon to a different machine, the files are transferred onto that machine as part of your profile....you may not want this....so you could instead use:
System.Environment.SpecialFolder.CommonApplicationData

Using WritePrivateProfileString to write path issue

I am using WritePrivateProfileString in c# (through DllImport) to store paths taken from textboxes on the interface. And the .ini file name is hardcoded in my application
string ini_file = ".\\config.ini";
However, when the file writing happens, the configuration file is written to the first path taken from the interface instead of writing it to the exe directory. Which is quite odd.
Debugging shows that the values are sent correctly to the WritePrivateProfileString but it still is written to the wrong location. Anyone knows why is that happenening?

I'd guess that something is changing the working directory of your process, most likely your code in the process. Note that the documentation has this to say:
If the lpFileName parameter does not contain a full path and file name for the file, WritePrivateProfileString searches the Windows directory for the file. If the file does not exist, this function creates the file in the Windows directory.
Now my guess is that this applies if you supply just a file name. Because your file name starts with . I believe that will force the function to start from the current working directory.
Having said all of that, and no matter what the cause of the problem is, you should use a fully-qualified path in order to make sure the file is written where you want it to be written. Whenever you want the file to go in a specific directory, it's always easiest to force that by using fully-qualified paths.
You can find the path to your executable using Application.ExecutablePath and then remove the file name part.
Another point to make is that the same directory as the executable may be a bad choice. If your program is installed under the Program Files directory then the directory which contains the executable will not be generally writeable. I think you should consider using a directory under in the user profile. Look for one of the Environment.SpecialFolder values.

Further to David Heffernan's answer - you can use
Path.GetDirectoryName(Application.ExecutablePath);
to safely get just the running application's folder part.
If you're in a dll rather than an executable, you can use
Path.GetDirectoryName(Assembly.GetAssembly(typeof(MyClass)).CodeBase);
Both require System.IO, and were originally posted here. Second example also requires System.Reflection).

Application data files are supposed to be written to the LocalApplicationData special folder.
string path = System.Environment.GetFolderPath(System.Environment.SpecialFolder.LocalApplicationData);
You typically will not have permissions to write into the Program Files folder etc.

Quick Question: How can I make sure the current directory is not changed because of OpenFileDialog?

say my application is installed in C:\programfiles\xyz\ I've some setting & other data files (*.dat files) in this directory too.
My application uses OpenFileDialog to open an image. Problem is that when ever user browses to some directory (say MyPictures) for an image. The current working directory of the application becomes that directory (MyPictures in this case).
After user inputs the image. I do some processing over it and save some values to imagedata.dat which will be located in the path where original application is installed.(C:\programfiles\xyz here )
In my code I'm just using FileStream("imagedata.dat",...,...) without any path prefix before the filename. Problem here is that application is crashing because it is searching for imagedata.dat in 'MyPictures\imagedata.dat'.
How can I avoid this?

You should be using absolute path names when saving data to files. The current working directory is controlled by the user, not by you (for example, if they launch your process from a shortcut then the working directory could've been changed before your process even starts up).
Also, you should never save anything under C:\Program Files during normal use. Doing this means your program needs to be running as an administrator, and unless you're doing administrator-y things then you should be able to run it as a regular user.
The correct thing to do in your case is to use the Environment.GetFolderPath() function to get the location of the ApplicationData folder and save your data under there. Just choose a sub-directory based on your application's name.

You could save it to GetCurrentDirectory then restore with SetCurrentDirectory. However, I agree wih codeka that using the appropriate GetFolderPath (probably ApplicationData, CommonApplicationData or LocalApplicationData) is a better solution.