Runtime: Single exe eigenständige Konsolen-App

Dieses Szenario wird derzeit nicht unterstützt. Behalten Sie das https://github.com/dotnet/corert Repo im Auge, um Arbeiten zu erhalten, die auf diesem Weg führen.

CoreRT ist der richtige Ort, um nach dieser Lösung zu suchen.

Vielen Dank. Es sieht so aus, als ob CoreRT genau das ist, wonach ich gesucht habe.

Für andere, die darüber stolpern könnten, lesen Sie hier

Ich möchte diese Funktion speziell ohne vorherige Kompilierung. Ich möchte kein Corert - ich möchte das gleiche Jit- und Debugging- und Laufzeiterlebnis wie eine normale eigenständige App -, aber ich möchte auch nicht vier Dateien pro Dienstprogramm verteilen. Das ist unpraktisch für alle, die das Dienstprogramm nutzen möchten. Ich möchte nur, dass es gepackt wird und von einer einzigen Exe ausgeführt wird. Dies veranlasst mich, für viele Dienstprogramme .NET Framework anstelle von .NET Core zu wählen.

.NET Framework "betrügt", da bereits viele Dateien im Betriebssystem vorhanden sind.
Sie können dasselbe mit .NET Core erreichen, indem Sie maschinenweit gemeinsam genutzten .NET Core installieren, wenn Sie dies wünschen.

Das Refactoring von CoreCLR, um alle seine Dateien zu einer zusammenzuführen (inkl. Native + verwaltet), ist keine triviale Arbeit, und ich denke nicht, dass das Szenario für zu viele Kunden so interessant ist.

Der Unterschied besteht darin, dass auf jedem Windows-Computer garantiert .NET Framework, nicht jedoch .NET Core vorhanden ist. Wenn es also keinen besonderen Grund gibt, der die Bereitstellung komplexer macht, werde ich wahrscheinlich dort bleiben.
Ich denke, Kunden schreiben normalerweise keine einzelnen Exe-Dienstprogramme. Vielleicht eines Tages. :-)

es sei denn, es gibt einen besonderen Grund, der es wert ist, die Bereitstellung komplexer zu gestalten

Es gibt VIELE Gründe, .NET Core gegenüber .NET Framework vorzuziehen. Leistung, Modularität, Wartungsfreundlichkeit, Isolation usw. Und das ignoriert die plattformübergreifende Funktionalität.

Ein einziges Exe-Dienstprogramm zu haben, ist meistens ein kosmetisches Problem. Es gibt keinen wirklichen Funktionsunterschied (für alle Beteiligten), wenn die ausführbare Datei eine einzelne Datei oder ein einzelner Ordner mit einer Handvoll Dateien ist.

@mellinoe Oh, ich stimme für Projekte im Allgemeinen zu, das ist sicherlich wahr. In den kleinen Dienstprogrammen, in denen diese Kosmetik wünschenswert ist, hat .NET Framework bisher gute Arbeit geleistet. Ich bin damit einverstanden, dass es im gleichen Sinne kosmetisch ist wie die Angabe einer Montagefirma und einer Copyright-Meldung. Aber eine kosmetische Sache zu sein, lässt mich es nicht weniger mögen. Offensichtlich keine Priorität hier, das ist durchaus verständlich.

Möglicherweise verwandt: https://github.com/dotnet/core/issues/600

Es ist meistens nicht kosmetisch. Stellen Sie sich vor, ich möchte eine Anwendung verteilen, in die mehrere Komponenten eingebettet sind, z. B. Idsrv4 oder RavenDb + meine eigenen Inhalte. Sie sind abhängig von den Aspnet-Kernbits. Dies alles funktioniert einwandfrei, solange sie von derselben Version des Aspnet-Kerns abhängen. Sobald einer von ihnen auf die nächste Version vorwärts rollt, wird es wahrscheinlich nicht mehr funktionieren. Wenn OTOH ich jede Komponente auf eine einzelne DLL reduzieren könnte, verschwindet das Problem.

Beachten Sie, dass es mehr technische Probleme gibt, als nur, dass ILMerge nicht funktioniert. Die Laufzeit selbst ist grundsätzlich in viele Dateien unterteilt, und es gibt auch Zusatzdateien wie den CLR-Host, die Textdatei für Laufzeitabhängigkeiten und vieles mehr. Der einzige Grund, warum eine ausführbare Datei mit einer einzelnen Datei in der Vergangenheit funktioniert hat, ist, dass auf .NET Framework, eine globale systemweite Installation, vertraut wurde. Der Vergleich der beiden Szenarien ist etwas unfair, da .NET Framework nicht wirklich über eine "eigenständige" Option verfügt.

Dies alles funktioniert einwandfrei, solange sie von derselben Version des Aspnet-Kerns abhängen. Sobald einer von ihnen auf die nächste Version vorwärts rollt, wird es wahrscheinlich nicht mehr funktionieren.

Das ist nicht wirklich wahr. Sie können mehrere verschiedene Anwendungen für verschiedene Laufzeitversionen veröffentlichen und diese dann in derselben "Über-App" bündeln. Sie können ihre Abhängigkeiten einfach nicht in einem einzigen Ordner mischen. Selbst wenn Sie die Framework-abhängige Veröffentlichungsoption verwenden, können Sie Versionen mischen und anpassen. Ich verstehe, dass dies weniger bequem ist als buchstäblich eine einzelne Datei zu haben und Dinge wie das Einbetten einer Exe als Ressource in das PE verhindern könnte. Ich bin mir jedoch nicht sicher, ob Sie sich darauf beziehen, da Sie die Datei wahrscheinlich noch extrahieren müssen, um sie auszuführen, was Sie auch mit einem Verzeichnis tun könnten.

Ich meinte nicht Laufzeitversion, ich weiß, dass das nicht funktionieren wird. Ich meine, was passiert in meinem Szenario, wenn jede Komponente von [email protected] abhängig [email protected] aktualisiert

Neben dem relevanten Punkt bereitstellbare Binäreinheit den Betriebsaufwand reduziert. Es verringert die Wahrscheinlichkeit, dass bei einer Bereitstellung ein Fehler auftritt, verringert die Belastung, kognitiv zu schätzen, was Sie ausgeliefert haben, und verringert die Konfiguration für Ops-Tools, sei es die Skripterstellung oder den gewünschten Status.

Ich schätze, dass das Werkzeug dotnet im Entstehen begriffen ist und gerade erst 2,0 erreicht hat, aber im Vergleich zu Alternativen wie Golang fehlt diese Funktion schmerzlich. Bitte erwägen Sie, es der Roadmap hinzuzufügen.

Als lib-Entwickler würde ich es begrüßen, ILMerge wieder in Core zu haben. 👍

Dotnet.exe ist eine einzelne Datei. NuGet.exe ist eine einzelne Datei. Ich denke, Kosmetik ist wichtig, und eine einzelne Datei-Exe ruft Einfachheit auf eine Weise hervor, wie es ein Ordner mit 100 Dateien nicht tut! Es wäre großartig, einen Weg zu finden, dies mit dotnetcore zu erreichen

Ich nahm an, dass dies möglich war, und kam nach einigen Wochen Arbeit, um das CLI-Konsolentool auf einer einzigen .exe zu veröffentlichen ... ähm, im Moment kann ich nicht einfach eine einzige * .exe bekommen?
Ich dachte, das wäre der Sinn von eigenständigen Kern-Apps?

