beRemote - Projekt: Remote Connection Manager

Hallo Forum,

ich möchte mich gerne an ein neues Projekt wagen und suche dafür 1-2 Mitstreiter, die von diesem Projekt überzeugt sind und dies unterstützen würden.

Ich möchte ein Remake eines Programms schreiben, da das Original nicht mehr weiterentwickelt wird. Zudem möchte ich einige Funktionen dort hinzufügen, die im täglichen Gebrauch einfach fehlen.
Bei dem "Original" handelt es sich um das Program "mRemote" (www.mremote.org).

Ich selbst arbeite täglich intensiv mit diesem Programm und hätte dort gerne die ein oder andere neue Funktion oder eine bessere Bedienung.

Einmal grob zusammengefasst, was mRemote (grob zusammengefasst) kann und anschließend was ich hinzufügen möchte. mRemote kann:

• Viele Server übersichtlich in einem TreeView mit Suchfunktion verwalten
• RDP, VNC, SSH, Telnet, HTTP(S)-Verbindungen aufbauen und für jede Verbidung/Server einen eigenen Tab anzeigen

Was ich vermisse:

• Credential-Profile, mit denen man nur im Profil neue Benutzerdaten hinterlegen muss und nicht in jeder Serverkonfiguration einzelnt
• die Möglichkeit weitere Remote-Protokolle einzufügen (Teamviewer, Mikogo)
• Viele Servereinstellungen auf einmal zu sehen und in einer Tabelle auf einmal anzeigen um sie leichter und schneller bearbeiten zu können
• Eine Möglichkeit aus mRemote heraus eine Remoteverbindung mit dem Management-Tool "Kaseya" zu starten
• Import/Suche von Servern
• SQL-Basierte Serverliste (ist nur in einer "Alpha"-Version in mRemote)
• Vielleicht eine Schnittstelle zum Ticketsystem OTRS

Dies möchte ich gerne in das Remake einbauen. Nicht zuletzt möchte ich dieses Projekt durchführen, weil ich Spaß daran habe und mich mit den Remotetechniken und den verschiedenen Protokollen auseinandersetzen möchte.
Das Ganze wird von jedem kostenlos genutzt werden dürfen. Ggf. auch OpenSource.

Wer also Interesse daran hat in einem Team dieses Programm umzusetzen und aus Spaß und Interesse mitzumachen, kann sich gerne bei mir melden:
per Mail: kristianreukauff -bei- beremote.net
per Skype: Xo-Mate (bzw. MSN: kreukauff -bei- gmx.de)
per Forum: hier im Thread oder per PN
Bitte nur ernst gemeinte Zuschriften, wenn ihr von dem Projekt zumindest in der "mRemote"-Variante überzeugt seit und dies auch zu Ende bringen möchtet!

Ich freue mich auf eure Zusammenarbeit!

Edit:
Mittlerweile wurde beRemote veröffentlicht.
Die offizielle Seite ist: www.beremote.net
Download:
Download Release Preview 2 x86
Download Release Preview 2 x64

Oder alternativ für alle, die nicht auf neue Funktionen warten können und dafür ggf. Bugs in Kauf nehmen, die stets aktuellen Snapshots:
beRemote latest Snapshot (64 Bit)
beRemote latest Snapshot (32 Bit)

Hallo zusammen,

ich möchte gerne ein Update für dieses Projekt verkünden und über die Entwicklungen in letzter Zeit berichten.

Zunächst einmal wird das hier vorgestellte Projekt seit Mai vorangetrieben und hat einen Namen bekommen.
Es heißt: beRemote

Wir – ein kleines Team aus zwei Personen – formen mit beRemote ein Stück Software in das unsere Vorstellungen und Ideen seit Beginn der Entwicklung einfließen.

Unsere Zielgruppe für diese Anwendung sind Administratoren und "Power-User", welche mit Remote-Systemen arbeiten und diese nutzen und/oder administrieren.
Da wir selbst als Entwickler und Administratoren in dieser Zielgruppe arbeiten konnten wir gut abschätzen was der Administrator von heute benötigt und bemühen uns diese Visionen in die Tat umzusetzen.
Nun zu unserem aktuellen Stand:
beRemote ist nun kurz vor dem ersten Release, welches wir "Release Preview 1" (RP1) nennen. Es enthält noch bei Weitem nicht alle Funktionen, welche wir im finalen Release sehe möchten, aber die Basisfunktionialität ist gegeben.
In Worten ausgedrückt bedeutet dies, dass bisher vieles möglich ist. Hier einmal ein Auszug der wichtigsten Features:

• Multitab-Ansicht mehrerer RDP oder Telnet-Verbindungen
• Unterstützung von RDP-Verbindungen mit NLA
• Verwalten von Verbindungen in einer Treeview-Ansicht
• Import von Verbindungen aus mRemote-Konfigurationsdateien
• Historyfunktion
• "Stopwatch" als Hilfe für Mitarbeiter in Dienstleistungsunternehmen
• Credentialmanagement (Hinterlegen von Logindaten)
• Lizenzmanagement
• Integrierter Updater mit Proxy-Support
• Schnittstelle für mehrere Datenbanken (derzeit nur SQLite umgesetzt, weitere folgen nach RP1)

Natürlich fehlen noch sehr viele Funktionen daher im Folgenden eine kleine TODO-Liste was in Zukunft noch so kommen wird:

• VNC-Support (als Remoteprotokoll)
• SSH-Support (als Remoteprotokoll)
• MSSQL-Support (als Datenbank)
• MySQL-Support (als Datenbank)
• "Tools & Features" - Viele kleine und große Helferlein für Administratoren
• Dokumentation der Protokollschnittstelle für 3rd Party Plugins
• Dokumentation der Datenbankschnittstelle für 3rd Party Plugins
• Dokumentation der Tools+Features-Schnittstelle für 3rd Party Plugins

Mit jedem Release folgen noch weitere Funktionen, welche jedem, der mit Remotesystemen arbeitet, ein funkeln in die Augen bringen wird. Natürlich verraten wir hier jetzt noch nicht alles, aber es ist es auf jeden Fall wert uns nicht aus den Augen zu verlieren.

Ein paar technische Details:
Die beRemote-GUI basiert ausschließlich auf WPF und wir orientieren uns an MVVM, setzen es aber noch nicht konsequent um. Die Basis von beRemote ist letztendlich ein leeres Gerüst, welches durch Plugins erweitert werden kann. Diese Plugins stellen wir selbst zur Verfügung, geben aber auch anderen Entwicklern die Möglichkeit beRemote selbst zu erweitern. Dies kann in Form von eigenen Remote-Protokollen erfolgen, aber auch in Form von eigenen Helfern, welche in dem Tools+Features-Ribbon integriert sind. Nicht zuletzt ist es auch möglich andere Schnittstellen zu entwickeln um auch aus anderen Programmen "live" Daten in beRemote nutzen zu können.

Zur Lizenz:
beRemote wird kostenlos für jeden sein. Es kann sowohl privat als auch kommerziell in beliebigen Umfang genutzt werden. Spenden sind natürlich gerne gesehen.
beRemote ist überwiegend nicht OpenSource. Einige Teile (z.B. Datenbankschnittstellen) werden jedoch (z.B. zu Demonstrationszwecken) frei zum Download inklusive SourceCode zur Verfügung stehen.

Und nun zuletzt noch etwas in eigener Sache:
Für beRemote suchen wir einen weiteren Entwickler, welcher Erfahrung in WPF haben sollte und bereit ist paar Stunden pro Woche in beRemote zu investieren. Insgesamt gibt es allerdings keine Zeitpläne, an welche jemand festgenagelt wird. Es ist ein Hobby-Projekt, in dem jeder sich seine Zeit selbst einteilen kann. Wir haben mittlerweile eine Recht umfangreiche Infrastruktur die uns beim Entwickeln und Dokumentieren sowie beim Bugtracking sehr gut unterstützt.
Wer Interesse hat unser Team zu verstärken, kann sich gerne bei uns per Mail an support-bei-beremote.net melden. Bitte sendet Kontaktdaten (z.B. Skype/MSN) mit.
Das war es erst mal für heute!
Bis demnächst, wenn wir euch unser erstes Release vorstellen dürfen!

Vorsicht, wenn du planst die Software auf einem Server einzusetzen. Der Name steht im Konflikt mit einem Symantec Backup Exec Dienst. (siehe Google)
Dies könnte Nutzer verwirren.

Hi,

