Hallo,

also:

du willst eine Library (DLL) erstelllen, die grundlegende Logik enthält und die du dann in jedem anderen Projekt verwenden/einbinden kannst?
Grundlegend eine gute Idee, aber was machst du wenn du merkst, dass deine Lib einen Fehler enthält. Musst du dann bei jedem einzelnen Programm die Lib gegen die neue Version austauschen? Da gibt es bessere Lösungen, wenn du so etwas willst... - aber nur meine Meinung....

Vielen Grüße
Florian

florian03 schrieb:

Da gibt es bessere Lösungen, wenn du so etwas willst

Zähl mal auf!

Der Ansatz passt doch.
Nun, um die Funktionalität der Bibliothek zu testen, kannst Du doch eine Projektmappe erstellen, bestehend aus Deinem DB-Code und einem sog. Komponententestprojekt. Dieses testet dann eben die Funktionalität Deines Codes und gibt Dir innerhalb weniger Sekunden die Rückmeldung, ob die Vermutungen, die Du über den Code hast, tatsächlich zutreffen.
Hier ein Screenshot aus einer meiner Bibliotheken, nachdem die bisherigen Tests durchlaufen wurde. Dauer vom Start der Tests bis zur Anzeige des Ergebnisses < 5 Sekunden.


btw: Auch in diese Richtung gehen der Beitrag von @mrMo und mir in dem Thread WinForms und die Rolle des Formulars. Wieviel Logik kann man auslagern (ggf. auch in eine Bibliothek) und so vom GUI trennen.

florian03 schrieb:

was machst du wenn du merkst, dass deine Lib einen Fehler enthält. Musst du dann bei jedem einzelnen Programm die Lib gegen die neue Version austauschen? Da gibt es bessere Lösungen

Ich wäre an deinem Wissen über bessere Lösungen interessiert.

Ich Unwissender Tropf arbeite noch mit .dlls um den dort enthalten Code nicht in jedem Projekt neu schreiben zu müssen... Daher würde ich es begrüßen wenn du mir da etwas auf die Sprünge hilfst und dein Wissen mit mir teilen würdest.

Hallo,

also ich habe für so etwas einen eigenen Nuget-Server. Auf diesem habe ich meine "Helper" gespeichert.
In die entsprechenden Projekte installiere ich dann einfach das Paket. Wenn ich eine Änderung mache kann ich das Nuget Paket einfach updaten und muss mich nicht um DLLs kümmern.
Mir fällt das deutlich leichter...

Viele Grüße
Florian

Hm … Was passiert, wenn ein fertiges Projekt auf Deine Bibliotheken in Deinem Nuget-Paket verweist und Du ein ein Update bereitstellst? Musst Du dann nicht auch im Projekt selber angeben, dass das Paket aktualisiert werden muss? Ein fertiges Programm wird doch nicht selbständig nachschauen können, ob es Paketupdates gibt. Zumindest mal nicht bei nem Offline-PC. Und bei einem mit Verbindung hab ich das bisher auch noch nicht erlebt.

nogood schrieb:

Als Kontrolle schaue ich "per Hand" in der DB nach ob die Funktion den Datensatz auch erzeugt hat.

Das wäre ein Test-smell (Eigenkreation, abgeleitet von code smell). Tests sollte man so nicht schreiben. Eine manuelle Kontrolle von Resultaten sollte nie stattfinden, da man im ungünstigsten Fall kein Bock auf die manuelle Kontrolle hat und so der Test sich selbst überflüssig macht. Dann lieber einen kleineren Test-smell einbauen: Doppeltest. Teste, ob der richtige Wert in die Datenbank geschrieben wird (1. Test), indem Du im Anschluss daran den Wert aus der DB abfragst und schaust, ob das, was Du zur DB schickst identisch mit dem ist, den Du losgeschickt hast (2. Test). Man sollte zwar keine 2 Aspekte in einem Test prüfen, aber das ist immer noch besser als ein manueller Ergebnistest. Ggf. könntest Du auch stattdessen das Ganze mocken. Will heißen, Du schiebst Deiner Lese-Schreib-Funktion eine Fake-DB unter, die die Aufrufe entgegennimmt und wiedergibt. Stichwort Dependency Injection. Naja, das ist aber dann schon ein paar Schritt weiter.
Lange Rede, gar kein Sinn: lieber Doppeltest (lesen und schreiben in einem Test testen) als Ergebnisse manuell kontrollieren zu müssen.

Hallo,

VaporiZed schrieb:

Hm … Was passiert, wenn ein fertiges Projekt auf Deine Bibliotheken in Deinem Nuget-Paket verweist und Du ein ein Update bereitstellst? Musst Du dann nicht auch im Projekt selber angeben, dass das Paket aktualisiert werden muss? Ein fertiges Programm wird doch nicht selbständig nachschauen können, ob es Paketupdates gibt. Zumindest mal nicht bei nem Offline-PC. Und bei einem mit Verbindung hab ich das bisher auch noch nicht erlebt.

