Assembly.GetEntryAssembly()。Location或Assembly.GetExecutingAssembly().Location

与System.IO.Path.GetDirectoryName()结合使用只获取目录。

来自GetEntryAssembly()和GetExecutingAssembly()的路径可以不同，即使在大多数情况下目录是相同的。

使用GetEntryAssembly()，你必须意识到，如果入口模块是非托管的(即c++或VB6可执行文件)，它可能返回null。在这些情况下，可以使用Win32 API中的GetModuleFileName:

[DllImport("kernel32.dll", CharSet = CharSet.Auto)]
public static extern int GetModuleFileName(HandleRef hModule, StringBuilder buffer, int length);

在。net Core 3及以上版本中，你会得到。dll文件而不是。exe文件。获取您可以使用的.exe文件路径。

var appExePath = Process.GetCurrentProcess().MainModule.FileName;

AppDomain.CurrentDomain.BaseDirectory

将解决问题，以引用第三方参考文件与安装包。

在。net6中，我的WPF应用程序(<TargetFramework>net6.0-windows</TargetFramework>)返回Assembly.GetEntryAssembly()的.dll文件路径!位置，而不是。exe文件。他们引入了System.Environment.ProcessPath:

var path = Environment.ProcessPath; // Note it may be null

返回启动当前执行进程的可执行文件的路径。当路径不可用时返回null。

请参见这里和这里的讨论。

可能有点晚了，但这个值得提一下:

Environment.GetCommandLineArgs()[0];

或者更准确地获取目录路径:

System.IO.Path.GetDirectoryName(Environment.GetCommandLineArgs()[0]);

编辑:

相当多的人已经指出GetCommandLineArgs并不能保证返回程序名。请参见命令行上的第一个单词只是按照约定的程序名。这篇文章确实指出“尽管很少有Windows程序使用这个怪癖(我自己不知道)”。因此，“恶搞”GetCommandLineArgs是可能的，但我们谈论的是一个控制台应用程序。控制台应用程序通常是快速和肮脏的。所以这符合我的KISS哲学。

编辑 从反馈来看，当您使用单元测试系统时，大多数其他解决方案似乎都不起作用。这是有道理的，因为可执行项不是你的应用程序，而是测试系统。我还没有核实过，所以我可能完全错了。如果是这样，我将删除这一编辑。

你可以简单地添加到你的项目引用System.Windows.Forms，然后像往常一样使用System.Windows.Forms. application . startuppath。

因此，不需要更复杂的方法或使用反射。