Wie erstellt/programmiert man eine Library in VisualStudio "richtig"?

  • VB.NET

Es gibt 24 Antworten in diesem Thema. Der letzte Beitrag () ist von nogood.

    Wie erstellt/programmiert man eine Library in VisualStudio "richtig"?

    Hallo,

    auf meinem Weg Programmieren zu lernen bin ich nun nicht mehr nur mit der Syntax beschäftigt ;) Danke an Euch.
    Bei den etwas "anspruchsvolleren" Projekten, komme ich leider immer wieder zu dem Problem, dass die Projekte nach relativ kurzer Zeit unübersichtlich werden (Spaghetti-Code, NinjaCode oder wie auch immer das heißt). 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 schneller neue Ideen umzusetzen und um mehr Separation zu bekommen.

    Unter Visual-Studio würde ich dafür ein neues Projekt anlegen "Klassen Bibliothek (NET.Core)". Konkret will ich den Anschluß einer MongoDb umsetzen (DB Art tut hier aber nichts zur Sache; könnte auch SQL sein).

    Ich habe dass schon mal gemacht jedoch bin ich damals so vorgegangen: Winforms Projekt erstellt und dann dort ein Library Projkt zur Solution hinzugefügt.Probleme hatte ich dann mit der Verwaltung unter Github. Ich konnte nicht beide Projekt "sichern".

    Nun zu meinen Frage:

    Ist das der richtige Weg? Library Projekt in VS erstellen. Dann ein zweites separates WinForms Projekt außerhalt der Library Solution erstellen. Die Library in das WinForms Projekt verlinken. So das ich jetzt in der Winforms Anwendung die Library so zu sagen ausführen kann. Da ich in dem reinen ClassLibrary Projekt die Funktionalität nicht prüfen kann.
    Beide Projekt separat bei Github zur QuellCodeVerwaltung hinzufügen. Fertig.


    Ziel ist es eine Library zu haben, die ich neuen Projekten verlinken kann. Dort hätte ich dann mit wenig Codezeilen eine "fertige" Datenbankanbindung.

    Nochmal kurz:
    Erzeugt man KlassenBibliotheken so, dass man zwei Projekte erzeugt ein z.B. WinForms und ein Library-Projekt, wobei die WinForms Anwendung mehr oder weniger nur der Kontrolle/Anzeige der Library dient?

    LG nogood
    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
    Meine Website
    Mein Projekt: SnippetLibrary
    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.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.

    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.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    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
    Meine Website
    Mein Projekt: SnippetLibrary
    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.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.
    @ Alle: Danke für die Antworten!
    @VaporiZed Extra Dank an Dich für die viele Hilfe die Du hier im Forum leistest. Ich hab den Thread gelesen.

    Dein Stichwort "Komponententestprojekt" hat mich zu diesen Links geführt:
    docs.microsoft.com/de-de/visua…st-your-code?view=vs-2019
    und dann zu diesem Beispiel für UnitTesting:
    https://docs.microsoft.com/de-de/visualstudio/test/walkthrough-creating-and-running-unit-tests-for-managed-code?view=vs-2019

    Ist für mich zur Abwechselung mal eine recht verständliche Erklärung von MS.

    Das Wort UnitTesting hab ich ja schon häufiger früher gelesen und wusste nicht so genau was das ist. Das steckt also dahinter:)

    Ich hoffe ich kann es mir erlauben und mich erst später mit diesem Thema/Aspekt auseinander zusetzen. Ich werde mein "UnitTesting" in diesem Fall wohl noch mit meiner eigenen WinForms-Anwendung machen.
    Warum? Das Beispiel auf der MicrosoftSeite ist ja ein Bankkonto. Wo die Funktion Abbuchung gestest wird. Erwarte 5 € = Ergebnis der Funktion 5 € -> UnitTest bestanden etc.
    Da ich CRUD Funktionen einer MondoDB umsetzen will ist mir als Anfänger auf dem Gebiet nicht klar wie ich das effizient testen soll, da ja keine einfachen Ints oder Strings zu erwarten sind. Sondern Collections und Documents (NoSQL sprech für Table und Record) erzeugt,gelesen,upgedated und deleted werden sollen.
    Zum Beispiel Create-Funktion soll einen Datensatz in die DB schreiben. Als Kontrolle schaue ich "per Hand" in der DB nach ob die Funktion den Datensatz auch erzeugt hat.
    Mal sehen wie die Reise weiter geht. Danke für die Hilfe

    P.S.: Ich sollte mir wirklich die Zeit nehmen und das DemoProjekt "Rollenentwicklung des Forms.zip" ansehen runtergeladen hab ich es schon ;)

    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.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.
    @VaporiZed So hatte ich mit das schon gedacht. Das ein Test eigentlich nur eine Sache Testen soll, dass in diesem Fall es aber okay ist Schreiben und Lesen zusammen zufassen.

    Anschluss Frage...

    Verwirrung über die mal wieder von MS duzenden .NET, .NET Core, NET Frameworks Versionen.

    Ich möchte erstmal zum Einstieg folgendes machen:
    In VS ein ClassLibrary Projekt erzeugen und dieses in einem anderen VS Projekt einbinden (References) und nutzen.

    funktioniert hat das mit folgender Kombi:
    Class Library (.Net Standard) und Winforms (.Net Framework)

    nicht funktioniert hat diese Kombination:
    Class Library (.NET Core) und Winforms (.Net Framework)


    Ich möchte später die Library auch in einem Blazor Projekt referencen kann ich das mit einer .Net Standart Library machen oder muss es eine .Net Core Library sein (es gibt auch eine Razor Class Library Option). Gibt es im Netz eine Übersicht darüber?



    allen einen schönen Sonntag noch

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „nogood“ ()

    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
    Meine Website
    Mein Projekt: SnippetLibrary
    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.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.
    Nachtrag:
    Ich sehe gerade in meinem Blazor Projekt, dass ich gar nicht einfach so eine ClassLibrary "referencen" kann?!Wie nutzt man denn da eine ClassLibrary ? Ich kann auf Dependencies rechte Mausetaste drücken "add Project Refence" oder "add COM Reference" aber eben nicht "add Refernce" (sorry hab VS Sprache auf Englisch installiert)?
    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)
    Bilder
    • FindDll.png

      56,04 kB, 784×543, 21 mal angesehen
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

    Danke hab es erstmal hinbekommen (denke) ich.

    HowTo:
    .NET Standard Library Projekt => DLL in ein BlazorProjekt einbinden:
    Library coden und kompilieren.
    Im Blazor Projekt rechte Maus Taste auf "Dependencies" dann dort "Add Project References" und dann die .DLL des Library Projektes mittels browse finden und adden (...Debug\xyz.dll). Nicht vergessen auf der Blazor-Komponenten Seite auf der man die Dll nutzen möchte noch das @using NamespaceName_meiner_Library hinzufügen.

    LG

    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?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    @ErfinderDesRades "... hast du eine Lib, und einen Grund warum es die lib geben soll ,..." In diesem Fall ist es so, dass ich die Datenbankzugriff-Methoden in eine Library packen möchte, damit ich die Funktionalität nicht bei jedem anderen Projekt nochmal schreiben muss. Ich erhoffe mir dadurch, dass ich das DRY-Prinzip (Dont repeat yourself) in bBezug auf den DB-Zugriff Projekt überreifend damit besser erfülle.
    Desweiteren erhoffe ich mir mehr Codeklarheit (weniger Zeilen/Ordner(Dateien) bei neuen Projekten da ich das ganze DB Zeug ja nicht "sehe" :)


    @florian03 Interessante Idee mit dem NugetServer! Wie macht man sowas? Hast Du da ein paar hilfreiche Links? Wie komplex ist das umzusetzen? Oder ist das im Grunde nicht das selbe wie immer darauf zu achten, dass man die aktuellste .dll hat?
    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/
    SIMDoku (Simple Dokumentenverwaltung)
    Mein Lernprojekt um die verschiedensten Facetten der .NET Entwicklung zu erkunden.
    GitHub

    VB Paradise Dark Theme
    Inoffizieller VB-Paradise Discord.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „EaranMaleasi“ ()

    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
    Meine Website
    Mein Projekt: SnippetLibrary
    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.
    SIMDoku (Simple Dokumentenverwaltung)
    Mein Lernprojekt um die verschiedensten Facetten der .NET Entwicklung zu erkunden.
    GitHub

    VB Paradise Dark Theme
    Inoffizieller VB-Paradise Discord.