.NET (Core) von .NET Framework 4.8 aus nutzen möglich?

Mir fiel keine bessere Überschrift ein, sorry. Daher versuche ich zunächst den Hintergrund zu erklären.

Für die etwas Älteren unter uns dürfte der Begriff „Gupta“ bzw. SQLWindows oder Team Developer u. U. bekannt sein. Dabei handelt es sich um eine Entwicklungsumgebung, die auf Ende der 80er/Anfang der 90er Jahre zurückreicht. Diese Entwicklungsumgebung war damals das Nonplusultra für die Entwicklung von Datenbankanwendungen unter dem damals noch jungen Windows 3/3.1. Entsprechend teuer war das auch, aber man konnte schon damals damit sehr schnell Sachen entwickeln, für die mit anderen Mitteln sehr lange gebraucht hätte.

Das Produkt gibt es heute noch. In den letzten zwei Jahrzehnte hat es leider den Besitzer mehrmals gewechselt (Gupta, Centura, wieder Gupta, dann Unify und heute OpenText), was es ihm nicht wirklich gutgetan hat: Die Entwicklung neuer bzw. besserer Funktionalität schritt nur langsam voran und so wurde es von anderen Systemen überholt.

Darüber hinaus führte die Hochpreispolitik dazu, dass es sich immer weniger Entwickler mit diesem System auseinandersetzen. Schließlich wurde sogar der Zugang zur Informationsressourcen nach dem Aufkauf durch OpenText geschlossen und nur für Kunden mit einem gültigen Wartungsvertrag ermöglicht – ein Unding, wie wir meine.

Aus diesem Grund beschlossen wir, dem ein Ende zu setzen und kündigten alle Wartungsverträge, da die Produktentwicklung den hohen Preis nicht rechtfertigt. So blieben wir auf der Version 6.2 stehen.

Diese Version kann sowohl C++-DLLs als auch mit dem .NET-Framework erstellte C#-DLLs verarbeiten, was wir auch nutzen. Nun aber wird das .NET-Framework nicht weiterentwickelt und so können wir maximal die C#-Version 7.3 nutzen. Alle Schönheiten von 8 und 9 bleiben uns verwehrt.

Nun komme ich endlich zu meiner Frage:

Welche Möglichkeiten/Ansätze gäbe es, über entweder C++ oder viel besser C# (Version 7.3/.NET-Framework) in .NET (zurzeit Version 5) erstellten DLLs zu nutzen? Geht das überhaupt?

Sorry für den langen einleitenden Text!

Schönen Dank im Voraus und liebe Grüße!

Hallo pollito,

du kannst eine .NET 5 (oder .NET Core) Assembly in einem C++/cli Projekt verwenden.
Dafür musst du ggf. die Projektdatei entsprechend anpassen (geht auch über die Projekteingenschaften).

Einen Ausschnitt aus einem Projekt, dass .NET 5 verwendet:

  <ItemGroup Label="ProjectConfigurations">
    <FrameworkReference Include="Microsoft.WindowsDesktop.App" />
	...
  </ItemGroup>
  <PropertyGroup Label="Globals">
	...
    <TargetFramework>net5.0</TargetFramework>
    <CLRSupport>NetCore</CLRSupport>
    <Keyword>ManagedCProj</Keyword>
	...
  </PropertyGroup>

Portieren eines C++/CLI-Projekts zu .NET Core

Ich denke nicht, dass du eine .NET 5 Assembly aus einer beliebigen .NET Framework Version referenzieren oder verwenden kannst.

Grüße spooky

Hallo Spooky,

danke für deine Antwort! Wie eingangs dargestellt, kann ich in der Gupta nur .NET-Framework-DLLs oder C-DLLs verwenden. Bei letzterem gehe ich davon aus, dass auch C-/CLI-DLLs nutzbar sind (prüfe ich noch).

