Runtime: Encuesta: AOT nativo

No pude encontrar la mejor etiqueta de área para agregar a este problema. Si tiene permisos de escritura, ayúdeme a aprender agregando exactamente una etiqueta de área .

Parece un error tipográfico - * 9. Which of these tasks are apart of your production debugging workflow? (Please select all that apply) ¿Tal vez debería ser "una parte de"?

¡Estoy tan feliz de ver este problema! 😄🚀

Pregunta: para los desarrolladores de UWP que han trabajado con la cadena de herramientas de .NET Native, ¿deberíamos responder a la encuesta simplemente diciendo que no hemos usado CoreRT antes, o dado que .NET Native tiene muchas similitudes (¿y algún código compartido también?) con CoreRT, deberíamos solo mencionamos esto en las notas y luego respondemos las otras preguntas de CoreRT solo con respecto a nuestra experiencia con .NET Native. 🤔

@ Sergio0694 gracias por la pregunta UWP. Estoy de acuerdo, creo que tiene sentido mencionar eso en las notas y responder al uso corert si hubiera usado la versión de código abierto.

¡Gracias por publicar esta encuesta!

También estaba confundido acerca de cómo responder ciertas preguntas como desarrollador de UWP que solo ha usado .NET Native. Tengo varias opiniones sobre la cadena de herramientas .NET Native de UWP, pero realmente no encontré un lugar para escribirlas. Totalmente bien si eso está fuera del alcance de esta encuesta, pero podría valer la pena aclararlo.

También sospecho que "porque .NET Native es el valor predeterminado para las compilaciones de lanzamiento de UWP y se requiere en la tienda" es probablemente la razón más común por la que las personas usan AOT, pero no es una de las respuestas completadas previamente para la pregunta 5.

Gracias por incluir Avalonia en las opciones de GUI :) Hemos experimentado con CoreRT+Avalonia antes y los resultados fueron magníficas aplicaciones nativas de GUI :D aunque no hemos mantenido la compatibilidad desde hace 2 años...

Una parte a menudo olvidada de .net es el desarrollo de juegos, muchas plataformas no permiten que se ejecute un JIT, piense en consolas o dispositivos IOS.
Es muy importante para el futuro del desarrollo de juegos conseguir que AOT nativo de .net sea un ciudadano de primera clase del ecosistema .net.
Algunos motores de juegos lanzaron su propio AOT (por ejemplo, Unity lo hace con il2cpp), pero es un desastre absoluto.
Así que una solución oficial sería más que bienvenida. Podría ser un evento que cambie la industria.
No olvide que la industria de los juegos está superando a la industria cinematográfica tanto en ganancias como en facturación.
Las consolas es donde se obtienen las principales ganancias.

Las opciones existentes para optimizar las aplicaciones publicadas funcionan bien para la mayoría de los escenarios a los que se dirige .NET en la actualidad.

...

AOT importa principalmente en aplicaciones GUI. Ahí es donde necesita enfoque. No veo aplicaciones web, servicios, etc. que necesiten eso

Estoy en desacuerdo. Para obtener la mejor UX del usuario final, se necesita AOT con enlace estático para motores de juegos , microservicios sin servidor , aplicaciones GUI de escritorio, aplicaciones iOS y Android , bibliotecas/SPA del lado del cliente basados ​​en WASM y herramientas CLI básicas (~pocos MB).

Deseaba poder compilar mi código con AOT fácilmente mientras probaba todos los escenarios anteriores en C# durante los últimos años y siento que .NET se está perdiendo mucho en comparación con los lenguajes basados ​​en LLVM como Rust.

La razón por la cual las opciones de publicación actuales parecen "funcionar bien" es porque .NET históricamente no ha sido adecuado para los escenarios anteriores y las personas simplemente implementan su propio AOT (por ejemplo: Unity, UWP, Mono) cuando usan C#. Soluciones de AOT parciales como ya que la imagen nativa (por ejemplo, ReadyToRun) podría "ayudar" en escenarios de arranque en frío para aplicaciones de servidor monolíticas o aplicaciones de cliente de escritorio grandes, pero el tamaño binario sigue siendo muchas veces mayor que lo que produciría un tiempo de ejecución AOT completo.

.NET ya no "funciona bien" para los microservicios sin servidor/en contenedores; estos podrían beneficiarse enormemente de la compilación AOT, el tamaño binario reducido y las dependencias mínimas .
La solución ReadyToRun + Tiered Compilation + IL Linker actual ya alcanzó un límite para el tamaño del archivo, lo que resulta molesto para las implementaciones autónomas, como la recomendada por AWS Lambda en su publicación de blog.

