Eine große ausführbare Datei oder viele kleine DLLs?

Question

Im Laufe der Jahre ist meine Anwendung von 1 MB auf 25 MB angewachsen, und ich gehe davon aus, dass sie noch weiter auf 40 bis 50 MB anwachsen wird. Ich verwende keine DLLs, sondern packe alles in diese eine große ausführbare Datei.

Eine einzige große ausführbare Datei hat gewisse Vorteile:

• Die Installation meiner Anwendung beim Kunden ist eigentlich: Kopieren und ausführen.
• Upgrades können einfach gezippt und an den Kunden geschickt werden
• Es besteht kein Risiko, dass es zu Konflikten mit DLLs kommt (wenn der Kunde nicht Version X der EXE, sondern Version Y der DLL hat)

Der große Nachteil der großen EXE ist, dass die Verknüpfungszeiten exponentiell zu wachsen scheinen.

Ein weiteres Problem besteht darin, dass ein Teil des Codes (sagen wir etwa 40 %) mit einer anderen Anwendung geteilt wird. Auch hier sind die Vorteile, dass:

• Es besteht kein Risiko, eine Mischung aus falschen DLL-Versionen zu haben.
• Jeder Entwickler kann Änderungen an dem gemeinsamen Code vornehmen, was die Entwicklung beschleunigt.

Aber auch dies hat erhebliche Auswirkungen auf die Kompilierzeiten (jeder kompiliert den gemeinsamen Code auf seinem PC neu) und auf die Verknüpfungszeiten.

Die Frage Gruppierung von DLL's für die Verwendung in Executable erwähnt die Möglichkeit, DLLs in einer ausführbaren Datei zu mischen, aber es sieht so aus, als ob dies immer noch erfordert, dass Sie alle Funktionen manuell in Ihrer Anwendung verknüpfen (mit LoadLibrary, GetProcAddress, ...).

Was halten Sie von der Größe ausführbarer Dateien, der Verwendung von DLLs und der besten Balance zwischen einfacher Bereitstellung und einfacher/schneller Entwicklung?

Answer 1

Eine einzige ausführbare Datei hat enorme positive Auswirkungen auf die Wartungsfreundlichkeit. Sie ist einfacher zu debuggen, zu verteilen (abgesehen von Größenproblemen) und vor Ort zu diagnostizieren. Wie Sie betonen, umgeht es die DLL-Hölle vollständig.

Die einfachste Lösung für Ihr Problem ist es, zwei Kompilierungsmodi zu haben, einen, der eine einzelne Exe für die Produktion erstellt und einen, der viele kleine DLLs für die Entwicklung erstellt.

Answer 2

Der Leitsatz lautet: die Anzahl Ihrer .NET-Assemblies auf das absolute Minimum zu reduzieren . Eine einzige Baugruppe ist die ideale Zahl. Das ist zum Beispiel bei Reflector oder NHibernate der Fall, die beide als sehr wenige Assemblies kommen. Mein Unternehmen veröffentlichte kostenlos zwei weiße Bücher zu diesem Thema Eine große ausführbare Datei oder viele kleine DLLs :

• Partitionierung der Codebasis durch .NET-Assemblies und Visual Studio-Projekte (8 Seiten)
• Definieren von .NET-Komponenten mit Namespaces (7 Seiten)

In diesen White-Books werden Argumente entwickelt, die mit ungültigen/gültigen Gründen für die Erstellung einer Baugruppe und einer Fallstudie über die Codebasis des Tools einhergehen NDepend .

Das Problem ist, dass MS die Idee fördert (und immer noch fördert), dass Baugruppen Komponenten sind, während Baugruppen nur Komponenten sind. physisches Artefakt Code zu verpacken. Der Begriff der Komponente ist ein logisches Artefakt und normalerweise sollte eine Baugruppe mehrere Komponenten enthalten. Es ist eine gute Idee, Komponenten mit dem Begriff der Namespaces zu partitionieren, obwohl dies nicht immer praktikabel ist (insbesondere im Falle eines Frameworks mit einer öffentlichen API, wo Namespaces zur Partitionierung der API und nicht unbedingt der Komponenten verwendet werden).

Answer 3

Eine große ausführbare Datei ist definitiv von Vorteil - man kann das gesamte Programm optimieren und hat weniger Overhead und die Wartung ist viel einfacher.

Was die Verknüpfungszeit anbelangt, so könnten Sie sowohl "viele DLLs" als auch "eine große ausführbare Datei" gleichzeitig haben. Für jede DLL gibt es eine Projektkonfiguration, die eine statische Bibliothek erstellt. Wenn Sie also Debugging betreiben, kompilieren Sie die "DLL"-Konfiguration des Projekts, und wenn Sie es ausliefern wollen, kompilieren Sie die "statische Bibliothek"-Konfigurationen Ihrer Projekte. Manchmal kommt es bei verschiedenen Konfigurationen zu unterschiedlichem Verhalten, aber das muss von Fall zu Fall geklärt werden.

Answer 4

Eine einfachere Möglichkeit, große Programme zu verwalten, besteht darin, sie in kleinere, handhabbare Teile zu zerlegen. Ein Programm kann in eine Shell und Module unterteilt werden, die die Shell um weitere Funktionen erweitern. Große Programme wie Visual Studio und Outlook verwenden alle die gleichen Konzepte. Versuchen Sie diesen Ansatz, um ein besser wartbares und robusteres Programm zu erstellen.