@loeffel

Ich denke mal für meine kleinen Projekte und meinen bescheidenem skill ist das überdimensioniert.

Aber ich möchte mich jetzt mal mit "SQL-Server Compact" beschäftigen. Ich glaube nach erstem lesen, wäre das eine alternative für Access 2003 DBs oder für SQLight DBs

Amelie schrieb:

ist das überdimensioniert

Quatsch. Einfach mal ausprobieren. Da gehört nicht so viel dazu und man muss längst nicht alles nutzen, was EF Core kann. EF ist es übrigens, vereinfacht gesagt, egal, welche Datenquelle vorliegt. Ob nun eine Access-DB, SQLight, MySQL oder SQL Server.

Amelie schrieb:

mal mit "SQL-Server Compact" beschäftigen

Was? Warum? Das ist nicht mehr weiterentwickelte Software und längst aus dem Supportzyklus raus. Die korrekte Version wäre SQL Server Express.

loeffel schrieb:

Was hindert euch daran, modernere Versionen oder Libraries zu verwenden

Gute Frage. Ich benutzte nur noch .NET8 und denke schon gar nicht mehr daran, überhaupt Framework zu verwenden. Das ist schon voll raus aus meinem Kopf. Aber das ist eine gute Frage.
Für das Design benutzte ich dann einfach WPF mit WPFUI. Sieht geil aus und ist auch nicht schwer zu verwenden. Für die ganzen kleineren Projekte mach ich auch nicht MVVM, das ist für "richtige" Projekte.

loeffel schrieb:

Was hindert euch daran, modernere Versionen oder Libraries zu verwenden, also hier in diesem Fall beispielsweise EntityFramework, EFCore und .NET?

Mit EF habe ich mich bisher zu wenig beschäftigt.
Ein DataSet ist ja erstmal losgelöst von jeder Datenbank und diese Trennung ist für mich sehr praktisch. Das heißt ich kann auch ganz ohne Datenbank damit arbeiten. Aber vielleicht geht das bei EF ja auch.
Mir hängt EF aber irgendwie zu stark an der Datenbank, ich habe das Gefühl es gehört eher zur DB als zu meinem Projekt.
.NET benutze ich und ich versuche bei jeder Gelegenheit Programme von Framework nach .NET zu überführen und das klappt auch ganz gut.

Meine Planungsschritte sind

• NET Framework -> .NET
  
• WinForms Classic -> WinForms MVVM
  
• WinForms MVVM -> WPF (evtl.)
  
• non-DB-Apps (Eigenbau, reicht aber erstmal) -> EF Core angebundene DB-Apps
  

nicht unbedingt in dieser Reihenfolge

loeffel schrieb:

Was hindert euch daran, modernere Versionen oder Libraries zu verwenden, ?

Also das wundert mich ein wenig. Ich war bisher der festen überzeugung, Microsoft will die Hobbyprogrammierer loswerden. Ich persönlich habe 2 Gründe: a) kein Vertrauen und b) die Sprache.
Zu a) habe jetzt keine genaue Übersicht, wieviele Installer für Visual Studio existieren, aber gefühlt hat jede Visual Studio Version seinen eigenen Installer. Also wenn jedes Jahr eine neue Kuh durchs Dorf getrieben wird, fehlt mir das Vertrauen, das es sich lohnt da mitzumachen.
zu b) Aud den MS Hilfeseiten seht ja immer 5 min Lesezeit. Das setzt aber voraus, das der Artikel nicht vollgespickt ist mit Begriffen, die ich nicht verstehe. Ich habe ja inzwischen Schwirigkeiten die unzähliben Optionen in Visual Studio zu verstehen die erscheinen wenn man ein Neues Projekt erstellen will.

@Coldfire Die Hilfeseiten sind maschinenübersetzt und kommen daher etwas umständlich(er) formuliert rüber. Darum such ich erst im Forum nach Lösungen bevor ich auf MS etwas nachlese.

