5

я мог бы сделать это:Каков правильный способ получить имя моего winforms?

return Assembly.GetEntryAssembly().GetName().Name; 

или

return Path.GetFileNameWithoutExtension(Application.ExecutablePath); 

бы и дать название приложения всегда ?? Если это так, это более стандартный способ получения имени приложения? Если в ней по-прежнему нет победной ситуации, есть что-то вроде одного метода быстрее другого? Или есть ли другой подход?

Спасибо.

+2

Трудно догадаться, что вы подразумеваете под «именем приложения», имеет значение контекст. Оба возвращают имя EXE * *. То же самое, что и имя процесса. –

+0

@ HansPassant О, я имею в виду основное название моего продукта. Например, для MS Word это «Microsoft Word», а не «WINWORD». В моем случае это имя, которое я жестко запрограммировал в свойствах приложения как имя сборки. Каким будет подход к этому? – nawfal

ответ

1

Это зависит от того, как вы определяете «имя приложения».

Application.ExecutablePath возвращает путь к исполняемому файлу, который запустил приложение, включая имя исполняемого файла, это означает, что если кто-то переименует файл, значение изменится.

Assembly.GetEntryAssembly().GetName().Name возвращает простое название сборки. Обычно это, но не обязательно, имя файла манифеста сборки, минус его расширение.

Итак, имя GetName().

Для более быстрого, я не знаю. Я предполагаю, что ExecutablePath быстрее, чем GetName(), потому что в GetName() требуется Reflection, но это нужно измерить.

EDIT:

Попытка построить эту консоль приложение, запустить его, а затем попытаться переименовать имя исполняемого файла с помощью проводника файлов Windows, снова запустить непосредственно с двойным щелчком мыши на переименованной исполняемый файл.
ExecutablePath отражает изменения, имя сборки по-прежнему тот же

using System; 
using System.Reflection; 
using System.Windows.Forms; 

namespace ConsoleApplication2 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      Console.WriteLine(Assembly.GetEntryAssembly().GetName().Name); 
      Console.WriteLine(Application.ExecutablePath); 
      Console.ReadLine(); 
     } 
    } 
} 
+0

Знаете ли вы, в каком сценарии они отличаются? исполняемое имя (из 'ExecutablePath'), похоже, точно совпадает с названием сборки. – nawfal

+0

См. Обновление в ответе – Steve

+0

спасибо .. Хаа, я пропустил этот взлом! :) – nawfal

4

В зависимости от того, что вы рассматриваете, чтобы быть имя приложения, есть даже третий вариант: получить название сборки или название продукта (те, которые обычно объявляются в AssemblyInfo.cs):

object[] titleAttributes = Assembly.GetEntryAssembly().GetCustomAttributes(typeof(AssemblyTitleAttribute), true); 
if (titleAttributes.Length > 0 && titleAttributes[0] is AssemblyTitleAttribute) 
{ 
    string assemblyTitle = (titleAttributes[0] as AssemblyTitleAttribute).Title; 
    MessageBox.Show(assemblyTitle); 
} 

или:

object[] productAttributes = Assembly.GetEntryAssembly().GetCustomAttributes(typeof(AssemblyProductAttribute), true); 
if (productAttributes.Length > 0 && productAttributes[0] is AssemblyProductAttribute) 
{ 
    string productName = (productAttributes[0] as AssemblyProductAttribute).Product; 
    MessageBox.Show(productName); 
} 
+0

Спасибо, я вернусь. – nawfal

+0

Почему 'titleAttributes [0] здесь выполняется AssemblyTitleAttribute'? Мы уже задали одно и то же: – nawfal

+0

@nawfal: Да, вы правы, маловероятно, что элементы в массиве будут любого другого типа, но определенные инструменты для анализа статического кода (например, ReSharper) отметят этот код как потенциальную угрозу NullReferenceException, поскольку ' obj, поскольку выражение T' будет вычисляться как 'null', если' obj' не 'T'. Написав 'obj is T' перед' obj как T', эти инструменты будут знать во время компиляции, чтобы исключений не было. –

Смежные вопросы