Katarzyna Rozmarynowska

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.

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".

Proszę wysłać zgłoszenie przez formularz kontaktowy. Warto do niego dołączyć paczkę z informacjami diagnostycznymi. Można ją wygenerować w programie serwisowym, wybierając w menu "Pomoc" -> "Eksportuj informacje diagnostyczne". Ważne jest, żeby paczka była generowana na tym samym komputerze, na którym występuje problem.

Informuję, że problem został rozwiązany w wersji 41.2.1. Na komputerach z zainstalowanym .NET Framework 4.8.1 nexo będzie działać poprawnie po zainstalowaniu wersji 41.2.1 i aktualizacji baz do tej wersji. Praca z bazami w starszych wersjach będzie możliwa - pod warunkiem, że InsLauncher.exe jest w wersij 41.2.1. W starszych wersjach nie będą jednak działać: Sfera, Serwer Kasowy (InsERT.Moria.SerwerKasowyHost.exe) oraz Serwer e-Usług (InsERT.Moria.SerwerRozwiazanMobilnych.exe). Zalecamy aktualizowanie baz do wersji 41.2.1. Rozwiązania własne korzystające z SDK mogą nie działać na komputerach z .NET Framework 4.8.1, aczkolwiek zależy to od tego, jak są zbudowane i w jaki sposób odwołują się do bibliotek nexo. Zalecamy korzystanie ze Sfery w wersji 41.2.1.

Tak, to jest prawidłowa metoda zmiany zalogowanego użytkownika. Niestety, nie ma w naszym API odpowiedniej metody, ale postaramy się taką dodać w jednej z najbliższych wersji. Tak, to jest prawidłowy sposób zamknięcia uchwytu.

Na początku września Microsoft udostępnił nową wersję platformy .NET Framework, oznaczoną numerem 4.8.1. Otrzymujemy zgłoszenia od użytkowników - potwierdzone przez nas w testach - że po jej zainstalowaniu nexo przestaje się uruchamiać. Zalecamy wstrzymanie się z instalacją .NET Framework 4.8.1 do momentu, gdy problem zostanie zdiagnozowany i rozwiązany. O postępach będziemy informować w wiadomościach InsMail oraz na Forum Użytkowników.

Słusznie, przepraszam za pomyłkę.

Oficjalna odpowiedź się pojawi, ale żeby jej udzielić, potrzebujemy więcej szczegółów i dlatego poprosiłam pana Dawida o kontakt z odpowiednimi osobami.

Proszę się skontaktować w tej sprawie z asp@insert.com.pl, tam uzyska Pan pomoc.

Typ IObiektyBibliotekiDokumentow był oznaczony jako Obsolete od wersji 33 i został usunięty z API w wersji 40. Informowaliśmy o tym tutaj: ogłoszenie z wersji 33, ogłoszenie z wersji 40.

Nie da się tego zrobić przy pomocy pliku startowego, ale są inne sposoby. Sposób 1: zaszycie parametrów w manifeście pakietu zawierającego rozwiązanie własne. Ustawia się je jako wartość atrybutu "CommandLineArguments" w elemencie LaunchAction. Niestety, nie da się tego aktualnie wyklikać, bo manifest jest tylko do odczytu, ale pozwolę sobie trochę zaspoilerować wersję 41 i wspomnę, że w nowej wersji naszych szablonów do aplikacji sferycznych będzie się dało automatycznie generować pakiet przy budowaniu projektu i manifest będzie tam oczywiście edytowalny. Wyobrażam sobie, że zaszycie parametrów w pakiecie może jednak nie być najlepszym rozwiązaniem, ale na szczęście jest sposób 2. Sposób 2: podanie parametrów przy uruchamianiu Launchera, czyli np.: InsLauncher.exe Nexo/MojScenariusz -- parametr1 parametr2 Kluczową kwestią jest tutaj oddzielenie parametrów dla InsLaunchera od parametrów dla uruchamianej przez niego aplikacji. Do tego właśnie służy separator "--". Wydaje mi się, że taki sposób uruchamiania nie jest udokumentowany w materiałach dołączonych do SDK, więc postaramy się ten brak jak najszybciej uzupełnić.

Mówienie o stronach sugeruje istnienie jakiegoś konfliktu, tymczasem żaden konflikt tu nie występuje, bo wszyscy mamy taki sam interes: Pan chce mieć szybki program, a my - InsERT - chcemy dostarczać szybkie programy. Szybkość działania nie jest jednak jedynym parametrem, na którym nam zależy. Bardzo ważne jest dla nas również to, aby oferować klientom bogatą funkcjonalność, komfort pracy i bezpieczeństwo danych, a wszystko to przy stałym zachowywaniu zgodności naszych rozwiązań z aktualnym stanem prawnym. Rozwiązania technologiczne, które stosujemy w nexo, zostały dobrane pod kątem osiągnięcia odpowiedniej równowagi w dążeniu do tych celów. Nie oznacza to jednak, że poświęcamy wydajność w imię innych rzeczy - na ile to możliwe, pracujemy nad jej podniesieniem. Należy jednak mieć na uwadze to, że w tak dużym i złożonym systemie trudno jest jakimś jednym ruchem radykalnie ulepszyć działanie całości. Możliwe - i często bardziej sensowne - jest skupienie się na poprawianiu konkretnych miejsc czy operacji. Jeśli zatem jest Pan w stanie powiedzieć dokładnie, jakie operacje w nexo działają według Pana zbyt wolno, to proszę o tym napisać. Konkretne zgłoszenie pozwoli nam podjąć konkretne działania.

