When Environment.CurrentDirectory Isn’t
I have been using Environment.CurrentDirectory for years as a way to programatically access the folder the application is running out of. In most cases, I was just displaying this information somewhere, or maybe defaulting a Save or Open File Dialog box.
I my current project however, I wanted to Process.Start a batch file residing in the same directory that the application was being deployed to. On my machine and all our test machines, calling the path to the batch file using Environment.CurrentDirectory worked beautifully for myself and the other developer working on the project. However, our tester and my user continually reported an error when when the batch file ran.
Long story short, if you don’t have admin rights, you might not be running the application where you think you are. If you absolutely need the path where the files are, and not the location you are running out of, use either Application.StartupPath or Assembly.GetEntryAssembly().Location.
Lessions Learned:
- If you set a value at the top of the class, you will forget about it in the method you are trying to debug. I didn’t actually see Environment.CurrentDirectory, just the path that was getting passed in as my variable. It wasn’t until I started writing the value out to a flat file with my tester logged in that I saw what was going on.
- Debug mode is useless if the code always works for you. Embarassingly, it took quite a bit of time for that fact to sink in.
- Don’t assume that something you have been doing for years is correct. I lost days (hours over days) assuming something was wrong with the batch file.