Solange Windows bedienbar bleibt, VB.net darauf läuft und WinForms funktioniert, werde ich nicht auf neumodischen Kram wechseln.

Coldfire schrieb:

Aud den MS Hilfeseiten seht ja immer 5 min Lesezeit. Das setzt aber voraus, das der Artikel nicht vollgespickt ist mit Begriffen, die ich nicht verstehe.

MS geht davon aus, wenn Du eine entsprechende MS-Doku Seite aufrufst, das Du weist was Du vorhast/suchst und Du daher auch mit den Begriffen zurecht kommst die dort verwendet werden. Meine Empfehlung: Verwende nicht die deutsche Übersetzung der MS-Doku Seite. Ansonsten ändere in der URL einfach de-de in en-us und schon hast die englische Seite.

loeffel schrieb:

Was hindert euch daran, modernere Versionen oder Libraries zu verwenden, also hier in diesem Fall beispielsweise EntityFramework, EFCore und .NET?

Also ich z.B. nutze seit Jahren entweder das Mono-Framework oder seit .NET-6 ausschließlich das.
An .Net Core hat massiv genervt, dass Microsoft da ein unvollständiges Produkt rausgebracht hat, mit der Erwartung dass jeder auf den Zug hüpfen wird.
Aber das kann der Laden gut, genau wie der ganze Schrott den Windows 10 und 11 mitbringen, neben den ganz nützlichen Funktionen. (*hust* Werbung im Startmenü, nach Hause telefonieren wo nicht notwendig) - aber das ist ein gänzlich anderes Thema und da wirst du denke ich nicht viel mit zu tun haben, @loeffel.

Ansonsten ist es glaube ich einfach die Schiere Masse an Informationen, die man für die alten Frameworks findet. Das und dass das noch für neue Projekte unterstützt wird.
Die allermeisten .Net-Entwickler und die, die es werden wollen, sind auf Windows fixiert. Da müsste MS definitiv mehr auf die neue Cross-Plattform-Fähigkeiten von .Net eingehen und bewerben vor allem. Linux und macOS sind ja mittlerweile ein Glück kein Fremdwort mehr für euch, aber da müsst ihr definitiv noch mehr ran.

Mit Blazor und MAUI habt ihr glaube ich einen guten Schritt gemacht, allerdings sind die im Vergleich zu den bekannten Technologien wie WinForms und WPF einfach maximal unverständlich aufgebaut.
Trotz dass ich mehrere Jahre Erfahrung darin habe, WPF Anwendungen zu bauen, fällt es unfassbar schwer - auch wegen der grottenschlechten Dokumentation dazu - auf MAUI und Blazor umzusteigen.

loeffel schrieb:

Wuerde mich sehr interessieren, was wir von Microsoft-Seite tun muessten, um die Adaption interessanter oder einfacher zu machen.

Mehr gute Dokumentation. Mehr Cross-Platform werben.
Ihr doktort jedes Jahr an der Sprache und dem Framework um. Jedes Jahr gibt's nun eine neue Sprach- und Frameworkversion, was widerum dazu führt, dass Entwickler abspringen, aus Angst, dass sie in einem Jahr wieder alles portieren müssen.
Andereseits funktioniert .Net 4.x immer noch brav für die neuen Versionen von Windows und es wird zugelassen, dass neue Projekte darin geschrieben werden.
Hier würde sich anbieten, dass .Net 4.X standardmäßig (auch im OS!) deaktiviert würde und bei Entwicklung eines neuen Projekts direkt drauf hingewiesen wird, dass es sich hier um ein Framework handelt, was nicht weiterentwickelt wird.

