Runtime: Umfrage: Native AOT

Ich konnte nicht herausfinden, welches Bereichslabel am besten zu diesem Problem hinzugefügt werden könnte. Wenn Sie über Schreibberechtigungen verfügen, helfen Sie mir bitte beim Lernen, indem Sie genau eine Bereichsbezeichnung hinzufügen .

Sieht aus wie ein Tippfehler - * 9. Which of these tasks are apart of your production debugging workflow? (Please select all that apply) Vielleicht sollte es "ein Teil von" sein?

Ich bin so froh, dieses Problem zu sehen! 😄🚀

Frage: Sollten wir für UWP-Entwickler, die mit der .NET Native-Toolchain gearbeitet haben, die Umfrage einfach beantworten und sagen, dass wir CoreRT noch nie zuvor verwendet haben, oder sollten wir, da .NET Native viele Ähnlichkeiten (und auch einigen gemeinsamen Code?) mit CoreRT aufweist, dies tun Wir erwähnen dies einfach in den Notizen und beantworten dann die anderen CoreRT-Fragen nur in Bezug auf unsere Erfahrung mit .NET Native? 🤔

@Sergio0694 danke für die UWP-Frage. Ich stimme zu, ich denke, es ist sinnvoll, dies in den Notizen zu erwähnen und auf die Verwendung von corrt zu antworten, wenn Sie die Open-Source-Version verwendet haben.

Vielen Dank für die Veröffentlichung dieser Umfrage!

Ich war auch verwirrt darüber, wie ich als UWP-Entwickler, der nur .NET Native verwendet hat, bestimmte Fragen beantworten soll. Ich habe eine Reihe von Meinungen über die .NET Native Toolchain von UWP, aber ich habe keinen Ort gefunden, an dem ich sie niederschreiben könnte. Völlig in Ordnung, wenn dies den Rahmen dieser Umfrage sprengen würde, aber es könnte sich lohnen, es zu klären.

Ich vermute auch, dass „weil .NET Native der Standard für UWP-Release-Builds ist und im Store erforderlich ist“ wahrscheinlich der häufigste Grund ist, warum Leute AOT verwenden, aber es ist keine der vorab ausgefüllten Antworten auf Frage 5.

Danke, dass Sie Avalonia in die GUI-Optionen aufgenommen haben :) Wir haben schon früher mit CoreRT+Avalonia experimentiert und die Ergebnisse waren wunderschöne native GUI-Apps: D obwohl wir die Kompatibilität seit 2 Jahren nicht mehr gepflegt haben ...

Ein oft vergessener Teil von .net ist die Spieleentwicklung, viele Plattformen erlauben kein Ausführen eines JIT, denken Sie an Konsolen oder IOS-Geräte.
Für die Zukunft der Spieleentwicklung ist es sehr wichtig, .net-natives AOT als erstklassigen Bürger des .net-Ökosystems zu erhalten.
Einige Spiele-Engines rollten ihr eigenes AOT (zum Beispiel Unity mit il2cpp), aber es ist ein absolutes Zugunglück.
Eine offizielle Lösung wäre also mehr als willkommen. Es könnte ein branchenveränderndes Ereignis sein.
Vergessen Sie nicht, dass die Spieleindustrie die Filmindustrie sowohl im Gewinn als auch im Umsatz überholt.
Konsolen sind der Ort, an dem der Hauptgewinn erzielt wird.

Die vorhandenen Optionen zum Optimieren veröffentlichter Anwendungen funktionieren gut für die meisten Szenarien, auf die .NET heute abzielt.

...

AOT ist hauptsächlich in GUI-Apps von Bedeutung. Da braucht es Fokus. Ich sehe keine Webapp, Dienste usw., die das brauchen

Ich bin nicht einverstanden. Für die beste Endbenutzer-UX wird AOT mit statischer Verknüpfung für Spiele-Engines , serverlose Microservices , Desktop-GUI-Anwendungen , iOS- und Android -Anwendungen, WASM-basierte clientseitige SPAs/Bibliotheken und grundlegende CLI-Tools benötigt (~ wenige MB).

Ich habe mir gewünscht, dass ich meinen Code einfach AOT kompilieren könnte, während ich in den letzten Jahren alle oben genannten Szenarien in C# ausprobiert habe, und ich habe das Gefühl, dass .NET im Vergleich zu LLVM-basierten Sprachen wie Rust stark zu kurz kommt.

Der Grund, warum die aktuellen Veröffentlichungsoptionen „gut zu funktionieren“ scheinen, liegt darin, dass .NET in der Vergangenheit für die oben genannten Szenarien nicht geeignet war und die Leute einfach ihr eigenes AOT (z. B.: Unity, UWP, Mono) implementieren, wenn sie C# verwenden. Teilweise AOT-Lösungen wie z als natives Image (z. B. ReadyToRun) kann in Kaltstartszenarien für monolithische Serveranwendungen oder große Desktop-Clientanwendungen "helfen", aber die Binärgröße ist immer noch um ein Vielfaches größer als das, was eine vollständige AOT-Laufzeit erzeugen würde.

.NET funktioniert bereits nicht gut für serverlose/containerisierte Microservices – diese könnten stark von der AOT-Kompilierung, reduzierter Binärgröße und minimalen Abhängigkeiten profitieren .
Die aktuelle ReadyToRun + Tiered Compilation + IL Linker-Lösung hat bereits eine Grenze für die Dateigröße erreicht, die für eigenständige Bereitstellungen ärgerlich ist, wie die von AWS Lambda in ihrem Blogbeitrag empfohlene .

Das eigentliche Problem ist, dass derzeit zu viele Laufzeiten/Codegeneratoren/Toolchains/Experimente mit ihren eigenen Macken verfügbar sind: IL2CPP/Burst (Unity), Monos AOT-Backend (Xamarin/Blazor/Uno), .NET Native/CoreRT (UWP), Monos LLVM-Backend, CrossGen/ReadyToRun (.NET Core) usw. und es ist einfach inakzeptabel, dass .NET keine standardisierte AOT-Kompilierungs-Toolchain hat.