Klar, dass geht natürlich nicht . Aber wenn ich mehrere Bibiliotheken eingebunden habe muss ich nur einmal auf aktuallisieren klicken und schon ist alles auf dem aktuellen Stand. Finde ich einfacher, als mit einzelnen DLLs zu handeln.


---


Zum Thema .Net:

Ich finde das ehrlichgesagt auch sehr verwirrend.
Also das .Net Framework ist (soweit ich das mitbekommen habe) am auslaufen, sprich, das ist die aktuell letze Version. Bei .Net Framework ist die Source auch geschlossen und es ist nur für Windows geeignet.
Deswegen soll die Zukunft .Net Core (5) werden. Die Sources sind offen und es kann (zumindest Konsole und Web) auf jeder Plattform ausgeführt werden.
.Net Standart war bisher eine Art "Minimalimplemention". Das heißt eine .Net Standart Bibiliothek kannst du in jedes Projekt einbinden - egal ob .Net Framewok, .Net Core, Xamarin...

Ich weiß allerdings nicht, wie das in Zukunft und bei .Net Core 5 dann aussieht.

Ich würde dir allgemein empfehlen alle Projekte (also nicht die Klassenbibiliotheken) nur noch in .Net Core zu erstellen, weil das wird wie gesagt die Zukunft sein...

So das war mein Verständnis der Versionen - keine Ahnung, ob alles richtig ist... - hier noch ein Link von MS wo es auch eine ganz gute Tabelle gibt: docs.microsoft.com/de-de/archi…net-core-and-net-standard

Viele Grüße
Florian

Naja, aber wenn ich ein Projekt P auf die DLLs verweisen lasse, welche sich im Debug-Verzeichnis der DLL-Projekte befinden, muss ich beim Update der DLLs gar nix explizit zusätzlich in P aktualisieren. Ich klick einfach auf kompilieren und alles ist up to date. Wenn sich inkompatible Veränderungen durch das DLL-Update ergeben, rebelliert der Compiler sofort. Dazu bedarf es natürlich, dass sowohl P als auch die DLL-Projekte auf dem selben PC liegen. Aber das dürfte bei vielen Hobbyprogrammierern (wie auch mir) der Fall sein.