Mein Vorschlag und auch der von vielen Kollegen aus dem Umfeld: seht lieber zu, dass ihr nützliche Features ins Framework bringt. Das kann ja ruhig zwei-drei Jahre dauern bis der nächste vollwertige Release rauskommt. Aber dieses STS und LTS-Krams funktioniert eher semi für die meisten Entwickler.
Zumal es immer noch ein Krampf ist, auf Linux mehrere Versionen zu installieren oder gar zu finden (Ubuntu 22.04 ist ein gutes Beispiel. .net 7 kein Problem, aber für .net 8 muss man eure Repos einpflegen) Das macht es für Entwickler, die gerade umsteigen unfassbar schwer da durchzublicken.

Nicht nur müssen sie das neue Betriebssystem kennenlernen, sondern werden auch gleich mit dem schlechtesten konfrontiert: am System rumdoktoren, damit sie die LTS nutzen können. Das ist unfassbar schlecht.

Ich misbrauche diesen Faden gerade um etwas zu ranten, aber ich wollte die Gelegenheit mal nutzen.
Microsoft hat da schon wahnsinnig gute Fortschritte gemacht. Soweit, dass ich wieder Windows als Haupt-OS nutze und das WSL für meine Arbeit nutze. Dennoch habt ihr da sehr viel zu tun.
Es ist mir durchaus bewusst, dass ihr da auch intern sehr mit zu kämpfen habt, weil ihr maximale Abwärtskompatibilität halten wollt - Hut ab dafür, bisher klappt es weitestgehend - aber genau wie ihr 16-Bit Software nicht mehr laufen lasst, muss es irgendwann auch hiermit so weitergehen.

So, sorry fürs Ranten und weitermachen

Ich entwickle wissenschaftliche Analysesoftware. Da gibt es bis heute Berechnungs-Elemente, die nur in Fortran zu finden sind. Teile meines Codes enthält noch Portierungen von Quickbasic. Und keins der neumodischen Dinge würden da was an der Funktionalität ändern. Mit WPF brauch ich in meiner Firma auch nicht zu kommen. Dass die Bedienung anders aussieht wird bei einem großteil der Kunden als Nachteil und nicht als Vorteil gesehen. Tatsächlich hatte ich große Hoffnungen darin, dass hier ein stimmiges Konzept vorliegen würde, dass die Trennung von Code und Benutzeroberfläche optimiert. Leider kommt das Feature nicht Winforms zugute. Also praktisch nur bei Neuentwicklung sinnvoll. Und daher so in 20-30 Jahren ein Thema . Da bin ich aber dann in Rente.

Moin moin

Also ich habe mit nun mit viel Arbeit das VS 2019 und die .Net 7 Runtime auf meinem PC installiert. ==> Windows 7 64Bit.
Da kann ich aber keine .Net Core auswählen.

Ich hatte auch mal mit dem WPF etwas "probiert". Ehrlich ist mir das dann alles zuviel, zu kompliziert... Irgendwie ein wirrwar an verschiedenen "Sprachen" usw..
Irgenwie bekomme ich den Eindruck, alles wird immer komplizierter gemacht.

Moin Klaus!

loeffel schrieb:

bestimmten deutschen Sprachwissenschaftlern, die meinten, ihre wissenschaftlich begruendete aber total weltfremde eindeutschungsvorgehensweise sei wichtiger als das teils englische Umgangsvokabular von uns Entwicklern.

Das erklärt tatsächlich einiges. Das wird sicherlich nicht nur im deutschen Sprachraum so sein.

loeffel schrieb:

"Produktrueckstandselement"

Ein... product backlog item?
Nicht deren Ernst.

loeffel schrieb:

An die meisten Dinge

Genau das ist der Punkt. Es hat sich weiterentwickelt und es muss ganz klar und deutlich gemacht werden, wo die Unterschiede sind.
Da ist ein feiner Grat zwischen Genie und Wahnsinn, was die Doku von solchen Themen angeht.