Wenn all diese Teams ihre Entwicklungsanstrengungen auf etwas Gemeinsames wie CoreRT, Mono LLVM-Backend oder das jetzt aufgegebene dotnet/lilic bündeln würden, wäre AOT eine viel bessere Erfahrung für .NET-Entwickler gewesen.

AOT mit statischer Verlinkung ist nun mit CI/CD für eine Vielzahl von Entwicklern für die breite Masse zugänglich und nicht mehr nur ein Ärgernis für eine marginale Leistungssteigerung.

C#-Endspiel: Nativer Code, native UI, schnelle und einfache Interoperabilität, native Exporte und leistungsorientierte APIs (z. B. System.IO.Pipelines, System.Text.Json).

Ich stimme der Aussage nicht zu, dass Webapps davon nicht profitieren würden. AOT würde bei serverlosen Workloads (auch bekannt als Azure Functions) sehr hilfreich sein. Ganz zu schweigen von den Vorteilen der Startzeit für CLI-Tools.

Ich habe die Umfrage beantwortet, aber um ehrlich zu sein, bekomme ich seit dem Start von .NET Core 1.0 nicht mehr diese kontinuierlichen Umfragen ohne eine klare Richtung, in die sich die Dinge entwickeln.

.NET Native ist das, was .NET die ganze Zeit hätte sein sollen, als das Ext-VOS-Projekt begann, und es gibt die Erfahrung von Singularity und Midori, auf die Sie sich sicherlich beziehen können, oder sogar einige interne Server mit ihnen zum Laufen bringen.

Sogar Java hat beschlossen, seine fehlenden AOT-Fähigkeiten nachzuholen, das Team fragt nicht, welche Workloads wir wollen, damit es funktioniert.

Wir verwenden NGEN kaum, da die Generierung der Codequalität seit der Veröffentlichung von .NET nie verbessert wurde und der Bereitstellungsworkflow im Vergleich zu anderen AOT-kompilierten Sprachen mühsam ist.

Wenn Sie also in Zukunft AOT wieder aus .NET fallen lassen, bedenken Sie, dass sich die gesamte Konkurrenz in verwalteten Sprachen jetzt auf AOT-Toolchains konzentriert, und sie fragen auch nicht, welche Workflows wir mit dem Compiler verwenden möchten.

Ich möchte, dass .NET weiterhin gedeiht und unabhängig vom Szenario die erste Option ist, und wenn überhaupt, Workflows übernehmen, bei denen Microsoft uns immer noch zwingt, C++ neben .NET zu verwenden, mit dem andere AOT-kompilierte Sprachen keine Probleme haben.

Ich habe die Umfrage beantwortet, aber um ehrlich zu sein, bekomme ich seit dem Start von .NET Core 1.0 nicht mehr diese kontinuierlichen Umfragen ohne eine klare Richtung, in die sich die Dinge entwickeln.

Ich finde es großartig, dass MS versucht, der Community zuzuhören, anstatt nur zu diktieren, was wir wollen.

@jkotas Mir ist aufgefallen, dass sich zwei verschiedene Links für diese Umfrage verbreiten, ist das in Ordnung?
https://www.surveymonkey.com/r/7THQK5K
https://www.surveymonkey.com/r/SQV8JQK

@texasbruce fragen Sie die anderen Entwickler, die ähnliche Umfragen zur plattformübergreifenden Unterstützung von GUI-, WCF- und EF-Tools beantwortet haben, wie sehr es geholfen hat.

Es ist zwar schön, dass sie uns fragen, aber es wäre schöner, wenn tatsächlich etwas passiert. Auch für Cross-Plattform-GUI bleibt abzuwarten, ob MAUI tatsächlich kommt oder wir Blazor in Web Widgets als Lösung geschoben bekommen.

Für mich ist die einzig akzeptable AOT-Lösung, wenn sie eine echte native Anwendung ohne JIT im Release-Modus generiert (kein betriebsbereiter Alias ​​für parallele Lösungen) und wenn sie in allen¹ .NET-Projekten funktioniert, an denen Entwickler arbeiten an. Dazu gehören insbesondere Winforms und WPF. Im besten Fall sollte es dann auch Standalone ohne Laufzeitabhängigkeiten funktionieren, ohne sich von 3MB auf 80MB aufzublähen.

¹ Aus technischen Gründen kann es vorkommen, dass AOT Fälle/APIs nicht unterstützen kann. „Auf allen“ zu sagen bedeutet, nicht alle APIs zu unterstützen, sondern alle Projektarten. .NET Core unterstützt: dll / winforms / wpf / winui / console / maui / … Etwas Ähnliches wie der Wechsel von .NET Framework zu .NET Core, was die meisten erlaubte Entwickler, ihre bestehenden Anwendungen zu übernehmen, ist das, was ich im Sinn habe.

_Ich habe auch Anwendungen in Delphi geschrieben und es nervt mich zu sehen, dass ich einfach meine einzelne ausführbare Delphi-Datei kompiliere und dann an eine andere Stelle schicke und sie einfach läuft. Und es ist einfach schneller. Gleiches gilt für eine C++-Anwendung, wenn sie auf eine bestimmte Weise kompiliert wird. Und Sie können immer noch beide Anwendungen debuggen und beide Anwendungen bieten immer noch einen nützlichen Stacktrace/Dump, wenn Sie sich entscheiden, die PDB einzuschließen. Aber aus Sicherheitsgründen können Sie sich auch dafür entscheiden, es NICHT einzuschließen, was dann auch gut funktioniert. Es nervt mich, mich zu fragen, warum wir das nicht mit C# haben können? Als ich von AOT-Plänen hörte, erwartete ich DAS._

