Wenn man seine Anwendung mit VS startet gibt es im Release-Ordner bei mir folgendes Ergebnis. (Siehe Bild). Alles landet in einem Ordner ohne Unterordner. Soweit ja auch OK. Während der Entwicklung habe ich da gar nicht weiter drüber nachgedacht.

Jetzt will ich die Anwendung installieren.
Mit Inno-Setup gehe ich den Assistenten durch und wähle dann den Ordner aus. Inno Setup packt dann alle Dateien zusammen. Nach der Installation sieht der Installationsordner dann genauso aus, wie der Release-Ordner + halt die unins000.dat und unins000.

Bei keiner Anwendung habe ich bislang eine solche Struktur mit solchen Dateien gesehen. Normal gibt es Unterordner, wo das alles etwas aufgeräumt ist.
Ich habe mal die .pdb und .xml-Dateien entfernt. Damit sieht das schon eher aus, wie bei anderen Anwendungen. Meine Anwendung scheint auch zu funktionieren, so dass die entfernten Dateien scheinbar unnötig sind. (Ist dem so, wozu werden sie dann überhaupt erstellt?)
Jetzt würde ich die .dll-Dateien in einen eigenen Ordner packen wollen. Das macht die Anwendung aber nicht mit (Logisch)

Jetzt meine Fragen:
- Wie kann man eine ordentliche Ordnerstruktur erstellen?
- Wie kann ich sicherstellen, dass die entfernten Dateien wirklich nicht benötigt werden? (Ich habe die Anwendung natürlich getestet)
- Kann man die vorhandenen .dlls verkleinern. Ich greife ja vermutlich nur auf einen Bruchteil der darin enthaltenen Funktionen zu.

Prinzipiell ist dieses Thema gut dokumentiert in der Dokumentation von Microsoft.
Viele Dinge Deiner Fragen kann man aber nicht pauschal beantworten, weil diese von der Applikation und den Anforderungen unterliegen:
Assemblys in .NET
[FAQ] Ordnerstruktur für .NET Projekte
Application publishing - .NET
Single file deployment and executable
Trim self-contained applications - .NET

Wie man Architektur angeht ist abgesehen von Best Practises einfach Erfahrungssache.

Aber Allgemein:

Zitat

Bei keiner Anwendung habe ich bislang eine solche Struktur mit solchen Dateien gesehen.

Das ist bei jeder .NET Anwendung so (und übrigens auch bei den meisten Java Anwendungen, weil das Grundprinzip unter der Haube ähnlich funktioniert).

Zitat

Normal gibt es Unterordner, wo das alles etwas aufgeräumt ist.

Nö, nicht bei Eager Dependency Loading.

Zitat

Jetzt würde ich die .dll-Dateien in einen eigenen Ordner packen wollen.

Warum, was hast Du davon? Es ändert sich für dich nichts, ausser die Optik, wenn jemand in den Ordner schaut.
Beschreib mal Deine Anforderung, dann kann man Dir Lösungen anbieten. "Ich will eine andere Ordnerstruktur" ist halt keine Anforderung, die mit einfachen Mitteln in .NET umsetzbar ist.
Dass Du nun implizit ausdrückst, dass die Standard-Output Struktur nicht vernünftig sei....

Und das Thema im Allgemeinen geht man in der .NET Welt völlig anders an, zB mit Trimming und Merging.
App Trimming in .NET 5
Für Legacy Loading gibts Assembly Bindings, die aus einem private Path geladen werden können.
Gleich aber die Info, dass das in der neuen .NET Welt nicht funktioniert, weil es keine App Domain mehr gibt.

Ich behaupte mal ins Feld, dass Du keine Applikation schreibst, die von einer eigenen Struktur profitieren würde.
Das Customizing wird Dich eher viel Zeit kosten - bei exakt null Nutzen.

Größere Anwendungen haben entsprechende Mechanismen, zB Plugin Frameworks, die das einem alles abnehmen.
Für die meisten Anwendungen aber Overkill.

Danke Abt.

Ich denke das Thema "Application publishing - .NET" und "Trim self-contained applications - .NET" ist das was ich brauche.
Das bezieht sich aber alles auf .Net Core, bzw. .Net 5, bzw. letzteres ist sogar nur dafür verfügbar, bei erstem ist es wohl das was ich suche?

Zitat

// https://docs.microsoft.com/de-de/dotnet/core/deploying/trim-self-contained Hinweis Beim Kürzen handelt es sich um experimentelles Feature in .NET 3.1 und .NET 5.0. Kürzen ist nur für Anwendungen verfügbar, die eigenständig veröffentlicht werden.

Mein Projekt ist noch .Net 4.8. Suche ich nach was anderem?

Wenn ich dich richtig verstehe und es dir um die pdb und xml Dateien geht: preventing-referenced-assembly-pdb-and-xml-files-copied-to-output

Zitat von Little Tester

Mein Projekt ist noch .Net 4.8. Suche ich nach was anderem?

Trimming / Tree Shaking ist mit .NET Framework nicht mit offiziellen Mitteln möglich.
Steht ja auch da, dass dies nur mit .NET Core ab einer gewissen Version möglich ist.

Danke Jompikumpi. Der Veröffentlichungsassistent sortiert diese Dateien bereits aus. Das ist gut. Ich habe auch rausgefunden, wie man den vernünftig nutzt und die .deploy-Endungen weglassen kann. Das erzeugt bereits ein richtig gutes Ergebnis. Noch störe ich mich an zwei Dingen:

- Die .application-Datei (NICHT .exe-Datei), die nicht funktioniert und auch nicht gebracht wird.
- Das automatisch die Unterordner "Application Files\Systeminventory_1_0_0_0" erstellt und dort die Dateien abgelegt werden. Ich kann zwar den Sinn dahinter verstehen, nämlich dass jede Version erhalten bleibt, aber ich müsste dann den Pfad des Installers dann immer anpassen.
- Bezugnehmend auf den vorherigen Punkt: Ist es möglich (ggf. durch eine Erweiterung) beim Veröffentlichen einer neuen Version das gesamte Projektverzeichnis extra abzuspeichern, also den Stand zu sichern? Das wäre super.

Zugegeben: Das sind alles Luxusprobleme. Man kann das alles von Hand machen. Automatisch wäre halt schöner.

@Abt: Ja, habe ich gelesen. Hätte aber sein können, dass es unter .Framework 4.x einfach anders heißt und / oder anders geregelt ist, ggf. externe Erweiterungen gibt. Deswegen hatte ich nochmal gefragt.

Ich habe jetzt auch schon mehrfach gemerkt, dass .Net 5.0 einiges anders macht und verbessert. Mit Abschluss dieser Version und dem erscheinen von VS 2022 und .Net 6 (=LTS-Version) wird umgestiegen.

VS bietet Pre-build und Post-build Events. Damit kann man sehr viel automatisieren.

How to: Specify build events (C#)