C# - aktualizacja programów

Cześć,

Jaką preferujecie drogę aktualizacji Waszych programów (interesuje mnie wersja programu desktopowego na platformę Windows) - aktualnie w ramach prób testowych na początek przy inicjalizacji porównuję wersję aktualnego programu z rejestrem określonym w bazie danych - jeśli wersja się różni pobierana jest z serwera nowa wersja - plik wykonywalny .exe - przy jego instalacji (instalator ręcznie trzeba uruchomić) - porównywany jest GUID aplikacji, stara wersja jest odinstalowana, a nowa - zainstalowana. Całość zrobiona za pomocą InnoSetup.

Podzielicie się sugestiami? Poradami? Dzięki!

Możesz na przykład napisać drugi program, który będzie wołany z Twojego i będzie ściągał i uruchamiał instalator. Twój program zamkniesz po wywołaniu tego drugiego a uruchomi go ponownie instalator.

Ja robię podobnie tylko mam web serwis że sprawdzeniem wersji i ściągania instalatora. Ściągany jest pełny instalator, pokazuje powiadomienie i jak ktoś kliknie to uruchamiam instalator z aplikacji (Process Start) i szybko zamykam program.
Instalator w InnoSetup. Podmienia wszystkie pliki.

A to ClickOnce już wyszło z mody?

@Someklnd: A to kiedykolwiek było modne?
Ja czasem używam do narzędziówek albo małych testów.

Ja nie mam akurat takich rzeczy, a cały czas myślę, żeby coś takiego zrobić do pomniejszych aplikacji. Pytanie tylko dlaczego pobierać cały instalator? Nie lepiej trzymać gdzieś w pliku aktualne MD5 checksum i pobierać/aktualizować tylko te pliki, które są nowe, a nie pobierać cały instalator? Z każdą nową wersją nowy plik z checksumami, napierw aktualizator pobiera plik, porównuje wersje i potem pobiera to co nowe/inne.

Nie wiem. Mi tak było prościej.
U mnie skrypty powershellowe robią buildy w wersji produkcyjnej i testowej, i tworzą instalatory. Potem skopiowanie na lokalny server klienta koniec.

Klient dostaje powiadomienie z tray-a, że jest nowa wersja, klika Aktualizuj, kilka razy Dalej i tyle. Poza tym instalator może czasem odpalić tool-a z migracjami w SQL-u.
To nie jest CI ale wystarcza.

jacek.placek napisał(a):

@Someklnd: A to kiedykolwiek było modne?

Ja czasem używam do narzędziówek albo małych testów.

Czyli zawsze było niemodne? :(
Pamiętam z zamierzchłych czasów, gdy jeszcze w WinFormsach pracowałem, ze to była właśnie metoda dystrybucji i aktualizacji aplikacji.

o jezu nawet nie wymawiaj tej nazwy.
ClickOnce to porażka, głównie ze względu na bugi. Co najmniej raz w tygodniu do supportu pisze ktoś komu aplikacja się nie uruchamia - trzeba wyczyścić cache clickonce z konsoli. Bug dobrze znany i niezałatany od wielu lat. I już nigdy nie będzie załatany bo ClickOnce do .NET Core nie dotarł. Poza tym zerowa kontrola nad instalatorem i jego wyglądem. A pliki pobierają się pojedynczo w nieskompresowanej formie z serwera. Co zrodziło pomysł żeby podmieniać pojedyncze pliki na serwerze ale nie jest to możliwe - chcieliśmy zrobić tak żeby dało się rozdzielnie kompilować moduły i podmienić tylko jeden plik na serwerze. Niestety nie ma tak łatwo - pliki są podpisane w manifeście. Manifest jest podpisany w pliku aplikacji, trzeba wszystko przekompilować i zmienić podpisy wszystkiego żeby podmienić jeden plik więc trzymanie ich osobno nie ma żadnego sensu.

Już lepiej to ogarnąć przez paczki .msi i .msp do patchów. Plus taki że patche zainstalowane w ten sposób pojawiają się windows update i użytkownik może łatwo odinstalować jedną lub więcej aktualizacji w miarę potrzeby jeśli mu coś przestaje działać

Też używam InnoSetupa. Zrobiłem w instalatorze jakby dwa tryby pracy - instalacja i aktualizacja. Minusem tego jest, że muszę budować dwie wersje instalatora (z poziomu kodu to zmiana jednego define'a).

Aplikacja sprawdza sobie w specjalnym pliku na serwerze aktualną wersję. Jeśli wersja aplikacji jest mniejsza, następuje pobranie aktualizacji. Następnie aplikacja uruchamia aktualizator i się zamyka. Aktualizator czeka na zamknięcie aplikacji za pomocą mutexa i gdy apka zostanie zamknięta - rusza do roboty.

@Juhas A nie możesz po prostu sprawdzić, czy program jest już zainstalowany? InnoSetup przecież nadal (chyba) umożliwia włączanie w instalkę własnego kodu. Trzy lata temu zrobiłem instalatory z takim sprawdzaniem tak w InnoSetup jak i w WiX. Do WiX'a znalazłem pakiet WixSharp.a tam było demo, które jak znalazło zainstalowany program, to go najpierw odinstalowywało. Obejrzałem, spodobało mi się i ten sam pomysł zastosowałem także w InnoSetup. No ale w końcu szefowie zdecydowali się na WiX i Visual Studio.

Ja zawsze robiłem tak, że sprawdzałem konkretny klucz w rejestrze. Jeśli istniał - znaczy, że program zainstalowany. Ale nie rozumiem po co odinstalowywać program, jeśli chcesz przeprowadzić aktualizację?

@Juhas: jak robiłeś aktualizację za pomocą InnoSetup bez odinstalowania starej wersji i z zainstalowaniem nowej?

Aktualizacja po prostu nadpisuje pliki, które mogą być nadpisane lb sterowane jest to flagami plików
ignoreversion, onlyifdoesntexist, confirmoverwrite itp. INfo jest w helpie InnoSetup.

Source:........; Flags: ignoreversion - zawsze nadpisze istniejący plik

Ja domyślnie w instalatorach ustawiam nadpisanie wszystkiego poza jakimś konfigami specyficznymi dla klienta/instalacji. Konfigi zmienne w folderze instalacji to zły pomysł ale coż, YOLO! :)

@alojzy_szczep: O takim sposobie (odinstalować tę usługę, jeśli jest, a potem instalować) zdecydował prowadzący naszą grupę.I na podstawie tego, czego się dowiedziałem od naszej grupy, a także z przeglądania kodów źródłowych tej usługę, uważam, że miał on rację. Samo wykonanie jest proste - sprawdzamy w rejestrze, czy jest i jeśli jest to wywalamy. Tak z grubsza. Tu EE.7z możesz podejrzeć. Powycinałem trochę, aby ktoś inaczej myślący z tej firmy (już u nich nie pracuję) się nie czepiał, ale myślę, że dasz radę. Tak tylko uprzedzam, bo tam jest jeszcze instalowanie Net Framework, bo usługa wymagała przynajmniej wersji 4.0, gdyż wtedy jeszcze XP było używane i całość jest trochę bardziej złożona.

Identyczny temat był jakiś rok temu na 4p. Wystarczy go odkopać, nie moge niestety go znaleźć. Tam było rozwiązanie :)