Laden...

Wie kann ich aus .NET Core via COM-Call eine .NET Framework Assembly aufrufen, die Reports erzeugt?

Erstellt von 1nf1n1ty vor 3 Jahren Letzter Beitrag vor 3 Jahren 819 Views
1nf1n1ty Themenstarter:in
286 Beiträge seit 2007
vor 3 Jahren
Wie kann ich aus .NET Core via COM-Call eine .NET Framework Assembly aufrufen, die Reports erzeugt?

Moin zusammen,

ich hoffe der Titel und das Forum passen, sonst bitte verschieben. Ich habe eine .NET Core 3 Anwendung, die von einer .NET Framework 4.5 Anwendung portiert wird. Ursprünglich wurde da eine Reporting-Engine verwendet, die es unter .NET Core nun nicht mehr gibt. Es handelt sich aber um sehr viele Reports, die nach Möglichkeit nicht alle neu erstellt werden sollen.

Mein Erster Ansatz war mit dem Windows Compatibility Pack zu arbeiten. Den musste ich leider canceln, weil die Reportkomponente Verweise auf System.Windows.Forms und System.Web enthält. Diese kann ich in einem .NET Core-Projekt leider nicht hinzufügen.

Meine Idee war nun den Zugriff über COM möglich zu machen. D.h. .NET Core macht einen COM-Call auf eine .NET Framework Assembly, welche wiederum den Report erzeugt und ein PDF in ein Verzeichnis legt und ein Ergebnis zurückmeldet. Mein Problem befindet sich beim Aufrufen des .NET Frameworks.

Ich habe die Assembly sichtbar gemacht (ComVisible(true)), alles mit GUIDs und ProgID versehen wie man das eben macht. Anschließend habe ich die Assembly referenziert. Der Aufruf der Methode klappt auch, allerdings bekomme ich dann eine FileNotFoundException. Verwiesen wird in dieser auf System.Configuration.ConfigurationManager aus dem .NET Framework.

Und da hänge ich jetzt fest. Ich brauche nun eine Idee warum die Assemblies nicht geladen werden. Muss ich mich in dem Falle selbst darum kümmern? Wenn ja: Wie stelle ich das an? Ich muss ja an jede Abhängigkeit denken.

Vielen Dank für die Hilfe

T
2.219 Beiträge seit 2008
vor 3 Jahren

Wäre es in dem Fall nicht möglich/sinnvoller, die alte Anwendung auf Framework zu belassen?
Welchen Zweck soll die Portierung haben, wenn die Abhängigkeit zum Framework eh nicht verändert werden können?

Wenn es sich dabei auch noch um eine alte Engine handelt, z.B. ≤ .NET 4.0 wird eine Portierung eh kaum klappen.
Ich würde sonst überlegen die Anwendung zur Generierung der Reports als .NET Framework Anwendung zu belassen.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

1nf1n1ty Themenstarter:in
286 Beiträge seit 2007
vor 3 Jahren

Hallo T-Virus,

ja, mit dem COM-Ansatz erkauft man sich die Abhängigkeit zum .NET Framework, das ist richtig. Es existiert jedoch bereits eine .NET Core Anwendung, die als Rahmen fungiert. Es ging nun lediglich darum damit auch Reports zu erzeugen. Da es schon einige sind erschien der Ansatz das über COM zu wrappen als einfacherere/schnellere Lösung um zumindest kurzfristig zu starten ohne an den Grundlagen der Reports zuviel rumzubasteln (und ggf. etwas kaputt zu machen).

Mittelfristig wäre der Weg eher den alten Kram abzulösen und auf neue Füße zu stellen, das wiederum ist aber dann ein größeres Projekt.

Viele Grüße

J
641 Beiträge seit 2007
vor 3 Jahren

Was ist es den für eine Report Engine?

cSharp Projekte : https://github.com/jogibear9988

16.806 Beiträge seit 2008
vor 3 Jahren

Die letzten Monate haben eher gezeigt, dass so eine "Zwitter-Runtime" mit .NET Core -> NET Framework -> COM keine gute Idee ist und das nicht so super toll funktioniert.

A
764 Beiträge seit 2007
vor 3 Jahren

Die letzten Monate haben eher gezeigt, dass so eine "Zwitter-Runtime" mit .NET Core -> NET Framework -> COM keine gute Idee ist und das nicht so super toll funktioniert.

Ich gehe sogar soweit zu behaupten, dass COM niemals mehr benutzt werden sollte und jeder! andere Ansatz besser (weniger schlecht) ist.

Noch zur Sache:
Du könntest den Report-Teil ja als eigene Applikation laufen lassen.
Werf ihm die Daten als XML hin und lass eine deine Report-App drüber laufen, oder biete das ganze als REST-Service an. Gibt da einige Möglichkeiten.

H
48 Beiträge seit 2020
vor 3 Jahren

com ist tot und den austausch kann man per grpc machen

1nf1n1ty Themenstarter:in
286 Beiträge seit 2007
vor 3 Jahren

Die ReportEngine ist die (gute) alte Crystal Reports Engine.

Ich habe in der Tat deinen Vorschlag (eigene Applikation) umgesetzt. .NET Core bietet zwar den Ansatz auf COM zuzugreifen, aber es hatte bei meinen Tests (und ich habe wirklich noch viel versucht) nicht funktioniert. Das COM nun aber absolut tot sein soll war mir so nicht bewusst, da ja erst die Unterstützung dafür in .NET Core Einzug erhalten hatte. Ich habe in der Vergangenheit schon einiges mit COM gemacht und das hatte bisher eigentlich immer funktioniert.

Wie dem auch sei: den Aufruf des neuen Tools habe ich nun soweit gekapselt, dass es eine Klasse zur Unterstützung der Ansteuerung des Tools gibt. Sie ruft das Tool im Hintergrund mit entsprechenden Parametern auf. Das Tool muss dann zwar mit ausgeliefert werden, ist dann aber so. Es funktioniert so jedenfalls super und es ist ja nicht als langfristige Lösung geplant. Für die Übergangsphase reicht das so erstmal.

Vielen Dank für eure Impulse.

Hinweis von Abt vor 3 Jahren

Bitte keine Full Quotes
[Hinweis] Wie poste ich richtig?

16.806 Beiträge seit 2008
vor 3 Jahren

Es wird seit >15 Jahren schon gepredigt endlich von COM Abschied zu nehmen - oft wird sich leider erst immer drum gekümmert, wenn der Druck zu groß wird.

Trotzdem, trotz dieser Predigt, wurde die COM Unterstützung in .NET Core extremst verbessert gegenüber dem Verhalten von .NET Framework. Grund: die Leute so schnell wie möglich von .NET Framework auf .NET Core zu portieren und den Weg dahingehend so einfach wie möglich machen.
Daher kann ich persönlich nur schwer glauben, dass es an .NET Core <-> COM selbst liegt.

Für die Übergangsphase reicht das so erstmal.

Nichts hält sich länger als Übergangslösungen - siehe COM 😉

F
10.010 Beiträge seit 2004
vor 3 Jahren

Leider wird COM immer noch zu oft benutzt und weitergepflegt.
Habe gerade erst für Lenel einen OpenDevice "Driver" erstellen müssen und das ist COM.
Gräßlich, wenn man modernere Sachen gewohnt ist.