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

  • »
  • Community
  • |
  • Diskussionsforum
.NET (Core) von .NET Framework 4.8 aus nutzen möglich?
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 222

Themenstarter:

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

beantworten | zitieren | melden

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!
René
private Nachricht | Beiträge des Benutzers
Spook
myCSharp.de - Member



Dabei seit:
Beiträge: 244
Herkunft: Esslingen a.N.

beantworten | zitieren | melden

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

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 222

Themenstarter:

beantworten | zitieren | melden

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!
René
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.752

beantworten | zitieren | melden

Zitat von pollito
Ich muss eine Brücke zwischen .NET-Framework und .NET schaffen, sofern das überhaupt möglich.
Ist es nicht.

private Nachricht | Beiträge des Benutzers
Palladin007
myCSharp.de - Member

Avatar #avatar-4140.png


Dabei seit:
Beiträge: 1.758
Herkunft: Düsseldorf

beantworten | zitieren | melden

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

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 222

Themenstarter:

beantworten | zitieren | melden

Zitat von Palladin007
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.
Zitat von Palladin007
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…
René
private Nachricht | Beiträge des Benutzers
Palladin007
myCSharp.de - Member

Avatar #avatar-4140.png


Dabei seit:
Beiträge: 1.758
Herkunft: Düsseldorf

beantworten | zitieren | melden

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

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 222

Themenstarter:

beantworten | zitieren | melden

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

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.752

beantworten | zitieren | melden

Alles was Du erzählst mag alles korrekt sein, aber halt auch nicht außergewöhnlich.
Zitat
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.
Zitat
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.
private Nachricht | Beiträge des Benutzers
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 222

Themenstarter:

beantworten | zitieren | melden

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!

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von pollito am .
René
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.752

beantworten | zitieren | melden

Du hast Aussagen getätigt, die den Fakten nicht entsprechen.
Zitat von pollito
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
Zitat von https://www.stimme.de/heilbronn/wirtschaft/aktuell/Lidl-beendet-Warenwirtschaftsprojekt;art140955
"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
Zitat von https://www.stimme.de/heilbronn/wirtschaft/aktuell/Lidl-beendet-Warenwirtschaftsprojekt;art140955
"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.
Zitat von https://agiles.com/de/warenwirtschaftsprojekte
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
Zitat von Abt
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.
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



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

beantworten | zitieren | melden

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
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
Palladin007
myCSharp.de - Member

Avatar #avatar-4140.png


Dabei seit:
Beiträge: 1.758
Herkunft: Düsseldorf

beantworten | zitieren | melden

Zitat
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.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.752

beantworten | zitieren | melden

Zitat von Palladin007
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.
private Nachricht | Beiträge des Benutzers
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 222

Themenstarter:

beantworten | zitieren | melden

Zitat von Palladin007
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!


René
private Nachricht | Beiträge des Benutzers
Palladin007
myCSharp.de - Member

Avatar #avatar-4140.png


Dabei seit:
Beiträge: 1.758
Herkunft: Düsseldorf

beantworten | zitieren | melden

Zitat
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 habe ich fast so oft gehört, wie die Anzahl Firmen, bei denen ich bisher gearbeitet habe
Sie alle hatten Chaos und auf die Frage, warum sie dieses Chaos nicht aufräumen konnten, kam dann die immer-gleiche Aussage (oder Ausrede), dass man schnell und handlungsfähig bleiben muss.

Das geht aber nur so lange gut, bis eben dieses Chaos besagte Handlungsfähigkeit so sehr einschränkt, dass es geschäftsschädigend wird und wenn entscheidende Personen erst dann mit sich reden lassen, ist es oft schon zu spät.
Wenn Du die Zeit und Muße hast, kannst Du ja mal eine Zeit- und Kostenplanung erstellen. Oft ist einem Chef ohne entsprechendes Wissen gar nicht bewusst, welche Probleme manche Entscheidungen entstehen lassen, so eine Zeit- und Kostenplanung kann da aber helfen.


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

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.752

beantworten | zitieren | melden

Zitat von Palladin007
Das habe ich fast so oft gehört, wie die Anzahl Firmen, bei denen ich bisher gearbeitet habe
Sie alle hatten Chaos und auf die Frage, warum sie dieses Chaos nicht aufräumen konnten, kam dann die immer-gleiche Aussage (oder Ausrede), dass man schnell und handlungsfähig bleiben muss.
Dem kann ich nur zustimmen und ist für mich i.d.R. ein deutliches Zeichen für "Tellerrand" aka "Bubble".
Aber das ist irgendwie auch natürlich (und nicht falsch verstehen, auch nicht ungewöhnlich, aber nachvollziehbar!) wenn man intern immer im gleichen Ökosystem unterwegs ist und das externe Auge fehlt; woher solls auch kommen?

Ich war schon bei soo vielen Kunden, sicherlich dreistellig in der Zahl, die alle von sich behauptet haben, dass sie ach so speziell seien..
Als Berater, Trainer oder Whatever sieht man aber so viel, dass man meist sagen kann: "eingefahren" wäre die bessere Begrifflichkeit als "speziell".
Das hören aber die Parteien natürlich nicht gern, weswegen man als Externer dann oft höflich statt ehrlich ist / sein muss. Ich versuche meist letzteres in Kombination mit ersterem zu sein, was durchaus die Gefahr birgt, dass man bei Kunden raus fliegt...
Viele Kunden wollen auch kein ehrliches Feedback, sondern wollen gar nicht so selten einfach nur ne externe Bestätigung, um sich intern zu bestötigen / bestätigen lassen, warum auch immer...hilft vielleicht dann dem einzelnen Kopf, aber nich der Firma und nich dem Projekt.
Aber so ist das halt.

private Nachricht | Beiträge des Benutzers