W pierwszej kolejności należałoby zajrzeć do logów systemu nexo oraz do windowsowego dziennika zdarzeń, bo mogą tam być zapisane informacje o błędach przy uruchamianiu. Logi nexo znajdzie Pan w katalogach: c:\Users\{użytkownik}\AppData\Local\InsERT\InsLauncherLogs\ c:\Users\{użytkownik}\AppData\Local\InsERT\Logs\ Jeśli uruchamia się program serwisowy, to można skorzystać z opcji w menu Pomoc -> Eksportuj informacje diagnostyczne, żeby spakować te logi w gotową paczkę, którą można przysłać do firmy InsERT do analizy, najlepiej za pośrednictwem formularza kontaktowego. Jeśli zdecyduje się Pan na przesłanie logów, to w miarę możliwości proszę dołączyć także informacje o tych "powiązanych programach działających na sferze" - co to za programy, jak są uruchamiane, w jaki sposób lokalizują biblioteki nexo.

Zgadza się - przekopiowanie pliku Xml.pak jest niezbędne od wersji 38.0.0, wcześniej nie trzeba było tego robić.

Niestety, do SDK w wersji 40.1 wkradł nam się błąd i niektóre pliki mają niewłaściwą wersję. Pracujemy nad tym, żeby udostępnić poprawioną wersję SDK. Tymczasem mogę Panu zaproponować obejście: rozwiązanie własne powinno zadziałać, jeśli zamiast błędnych plików z SDK użyje się plików, z których korzysta Subiekt. Dotyczy to plików InsERT.Moria.DaneDomyslne.dll i InsERT.Moria.WydrukiDaneDomyslne.dll. Wersję, z której korzysta Subiekt, znajdzie Pan standardowo w katalogu: c:\Users\{użytkownik}\AppData\Local\InsERT\Deployments\Nexo\{podmiot 40.1}\. Jeśli przekopiuje Pan wymienione pliki do folderu SDK albo do folderu wynikowego, do którego buduje się Pana rozwiązanie, to powinno się udać połączyć sferycznie z bazą.

Przyczyną takiego błędu jest brak parametrów wejściowych dla programu InsLauncher.exe. Do prawidłowego uruchomienia nexo potrzeba podania co najmniej parametrów "produkt/scenariusz". Przy uruchamianiu programu z linii poleceń wygląda to na przykład tak: InsLauncher.exe Nexo/Subiekt Listę wszystkich scenariuszy dostępnych dla danego produktu można znaleźć np. w programie serwisowym, w oknie generowania plików startowych: Pliki startowe to pliki, które są otwierane przez program InsLauncher.exe i mają w sobie zaszyte wszystkie parametry potrzebne do uruchomienia nexo.

OK, poprawimy to.

W kolumnie Hash znajduje się to, co wcześniej było w kolumnie ObiektyBibliotekiDokumentow.MD5. Jest to ciągle MD5.

Na razie chcielibyśmy mieć w tych szablonowych projektach tylko takie referencje, które są niezbędnym minimum, ale jeśli będziemy tam w przyszłości coś dopisywać, to Newtonsoft.Json będzie pewnie pierwszy na liście.

Chciałabym tu sprostować: folder QueryCache jest w tym samym miejscu, w którym był przez 40 wersji, natomiast zmieniło się to, że od wersji 40 programy sferyczne korzystają właśnie z tego folderu (odpowiedniego dla podmiotu, z którym łączą się sferycznie), zamiast robić sobie swój własny QueryCache w Tempie. Dokładniej rzecz biorąc, od wersji 40 programy sferyczne korzystają z tych samych folderów Binaries, Config i Work (w folderze Deployments/Nexo/podmiot/), co insertowe programy z linii nexo. Jeśli chodzi o ewentualne magiczne operacje podczas uruchamiania Subiekta, to być może znaczenie tu miało to, że przed uruchomieniem wybranego podmiotu InsLauncher robi porządek w folderze Binaries tego podmiotu, usuwając wszystkie pliki spoza bieżącej wersji podmiotu i w razie potrzeby wgrywając świeże kopie "fabrycznych" plików.

Zapisuję do poprawy w jednej z najbliższych wersji. Na teraz jedynym obejściem jest wyczyszczenie cache'a przy pomocy skrótu klawiszowego Alt+F4.