vielen Dank für den Hinweis. Die Namensgleichheit ist uns bekannt. Ich verstehe nur nicht ganz in wiefern das ein Problem ist? Die Dateien werden ja nicht im gleichen Ordner liegen und beRemote ist eine Client-Anwendung mit der man zu Servern (im Regelfall mit den Boardmitteln des Servers) verbindet.

Derzeit ist aber auch der Name der EXE-Datei nicht beremote.exe 😉 Daher sollte es dort keine Probleme geben - wenn man denn beide Dateien in den gleichen Ordner legen möchte.

Hi,

Ich denke es geht vielen so wie mir: Ist es möglich eine vorab-Alphaversion zu erhalten oder irgendwo herunterzuladen? Ich für meine Verhältnisse bin sehr interessiert an dem Projekt und kann meine Neugier nicht bremsen 😉

lg

Hi,

voraussichtlich diese Woche (zwischen Weihnachten und Neujahr) kommt das "Release Preview 1".
Wir haben in den letzten Tagen die Homepage mit einigen Informationen gefüttert, sodass dort schonmal einiges zu erkennen ist, wie es sein wird.
Sobald wir das Release Preview veröffentlichen, geben wir hier natürlich zuerst Bescheid 😃

Hallo,

also ich bin ja auch sehr gespannt auf das Projekt.... Die Screen-Shots machen auch schon einen guten Eindruck. Ich hoffe nur, dass es auch einen Weg geben wird, beRemote ohne Login zu benutzen - ein zus. Logon an beRemote das wäre für mich ein klares K.O. für den Einsatz des Produktes 😦

Und.... Ihr solltet Euch mal jemanden suchen, der etwas besser Englisch kann. Die Texte auf der Homepage sind... nunja... öhm... das geht besser 😉

Schöne Weihnachten!

Bye,
Michael

Ja... das mit dem Englisch... naja, man versteht was wir meinen - hoffe ich 😉

Das Login ist erforderlich, da es auch zur Verschlüsselung von hinterlegten Credentials genutzt wird.

Eine Übergabe der Logindaten als Parameter wäre aber denkbar, ebenso wie eine Authentifizierung via LDAP. Bei Letzterem müssen wir nur gucken wie dann die Credentialverschlüsselung durchgeführt werden kann. Das ist einer der Gründe, warum wir dies derzeit noch etwas hinten an gestellt haben.

Ja... das mit dem Englisch... naja, man versteht was wir meinen - hoffe ich 😉

Schon... macht halt nur einen etwas schlechten Eindruck - wo hingegen doch die Screenshots einen sehr professionellen Eindruck hinterlassen....

Das Login ist erforderlich, da es auch zur Verschlüsselung von hinterlegten Credentials genutzt wird.

Hmmm.... nunja.... Ihr werden schon wissen was ihr tut 😉

Ich hatte da einen ganz bestimmten Anwendungsfall für die Software....

Zum Hintergrund: Ich bin ein leidenschaftiler Anwender von Launchy, einen "Schnellstarter". Dieser bietet ein Plugin für PuTTY was mich jeden Tag entzückt. Auf meinem Systtem aktiviere ich Launchy durch einen Hotkey, tippe dann "ssh" gefolgt von dem Hostnamen (der dem PuTTY bekannt sein muss), drücke einmal beherzt auf ENTER und schwupps öffnet sich PuTTY mit der Connection zum angegebenen Host. Was mich daran so entzückt ist, dass man A) ohne die Maus auskommt und B) schnell "am Ziel" ist.

Ich hatte mit ähnliches für beRemote erhofft. Hotkey drücken, beRemote starten (mit Kommandozeilenparameter für die Angabe des Hosts + Protokoll) und schwupps ist man auf dem Rechner. Wenn da noch so ein blödes Login dazwischen funkt ist das mehr als lästig. Zumal ich pers. eh "unnötige Logins" hasse wie die Pest...

Bye,
Michael

OK, ich werde es mal als Feature Request aufnehmen

Ein "unnötiges Login" ist es nur, wenn man es in Verbindung mit einer Domain-Anbindung nutzt, da man nur dort von einer autorisierten Stelle (dem DC) eine echte Autorisierung zur Nutzung erhalten hat. Da das Programm aber nicht ausschließlich Stand-Alone, sondern auch mit zentralen Datenbanken z.B. in Servicedesks eingesetzt werden wird, ist das Login - in welcher Form auch immer; ob automatisch oder nicht - nicht komplett entfernbar.
Zumindest solange wir nicht wollen, dass irgendjemand die in der Datenbank hinterlegten Credentials ohne großen Aufwand entschlüsseln kann.

