I have a problem calling a batch file from another batch file when trying to run everything by using Process.Start. Basically I call the execution of a batch file from my c# program that looks like this:
call include.bat
//execute the rest of the batch file here
The include.bat file sets up paths and can be used by a number of other batch files. When I run the Process.Start sometimes this works and sometimes I get ERROR: cannot find include.bat. First of all any idea why this happens? And ideas on how to fix this from the batch file?
To switch to the directory your batch file is located in, use this:
cd %~dp0
I do this in almost all of my batch scripts. That way relative paths should always work.
I know this is an old question but I thought it would be worth noting that the approach promoted by the accepted answer (i.e. changing the working directory) may not always be appropriate.
A better general approach is to refer to dependencies by full path:
call "%~dp0include.bat"
(Since %~dp0 already ends with a backslash, we don't need to add another one.)
Here are some benefits of not changing the working directory:
The rest of the batch file can still use the original working directory.
The original working directory in the command prompt is preserved, even without "SETLOCAL".
If the first batch file is run via a UNC path (such as "\\server\share\file.bat"), the full-path call will succeed while changing the directory (even with "cd /d") will fail. (Using pushd/popd would handle this point, but they have their own set of problems.)
These benefits are particularly important for alias-type batch files, even if they are not as important for the specific situation that motivated this question.
Before the script, try CD /D %~dp0
First thing I'd try is to use full path information in the call statement for include.bat. If that fixes it, you probably are just not running the batch file from the proper location. I'm sure there's a "working directory" capability in C#, I'm just not sure what it is.
Do you set ProcessStartInfo.WorkingDirectory ( http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.workingdirectory.aspx ) on the ProcessStartInfo that you pass to Process.Start?
Since include.bat sometimes cannot be found, working directory may be wrong (not the folder where include.bat is located).
Related
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.
How do I debug my C# app when it really needs to be running from a specific folder and not from bin/debug? One of the first things my program does for example is determine what set of tools will be presented based on the executable file it finds. But since its running from the debug folder it can't find them. I can add the file there but that seems silly. There has to be a better way. Plus, there's really a bunch of other thighs it does that really requires it to be running from the proper folder eg. Z:\test.
I thought it might be the "Working Directory" setting under the "Debug" tab in Properties but that didn't seem to do anything. I'm using VS2010 and C# btw...
I hope I'm making sense.
Thanks
You can specify another output folder for your build.
Try setting Environment.CurrentDirectory to the directory you want to simulate.
Environment.CurrentDirectory = #"C:\SimulateThisDirectory\";
You can use
System.IO.Directory.SetCurrentDirectory("your-path");
from your code.
You need to differ between two things:
path from which process is started
current working directory of the process
First one you can't simulate easily. It would probably involve creating a symbolic link or creating some sort of rootkit.
As for second one, your method is fine, and you can check working directory in runtime by using Directory.GetCurrentDirectory or set it using Directory.SetCurrentDirectory.
Take note that if you are looking up directory of executing assembly, you will get path from which process is started.
You can run your program from as normal from the specific directory and then just attach the debugger
http://msdn.microsoft.com/en-us/library/c6wf8e4z.aspx
I've created a batch file that is being used with a Process. I currently just have the application pointing to a directory on my local machine.
Rather than having to bundle my exe with this batch, I would like to just embed it as a resource so that it will be contained in the exe. Is this possible with a batch file?
ProcessStartInfo startInfo = new ProcessStartInfo()
startInfo.FileName = "c:\test\batchFile.bat";
// set up and execute batch file with various arguments
I've added the batch file to my solution, and added it as a "resource" to my project file. I'm not entirely sure this is the way to go, or how to access this in my project.
As for embedding the batch file - you can embed just about anything if need be... the answer to this is yes :-)
As for how to use the embedded batch file - the easiest option is the read it from the resource (see http://msdn.microsoft.com/en-us/library/system.resources.resourcemanager.aspx and http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getmanifestresourcestream.aspx) and save it as a real file - then use that.
IF you would embed a .NET EXE/DLL you could use that without saving it as a real file... with a batch file I suspect you will need to save it as a real file.
How about this approach:
store your batch file in your program (as resource or string constant or ...)
save the contents to a temporary file
run this temporary batch file
of course :
you should run it but with command.com before
System.Diagnostics.Process.Start("cmd", "/c c:\test\batchFile.bat");
Probably the most bullet-proof way to do this is to write the .bat out to a temporary file, then run that temporary file.
cmd.exe is, in my experience, rather persnickety and can behave different ways in different contexts. If you want it to behave just like a .bat file that you would run from your filesystem, then you should run the .bat file from your filesystem.
You could try (but I would not recommend) piping the commands to an instance of cmd.exe, but as I say, you may get different behavior.
If i make the call File myFile = new File('myfile.txt'); where is does this get saved to?
It's relative to the process's current directory. What that is will depend on how your application has been started, and what else you've done - for example, some things like the choose file dialog can change the current working directory.
EDIT: If you're after a temporary file, Path.GetTempFileName() is probably what you're after. You can get the temp folder with Path.GetTempPath().
That won't compile.
EDIT: However, if you're after where creating a text file using StreamWriter or File.Create("text.txt"), etc, then I defer to the other answers above; where it will be where the application is running from. Be aware as others mentioned that if you're working out of debug it will be in the debug folder, etc.
NORMALLY it gets saved to the same directory the executable is running in. I've seen exceptions. (I can't remember the specifics, but it threw me for a loop. I seem to recall it being when it's run as a scheduled task, or if it's run from a shortcut.
The only reliable way to know where it is going to save if you are using the code snippet you provided is to check the value of System.Environment.CurrentDirectory. Better yet, explicitly state the path where you want it to save.
Edit - added
I know this is a bit late in modifying this question, but I found a better answer to the problem of ensuring that you always save the file to the correct location, relative to the executable. The accepted answer there is worth up-votes, and is probably relevant to your question.
See here: Should I use AppDomain.CurrentDomain.BaseDirectory or System.Environment.CurrentDirectory?
I'm trying to run a command-line process (which is extraction of a .7z archive) on a file that lies in a temporary folder on the windows user temp directory
(C:\Documents and Settings\User\Local Settings\Temp), using Process in my c# app.
I think the process return error that happens because of "access denied" because I can see a win32Exception with error code 5 when I dig in the prcoess object of .NET.
doing the same on some other location worked fine before, so I guess maybe it's something I'm not supposed to do ? (running a process to use a file on the the %TEMP%)
perhaps I need to pass security somehow?
Assuming that you are using regular .NET (not CF/Silverlight, etc) Accessing files in the user's temp area is entirely expected. I wonder if the problem isn't more that you've accidentally left the file open after creating it, perhaps by not using a "using" or similar?
I probably wouldn't suggest using environment variables (%TEMP% etc) when shelling out to a separate process; ideally you'd pass the full path to the file (less things to get wrong...), making sure to quote any path arguments (in case of space) - i.e. so your args are #"... ""c:\some path\whatever\tmp""..." (if you see what I mean).
Finally, if you are extracting files, you need to think about the existing contents. Path.GetTempFileName() is fine for creating a single file place-holder, but for extracting an archive you probably want to create a directory - guids are handy for this purpoes (while avioding conflicts, and remember to remove it afterwards):
string dir = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString());
running the same process using command-line (cmd) helped to figure out my problem was that I specified path arguments to the process using long-path-name.
Solution to this can be found here:
standard way to convert to short path in .net