Announcement: there is an English version of this forum on 
Nabend, ich bin auf der Suche eine Windows Anwendung die auf einem Server liegt, im Browser laufen zu lassen, also die GUI der Server Anwendung soll im Browser des Clients laufen. Ich erinnere mich das es da vor ~25 Jahren oder so mal was gegeben hat, war nicht schön aber hat funktioniert. Glaube das hatte irgendetwas mit cgi zu tun, war aber für GUI. Alternativ suche ich eine Möglichkeit eine C# .Net Anwendung (egal ob Framework oder Core, egal WPF oder WinForms), relativ einfach in einen Client und Server zu zerlegen, wie ich das mit TCP Sockets und Co anstelle weiß ich, es geht mir darum das Ganze mit möglichst wenig Aufwand zu bewerkstelligen. Hintergrund ist, es soll eine eigen entwickelte Produktiv Anwendung mit diverser Peripherie dran, in separate Back- und Frontend Anwendungen zerlegt werden.
:
Bearbeitet durch User
Tim T. schrieb: > ich bin auf der Suche eine Windows Anwendung die auf einem Server liegt, > im Browser laufen zu lassen, also die GUI der Server Anwendung soll im > Browser des Clients laufen. Du meinst vermutlich das hier: https://novnc.com/info.html
Hmmm schrieb: > Tim T. schrieb: >> ich bin auf der Suche eine Windows Anwendung die auf einem Server liegt, >> im Browser laufen zu lassen, also die GUI der Server Anwendung soll im >> Browser des Clients laufen. > > Du meinst vermutlich das hier: > > https://novnc.com/info.html Nein, kein VNC im Browser, es war nur die Anwendung, nicht der ganze Desktop. Wenn es so einfach wäre würde ich einfach RDP nehmen.
:
Bearbeitet durch User
Tim T. schrieb: > Hintergrund ist, es soll eine eigen entwickelte Produktiv Anwendung mit > diverser Peripherie dran, in separate Back- und Frontend Anwendungen > zerlegt werden. Dazu entwickelt man die "Produktiv-Anwendung" einfach direkt als Webanwendung.
Tim T. schrieb: > Wenn es so einfach wäre würde ich einfach RDP nehmen. https://learn.microsoft.com/de-de/troubleshoot/windows-server/remote/single-application-sharing-with-terminal-server
Tim T. schrieb: > ich bin auf der Suche eine Windows Anwendung die auf einem Server liegt, > im Browser laufen zu lassen, also die GUI der Server Anwendung soll im > Browser des Clients laufen. Ich erinnere mich das es da vor ~25 Jahren > oder so mal was gegeben hat, war nicht schön aber hat funktioniert. War das damals nicht mit Java oder auch mit Javascript verbunden? Bei Diablo2 sind optimale (naja..) Javascript-Verwaltungen im Hintergrund. Eigentlich vorbildlich, denn andere Spiele waren damals für Online noch teilweise in der Sackgasse.
Es gab mal Microsoft Silverlight, womit man .net Anwendungen komplett im Browser laufen lassen konnte. Quasi als Konkurrenz zu Java Applets, die ebenso komplett im Browser liefen. Außerdem gab es ActiveX, womit man Steuerelemente für den Browser in nativen Sprachen schreiben konnte. Silverlight und ActiveX sind längst eingestellt, und Java Applets sind auch "so gut wie tot" (und sind kaum noch unterstützt, weil sie immer mit Sicherheitslücken zu kämpfen hatten). Das ist aber alles komplett client-seitig, d.h. der Server ist jeweils eine komplett separate Anwendung, und man würde typischerweise per HTTP kommunizieren. Du hast aber ein fundamentales Problem: Tim T. schrieb: > also die GUI der Server Anwendung soll im > Browser des Clients laufen Eine Server-Anwendung hat erstmal keine GUI. Wenn du eine GUI-Anwendung hast, die in irgendeiner Form im Browser läuft, muss sie mit einer separaten Server-Anwendung, die auf dem Server läuft, kommunizieren. Typischerweise per HTTP. Das ist genau das, was 99.99% aller interaktiven Websites heutzutage machen, wobei die GUI-Anwendung in JavaScript geschrieben ist. Du könntest die klassische Windows-GUI-Anwendung auf dem Server laufen lassen und die GUI-Ausgabe in den Browser "Live-streamen", typischerweise per VNC/RDP und Browser-Client dafür (wie noVNC), aber nur das eine Fenster statt des ganzen Desktops. Ginge zwar, dürfte aber sehr ineffizient sein, den Server und dessen Internetverbindung belasten, und ziemlich hakelig zu bedienen sein. Tim T. schrieb: > Ich erinnere mich das es da vor ~25 Jahren > oder so mal was gegeben hat, war nicht schön aber hat funktioniert. > Glaube das hatte irgendetwas mit cgi zu tun, war aber für GUI. CGI läuft ja auf dem Server - also vielleicht wurde da per CGI-Anwendung ein Fensterinhalt in den Browser gestreamt. Wobei ich mir schlecht vorstellen kann, dass das vor 25 Jahren besonders gut funktioniert haben soll. Das einzig sinvolle Konzept ist es, GUI und Server zu trennen, und beide kommunizieren zu lassen. Da es um Web/Browser geht, ist HTTP/REST sehr naheliegend. Aber: Tim T. schrieb: > relativ einfach in einen > Client und Server zu zerlegen, wie ich das mit TCP Sockets und Co > anstelle weiß ich, es geht mir darum das Ganze mit möglichst wenig > Aufwand zu bewerkstelligen. Das ist so wie zu fragen, wie man einfach aus einem Auto ein Flugzeug bauen kann... Glücklicherweise gibt es viele leistungsfähige Frameworks für alle möglichen Sprachen um Web-Server-Anwendungen zu implementieren. Die sind aber natürlich nicht dafür da, dass man eine Desktop-GUI-Anwendung mal eben schnell umbaut. Die beste Lösung ist also: - Die reine Server-Funktionalität in C# in ASP.net laufen lassen, und ein HTTP-REST-Interface dafür implementieren - Eine GUI mit den üblichen Web-Technologien, also HTML+CSS+JavaScript implementieren, welche mit dem Server via HTTP+REST kommuniziert Es gibt eine Unmenge an Software, Tools, Frameworks, Büchern, Tutorials wie das geht, aber "mal eben schnell" ist das auch nicht. Dafür ist es dann gut und flüssig bedienbar, und wenn korrekt umgesetzt auch vom Smartphone aus etc. nutzbar. Du könntest den Client auch in C# als Desktop-Anwendung implementieren und per Sockets mit dem Server kommunizieren lassen, aber das ist umständlicher und weil dieser Ansatz mittlerweile ziemlich "out" ist, gibt es auch nicht so viel Software+Ressourcen dafür. Außerdem ist es aufwendig, den Client auf verschiedenen Plattformen laufen lassen zu können. Ansonsten bleibt nur das Fenster der GUI-Anwendung per VNC o.ä. zu streamen, mit den genannten Nachteilen.
Niklas G. schrieb: > Es gab mal Microsoft Silverlight, womit man .net Anwendungen komplett im > Browser laufen lassen konnte. Quasi als Konkurrenz zu Java Applets, die > ebenso komplett im Browser liefen. Außerdem gab es ActiveX, womit man > Steuerelemente für den Browser in nativen Sprachen schreiben konnte. > Silverlight und ActiveX sind längst eingestellt, und Java Applets sind > auch "so gut wie tot" (und sind kaum noch unterstützt, weil sie immer > mit Sicherheitslücken zu kämpfen hatten). > > Das ist aber alles komplett client-seitig, d.h. der Server ist jeweils > eine komplett separate Anwendung, und man würde typischerweise per HTTP > kommunizieren. Nein das ist es nicht. > Du hast aber ein fundamentales Problem: > > Tim T. schrieb: >> also die GUI der Server Anwendung soll im >> Browser des Clients laufen > > Eine Server-Anwendung hat erstmal keine GUI. Wenn du eine GUI-Anwendung > hast, die in irgendeiner Form im Browser läuft, muss sie mit einer > separaten Server-Anwendung, die auf dem Server läuft, kommunizieren. > Typischerweise per HTTP. Das ist genau das, was 99.99% aller > interaktiven Websites heutzutage machen, wobei die GUI-Anwendung in > JavaScript geschrieben ist. Unsinn, ob eine Server-Anwendung eine GUI hat oder nicht wird nicht dadurch entschieden ob es eine Server-Anwendung ist oder nicht. Der Rest ist absolut klar. > Du könntest die klassische Windows-GUI-Anwendung auf dem Server laufen > lassen und die GUI-Ausgabe in den Browser "Live-streamen", > typischerweise per VNC/RDP und Browser-Client dafür (wie noVNC), aber > nur das eine Fenster statt des ganzen Desktops. Ginge zwar, dürfte aber > sehr ineffizient sein, den Server und dessen Internetverbindung > belasten, und ziemlich hakelig zu bedienen sein. Genau das, nur ohne RDP und VNC war die Idee. Das Internet ist im übrigen dabei nicht involviert. > Tim T. schrieb: >> Ich erinnere mich das es da vor ~25 Jahren >> oder so mal was gegeben hat, war nicht schön aber hat funktioniert. >> Glaube das hatte irgendetwas mit cgi zu tun, war aber für GUI. > > CGI läuft ja auf dem Server - also vielleicht wurde da per CGI-Anwendung > ein Fensterinhalt in den Browser gestreamt. Wobei ich mir schlecht > vorstellen kann, dass das vor 25 Jahren besonders gut funktioniert haben > soll. Doch genau sowas lief da ab, nur das es kein Stream war sondern eher eine statische Angelegenheit mit mehr oder weniger häufigen Refreshs. > Das einzig sinvolle Konzept ist es, GUI und Server zu trennen, und beide > kommunizieren zu lassen. Da es um Web/Browser geht, ist HTTP/REST sehr > naheliegend. Aber: Das ist aber nunmal die Arbeitsaufwändigste Variante vor der ich mich versuche zu drücken. Dafür würde ich aber dann auch nicht auf HTTP/REST zurückgreifen sondern auf Sockets. Ansonsten wäre .NET Remoting noch eine Idee aber das ist ja leider mittlerweile auch tot. > Tim T. schrieb: >> relativ einfach in einen >> Client und Server zu zerlegen, wie ich das mit TCP Sockets und Co >> anstelle weiß ich, es geht mir darum das Ganze mit möglichst wenig >> Aufwand zu bewerkstelligen. > > Das ist so wie zu fragen, wie man einfach aus einem Auto ein Flugzeug > bauen kann... Nö, nur bevor ich anfange die GUI von der Funktionalität zu trennen und dabei Zeit zu versenken, wollte ich mal Fragen ob es da irgendwelche tollen Ideen gibt ohne so viel Aufwand. > Glücklicherweise gibt es viele leistungsfähige Frameworks für alle > möglichen Sprachen um Web-Server-Anwendungen zu implementieren. Die sind > aber natürlich nicht dafür da, dass man eine Desktop-GUI-Anwendung mal > eben schnell umbaut. Die Web Sache war nur für die GUI von der Anwendung, die auf dem Server läuft, direkt in ein Browser Fenster zu verfrachten, also praktisch komplett ohne Aufwand. > Die beste Lösung ist also: > - Die reine Server-Funktionalität in C# in ASP.net laufen lassen, und > ein HTTP-REST-Interface dafür implementieren > - Eine GUI mit den üblichen Web-Technologien, also HTML+CSS+JavaScript > implementieren, welche mit dem Server via HTTP+REST kommuniziert Oder eben den Web Blödsinn komplett zu lassen, die GUI von der Anwendung abzutrennen und diese beiden Teile über Sockets mit Delegaten, etc. kommunizieren zu lassen. > Es gibt eine Unmenge an Software, Tools, Frameworks, Büchern, Tutorials > wie das geht, aber "mal eben schnell" ist das auch nicht. Dafür ist es > dann gut und flüssig bedienbar, und wenn korrekt umgesetzt auch vom > Smartphone aus etc. nutzbar. Alles nicht mein Use Case, es ging nur um einen Weg ohne viel Aufwand das vorhandene Programm über den Browser woanders anzeigen zu lassen, mehr nicht. > Du könntest den Client auch in C# als Desktop-Anwendung implementieren > und per Sockets mit dem Server kommunizieren lassen, aber das ist > umständlicher und weil dieser Ansatz mittlerweile ziemlich "out" ist, > gibt es auch nicht so viel Software+Ressourcen dafür. Außerdem ist es > aufwendig, den Client auf verschiedenen Plattformen laufen lassen zu > können. Vorteil dabei ist, GUI und Anwendung sind beide schon fertig und wegen Async Aufrufen auch schon über Delegaten getrennt. Wird also darauf hinauslaufen, wenn nicht noch die Zündende Idee zum Ursprungsproblem kommt. Verschiedene Plattformen sind ebenfalls kein Thema es läuft auf beiden Seiten ganz banal unter Windows. Wobei die Serverseite (Applikationsausführende Seite) unter Linux laufen zu lassen schon einen gewissen Reiz hätte, aber dafür bekomme ich keine Kappa. > Ansonsten bleibt nur das Fenster der GUI-Anwendung per VNC o.ä. zu > streamen, mit den genannten Nachteilen. Da wäre die Alternative das Ganze als Citrix Virtual Apps oder sowas laufen zu lassen, sind aber halt wieder dauerhafte Kosten und wenn irgendwann mal alle betreffenden Systeme so umgestellt werden, ist es wieder ein Kostenfaktor.
:
Bearbeitet durch User
Das was du suchst ist das hier: https://dotnet.microsoft.com/en-us/learn/aspnet/blazor-tutorial/intro
Tim T. schrieb: > Unsinn, ob eine Server-Anwendung eine GUI hat oder nicht wird nicht > dadurch entschieden ob es eine Server-Anwendung ist oder nicht Es gibt Server Anwendungen mit GUI, aber dies ist meist eine lokale Admin Gui und nicht das, was der Client zu sehen bekommt. Tim T. schrieb: > Genau das, nur ohne RDP und VNC war die Idee. Du kannst dir natürlich gern ein eigenes Protokoll basteln, aber die Frage ist wozu. Tim T. schrieb: > Stream war sondern eher eine statische Angelegenheit mit mehr oder > weniger häufigen Refreshs. Na das kannst du immer noch so haben, Screenshots machen ist einfach. Tim T. schrieb: > Dafür würde ich aber dann auch nicht auf HTTP/REST zurückgreifen sondern > auf Sockets. Nackte Sockets zu nutzen ist halt viel komplizierter, weil du dein eigenes Protokoll drauf setzen musst. Allein schon die Tatsache, dass ein abgesendeter Block in einzelnen Bytes ankommen kann macht die Sache umständlich. Bei REST kriegst du das alles fix und fertig von den diversen Webframeworks, du hängst dich nur in die entsprechenden Callbacks rein. Tim T. schrieb: > Oder eben den Web Blödsinn Der Web Blödsinn ist halt extrem etabliert und mittlerweile die einfachste Möglichkeit, eine leistungsfähige GUI zu bauen. Tim T. schrieb: > und diese beiden Teile über Sockets mit Delegaten, etc. kommunizieren zu > lassen. Delegate kannst du bei Webentwicklung auch nutzen... Tim T. schrieb: > Vorteil dabei ist, GUI und Anwendung sind beide schon fertig und wegen > Async Aufrufen auch schon über Delegaten getrennt. Praktisch, aber es könnte durchaus trotzdem einfacher sein, in der Client Anwendung eine HTTP Library zu nutzen für die Kommunikation statt direkt auf nackte Sockets zuzugreifen. Ein wichtiger Teil ist natürlich dass du im Client die Kommunikation asynchron machst damit die GUI nicht einfriert; im Browser gibt's das gratis.
Tim T. schrieb: > Da wäre die Alternative das Ganze als Citrix Virtual Apps oder sowas > laufen zu lassen, sind aber halt wieder dauerhafte Kosten und wenn > irgendwann mal alle betreffenden Systeme so umgestellt werden, ist es > wieder ein Kostenfaktor. Citrix waere wohl am einfachsten. :) Ich habe aber auch schon ein JBoss-basiertes Webportal gesehen, dass neben den typischen Webanwendungen, auch (externe) Applikationen starten konnte, die dann im Browserfenster angezeigt wurden. Aber keine Ahnung wie die das gemacht haben... Vielleicht mit einem RDP-Proxy?
Mit genügend Energie und Wissen kann man sowas natürlich selber auch "ausprogrammieren": Die App bekommt einen internen, minimalen Webserver und entsprechend Code, die GUI-Controls dort abzubilden. Ist zwar mühsam, aber durchaus machbar. Schwierig bis unmöglich wird es nur, sowas nachträglich an eine bereits ferige App dranzuklöppeln ... Ein Kompromiss könnte es sein, das RDP-Protokoll in ein Webinterface einzubinden. Das RDP-Prokokoll sollte offen sein, weil es zahlreiche Open Source-Clients für RDP gibt und RDP auch auf ein Fenster einer Anwendung begrenzt werden kann. Gerade gefunden: https://learn.microsoft.com/de-de/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client remote-desktop-_web_-client!
Frank E. schrieb: > Die App bekommt einen internen, minimalen Webserver und entsprechend > Code, die GUI-Controls dort abzubilden. Ist das nicht genau das, was man z.B. bei Java Glassfish (zumindest zum Testen) macht? Interner Webserver, und eben die GUI in Form von HTML+JS ausliefern. Aber ob der Server intern oder extern ist macht doch kaum einen Unterschied. Oder meinst du dass man die vorhandene UI (in WPF o.ä.) automatisch in Web-Steuerelemente "konvertieren" würde? Frank E. schrieb: > Ein Kompromiss könnte es sein, das RDP-Protokoll in ein Webinterface > einzubinden. RDP und VNC will er ja nicht.
Frank E. schrieb: > Gerade gefunden: > > https://learn.microsoft.com/de-de/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client Und was habe ich deutlich weiter oben verlinkt? Wie man eine einzelne Anwendung via RDP zugänglich machen kann.
Niklas G. schrieb: > RDP und VNC will er ja nicht. Davon merkt er ja nichts - auf Client-Seite guckt er mit dem Browser und auch nur das Fenster der App, nicht den gesamten Desktop. RDP kommt nur als Quelle auf dem Server zum Einsatz.
Niklas G. schrieb: > ausliefern. Aber ob der Server intern oder extern ist macht doch kaum > einen Unterschied. Oder meinst du dass man die vorhandene UI (in WPF Nur ein App-interner Server hat auschließlich Zugriff auf die App, alles andere würde vermutlich (zumindest potenziell) den gesamten Desktop übertragen. Das könnte man entschärfen, wenn die App von Hause aus ausschießlich full screen läuft und sich nicht (über das Webinterface) beenden lässt.
Frank E. schrieb: > Davon merkt er ja nichts - auf Client-Seite guckt er mit dem Browser > und auch nur das Fenster der App, nicht den gesamten Desktop. Würde ich auch denken, aber will er ja nicht. Frank E. schrieb: > alles andere würde vermutlich (zumindest potenziell) den gesamten > Desktop übertragen Naja, dann muss man das VNC Ding halt so konfigurieren dass es immer nur auf das einzelne Fenster zugreift. Klar kann der VNC Server fehlerhaft sein, aber die eigene App kann genausogut fehlerhaft sein und irgendwelche Daten abgreifen oder Screenshots vom ganzen(!) Desktop machen und raussenden. Rein zufällig sind die gängigen Lösungen mit Webserver&Framework natürlich millionenfach erprobt und ausgereift...
:
Bearbeitet durch User
Frank E. schrieb: > alles andere würde vermutlich (zumindest potenziell) den > gesamten Desktop übertragen. Und, wo ist da das Problem? So eine Anwendung lässt man ja eh' in einem eigenen, dafür auf das nötigste beschnittenen Nutzerkonto laufen. Was soll es also stören, wenn da auch noch Desktop zu sehen ist?
Harald K. schrieb: > Frank E. schrieb: >> alles andere würde vermutlich (zumindest potenziell) den >> gesamten Desktop übertragen. > > Und, wo ist da das Problem? So eine Anwendung lässt man ja eh' in einem > eigenen, dafür auf das nötigste beschnittenen Nutzerkonto laufen. Was > soll es also stören, wenn da auch noch Desktop zu sehen ist? Hast du mal Software für Fremde entwickelt? Die kommen auf Ideen, sag ich dir, daran denkt man im Traume nicht. Oder sie sind verwirrt, an Stellen, die man selber garnicht wahrnimmt. Deshalb sowas immer von möglichst vielen Unbeteiligten und Ahnungslosen testen lassen ... :-)
Frank E. schrieb: > Hast du mal Software für Fremde entwickelt? Ich verdiene seit Jahrzehnten mein Geld damit. > Die kommen auf Ideen, sag > ich dir, daran denkt man im Traume nicht. Sicher. Aber abgesehen von psychischen Problemen ("Da ist aber doch ein Desktop!") kann so etwas keinen Schaden anrichten - einfach, weil das entsprechende Benutzerkonto so konfiguriert ist. Man könnte auch die eine Anwendung, um die es geht, anstelle des Explorers laufen lassen, dann gibt es keinen Desktop, sondern wirklich nur diese Anwendung. Dazu muss man für das entsprechende Benutzerkonto diesen Registry-Key anpassen:
1 | HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell |
Harald K. schrieb: > einfach, weil das entsprechende Benutzerkonto so konfiguriert ist. So einfach ist es dann auch nicht, es kann schnell mal passieren dass man versehentlich was frei gibt. Wenn die Dateisystem-Berechtigungen von Dateien eines anderen Users versehentlich zu lax eingestellt sind... Oder man vergessen hat einzustellen dass der User den PC nicht herunterfahren darf... Es gibt bestimmt noch zig weitere Dinge. Harald K. schrieb: > sondern wirklich nur diese Anwendung Dann muss man aber auch sicher sein dass man in der Anwendung garantiert nichts "exploiten" kann. Konnte man nicht zB unter Win95 den Login Screen umgehen indem man dort auf den Hilfe-Knopf geklickt hat und dann über Umwege den IE öffnen konnte...? Tendentiell würd ich sowas eher in einer VM oder Container machen, worin sonst nichts anderes läuft.
Niklas G. schrieb: > So einfach ist es dann auch nicht, es kann schnell mal passieren dass > man versehentlich was frei gibt. Wenn die Dateisystem-Berechtigungen von > Dateien eines anderen Users versehentlich zu lax eingestellt sind... > Oder man vergessen hat einzustellen dass der User den PC nicht > herunterfahren darf Wenn man nicht in der Lage ist, seinen Rechner richtig zu konfigurieren, dann sollte man von komplexeren Aufgaben die Finger lassen. Sicherheit ist nicht idiotensicher.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.