@ PRIMETSS

Ich dachte, das wäre der Sinn von eigenständigen Kern-Apps?

Der Sinn von in sich geschlossenen Apps besteht darin, dass sie in sich geschlossen sind, dh, dass .Net Core nicht auf dem Zielcomputer installiert sein muss, da die App selbst alles enthält, was sie zum Ausführen benötigt.

Um eine solche App bereitzustellen, müssen Sie ein gesamtes Verzeichnis von Dateien kopieren. Nur eine einzige Datei würde die Bereitstellung vereinfachen, aber das war's, es ist auch ohne diese eine eigenständige App.

Für große und serviceähnliche Apps ist dies möglicherweise nicht so wichtig, aber es ist wichtig, dass Befehlszeilentools und kleine Apps so einfach wie möglich und COPY-bereitstellungsfreundlich sind.

Ich schreibe regelmäßig Befehlszeilentools in .NET und wenn sie als 1 EXE vorliegen, werden Upgrades / Bereitstellungen / Verpackungen einfacher. Ich packe immer alle .config und andere erforderliche Dateien in EXE.

Stellen Sie sich diese Single-EXE als Mini-Container vor. Hier gelten fast alle Vorteile von containergestützten Bereitstellungen.

Das ist einfach schrecklich. Ich frage mich, warum dies während des Designprozesses genehmigt wurde. Ich möchte Ihre Bewerbung an einen Ihrer Kunden verteilen und dann viel Glück für ihn, um herauszufinden, was zu öffnen ist:

Das ist einfach hässlich und ein komplettes Durcheinander

Laufzeit/
MyProgram.exe
MyLib.dll

Dies wäre eine viel bessere Idee gewesen

Sogar Java geht damit besser um:

Ja, ich habe in die gleiche Richtung gedacht, da die eigenständigen Apps die Laufzeitdateien enthalten müssen (offensichtlich!) (Und wir haben keine Möglichkeit, diese zusammenzuführen), dann dachte ich auch, dass nur eine Ordnertrennung möglich wäre Seien Sie ordentlicher, und ja, ich denke auch, dass die Laufzeitdateien in einem Laufzeitordner gespeichert werden sollten. Jeder, der versucht, ein im Kern geschriebenes Befehlszeilentool zu verwenden, würde es zumindest etwas intuitiver finden als das, was ausgeführt werden soll.

@Scellow @PRIMETSS Ich muss zustimmen

Wie ist das überhaupt noch ein Problem? Die Nachfrage ist dafür durch das Dach.

Ja zu diesem separaten Ordner mit dem Zusatz, diesen in einen Bin zu komprimieren und zwei Dateien zu haben, die exe und den Bin. Einfache Verteilung.

Ein weiteres +1 zum erneuten Öffnen und als Feature.

Ich hatte erwartet, dass die eigenständige Bereitstellung in sich geschlossen ist, und fand meinen Weg hierher. Ich würde das auch gerne sehen.

Wie kann jemand sagen, dass dies nur ein kosmetisches Problem ist? (Nur Framework-Entwickler ...)
Niemand hat an Werkzeuge gedacht, die nicht installiert sind? (.NET hat dll-hell gelöst und .net core bringt es zurück)

Ich möchte nur, dass mein Befehlszeilen-Tool in sich geschlossen ist.

Das ist schlecht, wirklich schlecht!

+1

+1 Ich habe gerade versucht, benutzerdefinierte Aktivitäten in Azure Batch auf einem Cluster ohne .net-Kernlaufzeit auszuführen, und es kann nicht mit der hohen Anzahl von Dateien umgehen, die die "in sich geschlossene" Version erstellt.

Total size of resourceFiles cannot be more than 32768 characters

Dies ist keine offizielle Lösung, aber sie könnte nützlich sein. Ich bin der Autor von Warp, einem Tool, mit dem Sie eigenständige einzelne Binäranwendungen erstellen können: https://github.com/dgiagio/warp

Ich denke, Warp ist im Grunde das, wonach jeder hier sucht! Es geht nur um die Fähigkeit, eine einzelne Exe-Datei zu haben, egal was sich im Hintergrund befindet, nichts weiter. Denken Sie an NuGet-Pakete: Es ist eine einzelne .nuget-Datei und das war's; Es ist nicht komplexer als eine Datei, die andere Dateien verpackt.

Warp ist eine hackige Lösung, das wollen wir nicht

Was wir wollen ist:

dotnet publish --self-contained -c Release -r win10-x64

Und es produziert:

App.exe
runtime/

Oder besser wie GO / Rust etc.

App.exe

Alles andere ist nicht erwünscht

Warp erzeugt eine App.exe ... Wie ist es hacky? Offensichtlich ist es nicht Teil des Frameworks, sondern erreicht das Ziel "one exe file".

Dies ist, was ich meine, es sollte Standardverhalten sein, keine Drittanbieterlösung (ich denke)

Warp ist ein Genuss. Danke für deine Arbeit @dgiagio!

+1

Ich würde sehr gerne eine Art Einzeldateiarchiv sehen, das die ausführbare Datei und alle Abhängigkeiten bündelt. Die nativen müssen nicht enthalten sein - ich denke, es ist vollkommen in Ordnung, wenn der Dotnet-Kern auf dem System installiert sein muss. Etwas sehr ähnliches wie Javas JAR-Dateien. Eine Dar-Datei?

Etwas wie:
dotnet veröffentlichen - in sich geschlossen
dotnet run - eigenständige MyApp.dar

Es sieht so aus, als ob es jetzt einen Vorschlag dafür gibt: https://github.com/dotnet/designs/pull/52/files?short_path=28dba55

Hier ist das Tracking-Problem: https://github.com/dotnet/coreclr/issues/20287

Außerdem hat @shanselman einen Blog-Beitrag zur Warp-Lösung:

https://www.hanselman.com/blog/BrainstormingCreatingASmallSingleSelfcontainedExecutableOutOfANETCoreApplication.aspx

Ich habe den Vorschlag gelesen und Folgendes gesehen:

Das ist nicht das, was ich mir vorgestellt habe, das klingt nach einem langsamen Prozess, bei dem einfach alles gezippt wird.
Ich dachte, der gesamte Code würde in einer einzigen ausführbaren Datei / DLL zusammengeführt? oder vielleicht habe ich etwas im vorschlag verpasst?

@RUSshy Fragen Sie nach dem nativen Kompilieren des gesamten verwalteten Codes und dem Verknüpfen aller Elemente, um eine ausführbare Datei zu erhalten (wie in CoreRT)? Dies ist kein Ziel für die aktuelle Einzeldateiarbeit in .Net Core.

Es werden jedoch Lösungen zur Reduzierung der Festplattenextraktion und der Startzeit vorgeschlagen (z. B. Laden bestimmter Dateitypen direkt aus dem Bundle , Wiederverwenden extrahierter Dateien ). Die Entwicklungsstadien der Single-File-Lösung werden hier beschrieben.

CC: @jeffschwMSFT

Warum müssen die Dateien extrahiert werden? Wir sind in .NET mit ILMerge damit durchgekommen.

@ phillip-haydon, wie hier beschrieben, erreichen ILMerge- und Single-File-Lösungen unterschiedliche Ziele.

