标签云

微信群

扫码加入我们

WeChat QR Code

How do I find the application's path in a console application?In Windows Forms, I can use Application.StartupPath to find the current path, but this doesn't seem to be available in a console application.


Do you install .NET Framework on target (Client, Development) machine? if your answer is true; So, you can add a reference to System.Windows.Forms.dll and use Application.StartupPath! This is the best way if you want to drop away further future exceptions!

2019年07月21日37分09秒

AppDomain.BaseDirectory is app directory. Be aware that application can behave different in VS env and Win env. But AppDomain should be same not as application.path but i hope that this is not only for IIS.

2019年07月20日37分09秒

System.Reflection.Assembly.GetExecutingAssembly().Location returns where the executing assembly is currently located, which may or may not be where the assembly is located when not executing. In the case of shadow copying assemblies, you will get a path in a temp directory. System.Reflection.Assembly.GetExecutingAssembly().CodeBase will return the 'permenant' path of the assembly.

2019年07月21日37分09秒

SamGoldberg: That depend on how it is used: stackoverflow.com/q/1068420/391656 . Or you can ...new Uri(System.Reflection.Assembly.GetExecutingAssembly().CodeBase).LocalPath

2019年07月20日37分09秒

For whatever reason, in VS2013 (at least the copy I have) intellisense does not work past System.Reflection.Assembly. GetExeuctingAssembly() is there but you cannot see it.

2019年07月20日37分09秒

GetExecutingAssembly returns assembly that contains the code that is currently executing. This may not necessarily be the console .exe assembly. It may be an assembly that has been loaded from a totally different location. You will have to use GetEntryAssembly! Also note that CodeBasemight not be set when the assembly is in the GAC. The better alternative is AppDomain.CurrentDomain.BaseDirectory.

2019年07月20日37分09秒

Please write code in 4 spaces so it is comfortable to copy

2019年07月20日37分09秒

Don't use this. The BaseDirectory can be set at runtime. It is not guaranteed to be correct (like the accepted answer is).

2019年07月20日37分09秒

+1 This is likely the answer you want as it compensates for shadow copying.

2019年07月21日37分09秒

usr What makes you think that BaseDirectory can be set at runtime? It only has a getter.

2019年07月20日37分09秒

bitbonk it can be set at appdomain creation time.

2019年07月20日37分09秒

Isn't it that BaseDirectory can be changed in a *.lnk file, in the "Start in:" field?

2019年07月20日37分09秒

Just wanted to say, obviously there are many more than 2 options by how many other choices are posted...

2019年07月21日37分09秒

If whatever you're trying to do with said path doesn't support URI format, use var localDirectory = new Uri(directory).LocalPath;

2019年07月21日37分09秒

This is just wrong. What is the executable is not a .NET assembly at all? The right answer is to check the environment and inspect the command line.

2019年07月21日37分09秒

Ukuma.Scott This doesn't work if the path contains & or #

2019年07月20日37分09秒

And maybe this: path = Environment.GetCommandLineArgs()[0].Substring(0, iniFilePath.LastIndexOf("\\") + 1);

2019年07月20日37分09秒

usr the situation you allude to is highly theoretical. In the context of a console application, it doesn't really make sense to use any other method. Keep it simple!

2019年07月20日37分09秒

usr mmm - looking at the taskmgr cmdline column sort of backs up what I'm saying. A few system services with just the exe name. Never mind. What I'm trying to say is that when developing a console application there is no need to make things more complicated than they need to be. Especially when we already have the information available. Now, if you are running a console application in such a way as to trick GetCommandLineArgs then you are already jumping through hoops and you would probably need to ask yourself if a console app is the right way to go.

2019年07月20日37分09秒

Your "simple" solution involves two method calls. The "complicated" solution involves two method calls. No practical difference - except that the "simple" solution can give you the wrong answer under certain circumstances which aren't under your control when you're writing the program. Why take the risk? Use the other two method calls, and your program will be no more complicated but will be more reliable.

2019年07月21日37分09秒

Worked for my scenario, the other solutions did not, so thanks for providing another alternative :-)I was using ReSharper test runner to run an MS Unit test and the code I was testing needed a specific .dll to be in the executing directory...and Assembly.GetExecutingDirectory() weirdly returns a different result.

2019年07月20日37分09秒

this works well also if the exe in question is a windows serviceand current directory returns C:\Windows\system32. The above code returns the actual location of the exe

2019年07月21日37分09秒

Except if you then try to do something like File.CreateDirectory(path), it will give you the exception that it doesn't allow URI paths...

2019年07月20日37分09秒

Unfortunately this is doesn't work for paths that contain a fragment identifier (the # character). The identifier and everything following it is truncated from the resulting path.

2019年07月20日37分09秒

Why don't you swap new Uri and System.IO.Path.GetDirectoryName? That gives you a normal path string instead of a Uri.

2019年07月20日37分09秒

I find this the best one. This same approach has worked reliably for me in any environment. In production, debugging locally, unit testing... Want to open a content file that you included ("content - copy if newer") in a unit test? It's there.

2019年07月20日37分09秒

This will get the folder of the executable though

2019年07月21日37分09秒

Unless something has called Directory.SetCurrentDirectory()...

2019年07月20日37分09秒

MatthewWatson or even simpler, the program was executed from anotherfolder...

2019年07月21日37分09秒

I used that one, and it works well. But one time I used the method having it in my unit test project. And of course, it failed because it was looking for my file in C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 14.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW

2019年07月21日37分09秒

This is not correct because you can get random directories in result.

2019年07月21日37分09秒

this Command returns Environment.CurrentDirectory, which may be changed at runtime to any path, so it is not a reliable solution.

2019年07月21日37分09秒

Why p/invoke when there is so much .NET for this?

2019年07月20日37分09秒

Because why not?

2019年07月20日37分09秒

user3596865 because it requries a hard dependency to Windows and is not compatible with DNX or Mono. And maybe there is a breaking change in future Windows Versions. So again: why we should use pinvoke here?

2019年07月21日37分09秒

This answer has already been suggested 5 years ago, even more than once.

2019年07月21日37分09秒

Using Environment.CurrentDirectory is very wrong, don't use this! this path can change at runtime. Even at startup it is non-deterministic.

2019年07月20日37分09秒