Hallo,
seit vielen Jahren lebe ich bei und mit meinen Kunden sehr erfolgreich in der Clientlosen Umgebung. Das bedeutet: die Benutzer öffnen per UNC die Docusnap.Exe mit Parameter -USeConfig.
Funktioniert super, in seltensten Fällen spinnt das beim Konzept-Editor (zumindest meine Recherche und Erfahrung). Notwendig ein runtime-Eintrag in der Docusnap.exe.config.
Warum nicht eine Volloffizielle Nutzung so bauen, gern auch "geht halt der Konzept-Editor nicht, kann man sicher steuern.
Background: 95% der Docusnap-User nutzen Inventar und Berechtigungsfunktionen. In großen IT-Abteilungen ist es nervig, wenn jede Software einen Client braucht, dann muss da immer geupdatet werden und Vorlauf ist nötig. Könnte also ein Mehrwert sein für alle diese Kunden.
Daher: bitte mal in der Entwicklung darüber sprechen ob man nicht diese Variante als offizielle Option anbietet.
Danke an die Entwicklung!
Hallo,
Idee ist mittlerweile auch schon Methusalem. Aber dennoch nicht inaktuell, denn immer mehr Kunden setzen auf TIER-Modelle in der Serverlandschaft oder arbeiten vom HomeOffice aus. Da will man nicht nach jedem Update den Docusnap-Client überall ausrollen, zumal die Personenzahl begrenzt ist.
Vielmehr ist es wirklich toll, die Docusnap.exe per UNC z.B. "\serverShareSubshare1Docusnap.exe -UseConfig \serverShareSubshare1DsSettings.xml" im Arbeitsverzeichnis "\serverShareSubshare1" zu starten und somit "Clientless" arbeiten zu können. Einziger Nachteil halt der nötige Eeintrag für die DotNet-Ausnahme. Die Verknüpfung auf den Terminal-Server-Desktop, fertig ist das nutzbare Docusnap OHNE Setup des Clients.
Bitte schaut euch das noch einmal aus der Entwicklung an. Mich würden tatsächlich die aus eurer Sicht technischen Nachteile interessieren, was soll da nicht klappen (ich mache das seit mindestens 5-6 Jahren so)?
Wenn das so machbar ist, würde es völlig ausreichen, die nötige Befehlszeile in die Docusnap.exe.config mit einzubauen (weil sie nach jedem Update derzeit weg ist). Das Risiko dieser Option könnte man auch evtl. per Optionsschalter ausschließen, mit einem Hinweis auf die "mir nicht bekannten Nachteile".
Danke an die Entwicklung!
Frank Oehlschlägel
Docusnap-MVP since 2020
Wenn der Client dagegen mehr in Richtung zentraler Serversteuerung ginge, wie man es von vielen anderen Produkten kennt, könnte man auf die Verteilung von gemeinsamen Einstellungen auch ganz verzichten, da diese einmalig am Server definiert werden und über den Server die Clients remote updaten. Geht bei den Discovery Services ja auch. Dann hätte man vielleicht auch weniger Probleme der Synchronisation, denn aktuell wird eine Änderung, durchgeführt von Client1 nicht zwingend sofort in Client2 sichtbar, mitunter ist sogar ein Programmneustart von Client2 notwendig.