Как найти текущее имя исполняемого файла?

Возможный дубликат:
Как получить имя текущего исполняемого файла на С#?

Исполняемый файл загружает внешнюю библиотеку.
Есть ли способ узнать библиотеку исполняемого файла вызова?

(Я бы поклялся, что видел ответ на это в другом месте, но я больше не могу его найти)

Ответ 1

System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName

Ответ 2

Если вы хотите выполнить исполняемый файл:

System.Reflection.Assembly.GetEntryAssembly().Location

Если вы хотите, чтобы сборка, потребляющая вашу библиотеку (которая может быть той же самой сборки, что и выше, если ваш код вызывается непосредственно из класса в вашем исполняемом файле):

System.Reflection.Assembly.GetCallingAssembly().Location

Если вы хотите просто имя файла, а не путь, используйте:

Path.GetFileName(System.Reflection.Assembly.GetEntryAssembly().Location)

Ответ 3

В дополнение к ответам выше.

Я написал следующее test.exe как консольное приложение

static void Main(string[] args) {
  Console.WriteLine(
    System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName);
  Console.WriteLine(
    System.Reflection.Assembly.GetEntryAssembly().Location);
  Console.WriteLine(
    System.Reflection.Assembly.GetExecutingAssembly().Location);
  Console.WriteLine(
    System.Reflection.Assembly.GetCallingAssembly().Location);
}

Затем я скомпилировал проект и переименовал его вывод в файл test2.exe. Выходные линии были правильными и одинаковыми.

Но, если я запустил его в Visual Studio, результат:

д:\test2.vhost.exe

д:\test2.exe

д:\test2.exe

C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll

Плагин ReSharper для Visual Studio подчеркивает

System.Diagnostics.Process.GetCurrentProcess().MainModule

как возможно System.NullReferenceException. Если вы посмотрите на документацию MainModule, вы обнаружите, что это свойство может вызывать также NotSupportedException, PlatformNotSupportedException и InvalidOperationException.

Метод GetEntryAssembly также не на 100% безопасен. MSDN:

Метод GetEntryAssembly может возвращать значение null, когда управляемая сборка был загружен из неуправляемого приложения. Например, если неуправляемое приложение создает экземпляр COM-компонента, написанного в С#, вызов метода GetEntryAssembly из компонента С# возвращает null, поскольку точка входа для процесса была неуправляемой а не управляемой сборки.

Для моих решений я предпочитаю Assembly.GetEntryAssembly().Location.

Больше интереса, если нужно решить проблему для виртуализации. Например, у нас есть проект, в котором мы используем Xenocode Postbuild для связывания кода .net в один исполняемый файл. Этот исполняемый файл должен быть переименован. Таким образом, все вышеприведенные методы не работают, потому что они получают информацию только для исходной сборки или внутреннего процесса.

Единственное найденное решение -

var location = System.Reflection.Assembly.GetEntryAssembly().Location;
var directory = System.IO.Path.GetDirectoryName(location);
var file = System.IO.Path.Combine(directory, 
  System.Diagnostics.Process.GetCurrentProcess().ProcessName + ".exe");

Ответ 4

Environment.GetCommandLineArgs() [0]

Ответ 5

Я думаю, что это должно быть то, что вы хотите:

System.Reflection.Assembly.GetEntryAssembly().Location

Это возвращает сборку, которая была впервые загружена при запуске процесса, который, по-видимому, будет тем, что вы хотите.

GetCallingAssembly не обязательно будет возвращать нужную вам сборку в общем случае, так как она возвращает сборку, содержащую метод, который находится выше в стеке вызовов (т.е. он может находиться в одной и той же DLL).

Ответ 6

Assembly.GetEntryAssembly()

Ответ 7

Этот не был включен:

System.Windows.Forms.Application.ExecutablePath;

~ Джо