Auf meinem Systtem aktiviere ich Launchy durch einen Hotkey, tippe dann "ssh" gefolgt von dem Hostnamen (der dem PuTTY bekannt sein muss), drücke einmal beherzt auf ENTER und schwupps öffnet sich PuTTY mit der Connection zum angegebenen Host.

Wäre es auch in Ordnung, wenn beRemote bereits läuft und du dann diesen Befehl eingibst? Dann wäre das Thema mit dem Login auch gegessen, da dieser zu dem Zeitpunkt dann ja schon erfolgt ist. In meiner täglichen Arbeit habe ich beRemote jedenfalls den ganzen Tag auf, einfach da ich eigentlich immer Remote irgendwo drauf bin. Daher könnte ich mir vorstellen, dass es bei dir auch so sein könnte.

Wir sind kurz vor dem ersten PreRelease - leider etwas hinter dem Zeitplan, aber besser als ein paar zu viele Bugs zu haben.
Wenn alles nach Plan läuft, gibt es Montag mehr 😉

Klar ist das i. O. .....

Bye,
Michael

P.S.: Freue mich aufs erste Release....

Heute haben wir unser erstes PreRelease von beRemote veröffentlicht. Es ist das beRemote Release Preview 1. Ihr könnte es in der Download-Sektion auf www.beremote.net herunterladen oder ihr klickt den Download-Link im ersten Beitrag.
Es gibt noch einige bekannte und unbekannte Bugs. Ihr könnt diese in unserem Bugtracker verfolgen und melden. Der Bugtracker ist erreichbar unter https://tracker.beremote.net.
Zudem könnt ihr immer den letzten Snapshot von beRemote von unserer Website abrufen oder klick hier. Die Snapshots sind allerdings ungeprüft und können im schlimmsten Fall die Datenbank zerstören oder andere schwere Fehler beinhalten. Normalerweise passiert das natürlich nicht, aber man weiß ja nie...

Außerdem suchen wir noch weiterhin Entwickler, die das beRemote-Development-Team unterstützen möchten oder unter eigenem Namen Plugins entwickeln möchten. Wer Interesse hat, kontaktiert uns bitte über den "contact"-Link um unteren Ende der beRemote-Seite oder hier im Forum. Wir haben noch eine Menge vor!

Das Feature Request von m.knigge ist leider noch nicht implementiert, aber wird in Kürze umgesetzt.
Der Verlauf des Feature Requests kann hier verfolgt werden: https://tracker.beremote.net/issues/233

Hallo,

habe mir mal beide Varianten (32 und 64 bit geladen), leider stürzen beide bei Start mit einer IOException ab. Ebenso wird kein Log erstellt wo ein entsprechender StackTrace gezeigt werden würde. Habe dann aber doch einen gefunden in den Windows Protokollen, nachdem man keine Bugs im Tracker eröffnen kann poste ich diesen StackTrace hier> Fehlermeldung:

Anwendung: beRemote.GUI.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.IO.IOException
Stapel:
bei MS.Internal.AppModel.ResourcePart.GetStreamCore(System.IO.FileMode, System.IO.FileAccess)
bei System.IO.Packaging.PackagePart.GetStream(System.IO.FileMode, System.IO.FileAccess)
bei System.Windows.Application.LoadComponent(System.Uri, Boolean)
bei System.Windows.Application.DoStartup()
bei System.Windows.Application.<.ctor>b__1(System.Object)
bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
bei MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
bei System.Windows.Threading.Dispatcher.WrappedInvoke(System.Delegate, System.Object, Int32, System.Delegate)
bei System.Windows.Threading.DispatcherOperation.InvokeImpl()
bei System.Threading.ExecutionContext.runTryCode(System.Object)
bei System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode, CleanupCode, System.Object)
bei System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
bei System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
bei System.Windows.Threading.DispatcherOperation.Invoke()
bei System.Windows.Threading.Dispatcher.ProcessQueue()
bei System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
bei MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
bei MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
bei MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
bei System.Windows.Threading.Dispatcher.WrappedInvoke(System.Delegate, System.Object, Int32, System.Delegate)
bei System.Windows.Threading.Dispatcher.InvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
bei MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
bei MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef)
bei System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)
bei System.Windows.Application.RunInternal(System.Windows.Window)
bei System.Windows.Application.Run()
bei beRemote.GUI.App.Main()[/pre]