Wie ich das beim ersten Überfliegen sehe, muss das C++/CLI-Projekt aber als Ziel .NET 5 haben. Habe ich das richtig verstanden? Wenn es so ist, dann vermute ich, dass ich eine dafür erstellte C++/CLI-DLL nicht in ein Gupta-Projekt einbinden kann. Wenn ich richtig informiert bin, kann ich bei der Gupta nur C++/CLI-DLLs einbinden, die für das .NET-Framework erstellt wurden. Wie geschrieben, das überprüfe ich aber noch mit einem Testprogramm. Leider kann ich ohne Wartungsvertrag niemanden danach fragen, so dass immer probieren statt studieren angesagt ist...

Ich muss eine Brücke zwischen .NET-Framework und .NET schaffen, sofern das überhaupt möglich.

Nochmals vielen Dank und liebe Grüße aus dem verregneten Südwesten!

Ich muss eine Brücke zwischen .NET-Framework und .NET schaffen, sofern das überhaupt möglich.

Ist es nicht.

Wenn Ihr den Wartungsvertrag kündigt - warum dann daran fest halten?
Warum nicht auf Visual Studio oder Visual Studio Code oder Andere setzen?

Mir ist nicht ganz klar, wo Du nun was nutzen möchtest, aber als mögliche Brücke gäbe es noch .NET Standard.
Das sollte man zwar auch nicht mehr nutzen, aber es funktioniert ganz hervorragend als gemeinsame Code-Basis für .NET Framework 4.x oder .NET 5 Projekte.

Aber so oder so kannst Du Projekte, die dieses Gupta nicht unterstützt, nicht einfach so einbinden - kompilieren und dann als normale Referenz verwenden sollte aber gehen.

Wenn Ihr den Wartungsvertrag kündigt - warum dann daran fest halten?
Warum nicht auf Visual Studio oder Visual Studio Code oder Andere setzen?

Unser Hauptprodukt, welches in der Hauptsache mit Gupta entwickelt wurde, hat über 25 Jahre auf dem Buckel, so dass man nicht von heute auf morgen einen Schalter umlegen kann. Wir sind jedoch dabei und haben einige Teile bereits auf C# portiert. Nun sind wir so weit, dass wir uns an die großen Brocken wagen. Allerdings dürfen wir unsere Kunden, die weiterhin das System nutzen, nicht vergessen – für Sie müssen wir parallel weiterhin das System pflegen und zum Teil weiterentwickeln.

Dass dieses Vorhaben nicht einfach ist, zeigt u. a. das Beispiel an Lidl: Ein Großteil deren Software ist mit Gupta entwickelt worden. Vor ein paar Jahren läutete Lidl den Wechsel auf SAP ein. Nach langer Zeit und Schweiß musste das Projekt begraben werden, da es auch SAP nicht schaffte, die notwendigen Arbeitsprozesse nachzubilden – Lidl kehrte zur Gupta zurück. Also auch mit einem großen Budget ist so ein Vorhaben nicht ganz einfach.

Wir müssen nicht nur ein Systemwechsel vollziehen, sondern das Zielsystem erst entwickeln. Dabei müssen wir das alte System am Leben erhalten und teilweise weiter an die Bedürfnisse der Kunden anpassen bzw. erweitern.

Mir ist nicht ganz klar, wo Du nun was nutzen möchtest, aber als mögliche Brücke gäbe es noch .NET Standard.
Das sollte man zwar auch nicht mehr nutzen, aber es funktioniert ganz hervorragend als gemeinsame Code-Basis für .NET Framework 4.x oder .NET 5 Projekte.

Aber so oder so kannst Du Projekte, die dieses Gupta nicht unterstützt, nicht einfach so einbinden - kompilieren und dann als normale Referenz verwenden sollte aber gehen.

Wie beschrieben, müssen wir für unsere Kunden das Produkt laufend weiterentwickeln. Wir versuchen, diese Erweiterungen in C# zu realisieren. Das geht einerseits über die Gupta selbst, die in der Lage ist, .NET-DLLs zu benutzen. Allerdings ist die Unterstützung etwas eigenwillig und ein wenig sperrig, aber es geht. Anderseits kann Gupta seit je und eh C-DLLs einbinden, was auch mit C/CLI funktioniert – hierüber hat man auch eine Brücke zur .NET-Welt, indem man C++/CLI als Schnittstelle zu C# nutzt. Alles schön und gut, aber wir sind damit im NET-Framework gefangen – .NET-Projekte (früher .NET Core) lassen sich nicht einbinden und damit können wir maximal für das .NET-Framework 4.8 (C# Version 7.3) entwickeln. Blöd…

