Spis treści Poprzednia strona: Refleksja nad kodem Następna strona: Zarządzanie wersjami

Nazwa programu jest dość mglistym pojęciem. Przede wszystkim dlatego, że jest wiele różnych nazw. Związane jest to z tym, że w grę wchodzi tu sporo różnych technologii, które pojawiały się na przestrzeni lat i wciąż istnieją, czasami wchodząc sobie w paradę. Oto różne nazwy:

1. Nazwa pliku exe to nazwa tzw. modułu. Myślisz, że jest jedna? Nie, są dwie: „normalna”, którą widać i 8-znakowa (+ kropka i max 3 znaki rozszerzenia) dla 16-bitowych programów starego MS-DOS (można ją zobaczyć poleceniem dir /x odpalonym w katalogu z danym plikiem). Tę „normalną” nazwę pliku najlepiej pobrać tak: System.IO.Path.GetFileNameWithoutExtension(typeof(Program).Assembly.Location)
   ale raczej nie będzie nam to potrzebne, tym bardziej, że użytkownik może tę nazwę zmienić. Tak czy inaczej działanie (lub jego brak) nie powinno zależeć od tej nazwy.
2. Nazwa assembly ustawiana w parametrach projektu. Domyślnie tworzymy assembly jednoplikowe i jest to to samo, co #1, ale w ogólności tak być nie musi. Żeby jednak w to ingerować trzeba to zrobić programami narzędziowymi poza Visual Studio. Generalnie domyślnie tak, jak ustawimy #2, takie będzie też #1. Oczywiście po stworzeniu pliku exe można mu zmienić nazwę jak nazwę każdego innego pliku na dysku (na przykład na krótszą). Nazwa #2 zawsze jednak w nim siedzi i jest widoczna we właściwościach pliku jako tzw. Oryginalna nazwa pliku (na zakładce Szczegóły). Można tę zmianę też zrobić w VS jako post-build event command:
   move /Y "$(TargetPath)" "$(TargetDir)inny.exe">nul
   ale to nie da żadnej sensownej informacji w oknie Output w VS, więc do tego dopisujemy też
   echo File "$(TargetDir)inny.exe" has been created.
   Możemy tutaj rezultat też gdzieś skopiować, przenieść, skompresować, co tylko chcemy. Jeśli nie chcemy jednak stracić informacji o numerze linii błędu, to musimy tak samo zmienić nazwę pliku *.pdb.
   move /Y "$(TargetDir)$(TargetName).pdb" "$(TargetDir)inny.pdb">nul
   A oto jest sposób jak pobrać tę nazwę assembly w naszym programie: typeof(Program).Assembly.GetName().Name