ILMerge kombiniert die IL aus vielen Assemblys zu einer, verliert dabei jedoch die ursprüngliche Identität der zusammengeführten Assemblys. Dinge wie die Verwendung von Reflektion basierend auf den ursprünglichen Baugruppennamen schlagen also fehl. Apps können ILMerge weiterhin verwenden, wenn sie diese Änderung tolerieren können.

CoreRT ist etwas anderes, eine AOT-Kompilierung Ihres .NET-Codes, es sieht interessant aus, ist aber noch nicht fertig (ich wünschte, MS würde sich darauf konzentrieren und mehr Ressourcen zuweisen. Genau das wollen die Leute und warum sie zu GO gewechselt sind )

Wie auch immer, ich habe kein technisches Wissen, um über die Details zu sprechen, aber der Anwendungsfall ist:

Veröffentlichen Sie eine einzelne in sich geschlossene ausführbare Datei, und genau das, nichts gezippt, nichts extrahiert, kein Overhead, nur die ausführbare Datei

@ swaroop-sridhar hast du ein Beispiel dafür, wie es für Dotnet Core unter Linux funktioniert? Laut https://github.com/dotnet/ILMerge/blob/master/ILMerge/ILMerge.csproj#L13 handelt es sich um ein Windows / Mono-Projekt.

@thefringeninja ILMerge ist ein Windows-Tool. Ich kenne keine Pläne, ILMerge auf andere Plattformen zu portieren.
Die Single-File- Lösung wird plattformübergreifend implementiert. Dies ist im Entwicklungsprozess.

@karelz @mellinoe
Bereitstellen Bereitstellen Bereitstellen!Wenn einzelne oder weniger wie 1-3 Dateien, ist das besser für die Bereitstellung (Inlcude Publish, Update)!

CoreRT ist AOT
aber ppl wollen AOT?
Das Projekt (CoreRT) ist immer nicht bereit zu verwenden (ab 2014). Jetzt ist 2019! ( Ca. 5 Jahre dauern )
Was für wertvolle 5 Jahre für eine Pragrammsprache!Das CoreRT hat sogar keinen Plan für die nächste Veröffentlichung !!!ppl noch 5 Jahre warten lassen?

@ swaroop-sridhar Das ist bedauerlich. ILMerge / ILRepack eignet sich hervorragend für Bibliotheksentwickler, um das Problem der Diamantabhängigkeit zu vermeiden.

Es gibt Pläne, es in .NET Core 3.0 zu unterstützen - @richlander kann Sie über den Status aktualisieren.
Es wurde in .NET Core 3.0-Blogposts erwähnt - z. B. hier: https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/ in "Side-by-" Seite und App-lokale Bereitstellung ".
Lesen Sie auch: https://www.hanselman.com/blog/BrainstormingCreatingASmallSingleSelfcontainedExecutableOutOfANETCoreApplication.aspx

.net sollte nicht alle diese Hacks benötigen, um eine kleine, in sich geschlossene ausführbare Datei zu erstellen. Es sollte ein Standardverhalten sein, Sie werden von GO lebendig gefressen, Rust kommt auch, konzentrieren Sie sich auf CoreRT oder ILMerge, .net Core-Apps sind es bereits Der Start dauert lange, da alle Dateien geladen werden müssen. Fügen Sie mit zip / unzip nicht mehr belauscht hinzu, wie im Vorschlag erwähnt. Dies ist nicht der richtige Weg

.net sollte nicht alle diese Hacks benötigen, um eine kleine, in sich geschlossene ausführbare Datei zu erstellen. Es sollte ein Standardverhalten sein, Sie werden von GO lebendig gefressen, Rust kommt auch, konzentrieren Sie sich auf CoreRT oder ILMerge, .net Core-Apps sind es bereits Der Start dauert lange, da alle Dateien geladen werden müssen. Fügen Sie mit zip / unzip nicht mehr belauscht hinzu, wie im Vorschlag erwähnt. Dies ist nicht der richtige Weg

Wie du magst, sollte .net nicht lebend brauchen, weil ppl Java hat.
go oder rust oder dlang sollten das Build-Ziel für ein einzelnes ausführbares Programm nicht unterstützen, da sie über Fuck Zip / Unzip verfügen!

@ Russhy

.net sollte nicht alle diese Hacks benötigen, um eine kleine, in sich geschlossene ausführbare Datei zu erstellen

Einverstanden. Gleichzeitig bietet .NET bestimmte Funktionen gegenüber anderen Sprachen, die sich nur schwer mit den Anforderungen eines statischen Linkers vereinbaren lassen (z. B. spontane Codegenerierung, Reflexion, Datenbindung usw.). Wir haben versucht, diese Funktionen in Szenarien auszuschließen, in denen die Verknüpfung einzelner Dateien / statischer Dateien wichtig ist. Wir haben aus Kundenfeedbacks gelernt, dass sich das Ergebnis nicht mehr wie .NET anfühlt, auch weil die Anzahl der Bibliotheken, die Sie aus dem Ökosystem verbrauchen können, drastisch abnimmt.

Es ist also ein schwieriges Problem, einen Linker richtig zu machen, der keine Kompromisse bei der Genauigkeit der Funktionen eingeht, die wir alle in .NET abhängig und geliebt haben. Um dies zu lösen, experimentieren wir mit verschiedenen Ansätzen. Sie nennen das Hacks, ich nenne das aufgeschlossen und bereit, über den Tellerrand hinaus zu denken. Es ist jedoch nicht die richtige Antwort, .NET blind in Go / Rust / C ++ zu verwandeln.

Wir haben versucht, diese Funktionen in Szenarien auszuschließen, in denen die Verknüpfung einzelner Dateien / statischer Dateien wichtig ist. Wir haben aus Kundenfeedbacks gelernt, dass sich das Ergebnis nicht mehr wie .NET anfühlt, auch weil die Anzahl der Bibliotheken, die Sie aus dem Ökosystem verbrauchen können, drastisch abnimmt.

Hat das Team darüber nachgedacht, eine separate Version von .net zu erstellen, die auf native Entwicklung und eingeschränkte Umgebungen ausgerichtet ist, wie es Jetbrains mit Kotlin JVM / Kotlin NATIVE getan hat?

Wie Sie sagten, ist der Versuch, .net in alle Anwendungsfälle zu integrieren, nicht die klügste Option, sodass eine bestimmte Variante die richtige Antwort auf dieses Problem sein könnte

Und tbh, afaik, dieses Problem gab es vor dem .net-Kern nicht wirklich, da jede Windows-Installation bereits ein .net-Framework hatte. Sie mussten also nur Ihre wenigen KBs exe verteilen, und was mich ärgert, ist, dass niemand über diese Art nachgedacht zu haben scheint Dies ist ein Problem beim Entwerfen des .net-Kerns, der im Grunde ein Umschreiben des .net-Frameworks war. Aus diesem Grund sage ich, dass diese genannten Optionen einfache Hacks sind. Sie sind hier, um Designfehler zu beheben

Nach dem Lesen von https://github.com/dotnet/designs/blob/master/accepted/single-file/staging.md scheint es weitere Schritte für den Vorschlag zu geben, und er endet nicht bei zip / unzip, das ist also nicht der Fall ein verlorener Kampf, hoffentlich kann das Team mit etwas Leichterem kommen, was in diesem Dokument erwähnt wird, gut!

Aus diesem Grund bleibt Windows ein Spielzeugbetriebssystem.

@kjkrum Dinge wie was?

@cryru ist es, was die Leute sagen, wenn sie nicht wissen, was sie tun.

@Cryru Dinge wie die unbewusste Ablehnung der sehr realen Notwendigkeit, dies zu tun. Nahezu jedes andere existierende Build-System erstellt nicht nur eine statisch verknüpfte ausführbare Datei, sondern entfernt auch nicht verwendete Teile von Abhängigkeiten. Das Entfernen von Abhängigkeiten ist seit mindestens einem Jahrzehnt ein Standardmerkmal. statische Verknüpfung seit der Erfindung der Complier.

@Cryru Dinge wie die unbewusste Ablehnung der sehr realen Notwendigkeit, dies zu tun. Nahezu jedes andere existierende Build-System erstellt nicht nur eine statisch verknüpfte ausführbare Datei, sondern entfernt auch nicht verwendete Teile von Abhängigkeiten. Das Entfernen von Abhängigkeiten ist seit mindestens einem Jahrzehnt ein Standardmerkmal. statische Verknüpfung seit der Erfindung der Complier.

Zustimmen, Dies hängt tatsächlich mit der Position von C # -Programmen im Betriebssystem zusammen.
C # -Programme können nicht immer zu erstklassigen Bürgern werden.Nur um die zweite Klasse zu sein.

Dies ist behoben.
TLDR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

Einzelheiten:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-executeables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

Dies ist behoben.
TLDR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

Einzelheiten:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-executeables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

In welcher Version von Dotnet-Core wurde diese Funktion hinzugefügt? Ich verwende 3.0.100-preview5-011568 und habe diesen Fehler erhalten:
error MSB4030: "/p:PublishSingleFile=true" is an invalid value for the "SelfContained" parameter of the "ResolveFrameworkReferences" task. The "SelfContained" parameter is of type "System.Boolean".

LE: Eigentlich funktioniert es, es scheint nur, dass es einen Syntaxfehler in https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md gibt, der besagt, dass mit dotnet publish -r win10-x64 --self-contained /p:PublishSingleFile=true und ist tatsächlich ohne Hinzufügen von --self-contained .

Danke @mihaimyh Ich werde den Tippfehler im Design-Dokument beheben.

Ich bin immer gegen die Verwendung von Zip / Unzip-Lösung für
weil dies das nächste Problem verursachen wird.
So reduzieren Sie die Größe der Single-Exe-Datei!

Tatsächlich sollte IL-Merge von Anfang an auf ähnliche Weise verwendet werden.

Es sollte keine Debatte geben, dies ist Zeitverschwendung, niemand hat nach dem Zip / Unzip des Ganzen gefragt, und dennoch kamen sie mit diesem Design und verschwendeten ihre und unsere Zeit

Die Leute fragen nach einer einzelnen ausführbaren Datei und AOT, verschwenden Sie nicht unsere Zeit mit Microsoft

Ich möchte ausdrücklich eine einzelne Datei ohne AOT. Ich bevorzuge die JIT-Fähigkeit, damit ich Reflection, Generics und zur Laufzeit generierten Code verwenden kann.

Ich denke, MS will nicht hören, ok

Ich bin immer gegen die Verwendung von Zip / Unzip-Lösung für
weil dies das nächste Problem verursachen wird.
So reduzieren Sie die Größe der Single-Exe-Datei!

Ich bin mir nicht sicher, ob ich verstehe, als ob sein Reißverschluss bereits komprimiert ist. Oder meinen Sie die Reduzierung redundanter Abhängigkeiten und damit die Reduzierung der Größe vor der Komprimierung?

Die Negativität nicht verstehen. Ich habe es noch nicht anders als Schnelltest verwendet. Anscheinend funktioniert die einzelne ausführbare Datei jedoch gut für die Situation, in der eine App auf dem Client oder als CLI-Tool bereitgestellt wird. An dieser Stelle halte ich diese Funktion für nützlich. Abgesehen davon sehe ich in Dev oder einer anderen Umgebung keinen Anwendungsfall dafür, also funktioniert das, was sie getan haben, als Lösung für den Moment gut.

@ Russhy

Ich denke, MS will nicht hören, ok

Im Gegenteil, sie fordern und sammeln eine breite Palette von Anwendungsfällen, die Sie in verwandten Themen sehen können. Ihre Meinung ist wichtig, aber die Meinungen anderer in der Community sind genauso wichtig, und Sie sollten Microsoft nicht verspotten, wenn Sie ihnen zuhören.

Aufgrund Ihrer Aussage haben Sie mich möglicherweise für Microsoft gehalten. Ich bin nur ein Community-Mitglied wie Sie, das in keiner Weise für Microsoft spricht.

Ich bin immer gegen die Verwendung von Zip / Unzip-Lösung für
weil dies das nächste Problem verursachen wird.
So reduzieren Sie die Größe der Single-Exe-Datei!

Ich bin mir nicht sicher, ob ich verstehe, als ob sein Reißverschluss bereits komprimiert ist. Oder meinen Sie die Reduzierung redundanter Abhängigkeiten und damit die Reduzierung der Größe vor der Komprimierung?

Wenn Sie WebApi oder MVC oder ConsoleApp verwenden, schreiben Sie eine HelloWorld! Du weißt genau was ich meine.
Die gepackte Datei ist zu groß. Sie bringt zu viel Code, wird aber niemals ausgeführt.
Wenn IL-Merge-Methoden den nicht verwendeten Code-Zweig reduzieren.

Ja sicher, ich habe eine Konsole HelloWorld gemacht und ja sicher, es ist 68K

Das nicht in sich geschlossene war 67K
Aber seine C # nicht Montage. Wenn ich eine <1K HelloWorld wollte, warum dann c # verwenden?
Größere Apps verwenden mehr Framework, daher ist der Code an einem bestimmten Punkt benutzerdefinierter als das Framework.
Sind wir wirklich besorgt über ein paar 100K? Wenn ja, verwenden Sie kein Framework und verbringen Sie die Zeit damit, alles von Grund auf neu zu schreiben?
Was vermisse ich hier?

Ich bin immer gegen die Verwendung von Zip / Unzip-Lösung für
weil dies das nächste Problem verursachen wird.
So reduzieren Sie die Größe der Single-Exe-Datei!
Wenn Sie WebApi oder MVC oder ConsoleApp verwenden, schreiben Sie eine HelloWorld! Du weißt genau was ich meine.
Die gepackte Datei ist zu groß. Sie bringt zu viel Code, wird aber niemals ausgeführt.
Wenn IL-Merge-Methoden den nicht verwendeten Code-Zweig reduzieren.

@sgf gibt es hier zwei etwas getrennte Probleme:

• Wie kann ich den Code für eine App reduzieren?
• Wie packe ich die App in eine einzelne Datei?

Zur Code-Reduzierung gibt es weitere verschiedene Techniken

• IL zusammenführen: Dies gilt nicht für alle Apps, da dabei die Assemblyidentität verloren geht. Dies ist kein Ziel für die aktuelle Single-Exe-Arbeit.
• Nicht verwendete IL trimmen: Der PublishTrimmed -Eigenschaft) integriert. Weitere Optimierungen im ILLinker sind in der Entwicklung.
• Zip / Unzip: dotnet Publish komprimiert die veröffentlichte einzelne Datei derzeit nicht, kann jedoch durchgeführt werden.

Wie packe ich die App in eine einzelne Datei?
dotnet Publish unterstützt das Veröffentlichen in einer einzelnen Datei - die veröffentlichte Datei ist so groß wie die App sonst.

In Bezug auf den generierenden nativen Code:

• Derzeit wird die Generierung von nativem Code über den sofort einsatzbereiten Compiler (Eigenschaft PublishReadyToRun ) unterstützt.
• Das Veröffentlichen über die AOT-Kompilierung ist großartig ( CoreRT ), aber noch nicht verfügbar. Auch bei der AOT-Kompilierung hängt die Größe der ausführbaren Datei von den Kompilierungsoptionen ab: Beispiel: Schließen wir das JIT für die Ausführung von generiertem Code usw. ein?

Ja sicher, ich habe eine Konsole HelloWorld gemacht und ja sicher, es ist 68K

Das nicht in sich geschlossene war 67K
Aber seine C # nicht Montage. Wenn ich eine <1K HelloWorld wollte, warum dann c # verwenden?
Größere Apps verwenden mehr Framework, daher ist der Code an einem bestimmten Punkt benutzerdefinierter als das Framework.
Sind wir wirklich besorgt über ein paar 100K? Wenn ja, verwenden Sie kein Framework und verbringen Sie die Zeit damit, alles von Grund auf neu zu schreiben?
Was vermisse ich hier?

Entschuldigung, wie ur img gezeigt, mit selbst contianed.Thats 68626KB, es ist ungefähr 68mb = 68KK, nicht nur 68K !!!
Wir brauchen nicht <1kb (mit Self Contianed Das ist unmöglich), <3000KB ist in Ordnung, akzeptieren.
Aber 68 MB sind mehr als 30X +
Du schreibst nicht immer nur ein HelloWorld-Programm !!!

Entschuldigung, spät in der Nacht Fehler mit den K's
Vielen Dank für die zusätzliche Erklärung / Info swaroop-sridhar, einige neue Schalter dort, die mir nicht bekannt waren.
Ich habe es gerade mit 3.preview 6 mit den folgenden Schaltern versucht

dotnet Publish -r RID / p: PublishTrimmed = true / p: PublishSingleFile = true
und jetzt auf 29.000K

Sicher, nicht alle Apps werden Hello World sein, aber für eine C # Core SelfContained App, die auch die Laufzeit enthält ... Persönlich bin ich nicht besorgt. Klar, ich verstehe, wenn Sie ein winziges Konsolentool schreiben, wäre es schön, es 3K zu haben. Aber warum sollte man dafür überhaupt C # verwenden?
Interessante Diskussion obwohl Jungs!

30mb LOL, ruf mich an, wenn es so etwas wie 1-3mb sein wird, die Laufzeit ist voller Blähungen, check GO, Leute migrieren in Wellen

https://www.jetbrains.com/lp/devecosystem-2019/

Sogar Kotlin fängt an, Anteile zu gewinnen, und mit Kotlin Native wurde c # beschämt

Und Swift kommt zu Windows https://forums.swift.org/t/swift-win32-programming/20686

Also hier ein paar Vorschläge:

• Option zum Entfernen der Reflexion hinzufügen
• Option zum Entfernen von JIT-Inhalten hinzufügen
• Optimieren Sie den C # -Code besser, damit Sie sich nicht auf JIT verlassen

30mb LOL, ruf mich an, wenn es so etwas wie 1-3mb sein wird, die Laufzeit ist voller Blähungen, check GO, Leute migrieren in Wellen

https://www.jetbrains.com/lp/devecosystem-2019/

Sogar Kotlin fängt an, Anteile zu gewinnen, und mit Kotlin Native wurde c # beschämt

Und Swift kommt zu Windows https://forums.swift.org/t/swift-win32-programming/20686

Also hier ein paar Vorschläge:

• Option zum Entfernen der Reflexion hinzufügen
• Option zum Entfernen von JIT-Inhalten hinzufügen
• Optimieren Sie den C # -Code besser, damit Sie sich nicht auf JIT verlassen

Ich denke das ist nicht fair. .NET wurde nicht zum Erstellen der kleinsten Einzeldateikonsolenanwendungen entwickelt. Wir verwenden es für Asp.Net-Websites und apis. Daher bringt das Framework selbst eine Menge Funktionen mit sich, zusätzlich zu Tonnen von Nuget-Paketen, die Sie einschließen können. Ich kann mir nicht vorstellen, dass es Bedenken gibt, wenn eine Webanwendung 50 oder mehrere hundert Megabyte groß ist. Das Hauptanliegen ist Geschwindigkeit, Speichernutzung und langfristige Wartbarkeit. Wen interessiert die Größe auf dem Server?

Wenn Sie nur eine kleine Konsolenanwendung mit einer Größe von einer MB erstellen möchten, verwenden Sie das richtige Tool für diesen Job. Anstatt sich darüber zu beschweren, dass eine Anwendung mit einem voll funktionsfähigen Framework, das in eine einzige Datei gepackt ist, selbst für eine "Hallo-Welt" mehrere zehn Megabyte groß ist, warum nicht zum Beispiel Rust wählen?

Microsoft hat von Anfang an und noch mehr in den letzten Jahren hervorragende Arbeit mit .NET geleistet. Vielen Dank dafür.

Was ist auf einen solchen Unsinn, Lügen und einen Mangel an Effizienz zu antworten?

Sie wissen nicht, wie falsch die .net-Kernrichtung war, und erst kürzlich haben sie begonnen, dies durch die Arbeit an Distribution / IL Merge / AOT zu erkennen

Und jetzt, um auf dem Web-Assembly-Wagen weiterzumachen, können sie das nicht, weil die .net-Laufzeit so RIESIG ist, dass sie keine Dateien mit angemessener Größe bereitstellen können

Und Sie haben sich immer noch an "Wer kümmert sich um die Größe des Servers?" Festgehalten. Diese Denkweise hat den "angeblich modernen" .net-Kern zu einem bereits veralteten und irrelevanten Tech-Stack gemacht

Microsoft macht mit .net keine großartige Arbeit, sie sind gescheitert, weil sie alte Leute für die Kompatibilität mit .net Frameworks zufrieden stellen wollten. Dies war einer ihrer Fehler

Tut mir leid, wenn ich unhöflich klinge, aber manchmal muss man sein, um Änderungen vorzunehmen

Entschuldigung, wenn ich aber unhöflich klinge

Du klingst unhöflich, Punkt. Das und Ihre Entlassungen und das Springen zu Schlussfolgerungen haben nicht den Effekt, überzeugend zu sein.

Entschuldigung, spät in der Nacht Fehler mit den K's
Vielen Dank für die zusätzliche Erklärung / Info swaroop-sridhar, einige neue Schalter dort, die mir nicht bekannt waren.
Ich habe es gerade mit 3.preview 6 mit den folgenden Schaltern versucht

dotnet Publish -r RID / p: PublishTrimmed = true / p: PublishSingleFile = true
und jetzt auf 29.000K

Sicher, nicht alle Apps werden Hello World sein, aber für eine C # Core SelfContained App, die auch die Laufzeit enthält ... Persönlich bin ich nicht besorgt. Klar, ich verstehe, wenn Sie ein winziges Konsolentool schreiben, wäre es schön, es 3K zu haben. Aber warum sollte man dafür überhaupt C # verwenden?
Interessante Diskussion obwohl Jungs!