Ich meine nicht, dass Ihr von jetzt auf gleich auf C# umsteigt, sondern dass Ihr "nur" die IDE wechselt.
Da wäre natürlich spannend, was Gupta-spezifisch ist und nicht übernommen werden kann, doch bei C++ oder C# sollte Visual Studio (Code) durchaus realistisch sein.
Über einen Wechsel der Programmiersprache kann man danach ja immer noch nachdenken, wenn der eine Klotz erst mal weg ist.

Allerdings dürfen wir unsere Kunden, die weiterhin das System nutzen, nicht vergessen – für Sie müssen wir parallel weiterhin das System pflegen und zum Teil weiterentwickeln.

Das wäre ich strikt trennen. Wartung und kritische Bugfixes ok, aber wenn neue Features rein sollen, baut ihr euch nur riesige Probleme.
Wie Abt schon schrieb, ist eine Misch-Variante nicht möglich, es bleibt also nur die Möglichkeit, jede Änderung in beide Versionen (mit und ohne Gupta) zu pflegen, aber spätestens wenn Ihr auch noch strukturell umbaut, wird das zur Hölle.

Ich würde es schrittweise machen:

Erst Gupta absägen und möglichst wenig am Code selber ändern.
Danach zieht Ihr alles was geht auf .NET 4.8 oder wenigstens 4.6.1 hoch, so "gefangen" seid Ihr damit gar nicht, das unterstützt nämlich ab .NET Standard 2.0.
Steht diese Grundlage, könnt Ihr mit .NET Standard 2.0 weiter arbeiten, die meisten aktuellen Frameworks unterstützen das und es kann ab .NET 4.6.1 oder Core 2.0 verwendet werden.
Steht erst mal diese Grundlage, könnt Ihr Stück für Stück alles .NET 4.x auf .NET Standard 2.0 portieren und habt so eine gute Grundlage, die auch in .NET 5 verwendet werden kann.
Ist alles .NET Standard 2.0 (geht ja nur bei DLLs) zieht Ihr die Start-Projekte auf .NET 5 hoch. Der Umstieg der .NET Standard 2.0 DLLs auf .NET 5 ist nicht zwingend notwendig, aber in vielen Fällen auch einfach nur eine Property in der csproj.

Zwischen den Schritten ist dann Zeit für neue Features, aber mitten im Umbau würde ich die Weiterentwicklung pausieren.

Lidl kehrte zur Gupta zurück. Also auch mit einem großen Budget ist so ein Vorhaben nicht ganz einfach.

Eine ähnliche Geschichte erzählt man mir auch immer wieder, nur dass es da um die Neuentwicklung einer ganzen Software geht und zig Millionen rein gesteckt wurden.
Für mich klingt das so, als wäre ein großes Budget nicht nur kein Hinweis, dass es gelingt, sondern eher ein Problem, da man sich von dem Projekt erhofft, dass man alles auf einen schlag schafft - Geld ist ja da.
Spoiler: Das geht schief. Nicht alles auf einmal versuchen, lieber in einzelnen Schritten planen, das dauert dann vielleicht etwas länger, aber die Chance, dass es funktioniert, ist größer.

Das wäre ich strikt trennen. Wartung und kritische Bugfixes ok, aber wenn neue Features rein sollen, baut ihr euch nur riesige Probleme.
Wie Abt schon schrieb, ist eine Misch-Variante nicht möglich, es bleibt also nur die Möglichkeit, jede Änderung in beide Versionen (mit und ohne Gupta) zu pflegen, aber spätestens wenn Ihr auch noch strukturell umbaut, wird das zur Hölle.

