Dziwne zachowanie na Console.ReadLine() podczas odpalenia z Launchera

[Radomił Ząbik 308]

Mam prostą aplikację konsolową, utworzoną z waszego szablonu w Visual Studio 2019 na frameworku 4.7.2. Aplikacja po uruchomieni i połączeniu z bazą, oczekuje od użytkownika wprowadzenia dwóch zmiennych, które odpowiednio pętlą Sobie waliduję. Podczas debugowania nie wystąpił żaden problem z aplikacją. Po spakowaniu do MPGK i wgraniu na próbę do bazy, a następnie odpalenie poprzez utworzony w programie serwisowym skrót inslaunchera, aplikacja wpada w jakąś pętle, jakby był naciśnięty enter (prawa część screenu). Gdy odpale normalnie plik exe, z katalogu deployments, aplikacja działa bez zarzutu (lewa cześć screenu). Nie wiem teraz, czy to coś po mojej stronie, czy coś launcher powoduje.

 

[Katarzyna Rozmarynowska 168]

Aplikacja tworzona z szablonu jest tak skonstruowana, że przy uruchamianiu przez InsLaunchera dostaje strumieniem wejściowym parametry, które można w kodzie odebrać, używając metody DanePolaczenia.Odbierz. Jeśli nie ma Pan potrzeby wczytywać danych połączenia w taki sposób, to może Pan w pliku Konfiguracja.xml usunąć z węzła LaunchAction atrybuty "RedirectedInput" i "RedirectedInputEncoding".

 

[Radomił Ząbik 308]

Pliku konfiguracja.xml nie znalazłem, ale zmieniłem plik manifest.xml w pakiecie mpgk i działa

[Katarzyna Rozmarynowska 168]

Plik Konfiguracja.xml dodaje się automatycznie do projektów generowanych z szablonu - jeśli u Pana tak nie jest, to zachęcam do zainstalowania nowszej wersji naszego rozszerzenia do Visual Studio. W pliku Konfiguracja.xml jest manifest pakietu, który można edytować już z poziomu projektu w VS. Na podstawie zawartości pliku Konfiguracja.xml po udanej kompilacji projektu generujemy pakiet mpkg i instalator, którym można podłączyć go do bazy. 

[Radomił Ząbik 308]

34 minuty temu, Katarzyna Rozmarynowska napisał:

to zachęcam do zainstalowania nowszej wersji naszego rozszerzenia do Visual Studio

A tu możesz jest pies pogrzebany. Sprawdzę. Obsługuje już VS 2022?

35 minut temu, Katarzyna Rozmarynowska napisał:

Na podstawie zawartości pliku Konfiguracja.xml po udanej kompilacji projektu generujemy pakiet mpkg i instalator, którym można podłączyć go do bazy. 

Czy to oznacza, że mpgk powstanie już w wyniku kompilacji VS i nie będzie trzeba osobno korzystać z waszego narzędzia w programie serwisowym? Nie wiem, w jakiej formie jest ujęte "generujemy"

[Daniel Kozłowski 1 171]

3 minuty temu, Radomił Ząbik napisał:

39 minut temu, Katarzyna Rozmarynowska napisał:

to zachęcam do zainstalowania nowszej wersji naszego rozszerzenia do Visual Studio

A tu możesz jest pies pogrzebany. Sprawdzę. Obsługuje już VS 2022?

Co oznacza "już" ? Szablony dla VS2022 są dostępne od wersji 41.

 

4 minuty temu, Radomił Ząbik napisał:

40 minut temu, Katarzyna Rozmarynowska napisał:

Na podstawie zawartości pliku Konfiguracja.xml po udanej kompilacji projektu generujemy pakiet mpkg i instalator, którym można podłączyć go do bazy. 

Czy to oznacza, że mpgk powstanie już w wyniku kompilacji VS i nie będzie trzeba osobno korzystać z waszego narzędzia w programie serwisowym? Nie wiem, w jakiej formie jest ujęte "generujemy"

Tak, mamy już takie usprawnienia... Uprzedzając nie ma jeszcze automatu do instalacji/aktualizacji w podmiocie, ale nie wszystko na raz  

[Katarzyna Rozmarynowska 168]

1 godzinę temu, Radomił Ząbik napisał:

A tu możesz jest pies pogrzebany. Sprawdzę. Obsługuje już VS 2022?

Mamy osobne rozszerzenia do 2019 i 2022. 

 

1 godzinę temu, Radomił Ząbik napisał:

Czy to oznacza, że mpgk powstanie już w wyniku kompilacji VS i nie będzie trzeba osobno korzystać z waszego narzędzia w programie serwisowym? Nie wiem, w jakiej formie jest ujęte "generujemy"

Dokładnie tak. Folder wynikowy po kompilacji wygląda tak:

W folderze "Pakiet" mam plik mpkg, a w "Instalator" jest ten plik mpkg zapakowany w gotowy instalator. Wszystko to powstaje automatycznie po kompilacji (polecam zajrzeć do właściwości projektu, zakładka Build Events). Nie trzeba pakować rozwiązań programem serwisowym. Zachęcam, żeby zainstalować nową wersję rozszerzenia, którą dołączyliśmy do SDK w wersji 42

Na razie niestety jest tak, że po zmianie czegoś w kodzie trzeba takim instalatorem odinstalować rozszerzenie i zainstalować ponownie, ale pracujemy nad tym, żeby i to usprawnić, więc można się spodziewać kolejnych wersji naszego rozszerzenia. 

 

 

[Radomił Ząbik 308]

3 godziny temu, Daniel Kozłowski napisał:

Co oznacza "już" ? Szablony dla VS2022 są dostępne od wersji 41.

Racja, nawet Pani Urszula pisała, że zrobią do 41, jak o to prosiłem, chyba zadziałało przyzwyczajenie, że sugerowane funkcjonalności wdrażają się długo ...

 

1 godzinę temu, Katarzyna Rozmarynowska napisał:

W folderze "Pakiet" mam plik mpkg, a w "Instalator" jest ten plik mpkg zapakowany w gotowy instalator. Wszystko to powstaje automatycznie po kompilacji (polecam zajrzeć do właściwości projektu, zakładka Build Events). Nie trzeba pakować rozwiązań programem serwisowym. Zachęcam, żeby zainstalować nową wersję rozszerzenia, którą dołączyliśmy do SDK w wersji 42

Na razie niestety jest tak, że po zmianie czegoś w kodzie trzeba takim instalatorem odinstalować rozszerzenie i zainstalować ponownie, ale pracujemy nad tym, żeby i to usprawnić, więc można się spodziewać kolejnych wersji naszego rozszerzenia. 

O kurcze, i ja to przegapiłem, SUPER, ułatwi to wdrożenia u mniej ogarniętych klientów.

A macie może jakiś pomysł, albo planujecie coś, aby można było zawierać w pakiecie jakąś domyślną konfigurację, która potem nie będzie się nadpisywać przy każdorazowym odpaleniu z launchera? Obecnie korzystam z normalnego XML i wczytywania parametrów przez ConfigurationManager i to się sprawuje dobrze, tylko zmian muszę dokonywać w mpgk, bo jak zmienię to w deployment to nadpisze się z lanuchera.

 

[Daniel Kozłowski 1 171]

18 minut temu, Radomił Ząbik napisał:

O kurcze, i ja to przegapiłem, SUPER, ułatwi to wdrożenia u mniej ogarniętych klientów.

Co się zmieni od strony klienta / użytkownika ?

 

18 minut temu, Radomił Ząbik napisał:

A macie może jakiś pomysł, albo planujecie coś, aby można było zawierać w pakiecie jakąś domyślną konfigurację, która potem nie będzie się nadpisywać przy każdorazowym odpaleniu z launchera? Obecnie korzystam z normalnego XML i wczytywania parametrów przez ConfigurationManager i to się sprawuje dobrze, tylko zmian muszę dokonywać w mpgk, bo jak zmienię to w deployment to nadpisze się z lanuchera.

Dlaczego nie przechowuje Pan takich informacji w bazie danych ?

 

O planach wsparcia dla rozwiązań dodatkowych jak dodatkowa aplikacja / moduł zarządzający między innymi rozwiązaniami dodatkowymi z możliwością uruchamiania konfiguracji tych rozwiązań (pluginy, które nie posiadają interfejsu użytkownika) może opowie sam InsERT

[Radomił Ząbik 308]

1 godzinę temu, Daniel Kozłowski napisał:

Co się zmieni od strony klienta / użytkownika ?

Wgranie przez klienta mpgk poprzez serwisowy, a skorzystanie z instalatora, którego w żadne sposób dodatkowo nie muszę przygotowywać, trochę zmienia postać rzeczy.

1 godzinę temu, Daniel Kozłowski napisał:

Dlaczego nie przechowuje Pan takich informacji w bazie danych ?

Co łatwiej wytłumaczyć zwykłemu użytkownikowi? Edycja XML'a to jest coś, co każdy bardziej zaawansowany użytkownik, jest w stanie ogarnąć, prędzej niż podłączenie do bazy SQL, znalezienie tablicy i zmiany w jej wartości. Tak, można by to obejść jakimiś polami własnymi, ale to takie na około. Po za tym, staram się dostarczać klientom programy, w których parametry mogą zmieniać - za dużo słyszałem historii, jak to ktoś zrobił program i w samym kodzie zaszył ID podmiotu, który ten program obsługuje i teraz nie można się do niego dodzwonić, aby to poprawić. A tak robię XML'a, daję instrukcję, jak go zmienić, w samym XML są komentarze, Launcher można obejść zwykłym skrótem do Deployments i jest spokój.

[Daniel Kozłowski 1 171]

35 minut temu, Radomił Ząbik napisał:

2 godziny temu, Daniel Kozłowski napisał:

Co się zmieni od strony klienta / użytkownika ?

Wgranie przez klienta mpgk poprzez serwisowy, a skorzystanie z instalatora, którego w żadne sposób dodatkowo nie muszę przygotowywać, trochę zmienia postać rzeczy.

Oczywiście, że to zmienia postać rzeczy tylko to żadna nowość, taka możliwość istnieje od 2016 roku, w wersji 11 nexo zostało dołączone narzędzie "QuickInstaller.exe", które to umożliwia, nowość to automatyczne uruchamiania narzędzia spod VS i instalator, który pozwala wybrać podmioty, w których zostanie zainstalowane rozwiązanie (wcześniej instalowało się we wszystkich podmiotach).

 

43 minuty temu, Radomił Ząbik napisał:

2 godziny temu, Daniel Kozłowski napisał:

Dlaczego nie przechowuje Pan takich informacji w bazie danych ?

Co łatwiej wytłumaczyć zwykłemu użytkownikowi?

No najlepiej niczego z Pana propozycji...

 

46 minut temu, Radomił Ząbik napisał:

Edycja XML'a to jest coś, co każdy bardziej zaawansowany użytkownik, jest w stanie ogarnąć,

A co z pozostałymi użytkownikami, co z możliwością popełnienia błędu przy ręcznej edycji pliku konfiguracyjnego... ? Dla mnie standard, który stosujemy w naszych rozwiązaniach dodatkowych to zmiana parametrów rozwiązania poprzez dedykowany interfejs użytkownika i o takim rozwiązaniu myślałem pytając o miejsce przechowywania parametrów rozwiązania.

 

52 minuty temu, Radomił Ząbik napisał:

...prędzej niż podłączenie do bazy SQL, znalezienie tablicy i zmiany w jej wartości.

 Kilka razy czytałem, aby zrozumieć, gdyż w życiu bym nie pomyślał o takim rozwiązaniu.

 

54 minuty temu, Radomił Ząbik napisał:

Po za tym, staram się dostarczać klientom programy, w których parametry mogą zmieniać - za dużo słyszałem historii, jak to ktoś zrobił program i w samym kodzie zaszył ID podmiotu, który ten program obsługuje i teraz nie można się do niego dodzwonić, aby to poprawić.

Zgadzam się i uważam za minimum.

 

55 minut temu, Radomił Ząbik napisał:

A tak robię XML'a, daję instrukcję, jak go zmienić, w samym XML są komentarze, Launcher można obejść zwykłym skrótem do Deployments i jest spokój.

Nasze doświadczenia są niestety inne, mamy jedno rozwiązanie, które nie doczekało się jeszcze instalatora, w celu instalacji w pliku "cmd" należy tylko wprowadzić ścieżkę do folderu, w której znajduje się ten plik "cmd", aby ustawić ten folder przy uruchamianiu jako administrator - duża część użytkowników ma z tym problem, a to to tylko jedno rozwiązanie z wielu.

 

Co łatwiej wytłumaczyć zwykłemu użytkownikowi - edycję pliku XML, czy zmianę parametrów poprzez zaznaczenie/odznaczenie checkbox'a, wybór wartości z listy itd z interfejsu użytkownika ?

[Katarzyna Rozmarynowska 168]

16 godzin temu, Radomił Ząbik napisał:

A macie może jakiś pomysł, albo planujecie coś, aby można było zawierać w pakiecie jakąś domyślną konfigurację, która potem nie będzie się nadpisywać przy każdorazowym odpaleniu z launchera? Obecnie korzystam z normalnego XML i wczytywania parametrów przez ConfigurationManager i to się sprawuje dobrze, tylko zmian muszę dokonywać w mpgk, bo jak zmienię to w deployment to nadpisze się z lanuchera.