sollte eine moderne Sprache nicht ein wenig Ambition haben, die Welt zu vereinen?
Möchten Sie, dass alle Entwickler zu Hause c # für C ++ schreiben? oder sie zu Go schieben, Kotlin, Swift?
Marktanteil und weitere Erosion c #?

.Net, weil plattformübergreifende Implementierung nicht die ersten 15+ Jahre der großen Entwicklungsmöglichkeit verpasst hat.
Aber jetzt ist .net wieder auf dem richtigen Weg.

Ja, wie ich schon sagte, ich bin mir nicht sicher, warum die Negativität.
.Net Core war nichts anderes als fantastisch, wenn Sie von Full Framework kommen. Und die .Net Standard + Core-Verschmelzungsvision ist meiner Meinung nach sinnvoll und fortschrittlich.

Der Vergleich von .NET mit GO oder einer anderen Sprache / einem anderen Framework ist sinnlos.
Wie auch immer, ich bin OUT zu diesem Thema, da ich denke, dass die Lösung, an der sie arbeiten und die sie für Single .exe verbessern, meine "Frage" von vor einigen Jahren ziemlich gut gelöst hat ... Gut genug für mich und entspricht meinen unmittelbaren Bedürfnissen.

Also danke Guys & Gals!

AUS

Ich möchte alle in diesem Thread an den Verhaltenskodex erinnern.

Es ist in Ordnung, anderer Meinung zu sein oder eine andere Meinung zu haben, aber bitte, lassen Sie uns höflich sein und dies als technische Diskussion ausdrücken. Keine Notwendigkeit, starke Worte zu verwenden.
Auch das Targeting von Ideen und Implementierungen mit Ihren Meinungen ist ein faires Spiel. Es ist jedoch nicht akzeptabel, Menschen hinter sich anzugreifen. Bitte lasst uns alle respektvoll miteinander umgehen, unterschiedliche Meinungen hören und starke Aussagen und beleidigende Kommentare unterlassen.

Außerdem möchte ich alle bitten, offen für andere Standpunkte und Meinungen zu sein. Bevor Sie ein Urteil fällen, ist es normalerweise gut, die andere Seite zu hören - es steckt oft eine Geschichte dahinter, warum die Dinge so sind, wie sie sind. Das Stöbern in Ideen und Lösungen, wenn man weiß, warum sie so sind, wie sie sind, ist normalerweise produktiver.

Vielen Dank!

Ich bin immer gegen die Verwendung von Zip / Unzip-Lösung für
weil dies das nächste Problem verursachen wird.
So reduzieren Sie die Größe der Single-Exe-Datei!
Wenn Sie WebApi oder MVC oder ConsoleApp verwenden, schreiben Sie eine HelloWorld! Du weißt genau was ich meine.
Die gepackte Datei ist zu groß. Sie bringt zu viel Code, wird aber niemals ausgeführt.
Wenn IL-Merge-Methoden den nicht verwendeten Code-Zweig reduzieren.

@sgf gibt es hier zwei etwas getrennte Probleme:

• Wie kann ich den Code für eine App reduzieren?
• Wie packe ich die App in eine einzelne Datei?

Zur Code-Reduzierung gibt es weitere verschiedene Techniken

• IL zusammenführen: Dies gilt nicht für alle Apps, da dabei die Assemblyidentität verloren geht. Dies ist kein Ziel für die aktuelle Single-Exe-Arbeit.
• Nicht verwendete IL trimmen: Der PublishTrimmed -Eigenschaft) integriert. Weitere Optimierungen im ILLinker sind in der Entwicklung.
• Zip / Unzip: dotnet Publish komprimiert die veröffentlichte einzelne Datei derzeit nicht, kann jedoch durchgeführt werden.

Wie packe ich die App in eine einzelne Datei?
dotnet Publish unterstützt das Veröffentlichen in einer einzelnen Datei - die veröffentlichte Datei ist so groß wie die App sonst.

In Bezug auf den generierenden nativen Code:

• Derzeit wird die Generierung von nativem Code über den sofort einsatzbereiten Compiler (Eigenschaft PublishReadyToRun ) unterstützt.
• Das Veröffentlichen über die AOT-Kompilierung ist großartig ( CoreRT ), aber noch nicht verfügbar. Auch bei der AOT-Kompilierung hängt die Größe der ausführbaren Datei von den Kompilierungsoptionen ab: Beispiel: Schließen wir das JIT für die Ausführung von generiertem Code usw. ein?

Bei Bedarf führen native DLLs dynamisch zu einem Namen zusammen: XXX.exe (UnManaged).
Verwenden der statischen Analyse zur Analyse beim Kompilieren der nativeDLLs (UnManaged) -Verbindung auf Funktionsebene.

api-ms-win-core-console-l1-1-0.dll
api-ms-win-core-datetime-l1-1-0.dll
api-ms-win-core-debug-l1-1-0.dll
api-ms-win-core-errorhandling-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-file-l1-2-0.dll
api-ms-win-core-file-l2-1-0.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-heap-l1-1-0.dll
api-ms-win-core-interlocked-l1-1-0.dll
api-ms-win-core-libraryloader-l1-1-0.dll
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-memory-l1-1-0.dll
api-ms-win-core-namedpipe-l1-1-0.dll
api-ms-win-core-processenvironment-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-string-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-timezone-l1-1-0.dll
api-ms-win-core-util-l1-1-0.dll
api-ms-win-crt-conio-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
api-ms-win-crt-process-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
aspnetcorev2_inprocess.dll
clrcompression.dll
clretwrc.dll
clrjit.dll
coreclr.dll
dbgshim.dll
dotnet-aspnet-codegenerator-design.dll
hostfxr.dll
hostpolicy.dll
mscordaccore_amd64_amd64_4.6.27317.07.dll
mscordbi.dll
mscorrc.dll
mscorrc.debug.dll
sni.dll
sos.dll
sos_amd64_amd64_4.6.27317.07.dll
ucrtbase.dll
...etc...

Wenn Sie gute Arbeit leisten, ist das Ergebnis möglicherweise 2-3 MB groß. Wenn ich sie alle direkt mit 7zip verpackt habe, dauert es ungefähr 4,85 MB. Jetzt bekommen wir XXX.exe

Entwickeln Sie den ähnlichen Link auf Funktionsebene mit IL-Merge.
Für eine verwaltete DLL wieder der gleiche alte Trick.
Zuletzt verwaltete DLL als PE.exe-Abschnitte einbetten (als .net-Abschnitt markieren).

Zum Reflektieren Analyse-DLL vom Reflektionstyp. Behalten Sie die Metadaten und die Art der Reflexion (einschließlich der Funktion) sowie alle baumabhängigen Elemente bei.

Ich entschuldige mich, ich möchte mir nicht mehr die Zeit nehmen, um an der Diskussion darüber teilzunehmen. Die Meinungen können nicht vereinheitlicht werden.
Zuerst hatte ich das Ergebnis erwartet. Aber jetzt sollte ich wahrscheinlich andere Programmiersprachen in Betracht ziehen, um meine Bedürfnisse zu erfüllen (vielleicht Dlang vielleicht Go, vielleicht Kotlin, vielleicht Nim oder vielleicht ist Rust die beste).