Richtig. Allerdings liegt das Problem darin, dass wir zusammen mit dem Kunden in die Tiefe und nicht in die Breite gehen. In anderen Worten: Wir haben – nicht ganz gewollt bzw. geplant 🙂 – ein großes System entwickelt, mit dem wir in der Lage sind, auf Kundenwünsche bis ins Detail einzugehen. Dadurch haben wir eine überschaubare Kundenbasis, die eine Art Symbiose darstellt. Wären wir in die Breite gegangen, könnten wir mit den vorhandenen Entwicklungsressourcen nicht so in die Tiefe gehen, ohne die Kosten explodieren zu lassen. Deswegen müssen wir weiterhin in der Lage bleiben, jeden Kundenwunsch in akzeptabler Zeit und zu einigermaßen überschaubaren Kosten umsetzen zu können.

Gupta bestand bzw. besteht heute noch in erster Linie aus zwei Schichten: dem SQL-Datenbankserver SQLBase und dem fetten Client mit der Geschäftslogik. Das ist heute in nicht mehr zeitgemäß und ich denke, hier sollten wir ansetzen: Neue Funktionalität packen wir in eine weitere Serverschicht (ASP.NET), wodurch wir das moderne .NET problemlos nutzen können. Wir müssen nun auf der Client-Seite Gupta dazu bringen, damit zu arbeiten, womit wir die gewünschte Brücke bauen könnten. Hier spielt keine große Rolle, dass man dies mit dem .NET-Framework macht.

Alles was Du erzählst mag alles korrekt sein, aber halt auch nicht außergewöhnlich.

Wären wir in die Breite gegangen, könnten wir mit den vorhandenen Entwicklungsressourcen nicht so in die Tiefe gehen, ohne die Kosten explodieren zu lassen. Deswegen müssen wir weiterhin in der Lage bleiben, jeden Kundenwunsch in akzeptabler Zeit und zu einigermaßen überschaubaren Kosten umsetzen zu können.

Das ist so mit die typischste Aussage, die man in deutschen Unternehmen so von sich geben kann.
In Software kann man nicht nur Zeit und Geld stecken, sondern durch schlaue, nachhaltige Planung auch immense Kosten sparen und dabei flexibel bleiben.

Die Vergangenheit zeigt, dass i.d.R. die kurzsichtige Kostenersparnis in eine langfristige Kostensteigerung übergeht.

Man kann auch ganz ehrlich sagen: ihr habts verpennt und nun versucht ihr es wieder auf die Bahn zu bekommen 🙂
Ist ja nichts schlimmes dran.

Dass dieses Vorhaben nicht einfach ist, zeigt u. a. das Beispiel an Lidl: Ein Großteil deren Software ist mit Gupta entwickelt worden. Vor ein paar Jahren läutete Lidl den Wechsel auf SAP ein. Nach langer Zeit und Schweiß musste das Projekt begraben werden, da es auch SAP nicht schaffte, die notwendigen Arbeitsprozesse nachzubilden – Lidl kehrte zur Gupta zurück. Also auch mit einem großen Budget ist so ein Vorhaben nicht ganz einfach.

Das ist leider totaler Quark. Lidl bzw. die Schwarz-Gruppe ist bei mir um die Ecke und ich hab nen paar direkte Kontakte in die Schwarz Gruppe.
Wie so oft ist auch im Falle Schwarz Gruppe das SAP Projekt nicht an der Technologie, sondern an der Organisation gescheitert.
Das hat mit Budget genau 0,0 zutun.

Dass größere Projekte in größeren Unternehmen öfter schief gehen als in kleinen Unternehmen, das liegt auch an der Controlling Kette.
Eine Flachpiepe kann (sogar ganz alleine) in einem großen Unternehmen viel mehr Schaden anrichten, als in einem kleinen Unternehmen.

Typische deutsche Tugenden sind die Kristallkugeln so mancher Guru. Ich bin keiner und daher habe ich auch keine Kristallkugel. Allerdings ist ein Kommilitone aus meinem Ingenieurstudium in einer sehr hohen SAP-Etage beschäftigt. Da höre ich was anderes aus erster Quelle. Also könnte ich von deiner Aussage ebenfalls behaupten, die wäre ein schizophrenischer Quark.

Mich wundern ein wenig einige Umgangsformen, die vollkommen unnötig, etwas an sozialer Kompetenz und Empathie vermissen lassen. Wenn ich was zu sagen habe, versuche es mit einer klaren und vor allem freundlichen Sprache. Wenn ich nichts zu sagen habe, dann halte ich einfach meine Klappe.