Ich sehe immer wieder Probleme mit Reflektion, die häufig erwähnt werden, und ich glaube, dass es eigentlich nicht so wichtig ist, wenn der ASP.net-Kern eine große ausführbare Datei produziert.

Die meisten Orte, an denen AOT eine harte Anforderung ist, sind Dinge wie CLI-Tools, Spiele und UI-Anwendungen. Sie können wählerisch sein, welche Bibliotheken enthalten sein sollen, und können einige Reflexionsprobleme umgehen. Die Priorität sollte darin bestehen, "saubere" Anwendungen zu ermöglichen.

Ich sehe immer wieder Probleme mit Reflektion, die häufig erwähnt werden, und ich glaube, dass es eigentlich nicht so wichtig ist, wenn der ASP.net-Kern eine große ausführbare Datei produziert.

Mit der Veröffentlichung von Blazor WebAssembly werden meiner Meinung nach die ausführbare Größe und auch die Ausführungsgeschwindigkeit sehr wichtig sein und es könnte stark von AOT profitieren. Aber aus welchen Gründen auch immer wurde es in der Umfrage nicht einmal ausdrücklich erwähnt.

Ja, bitte schön! Ich habe überlegt, Rust oder CoreRT zu verwenden, um die Speichersicherheit zu gewährleisten und native Geschwindigkeiten zu erreichen und meinen Code nativ aufrufbar zu machen. Aber es wäre fantastisch, AOT in .NET zu haben, da es unglaublich reichhaltig und leistungsfähig ist und Rust, obwohl es fantastisch ist, nicht einfach zu wechseln ist.

@jkotas Mir ist aufgefallen, dass sich zwei verschiedene Links für diese Umfrage verbreiten, ist das in Ordnung?

Ja, wir verwenden unterschiedliche SurveyMonkey-Links für unterschiedliche Posts. Alle Links verweisen auf dieselbe Umfrage. Es ermöglicht uns zu sehen, wie die Verteilung der Antworten variiert, je nachdem, wo die Leute die Umfrage gefunden haben.

Für Gamedev brauchen wir das, ich habe die Arbeit an meiner Game-Engine https://github.com/amerkoleci/alimer_sharp zugunsten einer nativen Engine mit C++ ausgesetzt, ich pflege auch Bindungen für DirectX und Vulkan, hier wird Leistung benötigt

Für Gamedev brauchen wir das, ich habe die Arbeit an meiner Game-Engine https://github.com/amerkoleci/alimer_sharp zugunsten einer nativen Engine mit C++ ausgesetzt, ich pflege auch Bindungen für DirectX und Vulkan, hier wird Leistung benötigt

Identisches Szenario hier 😄, außer dass ich es nicht ausgesetzt habe . Ich mag AOT sowohl wegen der besseren Startzeiten als auch (und in meinem Fall noch wichtiger) wegen der Möglichkeit, optimierteren Code zu haben - ich bin mit einer 50%igen Erhöhung der Build-Zeiten für eine 10%ige Beschleunigung einverstanden, was offensichtlich ist. t wirklich die Haltung eines JIT

Ich bin mit einer 50%igen Erhöhung der Bauzeiten für eine 10%ige Beschleunigung einverstanden, was offensichtlich nicht wirklich die Einstellung eines JIT ist

Dies ist tatsächlich einer der großen sekundären Gründe, warum ich AOT in .NET möchte, anstatt zu einem anderen Ökosystem zu wechseln. Ich bin total verwöhnt von den schnellen Kompilierzeiten großer .NET-Projekte im Vergleich zu großen C++- oder Rust-Projekten.

Ich möchte JIT für die schnelle Iteration während der Entwicklung, aber AOT, sobald ich etwas an meine Kunden versende.

Ich hatte CoreRT verwendet, um plattformübergreifende (und plattformübergreifende) native Bibliotheken zu erstellen.

AOT mit statischer Verknüpfung wird dringend für Spiele-Engines in iOS- und Konsolenplattformen benötigt, die Jit deaktivieren und auch mehrere AOT-Kompilierungsmodi wünschen:

1. voll aot
2. hybride aot, die den Ausführungsmodus jit + aot oder interpreter + aot unterstützen
   Hybrid AOT ist wirklich wichtig für die Spieleindustrie, es kann das Spiel verändern

AOT mit statischer Verknüpfung wird dringend für Spiele-Engines in iOS- und Konsolenplattformen benötigt, die Jit deaktivieren und auch mehrere AOT-Kompilierungsmodi wünschen:

1. voll aot
2. hybride aot, die den Ausführungsmodus jit + aot oder interpreter + aot unterstützen
   Hybrid AOT ist wirklich wichtig für die Spieleindustrie, es kann das Spiel verändern

wie Mono auf der iOS-Plattform, aot+Interpreter-Ausführungsmodus.

Vollständiges AOT, einzelne exe, unabhängige Laufzeit und das Abschneiden unnötiger Codes macht mich definitiv zum Kreygasm XD

Auf diese Frage warte ich seit 10 Jahren. Verdammt, ich habe 5 coole Projekte, die auf der Festplatte verstauben, denn wenn ich sie veröffentliche, kann jedes Kind sie rückgängig machen, kleine Änderungen an der GUI vornehmen und sie als ihre eigenen verkaufen.

Ich habe Robocraft, Cardlife und Gamecraft mit Unity auf der PC-Plattform entwickelt und musste nie IL2CPP verwenden, es sei denn, dies ist erforderlich (lesen Sie Xbox One), nicht einmal für die Spielserver. Ich persönlich würde eine Mischung aus JIT-Kompilierung und einer Lösung wie Burst (die einen besseren Job macht, als ich es jemals mit expliziten Intrinsics machen könnte) als mehr als genug ansehen, wenn Leistung erforderlich ist. Ich verstehe jedoch, dass AOT für Plattformen erforderlich ist, die vollständig nativen Code erfordern, und für Plattformen, auf denen Hardwareressourcen wertvoll sind. Ich verstehe, dass die Entwickler der .net-Plattform gemischte Gefühle gegenüber AOT haben können, aber ich denke nicht, dass es eine Option ist, wenn wir wollen, dass es in der Spieleentwicklung breiter angenommen wird. Um ehrlich zu sein, macht es mir ein bisschen Angst, dass Unity ein Monopol auf Technologien wie IL2CPP und Burst hat.