Danke für alles, rede mit mir. Entschuldigung für mein Nörgeln. aus

@sgf Ich denke, Sie haben einige gute Punkte gemacht und ich weiß, dass Sie sich für das Thema entschieden haben. Ich wollte nur sagen, dass ich glaube, dass die Funktionen, nach denen Sie fragen, in den nächsten Jahren für .NET Core verfügbar sein werden. Wenn Sie heute eine kleine Dateigröße erhalten möchten, ist dies möglicherweise möglich, wenn Sie auf Mono abzielen.

1. Mono unterstützt bereits die AOT-Kompilierung mit Linking, um die Dateigröße zu reduzieren. Dies ist ein Grund, warum mono für die Laufzeitimplementierung des Browsers .net ausgewählt wurde. https://www.mono-project.com/docs/advanced/aot/ und ich gehe davon aus, dass Blazor-Projekte deshalb einen Linker haben können.

2. Microsoft hat erklärt, dass sie ihre .NET-Laufzeiten zu einer "leistungsstarken" zusammenfassen möchten. Anstatt für einige Dinge Mono und für andere .NET Core zu haben, möchten sie eine einzige Laufzeit, die für alle Szenarien geeignet ist. Dieses Defacto bedeutet, dass AOT und Linking / Code Stripping usw. unterstützt werden müssen. Daher erwarte ich in den nächsten Jahren, dass entweder die .NET Core-Laufzeit diese Funktionen erhält oder dass Mono- und .NET Core-Funktionen in einer neuen konsolidiert werden Laufzeit.

Wenn jemand es besser weiß, informieren Sie mich bitte.

+ 2 ¢

Ich denke, das Problem ist, dass anscheinend Entscheidungen ohne viele Informationen getroffen werden. Heutzutage reden überall, wo ich hinschaue, Leute darüber; die überwiegende Mehrheit der Menschen Programme bereitstellen haben diese oben auf ihrer Wunschliste, und viele bewegen sich mit einer besseren AOT / Einsetzbarkeit in andere Sprachen von C # entfernt. Ich denke, das ist eine ziemlich etablierte Tatsache, die sehr deutlich wird, wenn Sie in der Community aktiv sind. Dennoch scheint es die Entscheidungen nicht im geringsten zu beeinflussen.

Die Sache ist, es scheint, dass niemand genau weiß, inwieweit dies wichtig ist. Für mich persönlich ist es extrem wichtig, daher bin ich natürlich sehr voreingenommen, aber der Eindruck, den ich habe, ist, dass dies insgesamt von größter Bedeutung ist und es scheint, dass MS ihm nicht die Aufmerksamkeit schenkt, die es verdient, was vielen von uns den Eindruck hinterlässt Sie treffen uniformierte Entscheidungen, was uns wiederum nicht zuversichtlich macht, wie die Technologie insgesamt aussehen wird.

Ich stimme @RUSshy zu. CoreRT ist ein unglaubliches Projekt und geht definitiv in die richtige Richtung, aber insgesamt scheinen sich alle Bemühungen auf Server- / Webtechnologien zu konzentrieren. Dinge wie Laufzeiten, Jits und große Binärdateien sprechen in dieser Hinsicht für sich. Niemand, der Software bereitstellt, möchte diese Dinge.

Davon abgesehen nutze ich die Technologie persönlich immer noch, obwohl ich in einigen Bereichen nicht wirklich den Atem anhalte.

Ich würde mir eine stärkere Beteiligung der Community an der Richtung wünschen, auch wenn sich herausstellt, dass dies das Gegenteil von dem ist, was ich persönlich erwarte. Bisher scheinen jedoch Entscheidungen getroffen zu werden, ohne dies zu berücksichtigen. Es scheint, dass Server / Web das ist, was Geld verdient, und Leute, die Programme bereitstellen, sind eine vernachlässigbare Minderheit (zumindest in Bezug auf die Gewinne), aber wenn dies der Fall ist, würde ich zumindest wissen wollen, worauf sie ihre Entscheidungen stützen (auf welche ist sehr wahrscheinlich), weil es von außen so aussieht, als würden sie eine Münze werfen.

@ Alan-FGR

Bisher scheinen jedoch Entscheidungen getroffen zu werden, ohne dies zu berücksichtigen.

Haben Sie konkrete Beispiele für solche Entscheidungen zu teilen, da ich neugierig wäre, mehr zu erfahren.

Ich denke, MS sind sich der Mängel der aktuellen Dotnet-Core-Laufzeit sehr bewusst, und deshalb werden sie in Zukunft die Feature-Parität mit der Mono-Laufzeit anstreben.

Schauen Sie sich einfach die Versionshinweise für .net Core 3.0.0 Preview 6 an:

Heute kündigen wir .NET Core 3.0 Preview 6 an. Es enthält Updates zum Kompilieren von Assemblys für einen verbesserten Start und zur Optimierung der Größe von Anwendungen mit Linker- und EventPipe-Verbesserungen. Wir haben auch neue Docker-Images für Alpine auf ARM64 veröffentlicht.

Mir scheint, sie sind sich sehr bewusst, dass die Anwendungsgröße für bestimmte Szenarien wichtig ist - besonders jetzt, wo Blazor im Mix ist.

@ Alan-FGR Einverstanden ist, dass der Webfokus ziemlich seltsam ist, wenn man bedenkt, dass IIS einen Marktanteil von etwa 8% hat und sinkt. ASP.NET ist irrelevant, und keine Verbesserung von C # oder seinen Standardbibliotheken wird dies jemals ändern. C # wird von Konsolen-Apps, Windows-Diensten, mobilen Apps und PC-Spielen unterstützt. Es verdankt seinen Fortbestand der Einheit und Xamarin. Das ist eine Schande, denn C # ist eine wirklich unterhaltsame Sprache, in der man sich entwickeln kann. Das ist ein großes Lob von einem langjährigen Java-Entwickler, der immer noch der Meinung ist, dass Microsoft mit Windows XP seine Hochwassermarke hinterlassen hat.

Bei Bedarf führen native DLLs dynamisch zu einem Namen zusammen: XXX.exe (UnManaged).
Verwenden der statischen Analyse zur Analyse beim Kompilieren der nativeDLLs (UnManaged) -Verbindung auf Funktionsebene.

Ich bin nicht sicher, was Sie unter dynamischer Zusammenführung verstehen, aber es ist geplant, die nativen Komponenten statisch mit dem Host zu verknüpfen. Bitte beachten Sie diesen Abschnitt .

Entwickeln Sie den ähnlichen Link auf Funktionsebene mit IL-Merge.
Zum Reflektieren Analyse-DLL vom Reflektionstyp. Behalten Sie die Metadaten und die Art der Reflexion (einschließlich der Funktion) sowie alle baumabhängigen Elemente bei.

Wir haben die Möglichkeit erörtert, Assemblys zu einer zusammenzuführen und seitliche Metadatentabellen zur Unterstützung dynamischer Funktionen zu verwenden. Es bietet erhebliche Größeneinsparungen. Die Kosten für die Implementierung sind jedoch recht hoch - aufgrund der neuen Unterstützung für Metadaten und der Änderungen, die bei Debuggern / Profilern usw. erforderlich sind, um damit umzugehen.

