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:
IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6
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:
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).
Normal gibt es Unterordner, wo das alles etwas aufgeräumt ist.
Nö, nicht bei Eager Dependency Loading.
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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?
// 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?
IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6
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
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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:
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.
IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6
VS bietet Pre-build und Post-build Events. Damit kann man sehr viel automatisieren.