Hallo, ich schreibe hier, weil mir aktuell ein ganz anderes Thema am Herzen liegt, das ich viel viel viel wichtiger finde: Die Sicherheit. Der Schutz des Rechners und der Programme, die darauf laufen. Sowohl zu Hause als auch in Firmen ob klein oder groß bis zur sicherheitskritischen Infrastruktur. Es geistern da Zahlen durch die Welt (200 MRD BRD alleine) die ich eigentlich gar nicht glauben will. Und ich habe den Eindruck, es wird mehr und mehr. Auch unsere Firma wurde z.B. getroffen. Und in Kombination mit KI auf Seiten der Angreifer sehe ein da zusätzlich ein weiteres Steigerungspotenzial.
Ich sehe da Microsoft in der Pflicht. Zu oft wurden Entscheidungen in der Vergangenheit getroffen, wo Bequemlichkeit vor Sicherheit stand. Ein Unternehmen an Verkaufszahlen zu orientieren ist nicht immer zukunftsweisend. Und natürlich steht da Microsoft nicht alleine. Ich wünsche mir, das dieses Thema prominenter und klarer vermittelt wird. Ich will hier keine Strategie vorschlagen, aber langfristig würde ich mir wünschen, dass es so etwas wie Aussagen zur Sicherheit eines Produkts getroffen werden können ( noch besser: müssen). Das kann empirisch erfolgen, aber ich würde beispielsweise wirkich gerne wissen, ob die Software, die ich herstelle, sicher ist.

Mich konnte EF bislang kaum überzeugen.
Also die Vorteile von typDataset sind:

• unabhängig
  man braucht keinerlei Zusatz-Dll, keine Installation, keine Datenbank, nichtmal Nuget. Alles was man braucht ist FW-OnBord.
  
• portabel
  man kann eine komplette relationale Datenverarbeitung inklusive Daten in eine Zip tun, und bei wer sie downloaded - läuft out of the box.
  eine Datenbank kann man meist garnet verschicken, bzw. nur mit viel KnowHow bei Sender und empfänger, und wenn beide über SqlServerManagement-Studio verfügen.
  auch lässt sich ein Dataset fabelhaft durchs INet verschicken. Auf Arbeit haben wir einen Wcf-Service, mit dem wir (grundsätzlich beliebige) Db-Tabellen abfragen können, und Änderungen auch rückspeichern - also wir haben Change-Tracking sogar über Internet-Distanz.
  
• anschaulich
  man kann im Dataset-Designer ein ER-Diagramm entwickeln - und es sofort benutzen
  
• volle Kontrolle
  Die mit Dataset.WriteXml geschriebenen Daten sind plain-Text. Man kann sogar (einiges zu beachten) mit einer Volltext-Ersetzung nachträglich Tabellenspalten umbenennen - inklusive im Datenbestand.
  Am EF bisserl intransparent auch, dass die EF-Typen immer nur so Proxies sind, wo man nie weiss: Wird da nun eine Query gegen die Db abgeschossen, wenn ich die Property abrufe?
  
• datengebundenes Filtern und Sortieren
  bei typDataset werden die Daten im Speicher gefiltert und ist sofort verfügbar. Bei EF muss man da glaub extra rum-humpsen, und immer dieselben Daten neu nachladen
  
• Db-Traffic
  Ist bei typDataset geringer
  

Beispiel: PersonBeruf - kannste downloaden, und sollte laufen.
Ich hab vor langem auch mal einen Thread eröffnet, weil ich von EF so frustriert war, weil das trotz gewaltigen Installations-Bedarf (zig GB, wenn man SqlServer+SqlMMS mitrechnet) - und trotzdem kann man so eine PillePalle-Anforderung wie PersonBeruf nicht umsetzen.
Ach guck hier, diese Thread: Was EF nicht kann. Da wollte ich eine Auseinandersetzung, aber das Vergleichen scheiterte, weil ich mir nicht .Net5 drauf packen wollte.
Wenn du magst, kannst du ja auch mal versuchen, PersonBeruf mit EF nachzuprogrammieren. Inzwischen habich auch fetteren Rechner.