Hi Pippl,

Zunächst zum Tracker: Du musst dich erst registrieren und anmelden, damit du im Bugtracker Bugs reporten kannst.

Zum Problem:
Wo liegt bei dir beRemote? ggf. in einem Netzlaufwerk?
Die Meldung wirkt so, als hättest du keine Rechte auf den Ordner in dem beRemote liegt. Dort wird aber die Datenbank-Datei angelegt.

Programme (exe, dll,...) gehören nach %Programfiles%
Anwendungsdaten (Datenbanken, Konfiguration,...) gehören entweder nach %ProgramData% oder nach %AppData%
Das solltet ihr auf jeden Fall in eurer Software berücksichtigen... Im Programmverzeichnis hat der Benutzer keine Schreibrechte, und das ist auch gut so.

Ok habe im Tracker nun den Bug angelegt, und auch beschrieben wo beRemote beim Ausführen jeweils lag.

Prinzipiell gebe ich dir Recht. Andererseits kann die Datenbank aber auch von mehreren Benutzern von unterschiedlichen Rechnern gleichzeitig benutzt werden. Wir könnten den Default-Pfad für die SQLite-DB allerdings nach %appdata% das users legen.
Im Moment kann zur Anpassung des Pfades in der config.ini die Option dbpath angepasst werden.
Um die Datenbank woanders abzulegen, muss diese Option einfach angepasst werden. Z.B. dbpath=X:\beremote.db
Sollte das mit dem Release-Download nicht funktionieren, teste bitte einmal den aktuellsten Snapshot.

Für die Zukunft ist ohnehin zusätzlich zu der SQLite-Datebank noch die Möglichkeit der Nutzung einer MSSQL bzw. MySQL-Datenbank angedacht. Dies wird auch einige Performanceverbesserungen mit sich bringen.

Dann schau Dir bitte nochmal an, was er geschrieben hat.
AppData ist für den einzelnen User. Dann gibts noch CommonAppData und ProgramData kann dafür ebenfalls missbraucht werden.

Im Fazit hat er recht - ohne Ausnahme. Alle Fälle abgedeckt.

Ja, er hat auch Recht. Das bestreite ich nicht. Ich habe aber auch geschrieben, dass die DB durchaus in Netzlaufwerken liegen kann/darf und dass man den Pfad anpassen kann sowie dass wir den Standardpfad ändern werden (siehe hier)

Für die Zukunft ist ohnehin zusätzlich zu der SQLite-Datebank noch die Möglichkeit der Nutzung einer MSSQL bzw. MySQL-Datenbank angedacht. Dies wird auch einige Performanceverbesserungen mit sich bringen.

Na, dass Du Dich da mal nicht täuschst 😉 Ich vermute/unterstelle mal, soooo riesig wird die DB von beRemote nicht sein - die passt doch wahrschenlick locker komplett in den Cache vom SQLite. Dann hast Du keinen ("zeitintensiven") Traffic mehr übers Netz..... SQLite ist eh schon ziemlich flott unterwegs, es sei denn man arbeitet ohne Transaktionen (dann ist es - architekturbedingt - grottenlahm) oder nutzt keine Indices. Allerdings sind dann auch auch DB-Server lahm 😉

Ja, er hat auch Recht. Das bestreite ich nicht. Ich habe aber auch geschrieben, dass die DB durchaus in Netzlaufwerken liegen kann/darf

Ui ui ui ui.... neee neee, das lass mal schön sein - schon gar nicht bei Zugriffen von unterschiedlichen Rechnern - da schwächelt jede embedded Datenbank...

Can multiple applications or multiple instances of the same application access a single database file at the same time?

How To Corrupt An SQLite Database File --> Chapter 2.1

Bye,
Michael

Hi,
ja, so groß ist sie nicht, dass ist korrekt. Aber SQLite unterstützt meines Wissens nach keine Stored Procedures. Daher muss z.T. einiges etwas aufwändig "zusammengesucht" werden, was bei MSSQL eine StoredProcedure mit entsprechender Performance machen würde.

