Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

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

Avatar #avatar-2711.jpg


Dabei seit:
Beiträge: 285

Themenstarter:

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

beantworten | zitieren | melden

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
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von 1nf1n1ty am .
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1821
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
1nf1n1ty
myCSharp.de - Member

Avatar #avatar-2711.jpg


Dabei seit:
Beiträge: 285

Themenstarter:

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
jogibear9988
myCSharp.de - Member



Dabei seit:
Beiträge: 586
Herkunft: Offenau

beantworten | zitieren | melden

Was ist es den für eine Report Engine?
cSharp Projekte : https://github.com/jogibear9988
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15705
Herkunft: BW

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Alf Ator
myCSharp.de - Member



Dabei seit:
Beiträge: 631

beantworten | zitieren | melden

Zitat von Abt
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.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Alf Ator am .
private Nachricht | Beiträge des Benutzers
HansFred
myCSharp.de - Member



Dabei seit:
Beiträge: 49

beantworten | zitieren | melden

com ist tot und den austausch kann man per grpc machen
private Nachricht | Beiträge des Benutzers
1nf1n1ty
myCSharp.de - Member

Avatar #avatar-2711.jpg


Dabei seit:
Beiträge: 285

Themenstarter:

beantworten | zitieren | melden

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.

Moderationshinweis von Abt (02.12.2020 - 12:08:45):

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

private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15705
Herkunft: BW

beantworten | zitieren | melden

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.
Zitat
Für die Übergangsphase reicht das so erstmal.
Nichts hält sich länger als Übergangslösungen - siehe COM ;-)
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 10072

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers