Runtime: Enquête : AOT natif

Je ne pouvais pas trouver la meilleure étiquette de zone à ajouter à ce problème. Si vous avez des autorisations d'écriture, aidez-moi à apprendre en ajoutant exactement une étiquette de zone .

On dirait une faute de frappe - * 9. Which of these tasks are apart of your production debugging workflow? (Please select all that apply) Peut-être que ça devrait être "une partie de" ?

Je suis tellement content de voir ce problème ! 😄🚀

Question : pour les développeurs UWP qui ont travaillé avec la chaîne d'outils .NET Native, devrions-nous répondre à l'enquête en disant simplement que nous n'avons jamais utilisé CoreRT auparavant, ou puisque .NET Native présente de nombreuses similitudes (et du code partagé également ?) avec CoreRT, devrions-nous nous mentionnons simplement cela dans les notes, puis répondons aux autres questions CoreRT uniquement en ce qui concerne notre expérience avec .NET Native ? 🤔

@ Sergio0694 merci pour la question UWP. Je suis d'accord, je pense qu'il est logique de le mentionner dans les notes et de répondre à l'utilisation corert si vous aviez utilisé la version open source.

Merci d'avoir publié ce sondage !

J'étais également confus quant à la façon de répondre à certaines questions en tant que développeur UWP qui n'a utilisé que .NET Native. J'ai un certain nombre d'opinions sur la chaîne d'outils .NET Native d'UWP, mais je n'ai pas vraiment trouvé d'endroit où les écrire. Tout à fait bien si cela sort du cadre de cette enquête, mais cela pourrait valoir la peine d'être clarifié.

Je soupçonne également que "parce que .NET Native est la valeur par défaut pour les versions UWP et requises dans le Store" est probablement la raison la plus courante pour laquelle les gens utilisent AOT, mais ce n'est pas l'une des réponses pré-remplies pour la question 5.

Merci d'avoir inclus Avalonia dans les options de l'interface graphique :) Nous avons déjà expérimenté CoreRT+Avalonia et les résultats ont été de superbes applications d'interface graphique natives :D bien que nous n'ayons pas maintenu la compatibilité depuis 2 ans alors...

Une partie souvent oubliée de .net est le développement de jeux, de nombreuses plates-formes ne permettent pas à un JIT de fonctionner, pensez aux consoles ou aux appareils IOS.
Il est très important pour l'avenir du développement de jeux d'obtenir l'AOT natif .net en tant que citoyen de première classe de l'écosystème .net.
Certains moteurs de jeu ont lancé leur propre AOT (par exemple, Unity le fait avec il2cpp) mais c'est un naufrage absolu.
Une solution officielle serait donc plus que bienvenue. Cela pourrait être un événement qui changera l'industrie.
N'oubliez pas que l'industrie du jeu est en train de dépasser l'industrie du cinéma en termes de bénéfices et de chiffre d'affaires.
Les consoles sont l'endroit où le principal profit est réalisé.

Les options existantes d'optimisation des applications publiées fonctionnent bien pour la plupart des scénarios ciblés par .NET aujourd'hui.

...

AOT compte principalement dans les applications GUI. C'est là qu'il faut se concentrer. Je ne vois pas d'application Web, de services, etc. nécessitant cela

Je ne suis pas d'accord. Pour la meilleure UX de l'utilisateur final, AOT avec liaison statique est nécessaire pour les moteurs de jeu , les microservices sans serveur , les applications d'interface graphique de bureau, les applications iOS et Android , les SPA/bibliothèques côté client basés sur WASM et les outils CLI de base (~ quelques Mo).

J'ai souhaité pouvoir facilement compiler mon code AOT tout en essayant tous les scénarios ci-dessus en C # au cours des dernières années et je pense que .NET manque beaucoup par rapport aux langages basés sur LLVM comme Rust.

La raison pour laquelle les options de publication actuelles semblent « bien fonctionner » est que .NET n'a jamais été adapté aux scénarios ci-dessus et que les utilisateurs implémentent simplement leur propre AOT (par exemple : Unity, UWP, Mono) lors de l'utilisation de C#. Des solutions AOT partielles telles que comme image native (par exemple, ReadyToRun) peut "aider" dans les scénarios de démarrage à froid pour les applications serveur monolithiques ou les applications client de bureau volumineuses, mais la taille binaire est encore plusieurs fois supérieure à ce que produirait une exécution AOT complète.

.NET ne "fonctionne déjà pas bien" pour les microservices sans serveur/conteneurisés - ceux- ci pourraient grandement bénéficier de la compilation AOT, d'une taille binaire réduite et de dépendances minimales .
La solution actuelle ReadyToRun + Tiered Compilation + IL Linker a déjà atteint une limite de taille de fichier, ce qui est gênant pour les déploiements autonomes, comme celui recommandé par AWS Lambda dans son article de blog.

Le vrai problème est qu'il y a actuellement trop de runtimes/générateurs de code/chaînes d'outils/expériences disponibles avec leurs propres bizarreries : IL2CPP/Burst (Unity), le backend AOT de Mono (Xamarin/Blazor/Uno), .NET Native/CoreRT (UWP), Le backend LLVM de Mono, CrossGen/ReadyToRun (.NET Core), etc. et il est tout simplement inacceptable que .NET ne dispose pas d'une chaîne d'outils de compilation AOT standardisée.

Si toutes ces équipes combinaient leurs efforts d'ingénierie sur quelque chose de commun tel que CoreRT, le backend Mono LLVM ou le dotnet/lilic maintenant abandonné, AOT aurait été une bien meilleure expérience pour les développeurs .NET.

AOT avec liaison statique est désormais accessible à un grand nombre de développeurs avec CI/CD pour les masses et ce n'est plus seulement une gêne pour une augmentation marginale des performances.

Fin de partie C# : code natif, interface utilisateur native, interopérabilité rapide et facile, exportations natives et API orientées performances (par exemple, System.IO.Pipelines, System.Text.Json).

Je ne suis pas d'accord avec l'affirmation selon laquelle les applications Web n'en bénéficieraient pas. AOT aiderait grandement avec les charges de travail sans serveur (alias Azure Functions). Sans parler des avantages du temps de démarrage pour les outils CLI.

J'ai répondu à l'enquête, mais pour être honnête, je ne reçois pas cette demande continue d'enquêtes depuis le début de .NET Core 1.0, sans une direction claire où vont les choses.

.NET Native est ce que .NET aurait dû être depuis le début du projet Ext-VOS, et il y a l'expérience de Singularity et Midori à laquelle vous pouvez certainement vous identifier, ou même obtenir des serveurs internes avec eux.

Même Java a décidé de rattraper ses capacités AOT manquantes, l'équipe ne demande pas quelles charges de travail nous voulons qu'il fonctionne.

Nous utilisons à peine NGEN, car depuis la sortie de .NET, la génération de la qualité de son code n'a jamais été améliorée et le flux de travail de déploiement est pénible par rapport aux autres langages compilés AOT.

Donc, si à l'avenir, AOT est à nouveau supprimé de .NET, considérez que toute la concurrence dans les langages gérés se concentre désormais sur les chaînes d'outils AOT, et ils ne demandent pas non plus quels flux de travail nous aimerions utiliser le compilateur.

Je veux voir .NET continuer à prospérer et être la première option quel que soit le scénario, et si quoi que ce soit pour prendre en charge les flux de travail où Microsoft nous oblige toujours à utiliser C++ aux côtés de .NET, avec lesquels les autres langages compilés AOT n'ont pas de problèmes.

J'ai répondu à l'enquête, mais pour être honnête, je ne reçois pas cette demande continue d'enquêtes depuis le début de .NET Core 1.0, sans une direction claire où vont les choses.

Je pense que c'est une bonne chose que MS essaie d'écouter la communauté, plutôt que de simplement dicter ce que nous voulons.

@jkotas J'ai remarqué que deux liens différents pour cette enquête se répandent, est-ce que ça va ?
https://www.surveymonkey.com/r/7THQK5K
https://www.surveymonkey.com/r/SQV8JQK

@texasbruce demande aux autres développeurs qui ont répondu à des enquêtes similaires concernant la prise en charge de l'interface graphique multiplateforme, des outils WCF et EF dans quelle mesure cela a aidé.

Donc, même s'il est agréable qu'ils nous demandent, ce serait plus agréable lorsque des actions se produisent réellement. Même pour l'interface graphique multiplateforme, il reste à voir si MAUI se produira réellement ou si Blazor in Web Widgets est poussé comme solution.

Pour moi, la seule solution AOT acceptable est lorsqu'elle génère une véritable application native sans JIT du tout en mode de publication (pas d'alias de solution côte à côte prêt à l'emploi) et lorsqu'elle fonctionne sur tous¹ les développeurs de projets .NET travaillent au. Cela inclut spécifiquement Winforms et WPF. Dans le meilleur des cas, il devrait également fonctionner de manière autonome sans aucune dépendance d'exécution sans se gonfler de 3 Mo à 80 Mo.

¹ Pour des raisons techniques, il peut y avoir des cas/API AOT qui ne peuvent pas être pris en charge. Dire "sur tout" signifie ne pas prendre en charge toutes les API mais tous les types de projets pris en charge par .NET Core : dll / winforms / wpf / winui / console / maui / ... Quelque chose de similaire au passage de .NET Framework à .NET Core qui a permis la plupart développeurs de reprendre leurs applications existantes, c'est ce que j'ai en tête.

_J'ai également écrit des applications en Delphi et cela me dérange de voir que je viens de compiler puis d'expédier mon seul exécutable Delphi ailleurs et qu'il fonctionne. Et c'est juste plus rapide. Il en va de même pour une application C++ lorsqu'elle est compilée d'une manière spécifique. Et vous pouvez toujours déboguer les deux applications et les deux applications fournissent toujours un stacktrace/dump utile lorsque vous décidez d'inclure le PDB. Mais pour des raisons de sécurité, vous pouvez également décider de ne PAS l'inclure, ce qui fonctionne également très bien. Cela me dérange de me demander pourquoi ne pouvons-nous pas avoir cela avec C #? Quand j'ai entendu parler des plans AOT, je m'attendais à CECI._

Je vois toujours beaucoup de problèmes de réflexion mentionnés, et je pense que cela n'a pas beaucoup d'importance si le noyau ASP.net produit un gros exécutable.

La plupart des endroits où AOT est une exigence stricte sont des choses comme les outils CLI, les jeux et les applications d'interface utilisateur, ils peuvent être pointilleux sur les bibliothèques à inclure et peuvent éviter certains problèmes de réflexion. La priorité devrait être de permettre des applications "table rase".

Je vois toujours beaucoup de problèmes de réflexion mentionnés, et je pense que cela n'a pas beaucoup d'importance si le noyau ASP.net produit un gros exécutable.

Avec la sortie de Blazor WebAssembly, je pense que la taille de l'exécutable ainsi que la vitesse d'exécution vont être très importantes et qu'elles pourraient grandement bénéficier de l'AOT. Mais pour une raison quelconque, cela n'a même pas été mentionné spécifiquement dans l'enquête.

Oui jolie s'il vous plait ! J'envisageais d'utiliser Rust ou CoreRT afin de maintenir la sécurité de la mémoire et de gagner des vitesses natives et que mon code soit appelable en natif. Mais ce serait fantastique d'avoir AOT dans .NET, car il est incroyablement riche et puissant et Rust, bien que fantastique, n'est pas facile à faire la transition.

@jkotas J'ai remarqué que deux liens différents pour cette enquête se répandent, est-ce que ça va ?

Oui, nous utilisons différents liens SurveyMonkey pour différentes publications. Tous les liens pointent vers la même enquête. Cela nous permet de voir comment la distribution des réponses varie selon l'endroit où les gens ont trouvé l'enquête.

Pour gamedev nous en avons besoin, j'ai suspendu le travail sur mon moteur de jeu https://github.com/amerkoleci/alimer_sharp en faveur d'un moteur natif utilisant c++, je maintiens également les liaisons pour DirectX et vulkan, la performance est nécessaire ici

Pour gamedev nous en avons besoin, j'ai suspendu le travail sur mon moteur de jeu https://github.com/amerkoleci/alimer_sharp en faveur d'un moteur natif utilisant c++, je maintiens également les liaisons pour DirectX et vulkan, la performance est nécessaire ici

Scénario identique ici 😄, sauf que je ne l'ai pas suspendu . J'aime AOT à la fois pour les meilleurs temps de démarrage mais aussi (et dans mon cas, plus important encore), la possibilité d'avoir un code plus optimisé - je suis d'accord avec une augmentation de 50% des temps de construction pour une accélération de 10%, ce qui n'est évidemment pas c'est vraiment l'attitude d'un JIT

Je suis d'accord avec une augmentation de 50 % des temps de construction pour une accélération de 10 %, ce qui n'est évidemment pas vraiment l'attitude d'un JIT

C'est en fait l'une des principales raisons secondaires pour lesquelles je veux AOT dans .NET au lieu de passer à un écosystème différent. Je suis totalement gâté par les temps de compilation rapides des grands projets .NET par rapport aux grands projets C++ ou Rust.

Je veux JIT pour l'itération rapide pendant le développement, mais AOT une fois que j'expédie quelque chose à mes clients.

J'ai utilisé CoreRT pour créer des bibliothèques natives multiplateformes (et multiplateformes).

AOT avec liaison statique est nécessaire de toute urgence pour les moteurs de jeu dans iOS et la plate-forme de console qui désactivent le jit, et veulent également plusieurs modes de compilation aot :

1. plein
2. aot hybride qui prend en charge le mode d'exécution jit + aot ou interpréteur + aot
   l'aot hybride est vraiment important pour l'industrie du jeu, cela peut changer la donne

AOT avec liaison statique est nécessaire de toute urgence pour les moteurs de jeu dans iOS et la plate-forme de console qui désactivent le jit, et veulent également plusieurs modes de compilation aot :

1. plein
2. aot hybride qui prend en charge le mode d'exécution jit + aot ou interpréteur + aot
   l'aot hybride est vraiment important pour l'industrie du jeu, cela peut changer la donne

comme mono sur la plate-forme iOS, mode d'exécution aot + interprète.

Aot complet, exe unique, runtime indépendant et écrêtage de codes inutiles, cela me rend définitivement kreygasm XD

J'attends cette question depuis 10 ans. Bon sang, j'ai 5 projets sympas qui prennent la poussière sur le disque dur, car si je les libère, n'importe quel enfant peut les inverser, ajouter de petites modifications à l'interface graphique et les vendre comme les leurs.

J'ai développé Robocraft, Cardlife et Gamecraft avec Unity sur la plate-forme PC et je n'ai jamais eu besoin d'utiliser IL2CPP, sauf si nécessaire (lire Xbox One), pas même pour les serveurs de jeux. Personnellement, je verrais un mélange de compilation JIT et une solution comme Burst (qui fait un meilleur travail que je ne peux jamais faire en utilisant des intrinsèques explicites) comme plus que suffisant lorsque la performance est nécessaire. Cependant, je comprends qu'AOT est nécessaire pour les plates-formes qui nécessitent un code entièrement natif et pour les plates-formes où les ressources matérielles sont précieuses. Je comprends que les développeurs de la plate-forme .net puissent avoir des sentiments mitigés à propos de l'AOT, mais je ne pense pas que ce soit une option si nous voulons qu'elle soit adoptée plus largement dans le développement de jeux. Pour être honnête, cela me fait un peu peur que Unity ait le monopole de technologies comme IL2CPP et Burst.

Nous développons des simulateurs financiers/scientifiques performants et hautement évolutifs. Nos simulations peuvent durer de quelques minutes à plusieurs jours selon la complexité du modèle créé par l'utilisateur.

En raison de la nature de nos logiciels de simulation, les temps de démarrage ne sont presque jamais un problème, de même que la taille des logiciels/binaires. D'ailleurs, le temps qu'il faut pour installer le produit n'est pas non plus. Par exemple, il serait tout à fait acceptable pour nous que la compilation fasse partie de l'installation, même si un tel processus prenait beaucoup de temps.

Je dirais qu'environ 25% du code lors d'une exécution est créé dynamiquement, donc une approche hybride serait préférable; une combinaison de compilation AOT et JIT. Si les bits dynamiques devaient être interprétés, je pense qu'une grande partie des avantages de l'AOT serait diminuée, du moins dans notre cas d'utilisation.

Le GC est notre problème numéro un qui nous empêche d'atteindre une plus grande évolutivité (par exemple, une fois que nous obtenons environ 44 cœurs). Le fait que le compilateur soit capable d'effectuer des optimisations inter-assemblages plus approfondies, une incrustation agressive et une analyse d'échappement peut permettre d'allouer davantage d'objets de courte durée sur la pile au lieu du tas.

Il existe de nombreux endroits dans notre base de code où la qualité du code JIT devient un goulot d'étranglement, en particulier avec les allocations de registre et la gestion de nombreuses structures. Cela nous oblige à écrire du code pour manipuler le compilateur JIT pour faire ce qu'il faut (un tir à la corde fragile, obscurcissant et difficile à maintenir) ou à passer au code natif (et nous perdons beaucoup d'avantages du manque d'inlining et surcharge des transitions GC/PInvoke).

Parfois, de petites améliorations de la qualité du code peuvent faire des gains fous au cours d'un modèle qui fonctionne pendant des heures sur de nombreux cœurs. Pour nous, le JIT est devenu un peu fragile (encore moins déterministe) avec les performances, car notre base de code change avec le développement. Notre espoir serait qu'un compilateur AOT puisse prendre beaucoup plus de temps pour compiler et générer un code de bien meilleure qualité, réduisant certaines de ces fluctuations de performances inutiles et nous permettant de conserver une plus grande partie de notre base de code en C#.

En général, j'aimerais voir davantage d'investissements dans les technologies JIT et AOT.

cc @AndyAyersMS

AOT avec liaison statique est nécessaire de toute urgence pour les moteurs de jeu dans iOS et la plate-forme de console qui désactivent le jit,

Je suis totalement d'accord ici. Comme nous avons besoin d'une solution à ce problème (code C # exécuté sur des consoles de jeu pour un projet non Unity), nous utilisons une chaîne d'outils basée sur Mono-AOT. Mais il a de sérieuses limitations et ne fonctionne pas très bien.

Par conséquent, nous envisageons de faire fonctionner CoreRT sur 3 consoles de jeux en peuplier (XBox One, PlayStation 4 et Nintendo Switch). Un premier prof de concept montre que cela fonctionne réellement (toujours avec quelques limitations) mais déjà avec une amélioration significative des performances d'exécution par rapport à la solution basée sur Mono.

Mais avec la situation NDA autour des consoles de jeu, le support officiel pour cette cause d'utilisation est encore plus farfelu que d'obtenir l'AOT natif officiel en premier lieu.

Pour nous, le JIT est devenu un peu fragile (encore moins déterministe) avec les performances, car notre base de code change avec le développement.

@ jpapp05 J'aimerais en savoir plus sur votre application, et plus particulièrement sur le problème ci-dessus, car c'est l'une de mes principales préoccupations. N'hésitez pas à me contacter hors ligne (par e-mail dans le profil) si cela vous aide.

Salut @AndyAyersMS , ce serait génial. Je vous contacterai hors ligne car je peux parler un peu plus librement, mais je suis heureux de publier tout résumé de nos discussions pour le bénéfice des autres.

Je ne sais pas si c'est même un problème mais juste pour le mentionner ici.
Une fonctionnalité importante pour nous serait la possibilité de charger et de décharger dynamiquement des assemblys natifs lors de l'exécution.

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

Mon plus gros problème est que généralement .NET peut être facilement décompilé, sauf avec UWP Native, du moins pour ce que j'ai testé (j'espère avoir raison). Pas dans un état d'esprit "normal" d'entreprise, quelqu'un mettra beaucoup d'IP dans un projet qui peut être facilement décompilé.
Linux est cool, mais toutes les applications de bureau sont pour Windows dans le monde de l'entreprise.

Peut-être pour vous faciliter la vie, mettez une case à cocher qui dit :
COMPILATION NATIVE (Fonctionne UNIQUEMENT POUR WINDOWS 10 DESKTOP !)
Mec, fais ça et je ne me soucie plus d'AOT. Si cela fonctionne pour ASP.NET Core, cool ! Sinon, je m'en fous vraiment.

Au fait, merci d'avoir créé le problème et d'avoir réalisé l'enquête, vous avez fait un excellent travail car vous demandez l'avis de personnes qui utilisent la technologie dans leur travail. Je pense (en fait, j'en suis sûr) que vous manquez encore des tonnes d'opinions de développeurs de bureau qui ne s'impliquent généralement pas dans ces choses sur Github. Tout le monde ne se souvient pas (ou ne sait pas) que le code .NET peut être facilement décompilé et je suis sûr que leurs patrons deviendraient fous s'ils savaient : grin:.

Tout le monde ne se souvient pas (ou ne sait pas) que le code .NET peut être facilement décompilé

Chut ... Le fait que Rider le fasse automatiquement pour vous est incroyable lorsque j'essaie de comprendre comment quelque chose fonctionne dans les coulisses dans Unity ou des packages tiers. Pas aussi important maintenant, cependant, avec une grande partie du code étant open-source en premier lieu, mais vous voyez ce que je veux dire.

@jcbeppler Vous vous trompez, c'est un malentendu courant entre le bytecode et le natif, c'est juste une question d'avoir les bons outils.

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

Hex-Rays n'est qu'une solution possible, il y en a d'autres parmi lesquelles choisir.

@MostHated Ouais, j'ai compris. En fait, il est si simple de décompiler un logiciel en .NET que c'est comme si c'était open source et de nombreuses entreprises ne veulent pas que leur logiciel soit open source. "Il n'y a pas de repas gratuit" 😄

@pjmlp Je connais la différence entre décompiler et désassembler. Je ne peux rien contre le désassemblage de mon logiciel mais la compilation native peut rendre le logiciel beaucoup plus sécurisé car la personne ne peut pas faire une décompilation très simple. Un logiciel désassemblé aura certainement l'air bizarre et le code désassemblé peut même ne pas fonctionner correctement.

@jcbeppler Vous vous trompez, c'est un malentendu courant entre le bytecode et le natif, c'est juste une question d'avoir les bons outils.

Actuellement, un programme .NET décompilé révèle l'intégralité du code source. Cela inclut même tous les noms de méthodes et les noms de variables. C'est cool pour le débogage et nous permet d'avoir un stacktrace "lisible" lorsqu'une exception se produit. Cependant, c'est une énorme faille de sécurité et une raison pour laquelle il existe un énorme marché pour les obfuscateurs .NET.

Une application native peut être désassemblée. Mais il ne descend pas pour révéler son code source complet C++/Delphi etc. (il existe des outils qui tentent de reconstruire ce code source mais les résultats sont horribles). Ce que vous obtenez est au maximum du code assembleur et des organigrammes de contrôle. Si vous avez de la chance et qu'il est livré avec un fichier de symboles, vous obtenez également les noms des fonctions, mais en mode de publication, ce fichier de symboles n'est généralement pas inclus, encore une fois pour des raisons de sécurité.

Nous pouvons nous perdre dans les détails en parlant de la façon dont le code natif est une véritable protection. À mon avis, ce n'est pas une protection en termes de piratage (bien que grâce aux noms complets de méthodes / variables et à la génération complète de sources C #, une vérification de licence peut être supprimée sans nécessiter de connaissances particulières) ou de débogage, mais une protection contre les voleurs. Des outils comme dnSpy peuvent même exporter l'application .NET dans un projet VS complet en un SEUL CLIC. Il n'existe pas d'outil de ce type qui fonctionne de la même manière pour le code natif. Donc, pour les applications commerciales, ce serait une énorme victoire de générer du code natif, en plus du fait qu'elles n'ont plus à payer des milliers de dollars par an pour quelque chose qui ne fait que renommer toutes les méthodes et variables dans l'application finale.

Je suis curieux du résultat de cette enquête. Est-il prévu de les rendre publics sur la façon dont les gens ont voté?

@Symbai Ce n'est pas une protection contre quoi que ce soit, comme vous le dira tout développeur Android qui a essayé d'utiliser le NDK comme moyen de protéger son adresse IP. Les applications que vous mentionnez brièvement peuvent faire la même chose en un seul clic, et même si elles supposent généralement que le code C ou C++ est le code source d'origine, elles sont assez bonnes pour voler vos algorithmes.

Je veux AOT, pour les scénarios où .NET perdra à long terme contre Rust, Go, Swift, C++, Java (GraalVM), les applications de bureau, de console et mobiles/IoT où le temps de démarrage est vraiment important, il y a des contraintes élevées sur l'utilisation de la mémoire et la perte de vitesse due au JIT sur la charge d'assemblage n'est pas tolérable, tout comme dans certains scénarios ASP.NET, le code AOT peut être pertinent lorsque l'on met à l'échelle ses 100 instances de pods K8S.

D'un autre côté, je trouve également pertinent de conserver les capacités JIT, et de les améliorer également, sur des scénarios où JIT est la voie à suivre.

Il existe de nombreux langages qui offrent les deux modèles de compilation, permettant à leurs utilisateurs de choisir en fonction de la situation, donc fondamentalement, gardons JIT et améliorons l'histoire AOT dans la direction .NET Native, tout en oubliant la timide tentative nommée NGEN.

@Symbai Ce n'est pas une protection contre quoi que ce soit, comme vous le dira tout développeur Android qui a essayé d'utiliser le NDK comme moyen de protéger son adresse IP. Les applications que vous mentionnez brièvement peuvent faire la même chose en un seul clic, et même si elles supposent généralement que le code C ou C++ est le code source d'origine, elles sont assez bonnes pour voler vos algorithmes.

Voler un algorithme avec lequel je peux vivre, mais pas ce que .NET autorise aujourd'hui (par exemple WPF), où une personne a votre application complète magnifiquement et facilement prête à être exécutée en tant que projet VS. Je pense que UWP avec la compilation native fait du bon travail, si quelqu'un veut le démonter, ok, bonne chance ! J'utiliserai toujours la compilation native, quoi qu'il arrive. Le monde Android dont je ne peux pas parler, j'ai essayé AOT avec Xamarin Forms une fois et cela n'a vraiment pas fonctionné comme je m'y attendais.

Je pense que UWP avec la compilation native fait du bon travail, si quelqu'un veut le démonter, ok, bonne chance ! J'utiliserai toujours la compilation native, quoi qu'il arrive. Le monde Android dont je ne peux pas parler, j'ai essayé AOT avec Xamarin Forms une fois et cela n'a vraiment pas fonctionné comme je m'y attendais.

Spoiler - les personnes qui essaient d'atteindre votre source essaient probablement de s'améliorer/d'étendre/de s'intégrer avec vous, pas de vous arnaquer. S'ils essaient de vous arnaquer, alors vos mesures sont vraiment stupides.

Si j'écris un livre, demandez à quelqu'un de le traduire en japonais avant de le publier - je pourrais penser que je suis vraiment intelligent, parce que je ne comprends pas le japonais, et aucun de mes amis non plus. La réalité est cependant qu'il y a des pays entiers qui peuvent lire ce livre - et je ne fais rien de plus que de me tromper si je prétends le contraire.

Je dis cela en tant que développeur qui n'avait aucune expérience avec les binaires natifs désassemblés et qui a décidé de désosser le cryptage et les formats de données sur Star Citizen.

Il m'a fallu, à moi, quelqu'un sans expérience préalable, deux semaines pour partir de rien, pour avoir un programme qui peut non seulement décrypter leurs fichiers de données cryptés, mais aussi convertir leurs formats de données propriétaires en XML/JSON.

Après ces 2 semaines - je n'ai peut-être pas votre application complète prête à être exécutée en tant que projet VS - mais je me rends également compte que je n'en ai pas besoin. Il est beaucoup plus simple d'injecter mon propre code dans l'application existante, et de ne pas avoir à gérer tout leur code.

d'avoir un programme qui peut non seulement décrypter leurs fichiers de données cryptés

Le cryptage est quelque chose de complètement différent. Décompiler un JEU VIDEO pour créer des mods est quelque chose de complètement différent. La plupart des développeurs de jeux ne voient pas d'inconvénient à ce que leurs fans créent des mods, cela montre plutôt leur passion et leur amour pour le jeu. Et peut-être que le "cryptage" n'était pas du tout un cryptage, mais que les fichiers étaient simplement compressés pour une taille plus petite ? Pour ne pas avoir à stocker des milliers de fichiers uniques sur disque. Les performances auraient également pu être une raison ... la lecture de nombreux petits fichiers à partir du disque est plus lente que la lecture d'un fichier volumineux. Et après 2 semaines, vous avez pu décompresser les images emballées. Vous avez pu modifier le texte de certains fichiers de données. C'est formidable, mais ce n'est pas la raison pour laquelle les gens comme moi veulent se débarrasser du JIT.

Le problème que nous avons actuellement est que le code JIT peut être entièrement décompilé pour compléter le code source, Java a le même problème ainsi que tout autre langage JIT. Le code natif peut être désassemblé (cela transformera le code machine en code assembleur), les applications natives peuvent être crackées avec suffisamment de moyens, tout cela est vrai mais le code natif ne peut pas être compilé pour compléter le code source. Avez-vous déjà vu un outil comme dnSpy pour le code C++ ? Code Delphes ? Je n'ai pas. C'est parce qu'il n'est pas possible d'obtenir des noms de variables et de méthodes, ils n'existent plus simplement lorsqu'ils sont compilés correctement. Il n'est pas possible de transformer le désassemblage en C++ et de générer un projet entièrement fonctionnel que vous pouvez compiler. Cela doit sembler quelque chose de pas si important pour vous, mais c'est une chose énorme pour les applications commerciales. Nous voulons simplement nous débarrasser du fait que l'application .NET est un livre ouvert que tout le monde peut lire sans aucune connaissance. Lorsque nous investissons des milliers de dollars dans la recherche, nous ne voulons pas que tout le monde le regarde et le copie en quelques secondes. Nous voulons nous débarrasser de payer des milliers de dollars pour un obfuscateur dont le seul but est de renommer toutes les variables et les noms de méthodes, afin que les gens ne puissent plus ouvrir l'application et rechercher "licence" pour y accéder immédiatement. Ce n'est pas seulement (mais surtout) les coûts de l'obfuscateur, mais aussi le fait que les obfuscateurs créent des problèmes supplémentaires. J'ai rencontré cela moi-même assez souvent, en particulier avec la fréquence des versions de .NET Core. Nous avons dû attendre plusieurs semaines seulement pour un correctif qui fait fonctionner l'obfuscateur avec la dernière version de .NET Core.

Et bien que vous soyez confronté à tous ces problèmes en tant que développeur, vous devez également les expliquer à votre chef d'entreprise. À un moment donné, il pourrait vous demander s'il n'est pas préférable de simplement choisir un langage de programmation différent.

Avec C++ et Delphi, vous n'avez tout simplement pas ce problème. Je sais que ce n'est pas un problème pour tout le monde. Les développeurs open source trouveront le JIT plus intéressant et utile. Il est difficile de leur expliquer pourquoi quelqu'un veut que son code source soit un livre fermé, alors qu'ils pensent que les livres ouverts sont tout simplement meilleurs. Donc, idéalement, nous n'avons pas à nous expliquer nos points de vue complètement différents et AOT sera juste un interrupteur que vous pouvez activer en mode release si vous le souhaitez. Et si vous ne voulez pas, allez-y avec JIT.

Je suis vraiment reconnaissant à l'équipe .NET de nous avoir laissé choisir la "protection" comme raison pour laquelle nous voulons AOT ❤. Cela montre qu'ils sont conscients des besoins de certaines personnes. Et si les sondages révèlent que l'homme vote pour, nous pourrions enfin avoir une chance que l'implémentation AOT s'en occupe de la même manière qu'un compilateur C++. Pour votre information : je l'ai mis entre guillemets pour éviter toute discussion supplémentaire sur la protection réelle de l'AOT, les points de vue sont extrêmement larges sur celui-ci, comme nous l'avons peut-être déjà remarqué.

La sécurité n'est pas tout ou rien. La suppression d'IL n'empêche pas un attaquant déterminé d'inverser une application. Mais cela crée des obstacles qui sont pertinents d'un point de vue pratique. C'est de la défense en profondeur. C'est pourquoi les produits d'obfuscation IL peuvent être rationnels à utiliser.

Un de mes amis a craqué des produits .NET en décompilant IL en C # et en apportant des modifications plutôt triviales. Il n'est pas capable de cracker des applications natives. C'est beaucoup plus difficile. Il a également dû abandonner en présence d'obfuscateurs IL car l'outil de décompilation s'est écrasé sur ces binaires. Là encore, ces produits étaient protégés dans la pratique. Ça a marché.

@Symbaï

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

Hex-Rays fait du bon travail pour C, et il a des macros pour aider le processus de décision.

Avoir la source C, c'est un jeu d'enfant pour le convertir en C++ ou Delphi.

De plus, nous avons maintenant l'IA pour aider ceux qui ne sont pas assez habiles.

Ingénierie inverse neuronale des binaires dépouillés

Hex-Rays fait du bon travail pour C, et il a des macros pour aider le processus de décision.

Travaillez-vous pour Hex-Rays ou pour une entreprise qui vend des logiciels d'obscurcissement ? Il semble que.

Quoi qu'il en soit, même si vous le convertissez en C, le code sera très loin d'une bonne architecture C#. Même si vous récupérez des bouts de code, vous devrez y mettre pas mal d'efforts pour le modifier, l'améliorer, etc...
Si pour vous la compilation native n'est pas pertinente, ok. Mais pour beaucoup de gens, c'est pertinent.

BTW : Vous semblez très intéressé par la compilation JIT et vous semblez également avoir beaucoup d'expérience dans le désassemblage de logiciels. Je me demande pourquoi et où vous avez dû l'utiliser ? !

Indépendamment de ce que vous pensez de la facilité de décompilation de l'IL par rapport au code machine, cela ne change rien au fait qu'il s'agit d'une exigence réelle dans les vraies entreprises. (Et nous pourrions discuter de la validité ou de l'invalidité de cette exigence jusqu'à ce que les vaches rentrent à la maison.)

Mon employeur précédent a explicitement interdit la livraison d'outils .NET ou JVM en externe pour cette raison. Juste avant mon départ, une équipe a convaincu les supérieurs hiérarchiques de les laisser expédier un outil avec une forte obfuscation appliquée, mais sinon, nous écrivions des outils externes en C++ pour satisfaire la politique de l'entreprise.

Cette discussion a complètement dérapé. Si vous voulez tous avoir une guerre des flammes pour savoir si AOT est pertinent pour la protection IP, veuillez le faire ailleurs.

Hex-Rays fait du bon travail pour C, et il a des macros pour aider le processus de décision.

Travaillez-vous pour Hex-Rays ou pour une entreprise qui vend des logiciels d'obscurcissement ? Il semble que.

Quoi qu'il en soit, même si vous le convertissez en C, le code sera très loin d'une bonne architecture C#. Même si vous récupérez des bouts de code, vous devrez y mettre pas mal d'efforts pour le modifier, l'améliorer, etc...
Si pour vous la compilation native n'est pas pertinente, ok. Mais pour beaucoup de gens, c'est pertinent.

BTW : Vous semblez très intéressé par la compilation JIT et vous semblez également avoir beaucoup d'expérience dans le désassemblage de logiciels. Je me demande pourquoi et où vous avez dû l'utiliser ? !

Au contraire, je possède les compétences pour désosser le code natif en code source qui peut être utilisé par des tiers, donc je suis pleinement conscient que la compilation en code natif n'est qu'un obstacle pour les script kiddies, ce qui semble être la compréhension manquante ici.

EDIT : J'arrête également mes commentaires. Je voulais juste répondre à l'attaque personnelle.

Cloud Native et WPF Doit être AOT.
Client Windows pas d'exécution ! pas de juste à temps

Les résultats de l'enquête ont été publiés - https://github.com/dotnet/runtime/issues/41522. Nous sommes maintenant en train de faire un suivi auprès des personnes qui ont fourni leurs coordonnées et avons quelques questions de suivi supplémentaires.

AOT avec liaison statique est nécessaire de toute urgence pour les moteurs de jeu dans iOS et la plate-forme de console qui désactivent le jit,

Je suis totalement d'accord ici. Comme nous avons besoin d'une solution à ce problème (code C # exécuté sur des consoles de jeu pour un projet non Unity), nous utilisons une chaîne d'outils basée sur Mono-AOT. Mais il a de sérieuses limitations et ne fonctionne pas très bien.

Par conséquent, nous envisageons de faire fonctionner CoreRT sur 3 consoles de jeux en peuplier (XBox One, PlayStation 4 et Nintendo Switch). Un premier prof de concept montre que cela fonctionne réellement (toujours avec quelques limitations) mais déjà avec une amélioration significative des performances d'exécution par rapport à la solution basée sur Mono.

Mais avec la situation NDA autour des consoles de jeu, le support officiel pour cette cause d'utilisation est encore plus farfelu que d'obtenir l'AOT natif officiel en premier lieu.

@RalfKornmannEnvision Utilisez -vous les ports Xamarin Xbox One/PS4 Mono avec codegen LLVM ?

@RalfKornmannEnvision Utilisez -vous les ports Xamarin Xbox One/PS4 Mono avec codegen LLVM ?

@lateralusX Comme l'intégration a été faite par quelqu'un d'autre, je ne connais aucun détail. Mais pour autant que je sache, ils ont utilisé les ports mono fournis pour la XBox One/PS4 et ont créé un port simple pour le commutateur. eux-mêmes.

@RalfKornmannEnvision Ce serait formidable d'entrer en contact et de discuter de l'expérience liée à cela. Le codegen LLVM a (selon le projet) des effets de performance très positifs sur le code généré, donc s'il n'a pas été utilisé (doit être activé), il y a normalement beaucoup à gagner en l'activant simplement. Êtes-vous sur le serveur de discorde DotNetEvolution, si oui, peut-être pourrions-nous avoir une discussion hors ligne à ce sujet ?

@lateralusX Je suis à peu près sûr que les membres de l'équipe qui ont travaillé dessus ont activé le codegen LLVM et essayé d'autres choses. Leur dernière déclaration avant de passer à un autre projet était que c'était le mieux qu'ils pouvaient faire.

Dans le cadre de mon enquête, je construis une référence avec le composant principal en utilisant Xamarin Android et je l'exécute sur un appareil basé sur Tegra X1 pour voir si nous avons perdu des performances en raison d'un problème avec notre port Switch personnalisé de Mono. Malheureusement, les performances du projet Xamarin n'étaient pas si différentes de ce que nous avons vu sur le Switch.

Je suis désolé de ne pas être sur ce serveur Discord et pour être honnête, je ne sais pas grand-chose sur l'intégration MONO actuelle de toute façon. De mon point de vue c'est de toute façon une impasse pour ce projet. Le prototype CoreRT actuel (tout en ayant encore moins de support officiel) est déjà bien supérieur en termes de performances et de convivialité.

@RalfKornmannEnvision OK, merci pour vos informations et vos commentaires, tous très précieux.