Danke für deine Beiträge und ein schönes Wochenende!

Du hast Aussagen getätigt, die den Fakten nicht entsprechen.

Nach langer Zeit und Schweiß musste das Projekt begraben werden, da es auch SAP nicht schaffte, die notwendigen Arbeitsprozesse nachzubilden

Da Du ja ebenfalls "Insider-Informationen" hast, weißt Du ja sicherlich, dass hier nicht unbedingt nur die SAP selbst an Bord war, sondern auch entsprechende Beratungsunternehmen - und davon nicht nur eins und nicht zu wenig.
Und der damaligen Mitteilung kannst Du ja entnehmen, dass

"die ursprünglich definierten strategischen Ziele nicht mit vertretbaren Aufwand"

was also bedeutet, dass es sehr wohl möglich ist, aber der Kosten-Nutzen Faktor nicht mehr passt, sodass das Ziel nicht mehr verfolgt wird.
Hat also mit "nicht schaffte" wenig zutun.

Ebenso

"keine Entscheidung gegen SAP, sondern für ein eigenes System" gewesen sei. "Lidl wird auch weiterhin mit SAP in anderen Bereichen eng zusammenarbeiten."

Und Lidl hat eben einen Prozess, der nicht ganz zum SAP Retail Paket passt.

Auch der laufende Betrieb müsste also der Software angepasst werden, flexible Weiterentwicklungen sind nur schwer umsetzbar. Bei Lidl sorgten die gewünschten Anpassungen für extrem hohe Berater- und Systemintegrationskosten.

Andere Unternehmen, teilweise die größten Unternehmen der Welt (zB Nestle, Edeka, Metro..) laufen wunderbar auf der gleichen Technologie, die eben bei Lidl gescheitert ist.
Liegt also offenkundig nicht an der Technologie, wobei durchaus bekannt ist, dass SAP nicht unbedingt die Mega-Customizable Softwareplattform ist - das dürfte den Lidl Leuten bei Projektstart, der immerhin 7 Jahre her ist, nicht unbekannt sein.
Lidl geht da bei einigen Aussagen durchaus selbstkritisch um, und gibt Fehler zu - was für Deutsche / deutsche Unternehmen sehr ungewöhnlich ist.

Entspricht also meiner Aussage

Wie so oft ist auch im Falle Schwarz Gruppe das SAP Projekt nicht an der Technologie, sondern an der Organisation gescheitert.

und entkräftet Deine Aussage doch schon sehr.

Soweit ich es mitbekommen hatte, lag das scheitern bei Lidl an den zu verkursteten Strukturen, die man einfach nicht in SAP abbilden konnte.
Dort gab es teilweise auch spezielle Lösungen bei einigen Filialen, die wohl nicht nach SAP portiert werden konnten.
Es liegt also nicht direkt an SAP, dies lässt sich auch anpassen und erweitern.

Wir haben seit Ende 2019 auch einen Kunden, für den wir einen Konnektor zum Transfer von Auftragsdaten zwischen dem SAP System des Kunden und unserer Software Lösung entwicklen.
Zwar gibt es hin und wieder einige teilweise nicht vorgesehene Probleme, im groben lassen sich diese aber mit dem Kunden lösen.

Bei eurer Lösung wird dies aber eben nicht ohne Aufwand auf eurer Seite machbar sein.
Solange die Abhängigkeit von Gupta da ist, werdet ihr das Kernproblem nicht lösen können.
Es ist einfach technisch bedingt nicht lösbar.

Ohne die Trennung von Gupta, was ich leider nicht mal kenne, kommt der Sprung vom Framework zu dem neuen .NET 5+ einfach nicht in Frage.
Es wäre mit .NET Standard möglich eine Grundlage für einen späteren Sprung hin zu späteren .NET Versionen umzusetzen bzw. dadurch vorzubereiten.
Aber .NET Core und .NET 5 ist aktuell erstmal ausgeschlossen.
Wenn ihr nicht zwei Stände pflegen wollt, einmal für .NET Framework und eimal für aktuelle .NET Version, dann habt ihr keine große Wahl als auf .NET Standard zu setzen.