El verdadero problema es que actualmente hay demasiados tiempos de ejecución/generadores de código/cadenas de herramientas/experimentos disponibles con sus propias peculiaridades: IL2CPP/Burst (Unity), backend AOT de Mono (Xamarin/Blazor/Uno), .NET Native/CoreRT (UWP), El backend LLVM de Mono, CrossGen/ReadyToRun (.NET Core), etc. y es simplemente inaceptable que .NET no tenga una cadena de herramientas de compilación AOT estandarizada.

Si todos estos equipos combinaran su esfuerzo de ingeniería en algo común como CoreRT, el backend Mono LLVM o el ahora abandonado dotnet/lilic , AOT habría sido una experiencia mucho mejor para los desarrolladores de .NET.

AOT con enlace estático es accesible para una gran cantidad de desarrolladores ahora con CI/CD para las masas y ya no es solo una molestia para un aumento marginal en el rendimiento.

Juego final de C#: código nativo, interfaz de usuario nativa, interoperabilidad rápida y fácil, exportaciones nativas y API orientadas al rendimiento (por ejemplo, System.IO.Pipelines, System.Text.Json).

No estoy de acuerdo con la declaración que dice que las aplicaciones web no se beneficiarían de esto. AOT sería de gran ayuda con las cargas de trabajo sin servidor (también conocidas como Azure Functions). Sin mencionar los beneficios del tiempo de inicio para las herramientas CLI.

Respondí la encuesta, pero para ser honesto, no recibo esta solicitud continua de encuestas desde que comenzó .NET Core 1.0, sin una dirección clara hacia dónde van las cosas.

.NET Native es lo que .NET debería haber sido todo el tiempo, cuando comenzó el proyecto Ext-VOS, y existe la experiencia de Singularity y Midori con la que ustedes ciertamente pueden relacionarse, o incluso obtener algunos servidores internos con ellos.

Incluso Java ha decidido ponerse al día con sus capacidades AOT faltantes, el equipo no está preguntando qué cargas de trabajo queremos que funcione.

Apenas usamos NGEN, porque desde el lanzamiento de .NET, la generación de calidad de código nunca mejoró y el flujo de trabajo de implementación es un problema en comparación con otros lenguajes compilados de AOT.

Entonces, si en el futuro, AOT se elimina nuevamente de .NET, considere que toda la competencia en lenguajes administrados ahora se enfoca en las cadenas de herramientas de AOT, y tampoco preguntan qué flujos de trabajo nos gustaría usar el compilador.

Quiero ver que .NET siga floreciendo y siendo la primera opción, independientemente del escenario, y en todo caso, que se haga cargo de los flujos de trabajo en los que Microsoft todavía nos obliga a usar C++ junto con .NET, con los que otros lenguajes compilados de AOT no tienen problemas.

Respondí la encuesta, pero para ser honesto, no recibo esta solicitud continua de encuestas desde que comenzó .NET Core 1.0, sin una dirección clara hacia dónde van las cosas.

Creo que es genial que MS intente escuchar a la comunidad, en lugar de simplemente dictar lo que queremos.

@jkotas Noté que se están difundiendo dos enlaces diferentes para esta encuesta, ¿está bien?
https://www.surveymonkey.com/r/7THQK5K
https://www.surveymonkey.com/r/SQV8JQK

@texasbruce pregunte a los compañeros desarrolladores que respondieron encuestas similares con respecto al soporte de herramientas EF, WCF y GUI multiplataforma cuánto ha ayudado.

Entonces, si bien es bueno que nos pregunten, sería mejor cuando las acciones realmente sucedan. Incluso para la GUI multiplataforma, queda por ver si MAUI realmente sucederá o si obtendremos Blazor en Web Widgets como solución.

Para mí, la única solución AOT aceptable es cuando genera una verdadera aplicación nativa sin JIT en modo de lanzamiento (sin alias de solución en paralelo lista para ejecutar) y cuando funciona en todos los proyectos¹ .NET en los que están trabajando los desarrolladores. sobre. Esto incluye específicamente Winforms y WPF. En el mejor de los casos, también debería funcionar de forma independiente sin dependencias de tiempo de ejecución sin inflarse de 3 MB a 80 MB.

¹ Por motivos técnicos, es posible que haya casos/apis que AOT no admita. Decir "en todos" significa no admitir todas las API, sino todos los tipos de proyectos. NET Core admite: dll / winforms / wpf / winui / console / maui / ... Algo similar a cambiar de .NET Framework a .NET Core, lo que permitió la mayoría lo que tengo en mente es que los desarrolladores se hagan cargo de sus aplicaciones existentes.