loeffel schrieb:

Ich werde mich bemuehen, im Laufe des Jahres ein paar Grundlagen-Videos zu machen

Schöne Idee, aber es schließt Leute wie mich aus die Englisch nicht verstehen.

Mir würde es gefallen wenn alle Beispiele nicht nur in C# vorliegen würden, sondern auch immer in VB. Dann sollten alle Beispiele Copy/Paste fähig sein, d.h. notwendige Imports & Co. sollten im Source drin stehen. Wobei ich mit Bezeichnungen wie Foo & Bar nichts fangen kann. Auto und Reifen sagt da einfach mehr aus.

Ich finde viele Beispiele schrecklich, wenn ich 2-3 scrollen muss und dann feststelle das das ganze auch in 5-10 Zeilen passen würde.

Und die MS Hilfeseiten haben somit oft das gleiche Problem wie alle Artikel über Mathematik auf Wikipedia. Von Profis für Profis geschrieben.

Beim Schreiben kam mir der Gedanke das MS viel mehr Beispiele zum runterladen anbieten könnte. Nicht gleich für jeden Tipp ne ganze Projektmappe, aber thematisch sollte das machbar sein.

Ja, ich bin ja quasi der "Dataset-Onkel" des Forums
Hier: Daten laden, speichern, verarbeiten - einfachste Variante zeige ich, dass es das einfachste ist, um Irgendwas mal eben schnell abspeichern zu können.
Und hier DatasetOnly: DB-Programmierung ohne Datenbank argumentiere ich nochmal wortreich, dass man Datenbanken am besten überhaupt vermeidet - wenn das geht.
Man kann hochkomplizierte Datenverarbeitungen erstmal Dataset-Only entwickeln, und wenn sich später zeigt, dass man doch eine DB braucht (etwa für Multi-User-Anwendungen), dann kann man die auch noch nachträglich hinterlegen, ohne am Dataset was ändern zu müssen.

Insbesondere für Anfänger, zum Lernen und Einarbeiten in relationale Denke, und in Databinding, ist DatasetOnly das Mittel der Wahl.
Sehr oft hat man Anfänger, die wollen mw. ein Proggi haben zur Verwaltung eines Schach-Turniers, aber noch nie von Datenmodellierung gehört.
Mit DatasetOnly können sie das lernen. Wenn die da erstnoch mit SqlServer, Connection, Configuration EF und hastenichjeseehn rumhampeln müssten hätten sie keine Chance.

loeffel schrieb:

Wuerde mich sehr interessieren, was wir von Microsoft-Seite tun muessten, um die Adaption interessanter oder einfacher zu machen.

Ja, weiss ich auch net recht, vielleicht einen ObjectContext erfinden, den man einfach als File auf Platte hauen kann?
Und was bei Dataset auch schön ist: Wenn ich eins befüllt hab, wie auch immer, kann ich im Haltemodus direkt hineingucken, was da nu steht in die Tabellen. Hätten Sie das auch für EF?
Und natürlich den ER-Designer - den hat man für EF glaub mal abgeschafft, dann aber wieder eingeführt - also EF-CodeFirst geht mir ja ziemlich gegen den Strich.
Ich will meine Datenbanken angucken können, als ER-Diagramm.
Und nicht die Relationen erahnen müssen anhand von Enumerablen CodeFirst-Properties, die ich selbst hab schreiben müssen.

EDR hat das schön ausformuliert was ich mit "zu dicht an der DB" meinte. Sehe ich ganz genauso

Ein Beispiel für ein schlechtes Beispiel auf der MS Hilfeseite.



Das empfinde ich als ungefähr so gut lesbar wie MS BASIC V2 in den Retroforen, wenn die Leerzeichen zwischen den Befehlen weggelassen werden.