Das mit den Netzlaufwerken KANN zu Problemen führen, muss es aber nicht - steht auch so in deinem ersten Link. Im produktiven Testbetrieb (gibt es sowas? 😃) hatten wir zu dritt keine Probleme. Für größere Umgebungen wird es später ohnehin die größeren Datenbanken geben, wo das dann kein Problem mehr dastellt.

Die SQLite-DB ist primär für die Benutzung lokal gedacht. Netzlaufwerk ist zwar möglich, aber wie ich jetzt weiß, kann es problematisch werden.

Wenn Du eine zentrale DB brauchst dann kannst Du getrost auch die MongoDB verwenden.
Diese kannst Du zum einen fast als embedded DB umnieten (einfach die Exe starte) und auch als zentrale DB (exe als Service registrieren) laufen lassen. Zudem ist sie relativ klein, mit einem 30 Zeilen CMD zu "installieren" (im Prinzip Copy Paste) und in Sachen Performance fast nicht zu übertreffen.

Hi,
ja, so groß ist sie nicht, dass ist korrekt. Aber SQLite unterstützt meines Wissens nach keine Stored Procedures. Daher muss z.T. einiges etwas aufwändig "zusammengesucht" werden, was bei MSSQL eine StoredProcedure mit entsprechender Performance machen würde.

Naja, wenn die DB im Cache ist, dann sind auch die SQLs entsprechend schnell. Und da SQLite eine embedded DB ist, sprich sie läuft im gleichen Adressraum wie Deine Anwendung, sind die von Dir abgesetzten SQLs im Grunde "Stored Procedures" (ok, nicht 100%ig, aber ich glaube es kommt rüber was ich meine).

Das mit den Netzlaufwerken KANN zu Problemen führen, muss es aber nicht - steht auch so in deinem ersten Link.

Richtig - ist halt eine Sache des Timings. Wenn zwei "kritische" Zugriffe mehrere Sekunden auseinander liegen, dann ist das halt kein Problem. Liegen diese aber im ≤ msek-Bereich beieinander, dann u. U. schon....

Für größere Umgebungen wird es später ohnehin die größeren Datenbanken geben, wo das dann kein Problem mehr dastellt.

Ich kann und will Dir/Euch ja nicht vorschreiben wie ihr beRemote zu entwerfen habt, aber ich kann es mir trotzdem nicht verkneifen 😉 mal darauf hinzuweisen, dass Du/Ihr Euch damit u. U. mehr Probleme einhandelt als eigentlich notwendig....

Du sprichst von "größeren Umgebungen"... Aus meiner beruflichen Erfahrung kann ich Dir nur sagen, dass eine Applikation (bzw. der Benutzer, der per ODBC oder was auch immer auf die DB zugreift) i. d. R. **nicht **die Berechtigungen bekommt Tabellen zu erstellen, zu löschen, zu modifizieren usw.... D. h., Du (bzw. der Anwender) ist immer auf einen DBA (DB Admin) angewiesen, der die Änderungen am DB-Schema vornimmt. Soll heissen, sobald beRemote mit SQL-Server Anbindung irgendwo in Produktion gehen soll, ist der Aufwand auf Kundenseite "enorm", da erst einmal ein DBA involviert ist.

Gleiches Spiel bei einem Upgrade/Update, wenn sich in einer neuen Version von beRemote das DB-Schema geändert hat - nix mit mal eben neues beRemote deployen... neeee, erst einmal den DBA konsultieren und dann DB-Change mit Deployment koordinieren...

Ganz ehrlich.... Ich untertselle mal, aus DB-Sicht ist das was Du/Ihr da macht "Pillepalle" (nicht abwertend gemeint - ich meine damit die Komplexität der DB und der durchgeführten Zugriffe) und ich pers. würde daher eher dazu tendieren, einen "beRemote Server" zu entwickeln, der die Zugriffe auf die gemeinsame DB durchführt. Und dann würde ich mir auch mal überlegen, ob nicht eine NOSQL-DB die bessere Alternative ist. So aus dem Bauch könnte ich mir vorstellen, dass das dann ein beRemote Server relativ einfach zu implementieren ist...

