2012-03-03 27 views
5

mogę to zrobić:jaki jest właściwy sposób na podanie nazwy mojej aplikacji WinForm?

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

lub

return Path.GetFileNameWithoutExtension(Application.ExecutablePath); 

będą zarówno otrzymując żądany nazwa aplikacji zawsze ?? Jeśli tak, to jest bardziej standardowy sposób uzyskiwania nazwy aplikacji? Jeśli nadal jest sytuacja, w której nie ma wygranych, to jest jakaś metoda, która jest szybsza od drugiej? Czy istnieje inne właściwe podejście?

Dzięki.

+2

Trudno odgadnąć, co masz na myśli przez "nazwę aplikacji", kontekst ma znaczenie. Oba zwrócą nazwę pliku * EXE *. To samo, co nazwa procesu. –

+0

@HansPassant oh, mam na myśli główną nazwę mojego produktu. Na przykład dla MS Word, jest to "Microsoft Word", a nie "WINWORD". W moim przypadku nazwa, którą zakodowałam w Właściwości aplikacji jako Nazwa zespołu. Jakie byłoby podejście do tego? – nawfal

Odpowiedz

1

Zależy od tego, jak zdefiniujesz "nazwę aplikacji".

Application.ExecutablePath zwraca ścieżkę do pliku wykonywalnego, który uruchomił aplikację, łącznie z nazwą pliku wykonywalnego, co oznacza, że ​​jeśli ktoś zmieni nazwę pliku, wartość zmieni się.

Assembly.GetEntryAssembly().GetName().Name zwraca prostą nazwę zespołu. Jest to zwykle, ale niekoniecznie, nazwa pliku manifestu zespołu, bez jego rozszerzenia

Tak więc nazwa GetName(). Wydaje się bardziej prawdopodobna.

Dla szybszego, nie wiem. Zakładam, że ExecutablePath jest szybszy niż GetName(), ponieważ w GetName() wymaga Reflection, ale należy to zmierzyć.

EDIT:

Spróbuj zbudować aplikację konsoli, uruchom go, a następnie spróbuj zmienić nazwę nazwa pliku wykonywalnego za pomocą Eksploratora plików systemu Windows, uruchom ponownie bezpośrednio z podwójnym kliknięciem na zmienionej nazwie pliku wykonywalnego.
ExecutablePath odzwierciedla zmianę, nazwa Zgromadzenie jest wciąż ten sam

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

Czy wiesz, w jakim scenariuszu się różnią? nazwa pliku wykonywalnego (z 'ExecutablePath') wydaje się być dokładnie nazwą zestawu. – nawfal

+0

Zobacz aktualizację w odpowiedzi – Steve

+0

dzięki .. Haa Tęskniłem za tym hackerem! :) – nawfal

4

W zależności od tego, czego rozważa się nazwa aplikacja, jest nawet trzecia opcja: uzyskać tytuł zbiórki lub nazwę produktu (te zwykle są zadeklarowane w 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); 
} 

lub:

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

Dzięki, wrócę .. – nawfal

+0

dlaczego "titleAttributes [0] to AssemblyTitleAttribute" sprawdza tutaj? Już zapytaliśmy o to samo, prawda? – nawfal

+0

@nawfal: Tak, masz rację, jest bardzo mało prawdopodobne, że elementy w tablicy będą innego typu, ale niektóre narzędzia do analizy statycznych kodów (takie jak ReSharper) oznaczy ten kod jako potencjalne zagrożenie 'NullReferenceException', ponieważ' obj jako wyrażenie T' będzie oceniać na 'null' jeśli' obj' nie jest 'T'. Pisząc 'obj jest T' przed' obj as T', te narzędzia będą wiedzieć podczas kompilacji, że nie będą wysyłane żadne wyjątki. –

Powiązane problemy