Programm-Architektur bzw. Technologieauswahl (derzeit WinForms) um Updateprobleme zu beheben

Hallo,
ich habe aktuell ein Winform-Programm, welches auf ca. 15 Clients installiert ist.
Funktion: Es kommuniziert mit einen OPC-Server und mit Navision über Webservice. Wobei die Kommunikation zum OPC-Server mit einer Hersteller .NET Api gelöst ist.

Das Programm sieht teilweise unterschiedlich auf den Clients aus bzw. es werden unterschiedliche User Controls in Tabs angezeigt.

Nun habe ich aktuell folgende Probleme:
Wenn ich bei den Webservices (z.B. Funktion bekommt einen Parameter hinzu) etwas ändere muss , muss ich immer sofort alle Clients aktualisieren. Wie könnte ich den Update Prozess hier verbessern.
Weiteres bin ich mir nicht sicher ob ich auf WinForms bleiben sollte. Welche Technologie würde hier einsetzen. Habe aktuell leider nur mit WinForms gearbeitet.
Wäre z.B. eine zentrales Service eine bessere Lösung oder WEB usw.

Besten Dank für eure Hilfe bzw. Vorschläge
lg
stony

Wenn Du die Entitäten einer API änderst, dann musst Du diese auch zwingend beim Client aktualisieren; da führt kein Weg daran vorbei. Deswegen ist API Versionierung eine Wissenschaft für sich
Wenn es um Filterfunktionen geht, so gibt es OData, das alles rund um die Infrastruktur abdeckt und regelt.

Bei Aktualisierungen der Schnittstellen musst Du bei einer lokalen Instanz aktualisieren.
Das ist der riesen Vorteil von Webanwendungen: Du musst beim Client nichts aktualisieren. Und bei Apps (UWP bei Windows 10) gibts den Vorteil, dass Du das Aktualisieren komplett geschenkt bekommst.

Wenn es keine technologische Notwendigkeit gibt (zB. Performance bei CAD-Anwendungen) dann würde ich definitiv eine Webanwendung oder UWP (Windows 10 Requirement) empfehlen.

Hi,

hm - also wenn Updates so dermaßen häufig sind, dass Updates nicht die Ausnahme - sondern die Regel sind - dann ist eine lokale Anwendung schlicht die falsche Wahl in meinen Augen.

Von den Anforderungen, die du bisher genannt hast - würde ich wohl eine entsprechende Webanwendung aufsetzen mit ASP.NET. Dann sparst du dir die Updates.

Würde mir allerdings gut überlegen, dass sich das auch auszahlt - denn es kostet durchaus nicht wenig Einarbeitungszeit - und es muss ja auch sicher monetär noch sinnvoll sein. Insofern:
Wenn die Updates wirklich viele sind (ich glaub mehr wie 2-3 pro Jahr sollten ein gutes Maximum sein) -> Webanwendung. Wenn es weniger sind - würde ich eine schöne Update-Routine einbauen.

LG

Wobei es aber auch kein Hexenwerk ist einer lokalen Anwendung einen automatisches Update zu verpassen, sicherlich deutlich geringer im Vergleich zu einer Neuentwicklung in Technologie x.

Ich würde mir eine Webanwendung vor der Umsetzung genau durchdenken.
Meine Erfahrung mit praktisch allen Webanwendungen die ich kenne ist, dass Bedienkomfort und Optik nur schwer an eine clientseitige Anwendung herankommen.
Wenn man dann als Kunde zwischen den Zeilen gesagt bekommt "ich habs dadurch einfacher, damit müsst ihr eben leben" spricht das nicht sehr für den Entwickler.

Wozu hat sich denn MS mal ClickOnce ausgedacht?

Das hat den gesamten Updatemechanismus eingebaut, lässt sich recht einfach und Zentral im Unternehmen verwalten und benötigt keine Admin Berechtigungen.

Aber bei einer Neuentwicklung würde ich mir auch eher Web anschauen.

Als Web hin oder her aber was kostet es eine fertige App von WinForms auf Web zu portieren ?
Zumal ich denke, dass die meißte "logik" im Client ist.

Ich würde es also von den Kosten abhängig machen.
Wenig Kosten für eine WebApp -> WebApp (Wie Abt ja schon geschrieben hat, Look and Feel kann man gleich machen)
Bei hohen Kosten, Update Mechanismus einbauen oder Notfalls auf Click Once umsteigen
hier ist ein gutes Projekt um so etwas zu realisieren updateSystem.NET