Wir entwickeln leistungsstarke, hochskalierbare Finanz-/Wissenschaftssimulatoren. Unsere Simulationen können je nach Komplexität des vom Benutzer erstellten Modells von wenigen Minuten bis zu vielen Tagen dauern.

Aufgrund der Art unserer Simulationssoftware sind Startzeiten fast nie ein Problem, ebenso wie Software-/Binärgrößen. Übrigens auch nicht die Zeit, die für die Installation des Produkts benötigt wird. Zum Beispiel wäre es für uns völlig akzeptabel, wenn die Kompilierung Teil der Installation wäre, auch wenn ein solcher Vorgang lange dauert.

Ich würde sagen, dass etwa 25 % des Codes während eines Laufs dynamisch erstellt werden, daher wäre ein hybrider Ansatz vorzuziehen; eine Kombination aus AOT- und JIT-Kompilierung. Wenn die dynamischen Bits interpretiert werden müssten, würde meiner Meinung nach ein Großteil der Vorteile von AOT zumindest in unserem Anwendungsfall beeinträchtigt.

Der GC ist unser größtes Problem, das uns davon abhält, eine höhere Skalierbarkeit zu erreichen (z. B. sobald wir etwa 44 Kerne haben). Wenn der Compiler in der Lage ist, tiefer gehende Optimierungen zwischen Baugruppen, aggressives In-Lining und Escape-Analysen durchzuführen, können kurzlebigere Objekte auf dem Stack statt auf dem Heap zugewiesen werden.

Es gibt viele Stellen in unserer Codebasis, an denen die JIT-Codequalität zu einem Engpass wird, insbesondere bei Registerzuweisungen und beim Umgang mit vielen Strukturen. Dies zwingt uns, Code zu schreiben, um den JIT-Compiler so zu manipulieren, dass er das Richtige tut (ein Tauziehen, das zerbrechlich, verschleiernd und schwer zu warten ist) oder auf nativen Code zurückgreifen (und wir verlieren viel Nutzen durch fehlendes Inlining und Overhead von GC/PInvoke-Übergängen).

Manchmal können kleine Verbesserungen der Codequalität im Laufe eines Modells, das stundenlang auf zahlreichen Kernen läuft, verrückte Gewinne bringen. Für uns ist das JIT mit der Leistung etwas anfällig (noch weniger deterministisch) geworden, da sich unsere Codebasis mit der Entwicklung ändert. Unsere Hoffnung wäre, dass ein AOT-Compiler viel mehr Zeit zum Kompilieren und Generieren von Code mit viel höherer Qualität benötigt, einige dieser unnötigen Leistungsschwankungen reduziert und es uns ermöglicht, einen größeren Teil unserer Codebasis in C# zu belassen.

Im Allgemeinen würde ich gerne sehen, dass mehr in JIT- und AOT-Technologien investiert wird.

cc @AndyAyersMS

AOT mit statischer Verknüpfung wird dringend für Spiele-Engines in iOS und Konsolenplattformen benötigt, die Jit deaktivieren,