T-Virus

Wenn ihr nicht zwei Stände pflegen wollt, einmal für .NET Framework und eimal für aktuelle .NET Version, dann habt ihr keine große Wahl als auf .NET Standard zu setzen.

Meine Worte 🙂
Das setzt aber auch voraus, dass man ein Feature-Stop durchsetzt - zumindest solange die einzelnen Umbauten durch sind.
Steht der Zwischenstand, kann man wieder ein paar Features einbauen und macht danach mit dem Umbau weiter.

Abgesehen davon lassen auch die Kunden sich von so einem Feature-Stop überreden, man braucht aber jemanden, der das gut rüber bringen kann.
Ein Firma, bei der ich mal gearbeitet habe, hat genau das gemacht - fünf Jahre lang. In der Zeit haben sie die Software größtenteils neu entwickelt und an der alten Software nur Bugfixes umgesetzt.
Die Kunden waren natürlich nicht glücklich, doch auch die verstehen irgendwann, dass eine zig Jahre andauernde OP am offenen Herzen irgendwann mal pausiert werden muss.

Das setzt aber auch voraus, dass man ein Feature-Stop durchsetzt - zumindest solange die einzelnen Umbauten durch sind.

.. das setzt noch viel mehr, zB. dass man zuhört, dass man Ideen/Vorschläge der anderen annimmt und nicht nur versucht eigene Ideen irgendwie durchzuboxen/"es besser zu wissen" - egal ob sinnvoll, verwirklichbar; oder nicht 😉
Von anderen zu lernen und sich weiter zu entwickeln, ist eben auch eine gewisse Kunst.

Das setzt aber auch voraus, dass man ein Feature-Stop durchsetzt - zumindest solange die einzelnen Umbauten durch sind.
Steht der Zwischenstand, kann man wieder ein paar Features einbauen und macht danach mit dem Umbau weiter.

Wie oft im Leben, liegt die Wahrheit irgendwo zwischen drin... Einiges ist schon ausgelagert und Neues versuchen wir in .NET zu implementieren. Durch unser Geschäftsmodell müssen wir jedoch ständig in der Lage sein, sehr schnell auf gewisse Kundenanforderungen zu reagieren – das zeichnet uns aus und davon leben wir. Das mag in anderen Bereichen vollkommen anders sein, nicht jedoch bei uns.

Ich denke auch, wir haben die Lösung, indem wir von den heutigen zwei Schichten auf drei gehen (hatte ich kurz erwähnt in einem früheren Beitrag). Dann sind wir nicht mehr am alten Framework gefesselt.

Schönen Dank!

Und bezüglich Zwischen-Schicht:

Ich habe mal in einer Firma gearbeitet, die einen ähnlichen Plan verfolgt hat.
Ein sehr altes und sehr großes C-Projekt, nicht mehr wirklich wartbar, aber man muss ja schnell und handlungsfähig bleiben.
Der Plan war also, das Neuerungen in C# umgesetzt werden, das C-Projekt nutzt dann die Exe, gibt Daten rein, bekommt Daten raus, etc.
Der Plan war (vermutlich) mehr und mehr den C-Code zu verschlanken und Stück für Stück auf eine modulare C#-Basis hinzuarbeiten und auch von neuen Technologien profitieren zu können.
Das Ergebnis nach über 10 Jahren war, dass das C-Programm viel von seinem Chaos (z.B. irre Datei-Formate) auf die C#-Projekte übertragen hat und die meisten der C#-Projekte jetzt an einem ähnlichen Punkt stehen, wie das C++-Programm.

Ich will damit auf den ewigen Grundsatz hinaus: Provisorien halten am längsten.
(Und ja, ich weiß, dass das wirklich nicht vergleichbar ist)

Wie auch immer...
Wenn für euch nur diese Herangehensweise in Frage kommt, dann macht das so.
Achte aber darauf, dass sich das nicht im Sand verläuft und Ihr nicht in der gleichen Falle landet, wie mein Beispiel.