Video: HelperProjekt einbinden

    • VB.NET

    Es gibt 2 Antworten in diesem Thema. Der letzte Beitrag () ist von us4711.

      Video: HelperProjekt einbinden

      Gelegentlich schreibt man ja den einen oder anneren Code, der so gut ist, dasser geeignet ist, in mehreren Projekten Verwendung zu finden.
      Dazu verlegt man ihn am besten in ein eigenes Projekt, was man dann von anneren Projektmappen aus einbinden kann.
      Das VisualStudio öffnet ja nicht ein Projekt, wennman eins öffnet, sondern immer eine Projektmappe - eine Solution. Und die Solution kann mehrere Projekte enthalten, und dassis genau das Mittel, mit dem man mehrfachverwendbaren Code mehrfach verwenden kann.

      Jdfs. hier ein klein Video, wie man son Helpers-Projekt einbinden und dann nutzen kann. Auch gezeigt paar Fußangeln, also man muß aufpassen, dass das HelperProjekt ein niedrigeres oder gleiches Framework addressiert, und glaub auch die Ziel-Cpus müssen kompatibel sein.
      Und dann darf man sich vonne Bugs im Visualstudio nicht ins Bockshorn jagen lassen - das zickt nämlich auch manchmal rum, wos garnix rumzuzicken gibt.
      Das ist manchmal schwierig, da begründete von unbegründeten Fehlermeldungen zu unterscheiden, und die begründeten beheben, und die grundlosen iwie umschiffen, etwa mit aus und wieder anmachen oder was auch immer.

      Film1: DllProjekt einbinden

      Im Anhang ein klein Dateisystem dazu, mit 2 Solutions, die dasselbe Helpers-Projekt nutzen, und eine dritte (im "Vorher"-Ordner), dies nicht tut.
      Dateien
      • VB10Projekte.zip

        (127,31 kB, 271 mal heruntergeladen, zuletzt: )

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

      HelperProjekt anlegen

      Und hier noch, wie man ein HelperProjekt anlegt, wenn man findet, man habe Code gecodet, den man auch in anneren Projekten nutzen möchte.

      Film2 - DllProjekt anlegen

      Was mir an zu beachtendem grad einfällt:
      • Organisation des Dateisystems, nämlich dass das HelperProject einen eigenen Ordner bekommt, auf derselben Ebene wie die Projektmappen, die es einbinden sollen.

      • Das Helpers-Projekt muss vom Typ "Klassenbibliothek" sein

      • Kompilierungs-Kompatiblität - das HelperProjekt darf kein höheres Framework nutzen als die Ziel-Anwendung. Auch die Einstellung für die Ziel-Cpu kann man verdaddeln, aber ich weiß nichtmal die exakte Bedingung, wanns verdaddelt ist. Bei Problemen jedenfalls auch darauf achten

      • VisualStudio bugt herum, wenn man so tief inne Projekt-Konfiguration herumfummelt. Manche "Fehler" sind auf einmal weg, wenn man neu kompiliert, oder gar schließt und wieder öffnet.

      • Die Namespaces sind von entscheidender Bedeutung.
        Meine Strategie ist, dass mein wiederverwendbarer Code in denselben Namespace gelegt wird, wie die Klassen, die er erweitert. Das erfordert als erstes, den StammNamespace des HelpersProjekts zu löschen. Bei VB isses halt so, dass der StammNamespace sich vor alle selbstdefinierten setzt, also meine Klasse System.Collections.Generic.Minimax würde zu Helpers.System.Collections.Generic.Minimax, wenn ich den Rootnamespace des Helpers-Projektes drinne ließe.
        Es gibt auch annere Strategien mitte Namespaces, etwa "eigener Code in eigene Namespaces", aber ich finde das umständlich, im Code immer dran zu denken, die richtigen Namespaces zu importieren.


      Insgesamt ist die Projekt-Einbinderei mühsam zu erlernen, weil man keine vernünftigen Fehlermeldungen bekommt. Hat man etwa den RootNamespace im HelperProjekt drinne gelassen, dann liegt dessen gesamter Code ja in einem anneren Namespace, als was vlt. direkt inne Dateien als DateiNamespace gegeben ist (nämlich "RootNamespace.DateiNamespace").
      Und da fehlermeldet sich nix, sondern der Wiederverwendbare Code ist einfach nicht verfügbar, wo man ihn braucht, und da sucht man sich u.U. einen Wolf.

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

      @ErfinderDesRades:
      Auch die Einstellung für die Ziel-Cpu kann man verdaddeln

      Jo. Habe nach viel Try&Error Folgendes gefunden:
      - wenn Hauptprojekt auf x86, dann DDL-Projekt auf x86 oder AnyCpu
      - wenn Hauptprojekt auf x64, dann DDL-Projekt auf x64 oder AnyCpu

      Framework:
      - Clientprofile meiden, wie der Teufel das Weihwasser
      - DLL-Framework mus <= Hauptprojekt-Framework sein.

      Noch eine Besonderheit:
      Ich arbeite häufig mit eingebundenen OpenOffice-DLL's, die natürlich NICHT .net kompatibel sind, aber wohl Framework <3.5 unterstützen.
      Das ist aber ab .net 4.0 so ohne weiters nicht mehr möglich.
      Klappt aber, wenn man Folgendes beachtete:

      Im Basisprogramm ist die app.config wie folgt zu ändern:

      Quellcode

      1. <startup useLegacyV2RuntimeActivationPolicy="true" >
      2. <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
      3. </startup>

      Zur Sichtbarkeit von app.config muss "alle Dateien anzeigen" ausgewählt sein.
      Zielframework darf nicht grösser als NET 3.5 sein