Grüße

Veröffentlichung mit ClickOnce sollte am schnellsten das Problem lösen, die Updates jedesmal verteilen zu müssen. Vorteil ist, dass du keine Mühe in eine Änderung der vorhandenen UI-Technologie stecken musst - bei WinForms würde ich davon ausgehen, dass an vielen Stellen noch UI von Logik getrennt werden muss, und das kann Aufwand bedeuten.

Wenn du die UI komplett neu aufziehen möchtest, würde ich aus den von Abt genannten Gründen auf ClickOnce verzichten (ist es nicht ganz so übles Teufelszeug, wie es klingt, aber es hat echt Tücken). Mit einer Webanwendung ist man natürlich, was Aktualität des Clients angeht, auf der sicheren Seite UND spart sich aufwändige Installation und Updateroutinen. Der einzige Knackpunkt wäre, wenn die Clients derzeit UI-technisch irgendwas Abgefahrenes machen (kann man immer noch als Webanwendung umsetzen, wird aber unter Umständen schmerzhaft). Davon gehe ich aber bei WinForms auch nicht aus.

Schnelle Lösung - ClickOnce
langsamere, aber längerfristig tragfähigere Lösung - Webanwendung

LaTino

Danke mal für die viele Antworten.
Leider habe ich gerade nach gelesen und dadurch erfahren das das .Net Api keine ASP.NET Programme unterstützt da diese Ding signiert werden muss.

Wäre WFP eine Alternative.

@stony17
Deine Aussage ergibt für mich gerade keinen Sinn.
Was meinst du mit ASP .Net Programme?
ASP .Net ist eine Web Technologie aus Basis von .Net
Dort gibt es keine Programme.

Nachtrag:
Um dir beim Thema noch einen Denkanstoß zu geben.
Anstelle von X Parametern hinzuzufügen, was ab 7 Parametern auch zu viel wird, solltest du nur ein Container Objekt übergeben und dieses dann erweitern.
Die Clients brauchen dann im Idealfall nur ein Update, wenn dort Funktionen benätigt werden, die in der neuen "Version" deines Containers geschaltet werden können.

So kannst du quasi per Schalter Funktionen ausführen lassen und bei sauberen Kontrakten dann auch über Interfaces deine Antworten liefern lassen.
Aber hier müsstest du schon ein größeres Konzept fahren.
Wenn möglich könntest du auch einen Webservice aufsetzen, der einen XML Request String bekommt und dir einen XML Response String mit einem Schema liefert.
Dort könntest du dann Entsprechende Parameter + die Info welche interne Verarbeitung im Webservice ausgeführt werden soll, mitgeben.
Dies würde deine aktuellen Update Orgieen soweit drosseln, dass du wirklich nur bei neuen Funktionen deinen Client anpassen musst.

Aber hier musst du dann deine Architektur prüfen ob dies überhaupt machbar ist.
Wenn du z.b. komplexe Objekte oder Listen von komplexen/verzweigten Objekten liefern musst, wäre XML ab einer bestimmten Menge wieder Kontraproduktiv.
Dann könntest du ggf. auch über json als Format nachdenken.

Sollte als Denkanstoß reichen und dir ggf. sogar helfen dein Problem zu lösen.

Nachtrag 2:
WPF würde ich dir nicht direkt empfehlen.
Da du noch relativ am Anfang bist, müsstest du dich erst einmal in WPF einarbeiten, was aufgrund des eigenen Konzepts von WPF schon ein größeres Stück wäre.
Außerdem müstest du, je nachdem ob du ein Schichten Modell hast, ggf. den Client komplett neubauen.
Im Bestfall musst du nur die UI austauschen, was dir bei einem sauberen Schichten Modell recht einfach fallen dürfte.

Ansonsten würde ich einen Umstieg auf WPF nur wagen, wenn du die Zeit hast und es dir einen Mehrwert bringt.
Dein Update Problem würdest du damit nicht lösen, da du auch hier die Anwendung + DLLs updaten müsstest.

T-Virus

Ich habe leider noch null Erfahrung mit Web-Anwendungen, aber ich meine
Web-Anwendungen auf Basis von ASP.NET Technologie. So steht es zumindest in der Doku.

Leider habe ich gerade nach gelesen und dadurch erfahren das das .Net Api keine ASP.NET Programme unterstützt da diese Ding signiert werden muss.