Przypuszczam, że jest to problem z Windowsem, a nie z nexo. Przytoczony przez Pana błąd został zgłoszony Microsoftowi: Windows 11 insider preview 22H2.

Te informacje są i będą dostępne w tabeli ModelDanychContainer.Zalaczniki. Przy przejściu na nową wersję biblioteki są tam przepisywane - można to zaobserwować, włączając nową wersję biblioteki w Laboratorium.

Zgodnie ze wcześniejszymi zapowiedziami (patrz: ogłoszenie o zmianach w Bibliotece), w wersji 40.0.0 zostaną wprowadzone istotne zmiany związane z Biblioteką załączników. Nowa wersja Biblioteki, która dotychczas była dostępna w Laboratorium, zniknie z Laboratorium i zostanie automatycznie wdrożona u wszystkich użytkowników. Ważna informacja dla twórców rozwiązań własnych: zmieni się model danych i interfejsy sferyczne w obszarach związanych z Biblioteką. Co zmienia się w Bibliotece załączników? W starej wersji Biblioteki jeden załącznik był powiązany z dokładnie jednym obiektem. Jeśli użytkownik chciał powiązać ten załącznik z innym obiektem, to musiał go dodać drugi raz. To prowadziło do powstawania duplikatów, które niepotrzebnie zajmowały miejsce w bazie danych. W nowej wersji Biblioteki jeden załącznik może być powiązany z wieloma obiektami jednocześnie i ma w bazie tylko jeden egzemplarz. Nie można dodać do Biblioteki załącznika o takiej samej nazwie i rozszerzeniu. W module "Biblioteka załączników" można wylistować wszystkie obiekty podłączone do danego załącznika, a także odłączyć - niektóre z nich lub od razu wszystkie. W zakładce "Załączniki" na formatce obiektu można wybierać pomiędzy dodaniem do obiektu zupełnie nowego załącznika a podłączeniem takiego, który już jest w Bibliotece. Co się stanie z załącznikami, które są już w bazie? Podczas konwersji bazy danych do wersji 40.0.0 załączniki ze starej wersji biblioteki zostaną automatycznie przeniesione do nowej wersji. Jeśli w bazie istnieją załączniki, które mają taką samą nazwę i rozszerzenie, to "nadmiarowym" plikom zostaną zmienione nazwy. Na przykład: jeśli w bazie są 3 załączniki o nazwie "dokument.txt", to zostaną one przeniesione jako "dokument.txt", "dokument_kopia_000001.txt", "dokument_kopia_000002.txt". Zawartość plików nie ma tutaj znaczenia - jedynie nazwa i rozszerzenie. Wszystkie powiązania załączników z obiektami zostaną zachowane. Mam rozwiązanie własne korzystające z Biblioteki. Co muszę zrobić? Jeśli rozwiązanie własne korzysta z biblioteki przy pomocy interfejsu IBibliotekaZalacznikow, to prawdopodobnie nie wymaga żadnych zmian. Jeśli korzysta z interfejsów związanych ze starą wersją biblioteki, to trzeba je przepisać tak, aby korzystało z IBibliotekaZalacznikow, ponieważ stare interfejsy zostaną w wersji 40 - zgodnie z zapowiedziami - usunięte z API. Lista typów, które zostaną usunięte: InsERT.Moria.BibliotekaDokumentow.IObiektBibliotekiDokumentow InsERT.Moria.BibliotekaDokumentow.IObiektyBibliotekiDokumentow InsERT.Moria.BibliotekaDokumentow.IObiektyBibliotekiDokumentowDane InsERT.Moria.ModelDanych.ObiektBibliotekiDokumentow Tabele, które zostaną usunięte z bazy: ModelDanychContainer.ObiektyBibliotekiDokumentow Inne zmiany: InsERT.Moria.BibliotekaDokumentow.BrakNumeruKategoriiDBlad zostanie oznaczone jako "Obsolete". Zamiast tego typu należy używać InsERT.Moria.BibliotekaZalacznikow.BrakNumeruKaryBlad. InsERT.Moria.BibliotekaDokumentow.KategoriaAktOsobowychPrzypietaNieDoPracownikGrBlad zostanie oznaczone jako "Obsolete". Zamiast tego typu należy używać InsERT.Moria.BibliotekaZalacznikow.KategoriaAktOsobowychPrzypietaNieDoPracownikGrBlad. InsERT.Moria.BibliotekaDokumentow.ZbytWysokiNumerKategoriiDBlad zostanie oznaczone jako "Obsolete". Zamiast tego typu należy używać InsERT.Moria.BibliotekaZalacznikow.ZbytWysokiNumerKategoriiDBlad.

Pracujemy nad rozwiązaniem tego problemu. W międzyczasie można się posiłkować tym, jak wyglądała lista folderów w "dobrym" SDK, np. w wersji 37. Te na screenie na 100% powinny zostać, a pozostałe można usunąć.