We Keep Coding

File path for c# when moved to a memory stick

sorry first time user and currently learning c# at uni, i'm working on an assignment and i'm trying to get the file path to work on the memory stick as that's what i need to hand it in on, thanks many regards

I'm not completely sure what your question is by I think what you're talking about is absolute vs relative paths. If you use an absolute path like "C:\users\yourname\blalba\project\stuff", then it's obviously only going to only work on your computer. However, you mostly all of the time want to use relative paths. Relative paths have the root directory of the build output files for your project; where your .exe file is built for your project. This is usually in "projectdir\bin\debug" or "projectdir\bin\release". So if you put for example a file called 'test.txt' in that directory, you can simply put the relative path "test.txt" instead of "C:\users\yourname\blalba\project\bin\debug\test.txt". If you were to put 'test.txt' in the project directory, you can use the relative path "....\test.txt". "..\" means navigating one step back.

The path to the directory containing the files you are looking for is "F:\Mod005244, 1715840". The "1715840 JH" is just the name of the drive. You access different drives via the drive letter. In this case, the drive letter "F" was assigned to your flash drive.
I would suggest making the file path configurable or request input from the user of the program as the drive letter of a flash drive will not always be "F". There are even classes (such as FileBrowserDialog) that will open a graphical file browser dialog and prompt the user to navigate and select a file.

C# Listing all directories in C:\

In my application every user can set his own save path to save his files and settings
so every time the user log in i must search a folder that contains the username+"Data"
for example if the user name was "Kim" i need to find the path to the folder KimData
when i try to get all directories in C:\ the UnauthorizedAcessException appears
so is there a way to search for that folder or just skip the unauthorized folders while searching ?

The UnauthorizedAccessExpection means that the caller does not have the required permission to access the directory/file. Since you're doing it locally, there are several options. After you attempt to copy the data from VS to the data in the file (Create, copy, delete) etc.... you can try File.SetAttributes(yourfile, FileAttributes.Normal).
You can also use Environment.GetFolderPath. Accordingly, this:
"Gets the path to the system special folder that is identified by the
specified enumeration, and uses a specified option for accessing
special folders."
Also, I'm guessing you're simply looking through the entire directory/folder/path all at once. A workaround would be to probe one directory at a time. This is assuming you are adding a file. Once you've found your directory, you can use:
Directory.GetFiles(path)
.ToList()
.ForEach(s => files.Add(s));
Directory.GetDirectories(path)
.ToList()
.ForEach(s => AddFiles(s, files));
EDIT: Some helpful related questions on stack to look at might be:
UnauthorizedAccessException
Directory.GetFiles

Take a look at Ignore folders/files when Directory.GetFiles() is denied access and see if it helps you.
However if you are trying to look for a specific folder - which according to your question the user can place anywhere - in the entire directory tree i advise against it as it probably will be slow.
I would recommend saving the path somewhere and reading it from there when the user logs back on.
If its a desktop app and each user runs the app with its own windows account an even better solution would be to always write the data to the user's ApplicationData folder which you can get with Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData).
As the name indicates this folder exists to keep applications data and its individual for the user logged in to windows

Get access to program's own directory

this is a very simple issue.
Note: I am sure people have found and posted this same issue somewhere but I can't figure out the correct search terms to find it.
Okay, so here is my issue.
Let's say my program is stored at C:\Program Files (x86)\MyProgram\Program.exe.
Now in the program, it basically does
Directory.CreateDirectory(Application.StartUpPath + "\\Files")
So basically, this would create a directory called Files in the same folder as the program itself.
Assume that I have to create the folder in that location, so using a different location is not an option.
So the real problem is, if its located in the c:\Program Files directory, my program gets "access denied" when I try to create the folder.
So how can I get something like this to work without forcing the user to run it as an admin?

If it's in Windows 7, if UAC is elevate, you won't be able to modify anything in c:\Program Files without rooting yourself via 'run as administrator'.
And since windows is a multi-user operating system, storing anything user-specific there is a recipe for disaster.
The right place for your program to put its data is in the appropriate special folder, which you can get/create via either
// user-specific application data is stored here
string userSpecificAppDataDirectory = Environment.GetFolderPath(
SpecialFolder.ApplicationData ,
SpecialFolderOption.Create
) ;
// application data common to all users is stored here
string commonAppDataDirectory = Environment.GetFolderPath(
SpecialFolder.CommonApplicationData ,
SpecialFolderOption.Create
) ;
or one of the other Environment.GetFolderPath() overloads.