Als Idee: Kommunikation via HTTP und als Datenformat JSON (z. B. mit Json.NET). Und als DB dann im Hintergrund eine NoSQL DB wie MongoDB, Redis, DBreeze, DensoDB oder sowas - letztere kann man angeblich auch von Haus aus als Windows Dienst installieren und dann per REST befragen - beRemote Server geschenkt 😉. Vielleicht auch was leichtgewichtiges (aber hochperformantes) wie RaptorDB oder RaptorDB V2...

Und damit man nicht Zweigleisig fährt nimmt man die gleichen Klassen/Methoden auch für eine Einzelplatzversion, nur dass man dann die Kommunikation via HTTP rauslässt.... Dann spart man sich auch solch blöde Unterscheidungen zur Laufzeit "DB=SQLite" (ohne Stored Procedures) oder "DB=SQL-Server" (mit Stored Procedures - also zwei DBs mit unterschiedlichen Strategien um an die benötigten Daten zu gelangen)....

Stelle ich mir relativ spannend, aber nicht zu komplex vor...

Bye,
Michael

Hi,
also das es bei größeren Umgebungen ein Admin geben muss, ist soweit klar. Dieser muss dann die Tabellen anlegen oder ggf. Updates an den Tabellen durchführen. Das ist soweit auch so vorgesehen.

Aus meiner Erfahrung in den Unternehmen in denen ich gearbeitet habe kann ich aber sagen, dass die Hemmschwelle kleiner ist etwas bereits existierendes als "Server" zu verwenden (z.B. MSSQL) als etwas neues zu implementieren.
Zudem hat man bei den bestehenden Lösungen mit MSSQL, MySQL oder mit Sicherheit auch bei anderen Datenbanklösungen den Vorteil die Failover- und Hochverfügbarkeitsfeatures mitzubenutzen und nichts eigenes Implementieren zu müssen.

Ein "Problem" ist auch, dass wir noch ziemlich viel im Hinterkopf haben, was wir mit beRemote in etwas fernerer Zukunft alles machen wollen. Dabei werden dann jedoch erheblich mehr Datenmengen zusammenkommen als es jetzt noch der Fall ist.

Zuletzt ist es durch unsere Datenbankschnittstelle aber an sich möglich mit ein bisschen Programmierarbeit jede Datenbank dahinter zu benutzen. Mit dem nächsten Release werden wir das ganze aber auch Dokumentieren. Es ist dann also möglich je nach den eigenen Bedürfnissen die passende Datenbank zu benutzen. MSSQL und MySQL sind dabei halt die verbreitetsten.

Nichts desto trotz bin ich euch sehr dankbar für eure Anregungen. Wir werden die Alternativen zu unseren bisherigen Überlegungen einmal durchsprechen und abwägen ob wir unseren bisherigen Kurs beibehalten oder ob wir doch noch von der einen oder anderen Alternative überzeugt werden, von der wir vorher noch nichts gehört haben oder die bisher nicht in Betracht kam.

Hallo zusammen,

wir haben nun unsere zweite Version von beRemote, den Release Preview 2, rausgebracht.
Wie der Name schon sagt: Es ist noch nicht die finale Version. Dazu fehlen noch zu viele Features, aber es ist ein weiterer Schritt in die Richtung.

Wir haben beim Release Preview 2 einige Verbesserungen an der Performance vorgenommen, sowie unser integriertes Pluginsystem erweitert. Außerdem unterstützen wir nun auch VNC und haben einige Verbesserungen an der Benutzeroberfläche vorgenommen (Drag-n-Drop, QuickConnect-Buttons, Tooltips mit Verbindungsinformationen, verbesserte History uvm.).

Ihr seit herzlich eingeladen unser zweites Release zu testen:
Download x86
Download x64

In kürze wird es im übrigen eine Dokumentation zu unserer Plugin-Schnittstelle geben, sodass jeder Plugins für beRemote entwickeln kann.
Für Ideen, Kritik, Featurewünsche und Bugmeldungen sind wir natürlich wie immer dankbar.

PS:
Umgesetzte Änderungen auf Grund eurer Beiträge:

• Datenbank liegt nun per default unter Appdata
• Es gibt nun Parameter zum aufrufen von beRemote

PPS:
Wer Lust hat und sofort über neue Features informiert werden möchte, kann uns seit einiger Zeit auch auf Twitter folgen:beRemoteTeam