_También he escrito aplicaciones en Delphi y me molesta ver que solo compilo y luego envío mi único ejecutable de Delphi a otro lugar y simplemente se ejecuta. Y es simplemente más rápido. Lo mismo se aplica a una aplicación C++ cuando se compila de una manera específica. Y aún puede depurar ambas aplicaciones y ambas aplicaciones aún brindan un seguimiento/volcado de pila útil cuando decide incluir el PDB. Pero por razones de seguridad, también puede decidir NO incluirlo, lo que también funciona bien. Me molesta preguntarme por qué no podemos tener eso con C#. Cuando me enteré de los planes de AOT, esperaba ESTO._

Siempre veo que se mencionan mucho los problemas con la reflexión, y creo que en realidad no importa mucho si el núcleo de ASP.net produce un ejecutable grande.

La mayoría de los lugares donde AOT es un requisito estricto son cosas como herramientas CLI, juegos y aplicaciones de interfaz de usuario, pueden ser exigentes con respecto a qué bibliotecas incluir y pueden eludir algunos problemas de reflexión. La prioridad debe ser habilitar aplicaciones de "borrón y cuenta nueva".

Siempre veo que se mencionan mucho los problemas con la reflexión, y creo que en realidad no importa mucho si el núcleo de ASP.net produce un ejecutable grande.

Con el lanzamiento de Blazor WebAssembly, creo que el tamaño del ejecutable y también la velocidad de ejecución serán muy importantes y podría beneficiarse enormemente de AOT. Pero por alguna razón ni siquiera se mencionó específicamente en la encuesta.

¡Sí, bonita por favor! Estaba considerando usar Rust o CoreRT para mantener la seguridad de la memoria y obtener velocidades nativas y hacer que mi código sea invocable de forma nativa. Pero sería fantástico tener AOT en .NET, ya que es increíblemente rico y poderoso, y Rust, aunque fantástico, no es una transición fácil.

@jkotas Noté que se están difundiendo dos enlaces diferentes para esta encuesta, ¿está bien?

Sí, usamos diferentes enlaces de SurveyMonkey para diferentes publicaciones. Todos los enlaces apuntan a la misma encuesta. Nos permite ver cómo varía la distribución de las respuestas según el lugar donde las personas encontraron la encuesta.

Para gamedev necesitamos esto, suspendí el trabajo en mi motor de juego https://github.com/amerkoleci/alimer_sharp a favor del motor nativo usando c++, también mantengo enlaces para DirectX y vulkan, aquí se necesita rendimiento

Para gamedev necesitamos esto, suspendí el trabajo en mi motor de juego https://github.com/amerkoleci/alimer_sharp a favor del motor nativo usando c++, también mantengo enlaces para DirectX y vulkan, aquí se necesita rendimiento

Escenario idéntico aquí 😄, excepto que no lo suspendí. Me gusta AOT tanto por los mejores tiempos de inicio como también (y en mi caso, más importante), la oportunidad de tener un código más optimizado. Estoy bien con un aumento del 50% en los tiempos de compilación para una aceleración del 10%, que obviamente no es t realmente la actitud de un JIT

Estoy bien con un aumento del 50 % en los tiempos de compilación para una aceleración del 10 %, que obviamente no es realmente la actitud de un JIT

En realidad, esta es una de las grandes razones secundarias por las que quiero AOT en .NET en lugar de cambiar a un ecosistema diferente. Estoy totalmente mimado por los rápidos tiempos de compilación de los grandes proyectos .NET en comparación con los grandes proyectos C++ o Rust.

Quiero JIT para la iteración rápida durante el desarrollo, pero AOT una vez que estoy enviando algo a mis clientes.

Usé CoreRT para crear bibliotecas nativas multiplataforma (y multiplataforma).

Se necesita urgentemente AOT con enlace estático para los motores de juego en iOS y la plataforma de consola que deshabilitan jit, y también quieren múltiples modos de compilación aot:

1. lleno mucho
2. híbrido aot que admite el modo de ejecución jit + aot o interpreter + aot
   híbrido aot es realmente importante para la industria del juego, puede cambiar el juego

Se necesita urgentemente AOT con enlace estático para los motores de juego en iOS y la plataforma de consola que deshabilitan jit, y también quieren múltiples modos de compilación aot:

1. lleno mucho
2. híbrido aot que admite el modo de ejecución jit + aot o interpreter + aot
   híbrido aot es realmente importante para la industria del juego, puede cambiar el juego

como mono en la plataforma iOS, modo de ejecución aot+interpreter.

Aot completo, exe único, tiempo de ejecución independiente y recorte de códigos innecesarios definitivamente me hace kreygasm XD

Llevo 10 años esperando esta pregunta. Maldita sea, tengo 5 proyectos geniales que están acumulando polvo en el disco duro, porque si los publico, cualquier niño puede revertirlos, agregar pequeños cambios a la GUI y venderlos como propios.

Desarrollé Robocraft, Cardlife y Gamecraft con Unity en la plataforma de PC y nunca necesité usar IL2CPP, a menos que fuera necesario (léase Xbox one), ni siquiera para los servidores del juego. Personalmente, vería una combinación de compilación JIT y una solución como Burst (que hace un mejor trabajo que el que puedo hacer usando intrínsecos explícitos) como más que suficiente cuando el rendimiento es necesario. Sin embargo, entiendo que AOT es necesario para las plataformas que requieren código completamente nativo y para aquellas plataformas donde los recursos de hardware son preciosos. Entiendo cómo los desarrolladores de la plataforma .net pueden tener sentimientos encontrados sobre AOT, pero no creo que sea una opción si queremos que se adopte de manera más amplia en el desarrollo de juegos. Para ser honesto, me asusta un poco que Unity tenga el monopolio de tecnología como IL2CPP y Burst.

Desarrollamos simuladores financieros/científicos de alto rendimiento y alta escalabilidad. Nuestras simulaciones pueden ejecutarse desde unos pocos minutos hasta muchos días, según la complejidad del modelo que cree el usuario.

Debido a la naturaleza de nuestro software de simulación, los tiempos de inicio casi nunca son una preocupación, así como los tamaños binarios/del software. Por lo demás, tampoco lo es el tiempo que lleva instalar el producto. Por ejemplo, sería completamente aceptable para nosotros si la compilación fuera parte de la instalación, incluso si dicho proceso llevara mucho tiempo.

Diría que alrededor del 25% del código durante una ejecución se crea dinámicamente, por lo que sería preferible un enfoque híbrido; alguna combinación de compilación AOT y JIT. Si tuvieran que interpretarse los bits dinámicos, creo que muchos de los beneficios de AOT se verían disminuidos, al menos en nuestro caso de uso.

El GC es nuestro principal problema que nos impide lograr una mayor escalabilidad (por ejemplo, una vez que tengamos alrededor de 44 núcleos). Hacer que el compilador sea capaz de realizar optimizaciones más profundas entre ensamblajes, alineación agresiva y análisis de escape puede permitir que se asignen más objetos de corta duración en la pila en lugar del montón.

Hay muchos lugares en nuestra base de código donde la calidad del código JIT se convierte en un cuello de botella, particularmente con las asignaciones de registros y el manejo de muchas estructuras. Esto nos obliga a escribir código para manipular el compilador JIT para que haga lo correcto (un tira y afloja que es frágil, ofuscador y difícil de mantener) o cambiar al código nativo (y perdemos muchos beneficios por la falta de alineación). y gastos generales de las transiciones GC/PInvoke).

A veces, las pequeñas mejoras en la calidad del código pueden generar ganancias increíbles en el transcurso de un modelo que se ejecuta durante horas en numerosos núcleos. Para nosotros, el JIT se ha vuelto un poco frágil (incluso menos determinista) con el rendimiento, ya que nuestra base de código cambia con el desarrollo. Nuestra esperanza sería que un compilador AOT pudiera tomar mucho más tiempo para compilar y generar un código de calidad mucho mayor, reduciendo algunas de estas fluctuaciones de rendimiento innecesarias y permitiéndonos mantener una mayor parte de nuestra base de código en C#.

En general, me encantaría ver más inversiones tanto en tecnologías JIT como AOT.

cc @AndyAyersMS

Se necesita urgentemente AOT con enlace estático para motores de juego en iOS y plataforma de consola que deshabilitan jit,

Estoy totalmente de acuerdo aquí. Como necesitamos una solución para este problema (código C# que se ejecuta en consolas de juegos para un proyecto que no es de Unity), estamos usando una cadena de herramientas basada en Mono-AOT. Pero tiene algunas limitaciones serias y no funciona tan bien.

Por lo tanto, estamos buscando que CoreRT se ejecute en 3 consolas de juegos poplar (XBox One, PlayStation 4 y Nintendo Switch). Una prueba de concepto inicial muestra que realmente funciona (todavía con algunas limitaciones) pero ya con una mejora significativa en el rendimiento del tiempo de ejecución en comparación con la solución basada en Mono.

Pero con la situación de NDA en torno a las consolas de juegos, el soporte oficial para esta causa de uso es incluso más descabellado que obtener AOT nativo oficial en primer lugar.

Para nosotros, el JIT se ha vuelto un poco frágil (incluso menos determinista) con el rendimiento, ya que nuestra base de código cambia con el desarrollo.

@jpapp05 Me encantaría saber más acerca de su aplicación, y específicamente del problema anterior, ya que es una de mis principales preocupaciones. No dude en ponerse en contacto conmigo fuera de línea (por correo electrónico en el perfil) si eso ayuda.

Hola @AndyAyersMS , eso sería genial. Me pondré en contacto con usted fuera de línea ya que puedo hablar un poco más libremente, pero me complace publicar cualquier resumen de nuestras discusiones para el beneficio de los demás.

No sé si esto es incluso un problema, pero solo para mencionarlo aquí.
Una característica importante para nosotros sería la capacidad de cargar y descargar dinámicamente ensamblados nativos en tiempo de ejecución.

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

Mi mayor problema es que, por lo general, .NET se puede descompilar fácilmente, excepto con UWP Native, al menos hasta donde lo probé (espero tener razón). No en una mentalidad de empresa "normal", alguien pondrá una gran cantidad de IP en un proyecto que se puede descompilar fácilmente.
Linux es genial, está bien, pero todas las aplicaciones de escritorio son para Windows en el mundo empresarial.

Tal vez para hacer la vida más fácil, ponga una casilla de verificación que diga:
COMPILACIÓN NATIVA (¡FUNCIONA SOLO PARA WINDOWS 10 DE ESCRITORIO!)
Hombre, haz eso y ya no me importa AOT. Si funciona para ASP.NET Core, ¡genial! Si no, realmente no me importa.

Por cierto, gracias por crear el problema y hacer la encuesta, hiciste un gran trabajo porque estás pidiendo la opinión de las personas que usan la tecnología en sus trabajos. Creo (de hecho, estoy seguro) que todavía extrañas toneladas de opiniones de desarrolladores de escritorio que generalmente no se involucran en estas cosas en Github. No todos recuerdan (o saben) que el código .NET se puede descompilar fácilmente y estoy seguro de que sus jefes se volverían locos si supieran : grin:.

No todos recuerdan (o saben) que el código .NET se puede descompilar fácilmente

Shhh... El hecho de que Rider haga esto por usted automáticamente es sorprendente cuando trato de descubrir cómo funciona algo detrás de escena en Unity o paquetes de terceros. Sin embargo, ahora no es tan importante, ya que gran parte del código es de código abierto en primer lugar, pero entiendes lo que quiero decir.

@jcbeppler Está equivocado, ese es un malentendido común entre el código de bytes y el nativo, solo es cuestión de tener las herramientas adecuadas.

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

Hex-Rays es solo una posible solución, hay otras para elegir.

@MostHated Sí, lo tengo. De hecho, es tan simple descompilar un software en .NET que es como si fuera de código abierto y muchas empresas no quieren que su software sea de código abierto. "No existe tal cosa como un almuerzo gratis" 😄

@pjmlp Sé la diferencia entre descompilar y desensamblar. No puedo hacer nada contra el desensamblaje de mi software, pero la compilación nativa puede hacer que el software sea mucho más seguro porque la persona no puede hacer una descompilación muy simple. Un software desensamblado definitivamente se verá extraño y es posible que el código desensamblado ni siquiera se ejecute correctamente.

@jcbeppler Está equivocado, ese es un malentendido común entre el código de bytes y el nativo, solo es cuestión de tener las herramientas adecuadas.

Actualmente, un programa .NET descompilado revela el código fuente completo. Esto incluso incluye todos los nombres de métodos y nombres de variables. Esto es genial para la depuración y nos permite tener un seguimiento de pila "legible" cuando ocurre una excepción. Sin embargo, es una gran falla de seguridad y una de las razones por las que existe un gran mercado para los ofuscadores de .NET.

Una aplicación nativa se puede desmontar. Pero no baja para revelar su código fuente completo de C++/Delphi, etc. (hay algunas herramientas que intentan reconstruir este código fuente pero los resultados son horribles). Lo que obtienes es código ensamblador y diagramas de flujo de control como máximo. Si tiene suerte y se envía con un archivo de símbolos, también obtiene los nombres de las funciones, pero en el modo de lanzamiento, este archivo de símbolos generalmente no se incluye, nuevamente por motivos de seguridad.

Podemos perdernos en detalles hablando de cómo el código nativo es una protección real. En mi opinión, no es una protección en términos de craqueo (aunque gracias a los nombres de variables/métodos completos y a la generación completa de fuente de C#, se puede eliminar una verificación de licencia sin necesidad de ningún conocimiento especial) o depuración, sino una protección contra los ladrones. Herramientas como dnSpy pueden incluso exportar la aplicación .NET a un proyecto VS completo con UN SOLO CLIC. No existe tal herramienta que funcione de la misma manera para el código nativo. Entonces, para las aplicaciones comerciales sería una gran victoria generar código nativo, además del hecho de que ya no tienen que pagar miles de dólares al año por algo que simplemente cambia el nombre de todos los métodos y variables en la aplicación final.

Tengo curiosidad por el resultado de esta encuesta. ¿Hay algún plan para hacerlos públicos sobre cómo votó la gente?

@Symbai No es una protección contra nada, como te dirá cualquier desarrollador de Android que haya intentado usar el NDK como medio para proteger su IP. Las aplicaciones que menciona brevemente pueden hacer lo mismo con un solo clic, y aunque generalmente asumen el código C o C ++ como código fuente original, son lo suficientemente buenas como para robar sus algoritmos.

Quiero AOT, para escenarios en los que .NET perderá a largo plazo frente a Rust, Go, Swift, C++, Java (GraalVM), escritorio, consola y aplicaciones móviles/IoT donde el tiempo de inicio es realmente importante, hay grandes restricciones en el uso de la memoria y la pérdida de velocidad debido a JIT en la carga de ensamblaje no es tolerable, al igual que en algunos escenarios de ASP.NET, el código AOT puede ser relevante cuando uno está escalando sus 100 instancias de pods K8S.

Por otro lado, también encuentro relevante mantener las capacidades JIT y mejorarlas también, en escenarios donde JIT es el camino a seguir.

Hay muchos lenguajes que ofrecen ambos modelos de compilación, lo que permite a sus usuarios elegir según la situación, así que básicamente mantengamos JIT y mejoremos la historia de AOT en la dirección de .NET Native, mientras nos olvidamos del tímido intento llamado NGEN.

@Symbai No es una protección contra nada, como te dirá cualquier desarrollador de Android que haya intentado usar el NDK como medio para proteger su IP. Las aplicaciones que menciona brevemente pueden hacer lo mismo con un solo clic, y aunque generalmente asumen el código C o C ++ como código fuente original, son lo suficientemente buenas como para robar sus algoritmos.

Robar un algoritmo con el que puedo vivir, pero no lo que .NET permite hoy (por ejemplo, WPF), donde una persona tiene su aplicación completa hermosa y fácilmente lista para ejecutarse como un proyecto VS. Creo que UWP con compilación nativa hace un buen trabajo, si alguien quiere desarmarlo, ¡bueno, buena suerte! Siempre usaré la compilación nativa, pase lo que pase. Mundo Android del que no puedo hablar, probé AOT con Xamarin Forms una vez y realmente no funcionó como esperaba.

Creo que UWP con compilación nativa hace un buen trabajo, si alguien quiere desarmarlo, ¡bueno, buena suerte! Siempre usaré la compilación nativa, pase lo que pase. Mundo Android del que no puedo hablar, probé AOT con Xamarin Forms una vez y realmente no funcionó como esperaba.

Spoiler: las personas que están tratando de llegar a su fuente probablemente estén tratando de mejorar/ampliar/integrarse con usted, no estafarlo. Si están tratando de estafarlo, entonces sus métricas son realmente tontas.

Si escribo un libro, pido a alguien que lo traduzca al japonés antes de publicarlo; podría pensar que soy muy inteligente, porque no entiendo japonés, y tampoco mis amigos. Sin embargo, la realidad es que hay países enteros que pueden leer ese libro, y no estoy haciendo más que engañarme a mí mismo si pretendo lo contrario.

Digo esto como un desarrollador que no tenía experiencia con binarios nativos desensamblados y decidió aplicar ingeniería inversa al cifrado y los formatos de datos en Star Citizen.

A mí, alguien sin experiencia previa, me tomó dos semanas pasar de la nada a tener un programa que no solo puede descifrar sus archivos de datos cifrados, sino también convertir sus formatos de datos patentados en XML/JSON.

Después de esas 2 semanas, es posible que no tenga su aplicación completa lista para ejecutarse como un proyecto de VS, pero también me doy cuenta de que no es necesario. Es mucho más simple simplemente inyectar mi propio código en la aplicación existente y no tener que lidiar con todo su código.

a tener un programa que no solo puede descifrar sus archivos de datos cifrados

El cifrado es algo completamente diferente. Descompilar un VIDEOJUEGO para crear mods es algo completamente diferente. A la mayoría de los desarrolladores de juegos no les importa si sus fanáticos crean mods, sino que muestran su pasión y amor por el juego. ¿Y tal vez el "cifrado" no era un cifrado en absoluto, pero los archivos simplemente se empaquetaron para un tamaño más pequeño? Por no tener que almacenar miles de archivos individuales en disco. El rendimiento también podría haber sido una razón... leer muchos archivos pequeños del disco es más lento que leer un archivo enorme. Y después de 2 semanas, pudo descomprimir imágenes empaquetadas. Pudiste cambiar el texto dentro de algunos archivos de datos. Esto es genial, pero no es la razón por la que la gente como yo quiere deshacerse de JIT.

El problema que tenemos ahora es que el código JIT puede descompilarse completamente para completar el código fuente, Java tiene el mismo problema que cualquier otro lenguaje JIT. El código nativo se puede desensamblar (esto convertirá el código de máquina en código ensamblador), las aplicaciones nativas se pueden descifrar con suficiente dinero, todo esto es cierto, pero el código nativo no se puede compilar para completar el código fuente. ¿Alguna vez has visto una herramienta como dnSpy para código C++? ¿Código Delphi? no lo he hecho Es porque no es posible obtener nombres de variables y métodos, simplemente ya no existen cuando se compilan correctamente. No es posible convertir el desensamblado en C++ y generar un proyecto completamente funcional que pueda compilar. Esto debe sonar como algo que no es tan importante para usted, pero es algo muy importante para las aplicaciones comerciales. Solo queremos deshacernos del hecho de que la aplicación .NET es un libro abierto que todos pueden leer sin ningún conocimiento. Cuando invertimos miles de dólares en investigación, no queremos que todos lo vean y lo copien en un par de segundos. Queremos deshacernos de pagar miles de dólares por un ofuscador cuyo único propósito es cambiar el nombre de todas las variables y métodos, para que las personas ya no puedan abrir la aplicación y buscar "licencia" para acceder a ella de inmediato. No solo (sino principalmente) los costos del ofuscador, sino también que los ofuscadores crean problemas adicionales. Me encontré con esto muy a menudo, especialmente con la frecuencia de los lanzamientos de .NET Core. Tuvimos que esperar varias semanas solo por un parche que hace que el ofuscador funcione con la última versión de .NET Core.

Y mientras enfrenta todos estos problemas como desarrollador, también debe explicárselos a su gerente comercial. En algún momento, podría preguntarte si no es mejor elegir un lenguaje de programación diferente.

Con C++ y Delphi simplemente no tienes este problema. Sé que esto no es un problema para todos. Los desarrolladores de código abierto encontrarán el JIT más interesante y útil. Es difícil explicarles por qué alguien quiere que su código fuente sea un libro cerrado, cuando creen que los libros abiertos son simplemente mejores. Entonces, idealmente, no tenemos que explicarnos nuestras opiniones completamente diferentes y AOT será solo un interruptor que puede activar en el modo de lanzamiento si lo desea. Y si no quieres, adelante con JIT.

Estoy muy agradecido de que el equipo de .NET nos haya permitido elegir "protección" como una de las razones por las que queremos AOT ❤. Muestra que son conscientes de las necesidades que tienen algunas personas. Y si las encuestas revelan que el hombre vota por él, finalmente podríamos tener la oportunidad de que la implementación de AOT se encargue de esto de la misma manera que un compilador de C++. FYI: Lo puse entre comillas para evitar una mayor discusión sobre cuánta protección es realmente AOT, los puntos de vista son extremadamente amplios en este caso, como ya nos habrámos dado cuenta.

La seguridad no es todo o nada. La eliminación de IL no evita que un atacante determinado revierta una aplicación. Pero crea obstáculos que son relevantes en un sentido práctico. Es defensa en profundidad. Esta es la razón por la cual los productos de ofuscación de IL pueden ser de uso racional.

Un amigo mío ha descifrado productos .NET al descompilar IL a C# y realizar modificaciones bastante triviales. No es capaz de descifrar aplicaciones nativas. Es mucho más difícil. También tuvo que rendirse ante la presencia de ofuscadores de IL porque la herramienta de descompilación fallaba en esos binarios. Nuevamente, esos productos estaban protegidos en un sentido práctico. Funcionó.

@Symbai

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

Hex-Rays hace un buen trabajo para C y tiene macros para ayudar en el proceso de decisión.

Tener una fuente C es un juego de niños para convertirlo a C ++ o Delphi.

Además, ahora tenemos IA para ayudar a aquellos que no son lo suficientemente hábiles.

Ingeniería inversa neuronal de binarios despojados

Hex-Rays hace un buen trabajo para C y tiene macros para ayudar en el proceso de decisión.

¿Trabaja para Hex-Rays o para una empresa que vende software de ofuscación? Parece que.

De todos modos, incluso si lo convierte a C, el código estará muy lejos de una buena arquitectura C#. Incluso si obtiene partes del código, tendrá que esforzarse mucho para cambiarlo, mejorarlo, etc.
Si para ti la compilación nativa es irrelevante, ok. Pero para muchas personas es relevante.

Por cierto: pareces muy interesado en mantener la compilación JIT y también pareces tener mucha experiencia en desensamblar software. Me pregunto por qué y dónde tuviste que usar eso.

Independientemente de cómo se sienta cualquiera de ustedes acerca de la facilidad de descompilación de IL frente al código de máquina, no cambia el hecho de que es un requisito real en las empresas reales. (Y podríamos discutir sobre cuán válido o inválido podría ser ese requisito hasta que las vacas regresen a casa).

Mi empleador anterior prohibió explícitamente el envío de herramientas .NET o JVM externamente por este motivo. Justo antes de irme, un equipo convenció a los superiores para que les permitieran enviar una herramienta con una gran ofuscación aplicada, pero por lo demás estábamos escribiendo herramientas externas en C++ para satisfacer la política corporativa.

Esta discusión se ha descarrilado. Si todos quieren tener una guerra de fuego sobre si AOT es relevante para la protección de IP, háganlo en otro lugar.

Hex-Rays hace un buen trabajo para C y tiene macros para ayudar en el proceso de decisión.

¿Trabaja para Hex-Rays o para una empresa que vende software de ofuscación? Parece que.

De todos modos, incluso si lo convierte a C, el código estará muy lejos de una buena arquitectura C#. Incluso si obtiene partes del código, tendrá que esforzarse mucho para cambiarlo, mejorarlo, etc.
Si para ti la compilación nativa es irrelevante, ok. Pero para muchas personas es relevante.

Por cierto: pareces muy interesado en mantener la compilación JIT y también pareces tener mucha experiencia en desensamblar software. Me pregunto por qué y dónde tuviste que usar eso.

Por el contrario, poseo las habilidades para realizar ingeniería inversa de código nativo a código fuente que puede ser utilizado por terceros, por lo que soy plenamente consciente de que compilar a código nativo es solo un obstáculo para los script kiddies, que parece ser el entendimiento faltante. aquí.

EDITAR: También deteniendo mis comentarios. Solo quería responder al ataque personal.

Cloud Native y WPF Debe ser AOT.
¡El cliente de Windows no tiene tiempo de ejecución! sin JAT

Los resultados de la encuesta se han publicado: https://github.com/dotnet/runtime/issues/41522. Ahora estamos en el proceso de seguimiento con las personas que proporcionaron su información de contacto y tienen algunas preguntas de seguimiento adicionales.

Se necesita urgentemente AOT con enlace estático para motores de juego en iOS y plataforma de consola que deshabilitan jit,

Estoy totalmente de acuerdo aquí. Como necesitamos una solución para este problema (código C# que se ejecuta en consolas de juegos para un proyecto que no es de Unity), estamos usando una cadena de herramientas basada en Mono-AOT. Pero tiene algunas limitaciones serias y no funciona tan bien.

Por lo tanto, estamos buscando que CoreRT se ejecute en 3 consolas de juegos poplar (XBox One, PlayStation 4 y Nintendo Switch). Una prueba de concepto inicial muestra que realmente funciona (todavía con algunas limitaciones) pero ya con una mejora significativa en el rendimiento del tiempo de ejecución en comparación con la solución basada en Mono.

Pero con la situación de NDA en torno a las consolas de juegos, el soporte oficial para esta causa de uso es incluso más descabellado que obtener AOT nativo oficial en primer lugar.

@RalfKornmannEnvision ¿Está utilizando los puertos Xamarin Xbox One/PS4 Mono con LLVM codegen?

@RalfKornmannEnvision ¿Está utilizando los puertos Xamarin Xbox One/PS4 Mono con LLVM codegen?

@lateralusX Como la integración la hizo otra persona, no conozco ningún detalle. Pero hasta donde yo sé, usaron los puertos mono que se proporcionan para XBox One/PS4 e hicieron un puerto simple para Switch. ellos mismos

@RalfKornmannEnvision Sería genial ponerse en contacto y discutir la experiencia relacionada con esto. El generador de código LLVM tiene (según el proyecto) efectos de rendimiento muy positivos en el código generado, por lo que si no se usó (es necesario habilitarlo), normalmente hay mucho que ganar con solo habilitarlo. ¿Estás en el servidor de discordia de DotNetEvolution? Si es así, ¿podríamos tener una discusión fuera de línea relacionada con esto?

@lateralusX Estoy bastante seguro de que los miembros del equipo que trabajaron en esto habilitaron el código LLVM y probaron otras cosas. Su última declaración antes de pasar a otro proyecto fue que esto es lo mejor que podían hacer.

Como parte de mi investigación, construí un punto de referencia con el componente central usando Xamarin Android y lo ejecuté en un dispositivo basado en Tegra X1 para ver si perdimos rendimiento debido a un problema con nuestro puerto Switch personalizado de Mono. Desafortunadamente, el rendimiento del proyecto Xamarin no fue tan diferente de lo que hemos visto en Switch.

Lo siento, no estoy en este servidor de discordia y, para ser honesto, no sé mucho sobre la integración MONO actual de todos modos. Desde mi punto de vista, es un callejón sin salida de todos modos para este proyecto. El prototipo actual de CoreRT (aunque tiene aún menos soporte oficial) ya es muy superior en lo que respecta a rendimiento y usabilidad.

@RalfKornmannEnvision OK, gracias por su información y comentarios, todos muy valiosos.