@Abt
Hast wohl noch nicht das aktuelle Windows 10 Update
Hat sich bei mir schon am Wochenende eingeschlichen.
Jetzt gibt es "Neuigkeiten und interessante Themen" die unteranderem das Wetter in der Region anzeigen.
Kann man aber über Kontextmenü einfach abschalten.
Und zusätzlich sei auf System.Text.Json verwiesen, was Json.NET im grunde ersetzt.
Dies ist von der Usability recht identisch, kannst du also direkt verwenden.
Je nachdem was du von dem FileInfo brauchst, kannst du ggf. auch eine eigene Klasse anlegen und nur die nötigsten Informationen übernehmen.
Ebenfalls kannst du bei der Verwaltung der Einträge auch ein Dictionary nehmen.
Wenn du z.B. den Pfad oder nur den Dateinamen zur Suche brauchst, kannst du diesen als Key nehmen.
Über die Values kannst du dir dann auch immer eine Liste anlegen und befüllen.
Der Vorteil aus der Kombination ist neben dem einsparen der Handles auch das aussparen von unnötigen Daten was bei der Menge an Einträgen auch einiges an Speicher spart.
Ist das richtig, dass du fehlende Einträge aus Datensatz1 an Datensatz3 hängst, wenn diese in Datensatz2 nicht vorhanden sind?
Sieht auf den ersten Blick aus, wie falsch angehangen.
RestSharp ist nur die Client Seite.
Damit kannst du später an die eigentliche Rest API andocken.
Was du brauchst ist eine Web API.
Auch dazu gibt es eine gute Dokumentation bei Microsoft.
Du scheinst echt keine Ahnung von Datenbanken zu haben
Mit JS wirst du SQLite nicht (direkt) ansprechen können.
Bei SQLite handelt es sich um eine Embedded Datenbank, die man über eine API ansprechen muss.
Bei C# gibt es dafür entsprechende Bindings (Wrapper für die native C API).
Da wir auch nicht wissen von welchem Video du sprichst, kann man schlecht beurteilen was du da gesehen hast.
Bei JS würde ich entweder auf den Aufruf einer (web)API oder von einer lokalen Variable (assoziativ) ausgehen.
Dazu müsste man ber das Video kennen.
Du solltest den Link mal lesen und auch verstehen.
Die Web API läuft als Web Anwendung auf einem Webserver.
Deine lokale Anwendung kommuniziert nur mit der WebAPI und fragt dort die Daten ab.
Die Daten werden dabei ganz normal über http(s) Anfragen vom Client abgeschickt und die Antworten entsprechend zurück gesendet.
Wenn du dich mal mit einem einfachen Testprojekt dran machst, wirst du verstehen wie einfach das klappt.
Warum du Zugriff auf Registry willst, ist mir nicht ganz klar.
I.d.R. braucht man dies nur sehr selten bei einer Webanwendung.
Die WebAPI sollte auch nur zur Kommunikation zwischen Client und Datenbank dienen.
Mehr sollte diese hier erstmal nicht erfüllen, es sei den du hast noch Anforderungen die du über die Api abdecken willst.
Als Format zur Datenübertragung empfiehlt sich dann auch json, da es recht kompakt ist und dies von jedem gängigen Client ohne Probleme gelesen werden kann.
Die Umwandlung kannst du dann mit System.Text.Json machen, was auch ohne großen Aufwand programmiert werden kann.
Nachtrag:
Wenn du eine saubere Architektur hast, kannst du in deiner Anwendung eigentlich ohne großen Aufwand die Kommunikation im Client auf die WebAPI umstellen.
Wenn dies aber nicht der Fall sein sollte, dann schau die den Artikel dazu an.
Was du dort machen willst, kann nicht funktionieren ohne, dass man weitere Informationen mitgibt welche Eigenschaften ursprünglich initalisiert wurden.
Aber das Konzept selbst klingt zusehr nach magischen Code.
Kannst du den genaueren Zweck mal erklären?
Da du Daten aus deiner Personen Klasse nutzen willst, dann kannst du einfach prüfen ob diese gefüllt sind.
Bei String kannst du dies per String.IsNullOrEmpty prüfen.
Bei den anderen Datentypen wäre es dann nötig, diese zu Nullable umzuwandeln und einfach einen Null Check zu machen.
Nachtrag:
Wenn es dir nur um die Ausgabe geht, dann kannst du dies auch einfach lösen, in dem du eine Eigenschaft hast, dass deine Daten als String liefert.
Oder du legst dir eine Methode in deiner Klasse an, die einfach die gefüllten Felder in deinem Format ausgibt.
Wenn es nur dem Anzeige Namen im Task Manager dient, dann geht deine Umsetzung in die falsche Richtung.
Erstell doch die exe beim builden gleich mit dem richtigen Namen oder benenne diese vor dem Ausführen um.
Wenn die Anwendung bereits läuft, bringt ein umbenennen auch nichts mehr.
Mich würde aber interessieren, warum du den Ursprungsnamen per umbenennung verschleiern willst.
Klingt nicht gerade nach einem sinnvollen Einsatzzweck.
Wenn dir nur der richtige Ansatz fehlt, dann schau die mal die Klassen Directory, File und Path an.
Damit kannst du dann die Dateien einfach ermitteln.
Das drucken musst du dann vermutlich noch über einen entsprechenden Dialog anstoßen.
Sollte es in Winforms ohne großen Aufwand umsetzen lassen.
Ich hatte bis Ende 2018 auch noch mit Crystal Reports zu tun.
Wir haben diese damals in einem Web Projekt genutzt.
Eigentlich gibt es hier Installer mit der aktuellen Version, die dann auch die nötigen DLLs für dein Programm mitbringen würden.
Wenn es keine großen Breaking Changes gibt, dann muss man i.d.R. nicht die DLLs des Programms aktualisieren.
Wenn du aber ein Problem hast, solltest du es beschreiben und ggf. mal die DLLs im Programm updaten und schauen ob das Problem behoben ist.
Heute würde ich die Crystal Reports nicht mehr nutzen.
Wir haben diese durch die Telerik Reports ersetzt, da diese einfacher zu designen sind.
Vllt. wäre das auch was für dich.
Ist aufjeden Fall ein guter Ansatz.
Ich hoffe aber auch, dass wir da irgendwann mal raus kommen und es auch im Bereich der Programmierung in den Schulen gute Kurse gibt.
Wird aber vermutlich noch einige Jahre und vorallem bessere Bedingungen bei den Lehrkräften benötigen.
@Abt
Das der Code so verwurstet ist, ist für mich keine Überraschung.
Leider mangelt es unseren Lehrkräften sowohl an dem Know-How als auch an der Zeit, sich grundlegend mit den Sprachen zu befassen.
Dort werden stumpf Lehrpläne vorgegeben ohne dass die Lehrkräfte überhaupt selbst großartig die jeweilige Sprache kennen und verstehen was dort genau gemacht werden soll.
Teilweise unterrichten Leute C# die in ihrem Studium irgendwann mal mit Basic oder Java gearbeitet haben und dieses Wissen nun 1:1 auf C# übertragen.
Der Rest vom deutschen Bildungssektor sieht leider nicht besser aus.
Daher sollte man hier auch nachsichtig sein.
Wenn der TE Spaß an der Sache hat, kann er sich selbst mit der Sprache beschäftigen und es richtig lernen.
Der Vorschlag klingt insgesamt am sinnvollsten.
Dadurch könntet ihr per Interfaces den Aufbau vorgeben.
Spezifische Implementierungen mit Sonderwürsten wären dann auch gut verpackt.
Im Grund würdet ihr konzeptionel dann den gleichen Weg gehen wie die ADO .NET Treiber.
Dort gibt es auch gewissen Interfaces (DbConnection, DbCommand etc.) die eben grobe Vorgaben machen und nur die Basisfunktionalität vorschreibt.
Gegen diese müssen die Assemblies nur programmiert sein, dann könnt ihr einfach austauschbar machen je nachdem welche DB ihr verwendet.
Dürfte den Code um einiges übersichtlicher und sauberer gestalten.
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.
Der Ansatz mit dem Interface, war ja mein erster Gedanke auch wenn der Code das nicht ganz klar vorgibt.
Aber damit kann man das Problem lösen.
Jede abgeleitete Klasse müsste dann wieder eine eigene interne Implementierung umsetzen und dann diese Instanzieren und der jeweiligen Ableitung intern mitgeben.
Was du mit der innerClass vorhast, kann so nicht funktionieren.
Die Implementierung muss im aktuellen Stand in BaseClass erfolgen, was ja den Sinn deines Vorhabens schon im Grunde wegnimmt.
Wenn du aber eine Klassen Implementierung über BaseClass mitgeben willst, müsstest du eher eine Eigenschaft haben.
Dann brauchst du aber eher ein Interface, um eine Implementierung zu erzwingen.
Aber ohne zu wissen, was das Endergebnis sein soll, kann man vieles über unzählige Wege umsetzen.
public abstract class Base
{
// Eigenschaft für die Implementierung, die in der ergebenden Klasse zugewiesen werden muss
IInnerClass { get; set; }
// Interface für die Implementierung
public interface IInnerClass
{
// Hier Methoden/Eigenschaften einfügen, die Implementiert werden sollen!
}
}
public class Derived : Base
{
// Hier die Implementierung zuweisen
public IInnerClass { get; set; }
}
Die Frage wäre eher, was du damit erreichen willst.
Wenn du schon beim laden des Form einmal das Event feuern musst, klingt das eher nach einem Fehler im Prozess.
Es würde auch nichts dagegen sprechen, wenn du die Methoden im Code einfach selbst aufrufst und als Sender das jeweilige Control mitgibst.
Müsstest du am Ende auch mit dynamischen Code machen, da ist es einfacher die Event Methoden direkt mit entsprechenden Parametern aufzurufen.
Anbei:
Wenn der Code der Methoden identisch ist, kannst du auch eine CheckChanged Methode anlegen und diese allen Controls mitgeben.
Dadurch sparst du dir unnötige Events, die im Kern das gleiche machen.
Am besten nutzt die CefSharp oder ein aktuelles Browser Control.
Das Standard Control basiert auf dem IE11 und wird nicht mehr weiterentwickelt und supportet auch HTML5 nicht vollständig.
Rein zufällig haben wir letzte Woche was ähnliches umgesetzt.
Auch bei uns haben wir einen Reload der Seite eingebaut.
Dazu mache ich einfach ein window.location.href = window.location.href per JS.
Sollte auch ohne Probleme bei dir klappen.
Müsstest du vermutlich verzögert über window.setTimeout umsetzen.
Wie sieht den dein Code aus?
Anhand der aktuellen Meldungen klingt es eher nach irgend einem asynchronen Ablauf, bei dem du auf das Verzeichnis zugreifst bevor es angelegt wurd.
Da die System.IO Klassen im Kern nur Wrapper für die Win32 File Api sind, kann es nur einen Fehler geben beim Aufruf.
Ein Aufruf mit einem Ergebnis ohne den Ordner anzulegen würde eigentlich eine Exception werfen.
Deshalb kann der Code nur "krum" sein.
Ansonsten spielt auch das alter des Systems keine Rolle.
Mein Rechner ist von 2018 und liefert auch korrekte Werte.
@ClaraSoft
Ist mir klar, aber schau dir mal die Implementierungen von Contains und IsNullOrEmpty an.
Ein Contains ist aufwändiger in der Verwendung, da beim Contains auch noch die aktuelle Sprache beim Vergleich der Strings berücksichtigt werden muss.
Je nachdem wie häufig man Contains nutzt, umso mehr Laufzeit kostet der Einsatz.
Ein IsNullOrEmpty Check ist da umlängen effizienter, da die Prüfung keine zusätzlichen Resourcen benötigt.
Außerdem kann man damit auch klarer ausdrücken, dass man bei leeren Strings auch direkt raus kann.
Sonst muss jedes mal erst ein Contains durchlaufen, was bei längeren Strings auch etwas mehr Laufzeit benötigt.
Und je nach Anzahl der Programme sowie der Häufigkeit der Abfrage der Programme, kann dies auf lange Sicht unnötig Laufzeit kosten.
Wenn es hier also auch um Millisekunden geht, dann kann man hier auch einiges einsparen.
Es fühlte sich einfach falsch an, ohne typisiertes DataSet mittels T-SQL wahllos in der Datenbank rumzustochern.
Was genau meinst du damit?
Ohne DataSet lässt sich auch typisiert arbeiten.
Schau dir mal an wozu der DataReader da ist und welche Methoden er dir bietet.
Das Mapping von Daten aus der Datenbank auf Objekte ist in .NET über ADO .NET gang und gebe.
Was anderes macht Entity Framework intern auch nicht als über entsprechende Reader die Daten zu mappen.
Dazu solltest du dir ADO .NET nochmal anschauen um zu verstehen, wie man ohne DataTable/DataSet arbeiten kann.
HowTos und Tutorials gibt es dafür wie Sand am Meer.
Auch die .NET Doku zu dem Thema ist gut beschrieben.
Schau dir am besten die Entity Framework Doku an und verinnere dir erst mal was ein OR Mapper im Kern ist.
Mit .NET 5 und Entity Framework 5 hast du eine gute Basis und kannst die recht viele Grundlagen wie Verbindungsaufbau, Command anlegen und ausführen vereinfachen bzw. durch den Code First Ansatz einsparen.
Wieso willst du den einen weiteren Server für die Datenbank einrichten?
Die Datenbank ist im Endeffekt auch nur ein Programm, was auf einem Rechner läuft.
Dafür muss man bei kleinen Projekten keine dedizierte Hardware nur für die DB hinstellen.
Hier kannst du einfach einen zentralen Rechner nehmen, der dann die Datenbank und weitere Dienste stellt.
Aktuell hast du ja schon einen zentralen Fileserver.
Wenn dieser eine Kiste in eurem Zugriff ist und ihr dort Software installieren könnt, dann würde ich das auch direkt darauf machen.
In dem Fall könnt ihr auch eine freie Datenbank wie MariaDB oder PostgreSQL nehmen.
Diese kosten euch nichts und sind auch relativ leicht aufzusetzen.
Installer für Windows gibt es ebenfalls.
Aktuell klingt das Konzept wie eine Desktop Anwendung ala Winforms/WPF, die einfach auf eine Datei auf einer Freigabe zugreift.
Auch dort dürftet ihr bei gleichzeitgen Zugriffe schon Probleme bekommen und viel mit try/catch arbeiten.
Würde isch nur sinnvoll durch eine Datenbank oder einen vorgeschalteten Service lösen lassen.
Wie auch schon angesprochen wäre sonst nur ohne Datenbank Server eine embedded DB mit den gleichen Problemen wie reiner Dateizugriff über Freigabe möglich.
Dadurch würdet ihr das Problem aber nur von A nach B verschieben und nicht lösen.
Entweder eine Datenbank aufsetzen oder alternativ einen Service bauen, der die Zugriffe koordiniert und auch die nötigen Daten liefert/speichert.
Ich würde die Prüfung auf die Länge des MainWindowTitle vor dem Contains machen.
Ist die Länge 0, dann kann man sich das Contains sparen, was du aktuell aber immer machst!
So macht man erst ein Contains, was false liefert nur um dann erst zu merken, dass dort eh nichts drin steh.
Bzw. würde ich anstelle der Länge mit String.IsNullOrEmpty prüfen, damit es klarer ausgedrückt ist.
Den String "Programm -" solltest du nicht mitten im Code stehen haben.
Schieb diesen als Konstante (const string) in die Klasse ein.
Beim auslesen des Username macht du einfach ein Substring(0, 6).
Ohne zu wissen was in MainWindowTitle stehen sollte, könnte dort auch zufällig ein "Programm -" in einem fremden Programm stehen.
Ggf. solltest du den Part noch weiter abdichten, damit du keine falschen Einträge speicherst.
Der Fehler kommt, da du mit "(int)listFach.SelectedValue" eine Umwandlung des ausgewählten Wert zu int forcierst.
Da du den Wert aber nicht vorab auf null prüfst, knallt die Umwandlung.
Daher auch mein Rat von Gestern, doch erst zu prüfen ob die Werte stimmen und gültig sind.
Erst nach dem du die Eingaben validiert hast, solltest du die Abfrage gegen die Datenbank machen.
Dann wäre auch sichergestellt, dass du kein NULL oder ungültige Werte hast.
Was dscNRW damit sagen willst ist, dass du per debugger mal schauen sollst ob die Werte, die du dort erwartest auch drin stehen.
Dazu brauchst du Breakpoints, damit der Debugger an der Stelle anhält und du die Variablen bzw. in dem Fall die Eigenschaften der Controls prüfen kannst.
Um wieder zum Topic zurück zu kommen, du prüfst beim Read des DataReader nicht ob er false liefert.
In dem Fall würde dein aktueller Code beim Zugriff auf das Passwort Feld knallen, da es keine Einträge geben kann
Ebenfalls schließt du u.U. auch die verbindung nicht richtig, hier hatte Abt schon den Tipp mit using gegeben.
Dadurch würdest du deine Verbindungen während der Laufzeit der Anwendung ggf. aufbrauchen und kannst dann gar nicht mehr mit der DB kommunizieren.
Hier solltest du aber vor dem Abfragen gegen die DB prüfen ob die entsprechenden Felder/Parameter gefüllt und gültig sind.
Dann kannst du dir das aufbauen der Verbindung sparen und direkt eine Meldung ausgeben.
Die erste Abfrage erschließt sich mir nicht.
Warum hast du eine Tabelle mit dem Namen passwort und fragst nur die fachId ab?
Wäre eine Benutzer Tabelle nicht sinnvoller?
Hier kenne ich das Schema deiner Datenbank nicht, deshalb verwundert mich die Abfrage.
Passwörter werden nicht verchlüsselt sondern gehasht!
Schau dir dazu mal die best Practices an, damit du dies mit der möglichst gängigen Praxis machst.
Wenn ich dich richtig verstehe, willst du wissen welchen .NET Datentyp du für den jeweiligen Datenbank Spaltentypen nehmen musst.
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.
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?
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.