Hingefingert - Di 31.05.16 16:06
Titel: Verschiedene Programmversionen erstellen - DLL?

---

Hallo,

habe eine Frage zur Erstellung von verschiedenen Versionen eines Programms. Das Programm in VS 2015 entwickelt werden, soll unter Windows lauffähig sein, in C# geschrieben werden und aus verschiedenen Fenstern (früher hießen die mal im Studio Formen...keine Ahnung ob das immer noch so ist) bestehen. Das Programm soll im Vollbild laufen und je nach Programmversion sollen verschiedene Formen aufgerufen werden.
Ich möchte nicht darauf zurückgreifen das Programm mit allen Funktionen zu erstellen und anhand einer Konfigurationsdatei dann alles abschalten, was nicht laufen können soll - der Code soll also definitiv nicht drin sein.
Ich müsste also entweder, was ich vermeiden möchte und für Quatsch halte, mehrere Versionen mit identischem Code anlegen (was garantiert in Kuddelmuddel endet) oder die Formen nachträglich einzuladen (also wahrscheinlich mit DLLs). Lieg ich da richtig? Kennt einer von euch da ein gutes Tutorial oder kann mir jemand sagen, welche Suchbegriffe da treffen? Ich hab es mit Kombinationen aus "C# GUI DLL verteilen...etc" probiert, doch so wirklich nichts gefunden. Komplette Listings oder so sollen es gar nicht sein...suche nur nach Begriffen, die mir die Suche etwas erleichtern. *liebguck*

Danke im Vorraus :)

Ralf Jansen - Di 31.05.16 18:05

---

Man benutzt in der .Net Welt allgemein den Begriff Assembly, ja die Dateien haben oft die Endung Dll, ob etwas ein Exe oder Dll ist macht aber kaum noch einen Unterschied.
Scheinbar möchtest du Assemblies dynamisch laden um irgendwelche Funktionen (ist egal ob das jetzt was UI spezifisches oder sonstwas ist) nachrüsten zu können. Das Stichwort wäre also (neben Assembly) Plugin oder Addin System.

Um das zu entwickeln habe ich aber das Gefühl das deine Fähigkeiten (also nur aus deinem paar Worten geraten ;) ) möglicherweise nicht ausreichen.
Was dir mindestens leicht von der Hand gehen sollte bevor du sowas angehst ist Funktionalität in einer Anwendung sauber in Einzelteile zerlegen zu können. Wenn du Konzepte wie MVC oder ähnliches (auch wenn du die hier gar nicht brauchst) verstehst und dir der Einsatz von Interfaces ( programmieren mit und gegen Interfaces so das man die konkrete Klasse hinter dem Interfaces austauschen kann) leicht fallen wäre der Schritt zu einem Plugin System ein erreichbares Ziel. Ansonsten wäre es sinnvoll dieses Grundlagen erstmal zu schaffen. Ein Tutorial das irgendwas bezüglich eines Plugin Systema zeigt wird garantiert sowas als Voraussetzung annehmen oder es wäre kein Tutorial sondern ein Epos.

Th69 - Di 31.05.16 19:06

---

Hallo und :welcome:

ich habe mal ein wenig für dich im Internet gesucht, wo du dich einlesen bzw. du dir die Beispiele anschauen könntest:
Creating a simple plugin mechanism [https://code.msdn.microsoft.com/windowsdesktop/Creating-a-simple-plugin-b6174b62]
How to create an easy plugin-system in C# [http://www.codeproject.com/Tips/546639/How-to-create-an-easy-plugin-system-in-Csharp]
Implementing a Plug-In Architecture in C# [http://www.drdobbs.com/cpp/implementing-a-plug-in-architecture-in-c/184403942]

Du solltest den Code, den du für alle Programmversionen benötigst in eine (oder mehrere) eigene Assembly(-ies) auslagern, dann erstellst du dir mithilfe des Plugin-Systems entsprechende Assemblies, welche die Spezialfunktionalität (z.B. ganze Forms oder nur einzelne UserControls) beinhalten.
Nun erstellst du dir eine (oder mehrere) Projektmappe(n) ("Solution(s)"), welche dann die Projekte für die verschiedenen Programmversionen bereitstellen und referenzierst dort dann jeweils die gemeinsam genutzte Assembly (welche dann den Plugin-Mechanismus enthält) sowie die jeweils Programmversion-spezielle Assembly.

Ich hoffe, das ist für dich jetzt nicht zu viel Kauderwelsch ;-)

Hingefingert - Di 31.05.16 23:01

---

Hey Ralf,

die einzelnen Features hab ich bereits in Klassen zerlegt. Was also entfernt von der GUI gebraucht wird, wäre grob aufgeteilt. Ein Pflichtenheft ist also angelegt und sitze gerade am Designdokument. VB und VC wären nun nicht das Problem gewesen, doch eine komplette API, die leider nur in C# verfügbar ist, wollte ich nun nicht portieren. :D Das System ist damit dann ja klar, wenn auch jetzt nicht in C#. Danke für die Begriffe...sind ja gerade beim Umstieg immer der Hauptpunkt zum Haareraufen.

Hey Th69,
danke für die Links - guck ich mir nachher mal in Ruhe an. Ist ja im Prinzip wie in C++...also DLL kompilieren, Lib und Header einbinden und dann fröhlich die Blackbox nutzen. Wie gesagt: Danke für die Begriffe. Hab lange in PHP festgehangen und wenig Zeit für C über gehabt. Da fehlt einem schon ab und an der ein oder andere Begriff oder Konzepte bei einem Umstieg. Süß finde ich im Moment, dass die MSIL-Codes Assemblys heißen - das nehme ich dann mal so hin und denke mit einen Mov C#,AH Befehle zu :D

Super nett von euch. Habt mir super weitergeholfen! Danke schön! :)

GuaAck - Di 31.05.16 23:18

---

Hallo,

ich kenne VS2105 nur ansatzweise, meine Umgebeung ist Delphi 7. Unabhängig davon, die Formulierung "der Code soll also definitiv nicht drin sein." führt doch direkt zu der bedingten Compilierung.

Es gibt einen Quellcode und aus dem erzeugt man abhängig von den gesetzten Parametern die EXE/DLLs mit den gewünschten Programmteilen.

Denke ich in die falsche Richtung? Vielleicht sind Assemblies etwas in der Art?

Gruß
GuaAck

Ralf Jansen - Di 31.05.16 23:30

---

Habe ich das richtige Verstanden du möchtest nicht nur die Anwendung in verschiedene Dlls/Assemblies aufteilen sondern auch ~Welten~ mischen. Also z.B. eine C/C++ executable die eine in .Net Dll benutzt?
Oder hast du dir es komplett anders überlegt und C# gestrichen?