Was soll dieser Satz bedeuten? Was meinst Du für eine API, was für ASP.NET Programme und wo kommt der Signatursatz her?
Bitte formuliere Deine Sätze so, dass potentielle Leser sie verstehen.

@stony17
Wenn du schon einen Webservice hast und deine Clients in WinForms darauf zugreifen, was willst du dann mit einem weiteren Web?
Dann könntest du auch gleich ein Web aufsetzen und dir den Webservice sparen.
Aber dann müsstest du deine gesamte Code Basis ggf. umwerfen, da dein gesamter Client obsolete wäre und du dann alles von Grundauf mit z.B. AngularJS, WebAPI und html5 neu machen müsstest.

Ohne zu wissen, was alles an deinem aktuellen Client hängt, würde ich kaum glauben das sich der Aufwand hier rechnen dürfte.
Oder ist dein Client quasi auf 2-3 WinForms Dialoge begrenzt?
Wenn dieser schon dicker ist, würde ich den WinForms Client beibehalten und mit eher überlegen die Anbindung zwischen Client und Service zu optimieren um dauerhafte Updates möglichst zu begrenzen oder nur im Notfall zu machen.

Hier musst du deinen Webservice eben kompakter programmieren.
Ansätze dafür stehen in meinem letzten Kommentar bzw. in den Kommentaren der anderen 😃

Nachtrag:
@Abt
Steht in seinem letzten Post.
Ist zwar immer noch nicht ganz klar, aber ich denke er überlegt einen Umstieg von WinForms auf ein Web ala WebForms o.ä.
Halte ich aber vom Aufwand her, abhängig von der größe des Clients und der aktuellen Architektur eher für einen schlechten Ansatz.

T-Virus

Anbei der Text vom Support für diese DLL:

Can ASP.Net Projects Be Created with ClientAce?

No, they cannot. In order to create a ClientAce project that can be signed, a project must have the ability to be compiled as an executable. ASP.Net applications cannot be compiled as executables. At this time, only C# or VB.Net Windows Forms, WPF Forms, Consoles, or Service Applications have this ability. To work around this limitation, users can create an ASP.Net project and a console or service application using ClientAce. In this application, ClientAce code can be used to read OPC data and then write that data to a data source that can be used by ASP.Net. The data handling side can be ADO or LINQ.

Und Danke für die raschen Antworten.

@stony17
Ist dir klar was da steht?
Dort steht eben, dass man ein ASP .Net Projekt nicht zu einer Anwendung wie WinForms oder einer Konsolen Anwendung kompilieren kann.
Ist ja auch korrekt, da ASP .Net keine Anwendungen sondern Webs liefert.
ASP steht auch für Active Server Pages.

Du solltest dich in die Grundlagen Themen lieber nochmal ein lesen bzw. in die unterschiedlichen Bereiche von .Net bevor du noch mehr falsche Sachen zusammen würfelst.

Nachtrag:
Das ClientAce scheint sich hier auf das OPC zu beziehen.
Man kann dies, in dem Text oben erklärt, also nur mit einer .Net Anwendung verwenden, da die Anwendung signiert werden muss.

T-Virus

Du solltest dich in die Grundlagen Themen lieber nochmal ein lesen bzw. in die unterschiedlichen Bereiche von .Net bevor du noch mehr falsche Sachen zusammen würfelst.

Genau deswegen hab ich doppelt nachgefragt.

stony17, mir persönlich fällt es schwer Deine Umgebung und Requirements überhaupt zu verstehen, wenn Du mit Informationen wie der DLL erst so spät um die Ecke kommst.
Welche Requirements kommen denn noch so ans Tageslicht? 😉 Wie T-Virus es schon gesagt hat: Du würfelst da leider sehr sehr viel durcheinander, das nichts oder wenig miteinander zutun hat.

Ich hatte durch meinen fast 10 Jahren (nicht die Welt, aber wenigstens ein bisschen Erfahrung) in der Maschinenbaubranche auch schon mit OPC-UA zutun - und bin ehrlich gesagt verwundert, warum ASP.NET hier nicht gehen sollte.
Wir haben genau das gemacht - unter anderem mit signierten DLLs 😉 Wenn es eine Einschränkung von ClientAce - sei es technischer Natur oder aus Lizenzgründen - dann wäre so eine Info vorab einfach gut gewesen; hätte Dir uns und Zeit gespart. Wir machen das ja nicht aus bösen Beweggründen.