Ich stimme hier vollkommen zu. Da wir eine Lösung für dieses Problem benötigen (C#-Code, der auf Spielekonsolen für ein Nicht-Unity-Projekt ausgeführt wird), verwenden wir eine Mono-AOT-basierte Toolkette. Aber es hat einige ernsthafte Einschränkungen und funktioniert nicht so gut.

Daher prüfen wir, ob wir CoreRT auf 3 beliebten Spielkonsolen (XBox One; PlayStation 4 und Nintendo Switch) zum Laufen bringen. Ein erstes Konzept zeigt, dass es tatsächlich funktioniert (noch mit einigen Einschränkungen), aber bereits mit einer signifikanten Verbesserung der Laufzeitleistung im Vergleich zur Mono-basierten Lösung.

Aber mit der NDA-Situation in Bezug auf Spielkonsolen ist die offizielle Unterstützung für diesen Verwendungszweck noch weit hergeholt, als überhaupt ein offizielles natives AOT zu erhalten.

Für uns ist das JIT mit der Leistung etwas anfällig (noch weniger deterministisch) geworden, da sich unsere Codebasis mit der Entwicklung ändert.

@jpapp05 Ich würde gerne mehr über Ihre App und insbesondere über das oben genannte Problem erfahren, da dies eines meiner Hauptanliegen ist. Fühlen Sie sich frei, mich offline zu kontaktieren (per E-Mail im Profil), wenn das hilft.

Hallo @AndyAyersMS , das wäre toll. Ich werde Sie offline kontaktieren, da ich etwas freier sprechen kann, aber ich freue mich, eine Zusammenfassung unserer Diskussionen zum Nutzen anderer zu posten.

Ich weiß nicht, ob das überhaupt ein Problem ist, aber nur um es hier zu erwähnen.
Ein wichtiges Feature für uns wäre die Möglichkeit, native Assemblies zur Laufzeit dynamisch zu laden und zu entladen.

@movedoa siehe NativeLibrary APIs https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.nativelibrary?view=netcore-3.1

Mein größtes Problem ist, dass .NET normalerweise leicht dekompiliert werden kann, außer mit UWP Native, zumindest soweit ich es getestet habe (ich hoffe, richtig zu liegen). Nicht in einer "normalen" Unternehmensmentalität steckt jemand viel IP in ein Projekt, das leicht dekompiliert werden kann.
Linux ist cool ok, aber alle Desktop-Anwendungen sind für Windows in der Unternehmenswelt.

Um das Leben einfacher zu machen, setzen Sie vielleicht ein Kontrollkästchen mit der Aufschrift:
NATIVE ZUSAMMENSTELLUNG (FUNKTIONIERT NUR FÜR WINDOWS 10 DESKTOP!)
Mann, mach das und ich interessiere mich nicht mehr für AOT. Wenn es für ASP.NET Core funktioniert, cool! Wenn nicht, ist es mir wirklich egal.

Übrigens, vielen Dank für die Erstellung der Fragestellung und die Durchführung der Umfrage. Sie haben großartige Arbeit geleistet, weil Sie die Meinung von Menschen einholen, die die Technologie in ihrer Arbeit einsetzen. Ich denke (eigentlich bin ich mir sicher), dass Sie immer noch Tonnen von Meinungen von Desktop-Entwicklern vermissen, die sich normalerweise nicht auf Github in diese Dinge einmischen. Nicht jeder erinnert sich (oder weiß), dass .NET-Code leicht dekompiliert werden kann, und ich bin mir sicher, dass ihre Chefs verrückt werden würden, wenn sie das wüssten : grins:.

Nicht jeder erinnert sich (oder weiß), dass .NET-Code einfach dekompiliert werden kann

Shhh ... Die Tatsache, dass Rider dies automatisch für Sie erledigt, ist erstaunlich, wenn ich versuche herauszufinden, wie etwas hinter den Kulissen in Unity- oder Drittanbieterpaketen funktioniert. Jetzt ist es zwar nicht mehr annähernd so wichtig, da ein Großteil des Codes von vornherein Open Source ist, aber Sie verstehen, was ich meine.

@jcbeppler Sie liegen falsch, das ist ein häufiges Missverständnis von Bytecode und nativem Code. Es geht nur darum, die richtigen Tools zu haben.

https://www.hex-rays.com/products/decompiler/compare/compare_vs_disassembly/

Hex-Rays ist nur eine mögliche Lösung, es stehen andere zur Auswahl.

@MostHated Ja, ich habe es verstanden. Tatsächlich ist es so einfach, eine Software in .NET zu dekompilieren, dass es wie Open Source ist und viele Unternehmen nicht wollen, dass ihre Software Open Source ist. „So etwas wie ein kostenloses Mittagessen gibt es nicht“ 😄

@pjmlp Ich kenne den Unterschied zwischen Dekompilieren und Disassemblieren. Ich kann nichts dagegen tun, meine Software zu disassemblieren, aber die native Kompilierung kann die Software viel sicherer machen, da die Person keine sehr einfache Dekompilierung durchführen kann. Eine disassemblierte Software wird definitiv komisch aussehen und der disassemblierte Code wird möglicherweise nicht einmal richtig ausgeführt.

@jcbeppler Sie liegen falsch, das ist ein häufiges Missverständnis von Bytecode und nativem Code. Es geht nur darum, die richtigen Tools zu haben.

Derzeit wird ein .NET-Programm dekompiliert, das den gesamten Quellcode offenlegt. Dies schließt sogar alle Methodennamen und Variablennamen ein. Das ist cool zum Debuggen und ermöglicht uns, einen "lesbaren" Stacktrace zu haben, wenn eine Ausnahme auftritt. Es ist jedoch eine große Sicherheitslücke und ein Grund, warum es einen riesigen Markt für .NET-Obfuscatoren gibt.

Eine native Anwendung kann disassembliert werden. Aber es geht nicht hinunter, um seinen vollständigen C++/Delphi-Quellcode usw. zu enthüllen (es gibt einige Tools, die versuchen, diesen Quellcode neu zu erstellen, aber die Ergebnisse sind schrecklich). Was Sie erhalten, ist höchstens Assembler-Code und Kontrollflussdiagramme. Wenn Sie Glück haben und es mit einer Symboldatei geliefert wird, erhalten Sie auch die Funktionsnamen, aber im Release-Modus ist diese Symboldatei normalerweise nicht enthalten, wiederum aus Sicherheitsgründen.

Wir können uns in Details verlieren und darüber sprechen, wie nativer Code ein echter Schutz ist. Meiner Meinung nach ist es kein Schutz in Bezug auf Cracking (obwohl dank vollständiger vollständiger Methoden- / Variablennamen und vollständiger C#-Quellgenerierung eine Lizenzprüfung ohne spezielle Kenntnisse entfernt werden kann) oder Debugging, sondern ein Schutz vor Diebstahl. Tools wie dnSpy können die .NET-Anwendung sogar mit EINEM KLICK in ein vollständiges VS-Projekt exportieren. Es gibt kein solches Tool, das für nativen Code auf die gleiche Weise funktioniert. Für kommerzielle Anwendungen wäre es also ein großer Gewinn, nativen Code zu generieren, abgesehen von der Tatsache, dass sie nicht mehr Tausende von Dollar pro Jahr für etwas zahlen müssen, das nur alle Methoden und Variablen in der endgültigen Anwendung umbenennt.

Ich bin gespannt auf das Ergebnis dieser Umfrage. Gibt es Pläne, sie darüber öffentlich zu machen, wie die Leute gewählt haben?

@Symbai Es ist kein Schutz vor irgendetwas, wie Ihnen jeder Android-Entwickler sagen wird, der versucht hat, das NDK als Mittel zum Schutz seiner IP zu verwenden. Die Anwendungen, die Sie kurz erwähnen, können dasselbe mit einem einzigen Klick tun, und obwohl sie normalerweise C- oder C++-Code als ursprünglichen Quellcode annehmen, sind sie gut genug, um Ihre Algorithmen zu stehlen.

Ich möchte AOT, für Szenarien, in denen .NET langfristig gegenüber Rust, Go, Swift, C++, Java (GraalVM), Desktop-, Konsolen- und Mobil-/IoT-Anwendungen verliert, bei denen die Startzeit wirklich wichtig ist, gibt es hohe Einschränkungen bei der Speichernutzung und Geschwindigkeitsverlust aufgrund von JIT beim Laden der Assembly ist nicht tolerierbar, genau wie bei einigen ASP.NET-Szenarien kann AOT-Code relevant sein, wenn man seine 100 K8S-Pod-Instanzen skaliert.

Auf der anderen Seite finde ich es auch relevant, die JIT-Funktionen beizubehalten und sie auch zu verbessern, in Szenarien, in denen JIT der richtige Weg ist.

Es gibt viele Sprachen, die beide Kompilierungsmodelle anbieten, sodass ihre Benutzer je nach Situation auswählen und auswählen können. Lassen Sie uns also im Grunde JIT beibehalten und die AOT-Geschichte in Richtung .NET Native verbessern, während Sie den zaghaften Versuch namens NGEN vergessen.

@Symbai Es ist kein Schutz vor irgendetwas, wie Ihnen jeder Android-Entwickler sagen wird, der versucht hat, das NDK als Mittel zum Schutz seiner IP zu verwenden. Die Anwendungen, die Sie kurz erwähnen, können dasselbe mit einem einzigen Klick tun, und obwohl sie normalerweise C- oder C++-Code als ursprünglichen Quellcode annehmen, sind sie gut genug, um Ihre Algorithmen zu stehlen.

Mit dem Stehlen eines Algorithmus kann ich leben, aber nicht mit dem, was .NET heute zulässt (z. B. WPF), wo eine Person Ihre vollständige Anwendung schön und einfach als VS-Projekt ausführen kann. Ich denke, UWP mit nativer Kompilierung macht einen guten Job, wenn jemand es disassemblieren möchte, ok, viel Glück! Ich werde immer die native Kompilierung verwenden, egal was passiert. Über die Android-Welt kann ich nicht sprechen, habe AOT einmal mit Xamarin Forms ausprobiert und es hat wirklich nicht so funktioniert, wie ich es erwartet hatte.

Ich denke, UWP mit nativer Kompilierung macht einen guten Job, wenn jemand es disassemblieren möchte, ok, viel Glück! Ich werde immer die native Kompilierung verwenden, egal was passiert. Über die Android-Welt kann ich nicht sprechen, habe AOT einmal mit Xamarin Forms ausprobiert und es hat wirklich nicht so funktioniert, wie ich es erwartet hatte.

Spoiler – die Leute, die versuchen, an deine Quelle zu gelangen, versuchen wahrscheinlich, dich zu verbessern/zu erweitern/in dich zu integrieren, nicht dich abzuzocken. Wenn sie versuchen, Sie abzuzocken, dann sind Ihre Messwerte wirklich albern.

Wenn ich ein Buch schreibe, dann bitte jemanden, es ins Japanische zu übersetzen, bevor ich es veröffentliche – vielleicht denke ich, dass ich wirklich schlau bin, weil ich kein Japanisch verstehe, und keiner meiner Freunde tut es. Die Realität ist jedoch, dass es da draußen ganze Länder gibt, die dieses Buch lesen können – und ich tue nichts weiter, als mir etwas vorzumachen, wenn ich das Gegenteil behaupte.

Ich sage dies als Entwickler, der keine Erfahrung mit disassemblierten nativen Binärdateien hatte und sich entschied, die Verschlüsselung und die Datenformate auf Star Citizen zurückzuentwickeln.

Ich, jemand ohne vorherige Erfahrung, brauchte zwei Wochen, um aus dem Nichts zu einem Programm zu gelangen, das nicht nur ihre verschlüsselten Datendateien entschlüsseln, sondern auch ihre proprietären Datenformate in XML/JSON konvertieren kann.

Nach diesen 2 Wochen habe ich Ihre vollständige Anwendung möglicherweise noch nicht fertig, um als VS-Projekt ausgeführt zu werden - aber mir ist auch klar, dass ich das nicht muss. Es ist viel einfacher, einfach meinen eigenen Code in die vorhandene Anwendung einzufügen und mich nicht mit ihrem gesamten Code befassen zu müssen.

ein Programm zu haben, das nicht nur ihre verschlüsselten Datendateien entschlüsseln kann

Verschlüsselung ist etwas ganz anderes. Ein VIDEOSPIEL zu dekompilieren, um Mods zu erstellen, ist etwas völlig anderes. Die meisten Spieleentwickler haben nichts dagegen, wenn ihre Fans Mods erstellen, es zeigt eher ihre Leidenschaft und Liebe für das Spiel. Und vielleicht war die "Verschlüsselung" überhaupt keine Verschlüsselung, sondern Dateien wurden nur für eine kleinere Größe gepackt? Um nicht Tausende von einzelnen Dateien auf der Festplatte speichern zu müssen. Die Leistung könnte auch ein Grund gewesen sein ... das Lesen vieler kleiner Dateien von der Festplatte ist langsamer als das Lesen einer großen Datei. Und nach 2 Wochen konnte man gepackte Bilder entpacken. Sie konnten Text in einigen Datendateien ändern. Das ist großartig, aber nicht der Grund, warum Leute wie ich JIT loswerden wollen.

Das Problem, das wir derzeit haben, ist, dass JIT-Code vollständig zu vollständigem Quellcode dekompiliert werden kann, Java hat das gleiche Problem wie jede andere JIT-Sprache. Nativer Code kann disassembliert werden (dadurch wird Maschinencode in Assemblercode umgewandelt), native Anwendungen können mit ausreichendem Aufwand geknackt werden, all dies ist wahr, aber nativer Code kann nicht zu vollständigem Quellcode kompiliert werden. Haben Sie jemals ein Tool wie dnSpy für C++-Code gesehen? Delphi-Code? Ich habe nicht. Das liegt daran, dass es nicht möglich ist, Variablen- und Methodennamen zu erhalten, sie existieren einfach nicht mehr, wenn sie korrekt kompiliert werden. Es ist nicht möglich, die Disassemblierung in C++ umzuwandeln und ein voll funktionsfähiges Projekt zu generieren, das Sie kompilieren können. Dies muss für Sie nach etwas nicht so Wichtigem klingen, aber für kommerzielle Anwendungen ist es eine große Sache. Wir wollen nur die Tatsache loswerden, dass die .NET-Anwendung ein offenes Buch ist, aus dem jeder ohne jegliches Wissen lesen kann. Wenn wir Tausende von Dollar in die Forschung stecken, wollen wir nicht, dass jeder sie sich ansieht und sie innerhalb weniger Sekunden kopiert. Wir möchten Tausende von Dollar für einen Obfuscator bezahlen, dessen einziger Zweck darin besteht, alle Variablen- und Methodennamen umzubenennen, sodass die Benutzer die Anwendung nicht mehr öffnen und nach "Lizenz" suchen können, um sofort darauf zuzugreifen. Es sind nicht nur (aber hauptsächlich) die Kosten des Obfuscators, sondern auch, dass Obfuscators zusätzliche Probleme verursachen. Ich bin selbst ziemlich oft darauf gestoßen, besonders bei der Häufigkeit von .NET Core-Versionen. Wir mussten mehrere Wochen nur auf einen Patch warten, der den Obfuscator mit der neuesten .NET Core-Version zum Laufen bringt.

Und während Sie als Entwickler mit all diesen Problemen konfrontiert sind, müssen Sie sie auch Ihrem Business Manager erklären. Irgendwann fragt er dich vielleicht, ob es dann nicht besser ist, einfach eine andere Programmiersprache zu wählen.

Mit C++ und Delphi haben Sie dieses Problem einfach nicht. Ich weiß, dass dies nicht für jeden ein Problem ist. Open-Source-Entwickler werden das JIT interessanter und nützlicher finden. Es ist ihnen schwer zu erklären, warum jemand will, dass sein Quellcode ein Buch mit sieben Siegeln ist, wenn sie glauben, dass offene Bücher einfach besser sind. Im Idealfall müssen wir uns also nicht unsere völlig unterschiedlichen Ansichten erklären und AOT wird nur ein Schalter sein, den Sie im Release-Modus einschalten können, wenn Sie möchten. Und wenn Sie nicht möchten, fahren Sie mit JIT fort.

Ich bin dem .NET-Team wirklich dankbar, dass es uns erlaubt hat, „Schutz“ als Grund zu wählen, warum wir AOT ❤ wollen. Es zeigt, dass sie sich der Bedürfnisse mancher Menschen bewusst sind. Und wenn die Umfragen ergeben, dass der Mensch dafür stimmt, haben wir vielleicht endlich eine Chance, dass die AOT-Implementierung dies genauso erledigt wie ein C++-Compiler. FYI: Ich habe es in Anführungszeichen gesetzt, um weitere Diskussionen darüber zu vermeiden, wie viel Schutz AOT tatsächlich ist, die Standpunkte sind diesbezüglich extrem weit gefasst, wie wir vielleicht bereits bemerkt haben.

Sicherheit ist nicht alles oder nichts. Das Entfernen von IL hindert einen entschlossenen Angreifer nicht daran, eine Anwendung rückgängig zu machen. Aber es schafft praktisch relevante Hürden. Es ist eine Tiefenverteidigung. Aus diesem Grund können IL-Verschleierungsprodukte sinnvoll eingesetzt werden.

Ein Freund von mir hat .NET-Produkte geknackt, indem er IL in C# dekompiliert und ziemlich triviale Änderungen vorgenommen hat. Er ist nicht in der Lage, native Anwendungen zu knacken. Es ist viel schwieriger. Er musste auch in Gegenwart von IL-Obfuscators aufgeben, weil das Decompiler-Tool bei diesen Binärdateien abstürzte. Auch diese Produkte wurden im praktischen Sinne geschützt. Es funktionierte.

@ Symbai

Have you ever seen a tool like dnSpy for C++ code? Delphi code?

Hex-Rays macht einen guten Job für C, und es hat Makros, um den Entscheidungsprozess zu unterstützen.

Mit C-Quellcode ist es ein Kinderspiel, ihn in C++ oder Delphi zu konvertieren.

Außerdem haben wir jetzt KI, um denen zu helfen, die nicht geschickt genug sind.

Neuronales Reverse Engineering von gestrippten Binärdateien

Hex-Rays macht einen guten Job für C, und es hat Makros, um den Entscheidungsprozess zu unterstützen.

Arbeiten Sie für Hex-Rays oder für ein Unternehmen, das Verschleierungssoftware verkauft? Anscheinend.

Wie auch immer, selbst wenn Sie es in C konvertieren, wird der Code weit entfernt von einer guten C#-Architektur sein. Selbst wenn Sie Teile des Codes erhalten, müssen Sie sich viel Mühe geben, um ihn zu ändern, zu verbessern usw. ...
Wenn für Sie die native Kompilierung irrelevant ist, ok. Aber für viele Menschen ist es relevant.

Übrigens: Sie scheinen sehr daran interessiert zu sein, mit der JIT-Kompilierung Schritt zu halten, und Sie scheinen auch viel Erfahrung mit dem Disassemblieren von Software zu haben. Ich frage mich, warum und wo Sie das verwenden mussten?!

Unabhängig davon, wie jemand von Ihnen über die einfache Dekompilierung von IL im Vergleich zu Maschinencode denkt, ändert dies nichts an der Tatsache, dass dies eine echte Anforderung in echten Unternehmen ist. (Und wir könnten darüber streiten, wie gültig oder ungültig diese Anforderung sein könnte, bis die Kühe nach Hause kommen.)

Mein bisheriger Arbeitgeber hat aus diesem Grund ausdrücklich verboten, .NET- oder JVM-Tools extern zu versenden. Kurz bevor ich ging, überzeugte ein Team die Vorgesetzten davon, ein Tool mit starker Verschleierung ausliefern zu lassen, aber ansonsten schrieben wir externe Tools in C++, um die Unternehmensrichtlinien zu erfüllen.

Diese Diskussion ist aus dem Ruder gelaufen. Wenn Sie alle einen Flamewar darüber haben wollen, ob AOT für den IP-Schutz relevant ist, tun Sie es bitte woanders.

Hex-Rays macht einen guten Job für C, und es hat Makros, um den Entscheidungsprozess zu unterstützen.

Arbeiten Sie für Hex-Rays oder für ein Unternehmen, das Verschleierungssoftware verkauft? Anscheinend.

Wie auch immer, selbst wenn Sie es in C konvertieren, wird der Code weit entfernt von einer guten C#-Architektur sein. Selbst wenn Sie Teile des Codes erhalten, müssen Sie sich viel Mühe geben, um ihn zu ändern, zu verbessern usw. ...
Wenn für Sie die native Kompilierung irrelevant ist, ok. Aber für viele Menschen ist es relevant.

Übrigens: Sie scheinen sehr daran interessiert zu sein, mit der JIT-Kompilierung Schritt zu halten, und Sie scheinen auch viel Erfahrung mit dem Disassemblieren von Software zu haben. Ich frage mich, warum und wo Sie das verwenden mussten?!

Im Gegenteil, ich besitze die Fähigkeiten, nativen Code in Quellcode zurückzuentwickeln, der von Dritten weiterverwendet werden kann, daher bin ich mir völlig bewusst, dass das Kompilieren in nativen Code nur eine Hürde für Skript-Kiddies ist, was das fehlende Verständnis zu sein scheint Hier.

EDIT: Stoppe auch meine Kommentare. Wollte nur auf den persönlichen Angriff antworten.

Cloud Native und WPF müssen AOT sein.
Windows-Client keine Laufzeit ! kein JIT

Die Ergebnisse der Umfrage wurden veröffentlicht – https://github.com/dotnet/runtime/issues/41522. Wir sind jetzt dabei, die Personen zu kontaktieren, die ihre Kontaktinformationen angegeben haben und einige zusätzliche Folgefragen haben.

AOT mit statischer Verknüpfung wird dringend für Spiele-Engines in iOS und Konsolenplattformen benötigt, die Jit deaktivieren,

Ich stimme hier vollkommen zu. Da wir eine Lösung für dieses Problem benötigen (C#-Code, der auf Spielekonsolen für ein Nicht-Unity-Projekt ausgeführt wird), verwenden wir eine Mono-AOT-basierte Toolkette. Aber es hat einige ernsthafte Einschränkungen und funktioniert nicht so gut.

Daher prüfen wir, ob wir CoreRT auf 3 beliebten Spielkonsolen (XBox One; PlayStation 4 und Nintendo Switch) zum Laufen bringen. Ein erstes Konzept zeigt, dass es tatsächlich funktioniert (noch mit einigen Einschränkungen), aber bereits mit einer signifikanten Verbesserung der Laufzeitleistung im Vergleich zur Mono-basierten Lösung.

Aber mit der NDA-Situation in Bezug auf Spielkonsolen ist die offizielle Unterstützung für diesen Verwendungszweck noch weit hergeholt, als überhaupt ein offizielles natives AOT zu erhalten.

@RalfKornmannEnvision Verwenden Sie die Xamarin Xbox One/PS4 Mono-Ports mit LLVM-Codegen?

@RalfKornmannEnvision Verwenden Sie die Xamarin Xbox One/PS4 Mono-Ports mit LLVM-Codegen?

@lateralusX Da die Integration von jemand anderem durchgeführt wurde, weiß ich keine Details. Aber soweit ich weiß, haben sie die Mono-Ports verwendet, die für die XBox One/PS4 vorgesehen sind, und einen einfachen Port für den Switch erstellt. selbst.

@RalfKornmannEnvision Wäre toll in Kontakt zu treten und die diesbezüglichen Erfahrungen zu diskutieren. Das LLVM-Codegen hat (je nach Projekt) sehr positive Auswirkungen auf die Leistung des generierten Codes. Wenn das also nicht verwendet wurde (muss aktiviert werden), gibt es normalerweise viel zu gewinnen, wenn man es einfach aktiviert. Bist du auf dem DotNetEvolution-Discord-Server, wenn ja, könnten wir dort vielleicht eine Offline-Diskussion darüber führen?

@lateralusX Ich bin mir ziemlich sicher, dass die Teammitglieder, die daran gearbeitet haben, das LLVM-Codegen aktiviert und andere Dinge ausprobiert haben. Ihre letzte Aussage, bevor sie zu einem anderen Projekt übergingen, war, dass dies das Beste sei, was sie tun könnten.

Als Teil meiner Untersuchung erstelle ich einen Benchmark mit der Kernkomponente unter Verwendung von Xamarin Android und führe ihn auf einem Tegra X1-basierten Gerät aus, um zu sehen, ob wir aufgrund eines Problems mit unserem benutzerdefinierten Switch-Port von Mono an Leistung verloren haben. Leider war die Leistung des Xamarin-Projekts nicht so anders als die, die wir auf der Switch gesehen haben.

Es tut mir leid, dass ich nicht auf diesem Discord-Server bin, und um ehrlich zu sein, weiß ich sowieso nicht so viel über die aktuelle MONO-Integration. Aus meiner Sicht ist es sowieso eine Sackgasse für dieses Projekt. Der aktuelle CoreRT-Prototyp (bei noch weniger offizieller Unterstützung) ist in Bezug auf Leistung und Benutzerfreundlichkeit bereits weit überlegen.

@RalfKornmannEnvision OK, danke für deine Informationen und dein Feedback, alles sehr wertvoll.