Du gehst auf [Add Reference …], dann links unten auf … |Browse| (?) (sorry, hab VS2019CE deutsch, da heißt's |Durchsuchen|) und auf dieser TabPage auf den Button [Browse/Durchsuchen]. Und dann suchst Du Dir Deine kompilierte DLL raus.

##########

zu finden im Menü Project -> Project-Properties -> References (vermute ich zumindest stark; also effektiv in den Projekteigenschaften)

nogood schrieb:

Meine Versuche Ordnung im Programm zu erhalten scheitern häufig in den Momenten wo GUI und die "echten" Programmteile zusammen kommen.Ich möchte daher eine Library erstellen, in der ich die Teile für Datenbankzugriffe inkl. CRUD und Search Funktionen "stecke".

Um Ordnung herzustellen brauchst du keine Library-Projekte.
wenn du mit normalen Ordnern innerhalb deines Projekts keine Ordnung herstellen kannst, wirst du es mit zusätzlichen Library-Projekten auch nicht hinkriegen - eher wird es noch schlimmer - wenn zB Dinge auseinandergerissen werden, die zusammengehören.
Um ein Library-Projekt anzufangen, brauchst du zunächstmal einen triftigen Grund, warum du eine (zusätzliche) Library brauchst.
Sonst lasses besser.
Etwa alle Logik für den zugriff auf eine DB zusammenzufassen ist eine gute Idee, Ordnung zu schaffen.
Da kann man dem Projekt einen Ordner zufügen, evtl. auch einen Namespace, und dann weiss man, wo DB-Zugriffs-Code anzusiedeln ist.
Wie gesagt: Eine Extra-Library braucht man dafür nicht.
Libraries haben auch Nachteile: Zum Beispiel kann die Funktionalität nur über Public Member angesprochen werden. Wenn du die Anwendungs-Logik in deiner Anwendung lässt, kannst du zB mit Friend wesentlich besser kapseln.

Testing hingegen ist zB ist ein triftiger Grund, eine zusätzliche Library zu programmieren.
Weil Tests sind ja Code, den zum Kunden auszuliefern gar kein sinn macht.
Da kann man beim Setup die Test-Bibliothek einfach weglassen - und um sie für den Kunden weglassen zu können, muss sie logisch eine eigene Bibliothek sein.
Ein anderer guter Grund für eine Library ist, wenn du Code hast, der in mehreren verschiedenen Projekten verwendet werden soll.
So ein Utility-Projekt kann man dann schön in mehrere Solutions einbinden - so kann man vermeiden, dieselbe Lösung an verschiedenen Stellen mehrfach zu entwickeln.

Jo - hast du eine Lib, und einen Grund, warums die Lib geben soll - und welcher wäre das?

Nur um kurz die verschiedenen .NET Varianten aufzudröseln:

.NET Framework, oder auch .NET FX ist mit der Version 4.8 am Ende. Es wird keine neuen Features mehr bekommen, wenn man mal von Dingen wie neue TLS Versionen usw. absieht. Es ist closed bzw. shared source, und kann hier eingesehen werden:
referencesource.microsoft.com/

.NET Core war zunächst nur als kleines Cross-Plattform OpenSource Framwork gedacht, weswegen sich "Core" im Namen befindet. Jedoch wurde es so populär, dass Microsoft entschieden hat, mithilfe der Community daran weiter zu arbeiten wodurch wir nun ein bald noch größeres Framework als .NET FX haben.

.NET ist die Zukunft, die ab November diesen Jahres als .NET 5 .NET Core ablösen wird. Mit dieser Version soll dann die .NET Runtime alle anderen Runtimes ablösen, sodass, egal wo man sich gerade befindet, sei es Mac, Linux, iOS, Android, Windows, man dieselbe Implementation findet, und daher nicht mehr von den verschiedenen Lösungen auf der jeweiligen Plattform abhängig ist.

.NET Standard in alledem, ist die Lösung, um Code ebenfalls Plattform-, sogar Runtimeunabhängig zu gestalten. Mit .NET Standard wurde den Implementierern ein fester Satz an APIs vorgegeben, die sie Implementieren mussten, sodass Entwickler sich sicher sein können, welche APIs verfügbar sind. Entstanden ist es aus den Portable Class Libraries (PCL) was zwar schon damals (VS 2012/13) erlaubte für Android oder iOS zu entwickeln, jedoch noch ein ziemlicher Hickhack war, da man sich immer zwischen Kompatibilität und Features entscheiden musste. Da war .NET Standard ein absoluter Segen.

Zum Abschluss noch der Hinweis, dass man Libraries, wenn möglich, inzwischen nur noch in .NET Standard anlegen sollte. .NET Core Libraries sind nicht zu Empfehlen, es sei denn, man braucht unbedingt ein Feature, dass in .NET Core bereits umgesetzt wurde.

Edit:
Da wollte ich noch was zum Thema NuGet schreiben und habs beinahe vergessen. NuGet ist wunderbar einfach. Man kann es einfach auf nen Ordner schauen lassen, dann in den Ordner Pakete reinlegen, und schon tauchen die Auch im NuGet in VisualStudio auf und lassen sich wie die auf einem NuGet Server verwalten:
haacked.com/archive/2010/10/21…remote-nupack-feeds.aspx/

Hallo,

EaranMaleasi schrieb:

.NET ist die Zukunft, die ab November diesen Jahres als .NET 5 .NET Core ablösen wird. Mit dieser Version soll dann die .NET Runtime alle anderen Runtimes ablösen, sodass, egal wo man sich gerade befindet, sei es Mac, Linux, iOS, Android, Windows, man dieselbe Implementation findet, und daher nicht mehr von den verschiedenen Lösungen auf der jeweiligen Plattform abhängig ist.

Finde ich sehr interessant. Hab mir gerade den Artikel durchgelesen. Also .Net 5 löst sowohl .Net Core als auch .Net Framework ab und ist platformunabhängig.

Heist das, dass WPF Anwendungen in Zukunft auch auf Linux/Mac laufen?

LG Florian

Nope. WPF und WinForms sind nach wie vor Windows-Exclusiv, da sie nach wie vor auf die Windows-schnittstellen GDI bzw. DirectX zugreifen. Microsoft hat in den Repos auch das Umschreiben auf OpenGL, Vulkan usw. komplett untersagt.

Jedoch könnte Xamarin hier interessant werden. Xamarin setzt bereits jetzt auf Cross-Plattform GUI was Android, iOS und Windows Store Apps angeht, wodurch man 90-95% des Quellcodes nur einmal schreibt. In der App meiner Firma liegen wir bei ~93% als ich das letzte mal nachgesehen habe.
Da Xamarin auch die Entwicklung für Mac unterstützt, fehlen nur noch Windows und Linux.

Für diese gibt es bereits entsprechende Projekte, die zum einen auf WPF für Windows und zum anderen auf GTK# für Linux, BSD, usw aufbauen. Jedoch bin ich im Moment nicht mehr ganz aktuell was die Entwicklung der beiden angeht.