Es gibt einige andere Optionen, um die Binärgröße zu reduzieren. Wenn wir beispielsweise eine einzelne Datei direkt ausführen können (ohne in Dateien extrahieren zu müssen), können wir die Signatur / Zertifikate für jede DLL zugunsten von löschen Signieren der App als Ganzes. Dies kann manchmal einige MB sparen.

Bisher scheinen jedoch Entscheidungen getroffen zu werden, ohne dies zu berücksichtigen.

Haben Sie konkrete Beispiele für solche Entscheidungen zu teilen, da ich neugierig wäre, mehr zu erfahren.

Ich denke, MS sind sich der Mängel der aktuellen Dotnet-Core-Laufzeit sehr bewusst, und deshalb werden sie in Zukunft die Feature-Parität mit der Mono-Laufzeit anstreben.

@dazinator Ich denke, die Tatsache, dass MS Mono irgendwie für eine anständige Lösung hält, zeigt, dass sie ihre Produkte wirklich nicht kennen. Ich habe Mono verwendet, und obwohl es ein wichtiges Stück Technologie ist und dazu beigetragen hat, .NET immens bekannt zu machen, fehlt es definitiv an Qualität ... Xamarin hat großartige Marketingarbeit geleistet, um ihre Technologie zu fördern, aber es basierte auf vielversprechenden und unterversprechenden Es scheint, dass jeder, der diese Entscheidungen bei MS trifft, nur einen Teil seines Werbematerials gesehen und die Technologie nie wirklich genutzt hat. CoreRT hingegen ist eine Technologie, die mir bisher stark überboten wurde. Meiner Meinung nach ist es auf einem anderen Qualitätsniveau, und dennoch wird es von MS zugunsten einer Technologie vernachlässigt, von der ich vermute, dass sie mit Entenband zusammengehalten wird.

Einverstanden ist der Webfokus ziemlich seltsam, wenn man bedenkt, dass IIS einen Marktanteil von etwa 8% hat und sinkt. ASP.NET ist irrelevant, und keine Verbesserung von C # oder seinen Standardbibliotheken wird dies jemals ändern. C # wird von Konsolen-Apps, Windows-Diensten, mobilen Apps und PC-Spielen unterstützt.

@kjkrum das ist der Punkt. Vielleicht sind für sie jedoch 8% Marktanteil im Web immer noch viel wichtiger als für Windows und mobile Apps. Gute Web-Techniker helfen zumindest dem Verkauf von Windows-Servern, daher ist ihr Interesse daran offensichtlich, aber es ist auch eine sehr flache Strategie, sich so sehr darauf zu konzentrieren, und ich weigere mich zu glauben, dass dies der Grund für ihre Entscheidungen ist. MS schien mit der Dotnet-Stiftung und so vielen vielversprechenden Projekten in die richtige Richtung zu gehen, aber es scheint, als würden sie die Gelegenheit nutzen, eine dominante Technologie vorbeizulassen.

Ich weiß, dass dies anekdotisch ist, also wahrscheinlich bedeutungslos, aber alle Leute, die ich kenne und die C # für ihre Projekte verwendeten (hauptsächlich Spieleentwickler), sind aufgrund von Einschränkungen, die vollständig lösbar waren, zu etwas anderem übergegangen. Sie wechselten zu Rust, D, Go und C ++. Ich selbst verwende C ++ regelmäßig und lerne Rust, aber ich verwende C # immer noch für einige persönliche Projekte, weil es so viel besser ist, obwohl die Bereitstellung eines Qualitätsprodukts ein Problem darstellt.

Es verdankt seinen Fortbestand der Einheit und Xamarin.

Ja, was ist ein Segen und ein Fluch wegen der vielen technischen Probleme. Unity zum Beispiel hat einen sehr schlechten Ruf, aber zum Glück schien dies keinen Einfluss auf .NET / C # zu haben.
Obwohl XNA alles andere als perfekt ist, genießt es bei Benutzern und Entwicklern immer noch einen unglaublich guten Ruf.

Freut mich, dieses Land heute mit .NET Core 3.0 zu sehen. Danke Leute! 👍

Ich bin mir nicht sicher, ob die Leute das wollen. Wenn wir am Ende einen einfachen Taschenrechner mit einer Exe von 141 MB haben, ist die Funktion ein Fehler (und ich glaube, die tatsächlichen Kosten betragen 141 MB * 2, da sie irgendwo richtig extrahieren werden).

Ja, es ist definitiv was ich will. Es ist immer noch kleiner als eine normale eigenständige Bereitstellung.

Aggressiveres Trimmen und Schütteln von Baugruppen wäre willkommen, aber dies ist ein sehr nützlicher Anfang. Inkrementelle Verbesserungen sind der intelligenteste Weg, um Wert zu liefern.

Oh das ist was du willst? Mein schlechtes, ich wusste nicht, dass aufgeblähte Anwendung beliebt ist

Ein Taschenrechner braucht keine JIT, nicht einmal Reflection, aber da Sie das wollen, denke ich, dass ich von Anfang an im Unrecht bin, sollte ich aufhören zu programmieren

@RUSshy Es ist nicht aufgeblähter als jede andere eigenständige Bereitstellung, oder?

Das Entfernen von JIT und Reflexion ist unabhängig davon, ob alles in einer einzigen Exe verpackt ist. Das heißt, Sie können JIT und Reflexion ohne Single-Exe entfernen, und Sie können Single-Exe haben, ohne JIT und Reflektion zu entfernen. Sie sind separate Arbeiten.

Ich bin mir nicht sicher, ob die Leute das wollen. Wenn wir am Ende einen einfachen Taschenrechner mit einer Exe von 141 MB haben, ist die Funktion ein Fehler (und ich glaube, die tatsächlichen Kosten betragen 141 MB * 2, da sie irgendwo richtig extrahieren werden).

Es extrahiert die Dateien in C: Users [YourUserName] AppDataLocalTemp.net

Gibt es eine Möglichkeit zu überschreiben, wo einzelne Exe entpackt werden?
Ich bin auf ein Problem gestoßen, als versucht wurde, nach / var / .... zu extrahieren, wo Benutzer keine Schreibberechtigung haben.

@eiva welches Betriebssystem war das? War es AWS Lambda?
https://github.com/dotnet/core-setup/issues/7940 verfolgt die Behebung dieses Problems.

In der Zwischenzeit können Sie die Umgebungsvariable DOTNET_BUNDLE_EXTRACT_BASE_DIR festlegen, um zu steuern, wo die gebündelten Dateien extrahiert werden.

@ swaroop-sridhar Danke für die Antwort!
Es ist Centos.7, das die App über das "eingeschränkte" Dienstkonto startet.

@ jnm2 Ich weiß es zu schätzen, dass du C # liebst, das tue ich auch. Aber seien wir ehrlich, es ist Wahnsinn, dass ein Taschenrechner 128 Megabyte groß ist.

@TechnikEmpire Ich

Ich persönlich werde mich erst ganz zufrieden fühlen, wenn ich in der Lage bin, meinen eigenen Code und meine eigenen Bibliotheken, die referenzierten Bibliotheken von Drittanbietern und .NET selbst zu baumschütteln. Aber das macht die Single-Exe-Funktion für mich heute nicht weniger wertvoll. Es ist ein Schritt in eine Dimension. Baumschütteln ist eine eigenständige Dimension, von der ich hoffe, dass sie viel Aufmerksamkeit erhält.