Hallo Leute,
Ich hoffe ich habe hier das richtige Subforum für die Frage.
ich befinde mich gerade auf einem Scheideweg in meiner zukünftigen Entwicklung. Da vb.net ja von Microsoft defacto tot geredet ist und ich mich mit dem Thema c# auseinandersetzen muss, ist jetzt auch das Thema Zukunft des Frameworks zum zentralen Thema geworden. Wie die meisten mitbekommen haben wurde ja klargestellt das in Zukunft die Unterscheidung zwischen .net core / .net standard wegfallen und alles ins .net 5 als gemeinsame Plattform integriert wird. https://devblogs.microsoft.com/dotnet/introducing-net-5/
Ich habe ja schon mehr oder weniger erfolgreich ein Projekt auf den .net 5 Standard portiert:
Meine persönlichen Erfahrungen (ich habe als Basis mein CRM Tool genommen):
- Hat man eine Mehrlayer Architektur funktioniert es ganz gut.
- Die zentrale "App" in meiner Applikation musste ich von vb.net definitiv in C# umschreiben weil keine Templates in VS 2019 für VB.net verfügbar sind
- Das Umbauen der DLLs von 4.7 auf .net 5 hat insoweit gut funktioniert wenn man sich von Anfang an an die korrekten Konzepte aus .net hält und nicht vb6 Themen integriert hat (Vermeidung vom My Namespace usw.)
- Wer jetzt noch MVVM Light im Einsatz hat, hat ein Problem an der Backe. Die .core Implementierung wird seit Jahren nicht mehr aktualisiert, daher fehlt das wichtige CommandWPF. Lösung: Relaycommand Implementierung selbst machen.
In Summe habe ich ca. 2 bis 3 Tage verbraten um die Portierung hinzubekommen und das Programm wieder zum Laufen zu bringen.
Leider ist ein zentrales Thema (und das ich auch der Kern meiner Frage) für mich absolut ungelöst und anscheinend auf nicht wirklich lösbar:
Reporting mit RDLC Files (der klassische SQL Report!)
Win.Forms Reportviewer wird nicht mehr unterstützt (trifft auch schon im Core Framework zu).
Alternativen seitens MS sind Mangelware, eigentlich nicht vorhanden und es gibt auch keine Evidenz das sich MS dem Thema annimmt.
Ich habe für mich, diese 2 Lösungen entdeckt:
http://blog.geveo.com/IntegratingRDLCReportsToNetCoreProjects
Kurz beschrieben:
- Reports werden in eine eigene Assembly ausgelagert und über die ASP.net Core Implementierung von Reportviewer abgehandelt => funktioniert nicht ganz schlecht ist aber ein Drama wenn man, so wie ich, viele Parameter zu transportieren hat. Der Aufwand steigt auch enorm. Parallel dazu ergibt sich aktuell für mich das Problem, das ich zwar ein PDF erstelle (was auch funktioniert) dieses dann aber wieder aufrufen muss um eine Art Vorschau abzubilden.
und
https://github.com/lkosson/reportviewercore
Kurz beschrieben:
- Hier hat jemand eine eigene Implementierung für Win.Forms.Reportviewer gemacht um diesen zu ersetzen.
Die Lösung klingt ganz gut, ich bin aber noch nicht wirklich damit klargekommen, die Dokumentation ist etwas lückenhaft (damit muss ich mich defacto noch beschäftigen).
-----
Fazit:
Ms hat nichts offizielles, es gibt ein paar, leider kostenpflichtige, Lösungen. Es gibt Empfehlungen mit Art Report Services, serverseitig zu arbeiten, also alles und nichts.
Mich würde hier interessieren, hat sich jemand mit dem Thema beschäftigt, gibt es Lösungsansätze die ich noch nicht gesehen habe, oder hat Microsoft entschieden das Papierreports generell böse sind und wir in Zukunft ohne diese Reports auskommen müssen?
Ps:
Ich habe auch einmal Reporting über Flow Documents gemacht aber das war ein enormer Aufwand und wenig flexibel.
Ich hoffe ich habe hier das richtige Subforum für die Frage.
ich befinde mich gerade auf einem Scheideweg in meiner zukünftigen Entwicklung. Da vb.net ja von Microsoft defacto tot geredet ist und ich mich mit dem Thema c# auseinandersetzen muss, ist jetzt auch das Thema Zukunft des Frameworks zum zentralen Thema geworden. Wie die meisten mitbekommen haben wurde ja klargestellt das in Zukunft die Unterscheidung zwischen .net core / .net standard wegfallen und alles ins .net 5 als gemeinsame Plattform integriert wird. https://devblogs.microsoft.com/dotnet/introducing-net-5/
Ich habe ja schon mehr oder weniger erfolgreich ein Projekt auf den .net 5 Standard portiert:
Meine persönlichen Erfahrungen (ich habe als Basis mein CRM Tool genommen):
- Hat man eine Mehrlayer Architektur funktioniert es ganz gut.
- Die zentrale "App" in meiner Applikation musste ich von vb.net definitiv in C# umschreiben weil keine Templates in VS 2019 für VB.net verfügbar sind
- Das Umbauen der DLLs von 4.7 auf .net 5 hat insoweit gut funktioniert wenn man sich von Anfang an an die korrekten Konzepte aus .net hält und nicht vb6 Themen integriert hat (Vermeidung vom My Namespace usw.)
- Wer jetzt noch MVVM Light im Einsatz hat, hat ein Problem an der Backe. Die .core Implementierung wird seit Jahren nicht mehr aktualisiert, daher fehlt das wichtige CommandWPF. Lösung: Relaycommand Implementierung selbst machen.
In Summe habe ich ca. 2 bis 3 Tage verbraten um die Portierung hinzubekommen und das Programm wieder zum Laufen zu bringen.
Leider ist ein zentrales Thema (und das ich auch der Kern meiner Frage) für mich absolut ungelöst und anscheinend auf nicht wirklich lösbar:
Reporting mit RDLC Files (der klassische SQL Report!)
Win.Forms Reportviewer wird nicht mehr unterstützt (trifft auch schon im Core Framework zu).
Alternativen seitens MS sind Mangelware, eigentlich nicht vorhanden und es gibt auch keine Evidenz das sich MS dem Thema annimmt.
Ich habe für mich, diese 2 Lösungen entdeckt:
http://blog.geveo.com/IntegratingRDLCReportsToNetCoreProjects
Kurz beschrieben:
- Reports werden in eine eigene Assembly ausgelagert und über die ASP.net Core Implementierung von Reportviewer abgehandelt => funktioniert nicht ganz schlecht ist aber ein Drama wenn man, so wie ich, viele Parameter zu transportieren hat. Der Aufwand steigt auch enorm. Parallel dazu ergibt sich aktuell für mich das Problem, das ich zwar ein PDF erstelle (was auch funktioniert) dieses dann aber wieder aufrufen muss um eine Art Vorschau abzubilden.
und
https://github.com/lkosson/reportviewercore
Kurz beschrieben:
- Hier hat jemand eine eigene Implementierung für Win.Forms.Reportviewer gemacht um diesen zu ersetzen.
Die Lösung klingt ganz gut, ich bin aber noch nicht wirklich damit klargekommen, die Dokumentation ist etwas lückenhaft (damit muss ich mich defacto noch beschäftigen).
-----
Fazit:
Ms hat nichts offizielles, es gibt ein paar, leider kostenpflichtige, Lösungen. Es gibt Empfehlungen mit Art Report Services, serverseitig zu arbeiten, also alles und nichts.
Mich würde hier interessieren, hat sich jemand mit dem Thema beschäftigt, gibt es Lösungsansätze die ich noch nicht gesehen habe, oder hat Microsoft entschieden das Papierreports generell böse sind und wir in Zukunft ohne diese Reports auskommen müssen?
Ps:
Ich habe auch einmal Reporting über Flow Documents gemacht aber das war ein enormer Aufwand und wenig flexibel.
mfG.
Stephan
Stephan