In modern operating system the folder C:\program files (x86) is write protected by the OS. You can't create sub folders here without using an administrative account (and also in that case you will be asked to confirm this action unless you disable UAC). So the correct way to follow is to create your data folder in another place. The best option is the CommonApplicationData folder extracted using:
Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
or the SpecialFolder.ApplicationData enum if your data should be differentiated by the current user of the application, or the SpecialFolder.MyDocuments if these files are produced by your user and need to be opened freely by other programs (or need to be included in a backup)
After you get the special folder provided by the OS to store application data remember to create a subfolder for your application and the other subfolders as required by your requirements
// In Win7 this usually resolves to C:\ProgramData, but do not use this folder
string appCommon = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);
// This resolves to C:\programdata\your_app_name\files
string appData = Path.Combine(appCommon, "your_app_name", "files");
// This will create all directories in the specified path one by one....
if(!Directory.Exists(appData)) Directory.CreateDirectory(appData);

You could try creating any files or folders you need during your installation procedure. I am not sure what success you would find if using a third party install creator, but my understanding is that items added via the Application Files... button in the Publish tab of the Project Properties section in Visual Studio then have access privileges kind of inherently granted for use by the application.

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.

How to check if application runs from \program files\

Is there a reliable method to check if an application is run from somewhere beneath program files?
If the user installs the application to program files on local machine, we need to put writable files somewhere else to avoid virtualization on Vista and Win7. When installed to a network disk, though, we want to keep these files with the installation for shared access among users.
Today we do an string comparison between startup path and CSIDL_PROGRAM_FILES, but something tells me this is a very unreliable method.
Any smart solution out there?
Is there a 'IsRunningFromProtectedFolder( )'-api that I do not know about?
Are there any other folders giving the same problems as program files do?

This is not a terribly good idea, as a user can install it wherever they want to, and then the check might fail. Instead have a checkbox when the user installs the app, deciding if it is installed locally or on a server.

As you I also found problems dealing with UAC folder virtualization.I suggest a workaround, it seems that it should work.
It comes from the assumption that elevated processes always use original copies and not the virtualized ones (CMIIW). Also I assume that you setup processed was executed elevated
The idea is to create a "general" process (non-elevated, legacy), that your main installer should run. This process will create a file name in the user chosen folder with a name and contents that both your programs know (for example, test73819704.bin). If the folder virtualized, this file should appear in the user VirtualStore and SHOULD NOT in the original one (from the point of view and privileges of the installer).
So for chosen C:\Program_Files_But_Not_Necessarily and Process-1 (elevated)
Process-1 ensures there's no file C:\Program_Files_But_Not_Necessarily\test73819704.bin
It launches Process-2 with no elevation
Process-2 creates C:\Program_Files_But_Not_Necessarily\test73819704.bin and checks whether it really exists. If exists it would return with a good return code, otherwise with a "failed" one.
Process-1 waits for Process-2 and analize the result. If good, checks for C:\Program_Files_But_Not_Necessarily\test73819704.bin, if it exists, go for "Bingo! No virtualization occured", if doesn't exist, "Bad, let's find some other storage place". If the code from the Process-2 is "failed" one, show the user some error message.
Unfortunately I could not test it right now, but I guess it should work and there's a logic behind this, with Process-2 you just emulate the behavior of your main program )

We allow our users to install anywhere...
If the user has taken the default, and is installed in Program Files, we make the assumption that we need to write to Documents and Settings/Users. Otherwise, we write our data to a folder under the directory the software is in. This of course can still cause problems, and the install does indeed allow people to choose a different data location if they choose to not go for the default.
On top of that, it's a simple ini file change and a copy to move the data.
On start up we detect if we are in the Program Files directory by comparing the value we obtain from SHGetFolderPath(CSIDL_PROGRAM_FILES) with the start of the path the executable is in.