3. Tytuł [ang. title] ustawiany w oknie Assembly Information to pełna nazwa aplikacji w oknie Menedżer zadań na zakładce Procesy, a także opis pliku pojawiający się w eksploratorze Windows (po najechaniu myszką na plik i we właściwościach pliku – a tam jest gwarancja, że zmieści się tylko 19 znaków, tzn. zmieści się więcej, ale na zakładce szczegóły nie zawsze będzie widać więcej, zależy od czcionki i od tego jakie szerokie są to znaki). Nazwa aplikacji w oknie Menedżer zadań na zakładce Procesy nie jest dokładnie taka sama, ale dopisane jest do niej ” (32-bitowy)”. Hmmm… Jak się tego pozbyć? Trzeba wyłączyć domyślnie zaznaczony checkbox „Prefer 32-bit” we właściwościach projektu Build\General i skompilować to od nowa. Czy jednak chcemy się tego pozbyć? Jeśli robimy dla siebie, to tak, a jeśli dla bliżej nieokreślonych ludzi i środowisk, to nie – chcemy zostawić 32 bitowość. Na zakładce Szczegóły Menedżera zadań będzie i tak zawsze widoczna nazwa #1. Po rozwinięciu strzałki (w zakładce Procesy w sekcji Aplikacje) widzimy nazwę głównego okna #4 i… inną ikonkę. Żeby były takie same musimy ustawić swoją ikonkę aplikacji na zakładce Application\Resources a następnie tę samą ikonkę zmienić na formatce (właściwość Icon). Do wyboru są tylko pliki *.ico. Skąd je wziąć? Najlepiej narysować sobie png rozmiaru 256×256 z przezroczystością i jakimś online-owym konwerterem utworzyć z niego plik ico z wieloma wersjami rozmiarów i palet. Nie zapomnij też o wersji 16-bitowej na 16×16 pikseli (widok listy w Eksploratorze plików). Wszystkie te różne ikonki powinny być zakodowane razem w pliku ico. No i jeszcze warto wiedzieć jak ten tytuł pobrać iskorzystać z niego w naszym programie: typeof(Program).Assembly.GetCustomAttribute<AssemblyTitleAttribute>().Title
4. Nazwa głównego okna aplikacji. W aplikacji Windows Forms, jest to właściwość Text klasy dziedziczącej po Form, a w aplikacji WPF jest to właściwość Title klasy Window lub dziedziczącej po niej. A co jeśli to aplikacja konsolowa? Można jej ustawić Console.Title i uzyskać podobny efekt, ale uwaga na kodowanie znaków. Konfiguracja okna konsoli nie zależy od programisty aplikacji, ale od systemu i jego użytkownika. Windows 10 nie ma z tym problemów, ale poprzednie wersje…szkoda gadać. Tak czy inaczej przetestować to trzeba jeśli się na takie rozwiązanie zdecydujemy.
5. Nazwy innych okien aplikacji. Czy są takie same, czy inne? Czym się różnią? Nazwą pliku? Czy w ogóle pozwolić na to żeby użytkownik otworzył naszą aplikację dwa i więcej razy? A może zrobić interfejs typu MDA? Czy każde okno ma swój przycisk na pasku zadań? Jaka jest nazwa na tym przycisku i czy się zmienia? Pamiętaj, że fakt, że wszystko da się zrobić nie jest jeszcze powodem, żeby na siłę próbować robić coś niestandardowego co się może na nas zemścić. Jak? Dla użytkownika nie będzie oczywiste jak to użytkować i pójdzie do konkurencji, która mniej mu to udziwniła.
6. Nazwa skrótu do aplikacji, który stworzył instalator. A może więcej niż jeden skrót: na pulpicie, w menu start, na pulpitach innych użytkowników, na pasku zadań, na pasku szybkiego uruchomienia, na liście szybkiego dostępu, itp. Zwykle jest to nazwa taka sama jak #3. Zaraz, zaraz. Jaki instalator? Otóż programów .NET-owych nie trzeba instalować (chyba że to usługa Windows). Wystarczy skopiować i uruchomić. Co innego jeśli te programy potrzebują dodatkowych ustawień i muszą sobie przechować dane specyficzne dla danej maszyny (komputera) lub konta (użytkownika). Co z ich ustawieniami? Jeśli mają one sens na innym komputerze i są przechowywane w pliku konfiguracyjnym obok samego programu, to można je też skopiować (pod warunkiem że program ich nie aktualizuje, bo jeśli tak to musi to sobie trzymać w folderach %APPDATA% dla każdego użytkownika osobno). No i decyzja: czy te ustawienia ustalamy podczas instalacji, czy możemy modyfikować podczas działania programu. Jeśli modyfikować to jak?
7. Wersjonowanie. Czy numer wersji jest widoczny w nazwie? Jeśli tak, to trzeba będzie zmieniać wszystkie okna i skróty. Czy warto? Czy użytkownika interesuje którą ma wersję? Nie. Chce tylko wiedzieć, że jest najnowsza albo nie. A w razie gdy najnowsza z jakiegoś powodu mu nie odpowiada chce mieś możliwość powrotu do starszej, do której albo jest już przyzwyczajony, albo która po prostu działa. Czasem użytkownik chce być informowany o nowszych wersjach, a czasem go to wkurza, a inny może chcieć żeby się wszystko samo aktualizowało bez żadnej ingerencji człowieka. Daj mu te wszystkie opcje do wyboru! Po prostu.
8. Nazwa na liście aplikacji. Gdzie jest taka lista? W ustawieniach systemowych. Tam można aplikację odinstalować, a czasem też naprawić jakoś zepsutą instalację, czy zaktualizować wersję. Co ma zrobić użytkownik, który chce usunąć aplikację, a nie wie gdzie są jej pliki? Co z tego że sam je gdzieś skopiował, nie pamięta gdzie, to było dawno. Wie natomiast, że może znaleźć aplikację na liście aplikacji w ustawieniach systemu. Zadbaj o to, żeby tam była i pod właściwą nazwą. Do tego trzeba pisać do rejestru Windows do klucza dostępnego dla administratorów i programów instalacyjnych. I wracamy do potrzeby posiadania instalatora dla naszej aplikacji. O tym będzie następny rozdział.
   

Spis treści Poprzednia strona: Refleksja nad kodem Następna strona: Zarządzanie wersjami