ich mache meine ersten Schritte mit .Net 6 und versuche einen Dienst mit Hilfe von BackgroundService zu erstellen. Die Grundlagen sind von Microsoft relativ gut beschrieben, aber eine Sache will mir nicht gelingen: Das Abrufen von Parametern im Worker Service.
In meinem Beispiel würde ich gerne die Parameter der Kommandozeile abrufen. Diese stehen auch im Worker in "Configuration" zur Verfügung, ich weiß aber nicht, wie ich den Wert programmtechnisch abrufen muss.
@Papst und @Abt
Nochmals Danke für die Unterstützung! Das Programm funktioniert nun und dieser Thread kann geschlossen bzw. als erledigt markiert werden.
Ich habe die Stelle in der Doku gefunden und sie mir angeschaut. Darauf hin habe ich den Code entsprechend geändert. Jetzt schaue ich mir die Beispiele an und versuche ich mich an die Authentifizierung.
ich habe zu 99,99% nichts mit Zugriff aufs Internet zu tun, daher fällt es mir etwas schwer, den richtigen Einstieg zu finden.
Ich muss den Inhalt einer Seite auslesen und im Abhängigkeit vom Ergebnis eine Seite aufrufen, die passwortgeschützt ist. Das Auslesen der Seite funktioniert ohne nennenswerte Probleme – dazu verwende ich HttpClient:
static string GetContent(string IP)
{
using (var client = new HttpClient())
{
var result = client.GetAsync(IP).Result.Content.ReadAsStringAsync().Result;
int start = result.IndexOf("<body>") + "<body>".Length;
int length = result.IndexOf("</body>") - start;
return result.Substring(start, length);
}
}
Nun möchte ich in Abhängigkeit des Ergebnisses folgenden Befehl absetzen:
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.
Lieben Dank euch beiden! Ja, so ist die Software auch aufgebaut. Das funktioniert auch gut. Mein Wunsch war/ist, wie mehrfach erläutert, eher etwas kosmetisches.
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!
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.
Abgesehen von Sinn oder Unsinn dieses Vorhabens, aber wenn die Umsetzung dieser Klassen in der selben Firma erfolgt, sollte doch eigentlich eine Teambesprechung ausreichen um die Programmierung einheitlich zu gestalten ;-)
Ja, ich schrieb bereits, dass dafür eine Arbeitsanweisung reichen würde. Es wäre aber ein Tick schöner, diese Vorgabe mit einer Art Vorlage programmtechnisch zu steuern.
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…
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!
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?
Du hast Recht, wenn die Klassen von externen Entwicklern abgeleitetr werden sollen. Der Autor der abgeleiteten Klassen sind jedoch wir :-) Z. B. behandeln MySQL und Guptas SQLBase die Eigenschaften von Datenbankfeldern zum Teil ziemlich unterschiedlich. Dennoch wollte ich erreichen, dass diese Behandglung in einer gleichnamigen Klasse stattfindet, um einfach Wartung, Weiterentwicklung und Dokumentation ein bisschen zu vereinheitlichen. Mehr verbirgt sich nicht dahinter und wir wollen keine Raketenwissenschaft daraus machen.
Nun, wenn das nicht vorgesehen ist, dann lassen wir es. Der Hintergrund war folgender:
Die Basisklasse bietet Methoden für den Zugriff auf unterschiedliche Datenbanksysteme – diese sind vom jeweiligen Datenbanksystem unabhängig. Zusätzlich definiert die Basisklasse abstrakte Methoden, die in den abgeleitetren Klassen implementiert werden. Diese abgeleiteten Klassen sind dagegen abhängig vom Datenbanksystem und bilden die Schnittstelle zwischen dem spezifischen Datenbanksystem und der höheren datenbankunabhängigen Abstraktionsebene. Bis hierhin also was ganz Normales.
Während der Entwicklung habe ich festgestellt, dass ich in den abgeleiteten Klassen für die datenbankspezifische Verwaltung weitere Klassen benötige. Die Implementierung dieser Klassen ist je nach Datenbanksystem sehr unterschiedlich – dennoch wollte ich der Übersichtlichkeit halber, die gesamte Funktionalität in gleichlautende Klasse kapseln. Also eher eine erzwungene Kosmetik für Wartung, Weiterentwicklung und Dokumentation.
Wenn das nicht geht, dann muss man es nicht übers Knie brechen. Es gibt dann eine Arbeitsanweisung, wie neue abgeleitete Klassen (neue Schnittstellen zu anderen Datenbanksystemen) auszusehen haben.
Bitte nicht steinigen wegen dieser Frage, aber ich komme selbst nicht drauf! Danke ;-)
Im unteren Code habe ich zwei abstrake Methoden in einer Basisklasse. Diese muss ich in abgeleiteten Klassen implementieren – bis hierhin alles klar. Wie kann ich aber erzwingen, dass eine von Base abgeleitete Klasse die innere Klasse "innerClass" implementiert?
public abstract class Base
{
public abstract void Func1();
public abstract void Func2();
public class innerClass { }
}
public class Derived : Base
{
public override void Func1()
{
return;
}
public override void Func2()
{
return;
}
}
Können wir das Thema als beendet erachten? Ich habe bereits dargelegt, dass ich die Infos aus dem Schema ermittle wie z. B. hier:
Zitat
Die Datentypen der Datenbankspalten erfahre ich über das Tabellenschema. An dieser Stelle wollte ich ansetzen. Wie aber beschrieben: Ich wollte mich vergewissern, dass es doch nicht anders (einfacher bzw. einheitlicher) geht.
Ich habe das hervorgehoben, damit das nicht nocheinmal untergeht.
Daraus fehlende Basics und sonstiges abzuleiten ist schon ein bisschen gewagt, insbesondere wenn gerade das vorgeworfen wird, was bereits erwähnt wurde und genutzt wird.
Nochmals vielen Dank an alle! Ich hatte gehofft, dass der Hersteller des jeweiligen Dataproviders diese Infos irgendwo liefert, um keinen Mapper selbst machen zu müssen. Eigentlich wäre das nicht so schwer, denn der Hersteller beschreibt, wie die Daten zu interpretieren sind. Diese Info hätte man auch in den Dataprovider packen können.
Ich mappe dann selbst und erachte das Thema als beantwortet bzw. gelöst.
Wenn ich dich richtig verstehe, willst du wissen welchen .NET Datentyp du für den jeweiligen Datenbank Spaltentypen nehmen musst.
Ja, genau so ist es.
Zitat von T-Virus
Dazu musst du schauen, wie der jeweilige ADO .NET Provider die Datentypen mappt.
Einen allgemeinen Ansatz kann man hier nur schwer umsetzen, wenn es über grundlegende Datentypen hinaus geht.
Das dachte ich mir. Aber bevor ich es selbst mache, wollte ich erst die Experten fragen.
Zitat von T-Virus
Nachtrag:
Das Mapping musst du so oder so über das Tabellen Schema machen.
Wenn du dies aber kennst, dann kannst du dies auch ohne Schema Abfrage machen.
Was genau ist den dein Ziel?
Die Datentypen der Datenbankspalten erfahre ich über das Tabellenschema. An dieser Stelle wollte ich ansetzen. Wie aber beschrieben: Ich wollte mich vergewissern, dass es doch nicht anders (einfacher bzw. einheitlicher) geht.
Zitat von T-Virus
Wenn du Daten auslesen musst, kannst du dies auch über einen OR Mapper machen.
Der kennt dann seine Datentypen, dann musst du es nicht selbst mappen.
T-Virus
Mein Ziel ist, C#-Zugriffsklassen aus den Datenbankstrukturen automatisch zu machen. Diese sollen für eine spezielle Anwendung erstellt werden. EF o. ä. ist in diesem Fall nicht erwünscht bzw. mit älteren Versionen von SQLBase erst gar nicht möglich.
Danke, aber ich habe bereits mehr als 10 Minuten damit verbracht und die Doku kenne ich. Ich schrieb:
Zitat
Welche sind die empfohlenen Vorgehensweisen (...)
In erster Linie möchte ich wissen, ob es standarizierte Methoden gibt, die ich dafür verwenden kann, den CLR-Datentyp abzufragen.
Sicher, ich kann das Schema ermitteln und die Datenbank-Datentypen der Felder abfragen, um anhand von Tabellen (z. B. die von dier verlinkte Seite) selbst ein Mapping zu machen. Vielleicht geht es aber einfacher – darauf zielt meine Frage ab.
Im Übrigen, ich verwende den SQL-Server nicht, sondern SQLBase und MySQL.
Ich war lange nicht mehr hier. Die neue Forensoftware sieht hübsch aus. Respekt! Aber nun zu meiner Frage:
Welche sind die empfohlenen Vorgehensweisen, um ein Mapping zwichen SQL- und .Net-Datentypen zu bewerkstelligen? Der Zugriff auf die Datenbanken soll mit dem .Net-Dataprovider erfolgen.
verwendetes Datenbanksystem: <SQLBase 11.x und 12.x, MySQL>
Ich muss eine Anwendung primär für die oben angegebenen Versionen von SQLBase entwickeln. Dadurch stehen mit Technologien wie z. B. EF nicht zur Verfügung, denn EF steht erst mit der Version 12.3 zum ersten Mal zur Verfügung, wir jedoch ältere Versionen unterstützen müssen.
Nun stehen uns ODBC, OLEDB, ADO und .NET Data Provider zur Verfügung. Dazu habe ich ein paar Fragen:
Bisher habe ich in Verbindung mit dieser Datenbank lediglich den .NET Data Provider benutzt. Das funktioniert auch gut. Aber weil eventuell auch MySQL und vielleicht auch der SQLServer irgendwann benutzt werden sollten, frage ich mich, ob im Hinblick auf den Sourcecode nicht besser wäre, auf OLEDB oder ODBC zu setzen – wenn ich das richtig sehe, müsste ich im Idealfall lediglich die Verbindungszeichenkette ersetzen und ich könnte meine Anwendung mit einem anderen Datenbanksystem ausführen.
Beim .NET Data Provider ist zwar die Funktionalität mehr oder weniger normiert, die Methoden der einzelnen Datenbanksystemen heißen jedoch anders wie unten im Beispiel:
SQLBaseConnection con = new SQLBaseConnection();
MySqlConnection con = new MySqlConnection();
Das würde bedeuten, entweder bedingte Kompilierung, Source doppeln oder einen selbst entwickelten Wrapper nutzen (ich würde das wahrscheinlich so realisieren).
Wie sehen die Experten das? Vielleicht drehe ich mich wieder nur im Kreis und sehe den Wald vor lauter Bäumen nicht.