Nie jestem pewna, czy dobrze rozumiem. Czy chodzi o taką sytuację: ma Pan w pakiecie plik, z którego korzysta rozszerzenie, który oczywiście trafia do folderu Deployments\Nexo\baza\Binaries, gdzie jest nadpisywany przez InsLaunchera za każdym razem, gdy się zmieni? Raczej nie będziemy nic zmieniać w tym, jak InsLauncher traktuje pliki w Binaries. Myślę, że może lepiej byłoby, żeby z poziomu rozwiązania własnego można było korzystać z katalogów Deployments\Nexo\baza\Config i Deployments\Nexo\baza\Work, bo tam jest miejsce na takie rzeczy i launcher nic tam nie rusza. Z drugiej strony, to niekoniecznie jest miejsce, do którego chciałabym wysyłać użytkownika, żeby coś sobie zmieniał.

Czy dobrze to rozumiem? Może Pan opisać problem bardziej szczegółowo?

[Daniel Kozłowski 1 171]

19 minut temu, Katarzyna Rozmarynowska napisał:

Może Pan opisać problem bardziej szczegółowo?

Wszyscy autorzy rozwiązań dodatkowych mają / będą mieli te same problemy, a że do nich należę to pozwolę sobie odpowiedzieć - chodzi o możliwość przechowywania i zmiany parametrów / konfiguracji rozwiązań dodatkowych.

 

Jak wspominałem wyżej według mnie pliki xml przechowywane na dysku nie są najlepszym rozwiązaniem, nawet gdyby udało się rozwiązać problem ich przechowywania i nadpisywania przez nexo, to cały czas będzie to konfiguracja lokalna stanowiska, którą trzeba będzie w wielu przypadkach utrzymywać na wszystkich stanowiskach, na których będzie uruchamiane to rozwiązanie, zmianie stacji klienckiej czy serwera trzeba będzie pamiętać jeszcze o przenoszeniu konfiguracji rozwiązań dodatkowych... Stąd pomysł przechowywania takich informacji w jednym centralnym miejscu jakim jest baza danych. A skoro już w bazie danych to byłoby miło otrzymać wsparcie - miejsce i metody do zapisu i odczytu parametrów, być może generyczny interfejs użytkownika, aby każdy autor nie musiał tworzyć własnych struktur i mechanizmów do ich obsługi.

 

Temat poruszany również na forum produktowym.

[Urszula Buczek 298]

Temat był faktycznie poruszany i mamy zapisany do rozważenia. 

[Radomił Ząbik 308]

8 godzin temu, Katarzyna Rozmarynowska napisał:

Czy dobrze to rozumiem?

Tak, chodzi o sytuacje, w której launcher, za każdym razem nadpisuje plik w katalogu deployments, w tym przypadku zaawansowaną konfigurację rozwiązania.

Aczkolwiek, to o czym wspomniał Pan Daniel, czyli uniwersalny mechanizm przechowywania parametrów dla rozwiązań własnych, gdzie w rozwiązaniu własnym wskazywało się by komplet takich parametrów, ich typ i wartość domyślną, byłby zdecydowanie fajniejszym rozwiązaniem i wygodnym w edycji z poziomu NEXO.

Niestety wiem, że te fajne i skomplikowane rzeczy, to u was trwają, więc z reguły pierw szukam rozwiązań najprostszych

[Jacek Izydorczyk 1 336]

W dniu 20.10.2022 o 16:01, Katarzyna Rozmarynowska napisał:

Na razie niestety jest tak, że po zmianie czegoś w kodzie trzeba takim instalatorem odinstalować rozszerzenie i zainstalować ponownie...

Można też w programie serwisowym ponownie załadować ten pakiet do bazy dystrybucyjnej bez kasowania poprzedniej wersji - zostanie zaktualizowany.

[Katarzyna Rozmarynowska 168]

Dziękuję za wyjaśnienia. Będziemy myśleć, co można z tym zrobić. 

 

W dniu 22.10.2022 o 20:56, Jacek Izydorczyk napisał:

Można też w programie serwisowym ponownie załadować ten pakiet do bazy dystrybucyjnej bez kasowania poprzedniej wersji - zostanie zaktualizowany.

To aktualnie najkrótsza droga, ale może uda nam się ją jeszcze skrócić. 

[Radomił Ząbik 308]

W dniu 20.10.2022 o 16:01, Katarzyna Rozmarynowska napisał:

Na razie niestety jest tak, że po zmianie czegoś w kodzie trzeba takim instalatorem odinstalować rozszerzenie i zainstalować ponownie, ale pracujemy nad tym, żeby i to usprawnić, więc można się spodziewać kolejnych wersji naszego rozszerzenia. 

O matulu błagam o to, było by naprawdę przydatne, w szczególności jak nie mam Uwierzytelniania Windows, to brakuje bardzo funkcji "zastąp". Tak hipotetycznie, kwestia zapamiętania danych dostępowych do SQL, raczej na pewno odpada?

[Katarzyna Rozmarynowska 168]

W dniu 15.11.2022 o 14:17, Radomił Ząbik napisał:

O matulu błagam o to, było by naprawdę przydatne, w szczególności jak nie mam Uwierzytelniania Windows, to brakuje bardzo funkcji "zastąp". Tak hipotetycznie, kwestia zapamiętania danych dostępowych do SQL, raczej na pewno odpada?

Nie chcę wszystkiego zdradzać przed wydaniem wersji, więc powiem tylko, że zapamiętywanie danych do SQL nie odpada. 

[Radomił Ząbik 308]

To miło

Widziałem też to ...

Cytat

Do szablonów projektów sferycznych dodamy możliwość automatycznej instalacji rozwiązania po udanym buildzie projektu.

 

[Radomił Ząbik 308]

W dniu 21.10.2022 o 10:35, Daniel Kozłowski napisał:

Wszyscy autorzy rozwiązań dodatkowych mają / będą mieli te same problemy, a że do nich należę to pozwolę sobie odpowiedzieć - chodzi o możliwość przechowywania i zmiany parametrów / konfiguracji rozwiązań dodatkowych.

 

Jak wspominałem wyżej według mnie pliki xml przechowywane na dysku nie są najlepszym rozwiązaniem, nawet gdyby udało się rozwiązać problem ich przechowywania i nadpisywania przez nexo, to cały czas będzie to konfiguracja lokalna stanowiska, którą trzeba będzie w wielu przypadkach utrzymywać na wszystkich stanowiskach, na których będzie uruchamiane to rozwiązanie, zmianie stacji klienckiej czy serwera trzeba będzie pamiętać jeszcze o przenoszeniu konfiguracji rozwiązań dodatkowych... Stąd pomysł przechowywania takich informacji w jednym centralnym miejscu jakim jest baza danych. A skoro już w bazie danych to byłoby miło otrzymać wsparcie - miejsce i metody do zapisu i odczytu parametrów, być może generyczny interfejs użytkownika, aby każdy autor nie musiał tworzyć własnych struktur i mechanizmów do ich obsługi.

 

Temat poruszany również na forum produktowym.

Czy po roku, jakieś rozważenia w temacie obsługi parametrów rozwiązań własnych, z poziomu GUI programów linii NEXO, zaczęły się materializować?

[Urszula Buczek 298]

Temat mamy zapisany do realizacji. Ma on całkiem wysoki priorytet, ale na chwilę obecną nie powiem dokładnie kiedy się uda go zrealizować. 

[Radomił Ząbik 308]

To jeszcze dopytam. Te poniższe elementy, które pojawiły się w wtyczkach, będą do tego stosowane i warto już z nich korzystać?

[Jacek Izydorczyk 1 336]

Te elementy były tam od samego początku 😉

[Radomił Ząbik 308]

4 minuty temu, Jacek Izydorczyk napisał:

Te elementy były tam od samego początku

Może, nie wiem, może dlatego, że teraz dopiero bawiłem się Menu Sferycznym i Filtrem Sferycznym, ale w szablonach Sfery zdarzeniowej, czy zwykłej Sfery ich nie widziałem, może przegapiłem No ale w każdym razie, wykorzystanie go, do ustawienia parametrów aplikacji, wydaje się naturalnym.

 

W dniu 9.11.2023 o 08:09, Urszula Buczek napisał:

Temat mamy zapisany do realizacji. Ma on całkiem wysoki priorytet, ale na chwilę obecną nie powiem dokładnie kiedy się uda go zrealizować. 

Nie wiem, jaka jest lista planów i nie wiem, czy gdzieś o tym wspominałem, ale wydaje mi się, że fajnie by było, jakby te parametry były definiowane na podobę pól własnych, oczywiście od strony pluginu ich definicja i domyślna wartość, a edycji ich w GUI NEXO, ale chodzi o uwzględnienie słowników, systemowych i własnych - naturalne wydaje się nadanie parametru Magazyn, który użytkownik mógłby wybrać z listy, a nie wpisywać ID czy Symbol