Nigromancia
Proporcionar una respuesta real.
¿Cuál es la diferencia entre .Net Core y Mono?
.NET Core ahora es oficialmente el futuro de .NET. Comenzó en su mayor parte con una reescritura del marco ASP.NET MVC y las aplicaciones de consola, que por supuesto incluye aplicaciones de servidor. (Dado que es Turing-complete y admite interoperabilidad con C dlls, podría, si lo deseara, también escribir sus propias aplicaciones de escritorio, por ejemplo, a través de bibliotecas de terceros como Avalonia, que eran un poco muy básicas en el momento en que escribí esto por primera vez, lo que significaba que estabas bastante limitado a las cosas de la web o del servidor). Con el tiempo, se han agregado muchas API a .NET Core, tanto que después de la versión 3.1, .NET Core saltará a la versión 5.0, se conocerá como .NET 5.0 sin el "Core", y ese será el futuro de .NET Framework. Lo que solía ser .NET Framework completo permanecerá en modo de mantenimiento como Full .NET Framework 4.8.x durante algunas décadas, hasta que muera (tal vez todavía habrá algunas actualizaciones, pero lo dudo). En otras palabras, .NET Core es el futuro de .NET, y Full .NET Framework seguirá el camino de Dodo / Silverlight / WindowsPhone .
El punto principal de .NET Core, aparte del soporte multiplataforma, es mejorar el rendimiento y habilitar la "compilación nativa" / implementación autónoma (para que no necesite .NET framework / VM instalado en la máquina de destino) .
por un lado, esto significa docker.io implementación en Linux, y por el otro despliegue, autónomo es útil en la "nube de computación", ya que a continuación, puedes utilizar cualquier versión del framework .NET-CORE se quiere, y no tiene que preocuparse por las versiones del framework .NET que el administrador del sistema ha instalado realmente.
Si bien el tiempo de ejecución de .NET Core admite múltiples sistemas operativos y procesadores, el SDK es una historia diferente. Y si bien el SDK admite múltiples sistemas operativos, el soporte de ARM para el SDK todavía está en progreso. .NET Core es compatible con Microsoft. Dotnet-Core no vino con WinForms o WPF ni nada de eso.
- A partir de la versión 3.0, WinForms y WPF también son compatibles con .NET Core, pero solo en Windows y solo con C #. No por VB.NET (soporte VB.NET planeado para v5 en 2020). Y no hay Forms Designer en .NET Core: se envía con una actualización de Visual Studio más tarde, en un momento no especificado.
- Los formularios web todavía no son compatibles con .NET Core, y no hay planes para admitirlos ( Blazor es el nuevo chico en la ciudad para eso).
- .NET Core también viene con System.Runtime, que reemplaza a mscorelib.
- A menudo, .NET Core se mezcla con NetStandard , que es un poco envolvente alrededor de System.Runtime / mscorelib (y algunos otros), que le permite escribir bibliotecas que se dirigen a .NET Core, Full .NET Framework y Xamarin (iOS / Android), todo al mismo tiempo.
- .NET Core SDK no funciona / no funcionó en ARM, al menos no la última vez que lo comprobé.
"The Mono Project" es mucho más antiguo que .NET Core.
Mono es español y significa mono, y como comentario adicional, el nombre no tiene nada que ver con la mononucleosis (pista: puede obtener una lista de personal en http://primates.ximian.com /).
Mono fue iniciado en 2005 por Miguel de Icaza (el tipo que inició GNOME , y algunos otros) como una implementación de .NET Framework para Linux (Ximian / SuSe / Novell). Mono incluye formularios web, Winforms, MVC, Olive y un IDE llamado MonoDevelop(también conocido como Xamarin Studio o Visual Studio Mac). Básicamente el equivalente de (OpenJDK) JVM y (OpenJDK) JDK / JRE (en oposición a SUN / Oracle JDK). Puede usarlo para que las aplicaciones ASP.NET-WebForms + WinForms + ASP.NET-MVC funcionen en Linux.
Mono es compatible con Xamarin (el nuevo nombre de la compañía de lo que solía ser Ximian, cuando se centraron en el mercado móvil, en lugar del mercado de Linux), y no por Microsoft.
(dado que Xamarin fue comprado por Microsoft, eso es técnicamente [pero no culturalmente] Microsoft). Por
lo general, obtendrá su material C # para compilar en mono, pero no el material VB.NET.
Mono pierde algunas características avanzadas, como WSE / WCF y WebParts.
Muchas de las implementaciones de Mono están incompletas (p. Ej., Lanzan NotImplementedException en el cifrado ECDSA), tienen errores (p. Ej. ODBC / ADO.NET con Firebird), se comportan de manera diferente que en .NET (por ejemplo, serialización XML) o son inestables (ASP.NET MVC) e inaceptablemente lento (Regex). Por el lado positivo, la cadena de herramientas Mono también funciona en ARM.
En lo que respecta a .NET Core, cuando dicen multiplataforma, no esperes que multiplataforma signifique que en realidad solo puedas instalar .NET Core en ARM-Linux, como puedes hacer con ElasticSearch. Tendrás que compilar todo el framework desde la fuente.
Es decir, si tiene ese espacio (por ejemplo, en una Chromebook, que tiene un total de 16 a 32 GB de HD).
También solía tener problemas de incompatibilidad con OpenSSL 1.1 y libcurl.
Se han rectificado en la última versión de .NET Core versión 2.2.
Demasiado para multiplataforma.
Encontré una declaración en el sitio oficial que decía: "El código escrito para él también es portátil en las pilas de aplicaciones, como Mono".
Mientras ese código no se base en llamadas WinAPI, Windows-dll-pinvokes, COM-Components, un sistema de archivos que no distingue entre mayúsculas y minúsculas, la codificación predeterminada del sistema (página de códigos) y no tiene problemas de separación de directorios, eso es correcto. Sin embargo, el código de .NET Core se ejecuta en .NET Core y no en Mono. Entonces mezclar los dos será difícil. Y dado que Mono es bastante inestable y lento (para aplicaciones web), no lo recomendaría de todos modos. Pruebe el procesamiento de imágenes en .NET core, por ejemplo, WebP o mover GIF o tiff de páginas múltiples o escribir texto en una imagen, se sorprenderá desagradablemente.
Nota:
A partir de .NET Core 2.0, existe System.Drawing.Common (NuGet), que contiene la mayor parte de la funcionalidad de System.Drawing. Debería tener más o menos funciones completas en .NET-Core 2.1. Sin embargo, System.Drawing.Common usa GDI + y, por lo tanto, no funcionará en Azure (las bibliotecas System.Drawing están disponibles en Azure Cloud Service [básicamente solo una VM], pero no en Azure Web App [¿básicamente alojamiento compartido?])
Entonces Hasta ahora, System.Drawing.Common funciona bien en Linux / Mac, pero tiene problemas en iOS / Android; si funciona, existe.
Antes de .NET Core 2.0, es decir, en algún momento a mediados de febrero de 2017, podría usar SkiaSharp para imágenes (ejemplo) (todavía puede).
Después de .net-core 2.0, notará que SixLabors ImageSharpes el camino a seguir, ya que System.Drawing no es necesariamente seguro y tiene muchas pérdidas de memoria reales o potenciales, por lo que no debe usar GDI en aplicaciones web; Tenga en cuenta que SkiaSharp es mucho más rápido que ImageSharp, ya que utiliza bibliotecas nativas (que también pueden ser un inconveniente). Además, tenga en cuenta que si bien GDI + funciona en Linux y Mac, eso no significa que funcione en iOS / Android.
El código no escrito para .NET (no Core) no es portátil para .NET Core.
Es decir, si desea una biblioteca C # que no sea GPL como PDFSharp para crear documentos PDF (muy común), no tiene suerte(En el momento)( ya no ) No importa el control ReportViewer, que usa Windows-pInvokes (para cifrar, crear documentos mcdf a través de COM, y para obtener información de fuente, carácter, interletraje, incrustación de fuente, medir cadenas y hacer saltos de línea, y para dibujar realmente tiffs de calidad aceptable) , y ni siquiera se ejecuta en Mono en Linux
( estoy trabajando en eso ).
Además, el código escrito en .NET Core no es portátil para Mono, porque Mono carece de las bibliotecas de tiempo de ejecución de .NET Core (hasta ahora).
Mi objetivo es usar C #, LINQ, EF7, visual studio para crear un sitio web que se pueda ejecutar / alojar en Linux.
EF en cualquier versión que probé hasta ahora fue muy lento (incluso en cosas tan simples como una tabla con una combinación izquierda), no lo recomendaría nunca, tampoco en Windows.
En particular, no recomendaría EF si tiene una base de datos con restricciones únicas, o columnas varbinary / filestream / hierarchyid. (Tampoco para la actualización de esquema).
Y tampoco en una situación en la que el rendimiento de la base de datos es crítico (digamos de 10+ a más de 100 usuarios concurrentes).
Además, ejecutar un sitio web / aplicación web en Linux tarde o temprano significará que tendrá que depurarlo.
No hay soporte de depuración para .NET Core en Linux.(Ya no, pero requiere JetBrains Rider).
MonoDevelop (todavía) no admite la depuración de proyectos .NET Core.
Si tienes problemas, estás solo. Tendrás que usar un registro extenso.
Tenga cuidado, tenga en cuenta que un registro extenso llenará su disco en poco tiempo, particularmente si su programa entra en un bucle infinito o recursividad.
Esto es especialmente peligroso si su aplicación web se ejecuta como root, porque el inicio de sesión requiere espacio de archivo de registro; si no queda espacio libre, ya no podrá iniciar sesión.
(Normalmente, aproximadamente el 5% del espacio en disco está reservado para el usuario root [también conocido como administrador en Windows], por lo que al menos el administrador puede iniciar sesión si el disco está casi lleno. Pero si sus aplicaciones se ejecutan como root, esa restricción no se aplica a el uso de su disco y, por lo tanto, sus archivos de registro pueden usar el 100% del espacio libre restante, de modo que ni siquiera el administrador pueda iniciar sesión más.)
Por lo tanto, es mejor no cifrar ese disco, es decir, si valora sus datos / sistema.
Alguien me dijo que quería que fuera "en Mono", pero no sé qué significa eso.
Significa que no quiere usar .NET Core, o simplemente quiere usar C # en Linux / Mac. Supongo que solo quiere usar C # para una aplicación web en Linux. .NET Core es el camino a seguir para eso, si absolutamente quieres hacerlo en C #. No vayas con "Mono propiamente dicho"; en la superficie, parecería funcionar al principio, pero créanme que se arrepentirán porque el ASP.NET MVC de Mono no es estable cuando su servidor funciona a largo plazo (más de 1 día): ahora se les ha advertido. Consulte también las referencias de "no se completaron" al medir el rendimiento de Mono en los puntos de referencia de Techempower.
Sé que quiero usar el marco .Net Core 1.0 con las tecnologías que enumeré anteriormente. También dijo que quería usar "cgi rápido". No sé lo que eso significa tampoco.
Significa que quiere usar un servidor web con todas las funciones de alto rendimiento como nginx (Engine-X), posiblemente Apache.
Luego puede ejecutar mono / dotnetCore con alojamiento basado en nombre virtual (múltiples nombres de dominio en la misma IP) y / o equilibrio de carga. También puede ejecutar otros sitios web con otras tecnologías, sin requerir un número de puerto diferente en el servidor web. Significa que su sitio web se ejecuta en un servidor fastcgi y nginx reenvía todas las solicitudes web de un determinado dominio a través del protocolo fastcgi a ese servidor. También significa que su sitio web se ejecuta en una tubería fastcgi, y debe tener cuidado con lo que hace, por ejemplo, no puede usar HTTP 1.1 al transmitir archivos.
De lo contrario, los archivos serán ilegibles en el destino.
Ver también aquí y aquí .
Para concluir:
.NET Core en la actualidad (2016-09-28) no es realmente portátil, ni es realmente multiplataforma (en particular, las herramientas de depuración).
La compilación nativa tampoco es fácil, especialmente para ARM.
Y para mí, tampoco parece que su desarrollo esté "realmente terminado", todavía.
Por ejemplo, falta System.Data.DataTable / DataAdaper.Update ...
(ya no con .NET Core 2.0)
Junto con las interfaces System.Data.Common.IDB *.(ya no con .NET Core 1.1)
si alguna vez hubo una clase que se usa con frecuencia, DataTable / DataAdapter sería ...
Además, el instalador de Linux (.deb) falla, al menos en mi máquina, y yo ' Estoy seguro de que no soy el único que tiene ese problema.
Depurar, tal vez con Visual Studio Code, si puede construirlo en ARM (logré hacerlo, NO siga la publicación de blog de Scott Hanselman si lo hace , hay un tutorial en la wiki de VS-Code en github), porque No ofrecen el ejecutable.
Yeoman también falla. (Supongo que tiene algo que ver con la versión de nodejs que instaló: VS Code requiere una versión, Yeoman otra ... pero debería ejecutarse en la misma computadora. Bastante lamentable
No importa que se ejecute en la versión de nodo enviada por defecto en el sistema operativo.
No importa que no haya dependencia en NodeJS en primer lugar.
El servidor kestell también está en progreso.
Y a juzgar por mi experiencia con el proyecto mono, dudo mucho que hayan probado .NET Core en FastCGI, o que tengan alguna idea de lo que significa el soporte de FastCGI para su marco, y mucho menos que lo probaron para asegurarse de que "todo funciona ". De hecho, acabo de intentar hacer una aplicación fastcgi con .NET Core y me di cuenta de que no hay una biblioteca FastCGI para .NET Core "RTM" ...
Entonces, cuando va a ejecutar .NET Core "RTM" detrás de nginx, solo puede hacerlo enviando solicitudes a kestrell (ese servidor web derivado de nodo JS semiacabado): actualmente no hay soporte fastcgi en .NET Core "RTM", AFAIK. Dado que no hay una biblioteca fastcgi .net core, y no hay muestras, también es muy poco probable que alguien haya realizado alguna prueba en el marco para asegurarse de que fastcgi funcione como se esperaba.
También cuestiono el rendimiento.
En el punto de referencia (preliminar) de techempower (ronda 13) , aspnetcore-linux se ubica en un 25% en relación con el mejor rendimiento, mientras que los marcos comparables como Go (golang) se clasifican en el 96.9% del rendimiento máximo (y eso es cuando se devuelve texto sin archivo) -solo acceso al sistema). .NET Core funciona un poco mejor en la serialización JSON, pero tampoco parece convincente (ir alcanza el 98.5% del pico, .NET core 65%). Dicho esto, no puede ser peor que "mono propiamente dicho".
Además, dado que todavía es relativamente nuevo, no todas las bibliotecas principales se han portado (todavía), y dudo que algunas de ellas se porten alguna vez.
El soporte de imágenes también es cuestionable en el mejor de los casos.
Para cualquier encriptación, use BouncyCastle en su lugar.
¿Me pueden ayudar a entender todos estos términos y si mis expectativas son realistas ?
Espero haberte ayudado a tener más sentido con todos estos términos.
En lo que respecta a sus expectativas: el
desarrollo de una aplicación de Linux sin saber nada sobre Linux es una idea realmente estúpida en primer lugar, y también está destinado a fallar de una forma horrible u otra. Dicho esto, dado que Linux no tiene costos de licencia, en principio es una buena idea, PERO SOLO SI SABES LO QUE HACES.
Desarrollar una aplicación para una plataforma en la que no pueda depurar su aplicación es otra muy mala idea.
Desarrollar para fastcgi sin saber qué consecuencias hay es otra muy mala idea.
Hacer todas estas cosas en una plataforma "experimental" sin ningún conocimiento de los detalles de esa plataforma y sin soporte de depuración es un suicidio, si su proyecto es más que una página de inicio personal. Por otro lado, supongo que hacerlo con su página de inicio personal con fines de aprendizaje probablemente sea una muy buena experiencia, entonces podrá conocer cuál es el marco y cuáles son los problemas no marco.
Puede, por ejemplo, (mediante programación) montar en bucle un fat32, hfs o JFS insensible a mayúsculas y minúsculas para su aplicación, para evitar los problemas de mayúsculas y minúsculas (no se recomienda el montaje en bucle en producción).
Para resumir
En la actualidad (2016-09-28), me mantendría alejado de .NET Core (para uso de producción). Tal vez en uno o dos años, puede echar otro vistazo, pero probablemente no antes.
Si tiene un nuevo proyecto web que desarrolla, inícielo en .NET Core, no en mono.
Si desea un marco que funcione en Linux (x86 / AMD64 / ARMhf) y Windows y Mac, que no tenga dependencias, es decir, solo enlaces estáticos y ninguna dependencia en .NET, Java o Windows, use Golang en su lugar. Es más maduro y su rendimiento está probado (Baidu lo usa con 1 millón de usuarios simultáneos), y Golang tiene una huella de memoria significativamente menor. Además, golang está en los repositorios, el .deb se instala sin problemas, el código fuente se compila, sin requerir cambios, y golang (mientras tanto) tiene soporte de depuración con delve y JetBrainsGogland en Linux (y Windows y Mac). El proceso de compilación de Golang (y el tiempo de ejecución) tampoco depende de NodeJS, que es otra ventaja.
En lo que respecta a mono, aléjate de él.
No es nada sorprendente lo lejos que ha llegado el mono, pero desafortunadamente no puede sustituir sus problemas de rendimiento / escalabilidad y estabilidad para las aplicaciones de producción.
Además, el monodesarrollo está bastante muerto, en gran medida solo desarrollan las partes relevantes para Android e iOS, porque es allí donde Xamarin gana su dinero.
No espere que Web-Development sea un ciudadano Xamarin / mono de primera clase.
.NET Core podría valer la pena si comienzas un nuevo proyecto, pero para los proyectos de formularios web grandes existentes, la transferencia en gran medida está fuera de discusión, los cambios necesarios son enormes. Si tiene un proyecto MVC, la cantidad de cambios podría ser manejable, si el diseño de su aplicación original fuera sensata, lo que no es el caso para la mayoría de las aplicaciones existentes llamadas "históricamente desarrolladas".
Actualización de diciembre de 2016: la
compilación nativa se ha eliminado de la vista previa de .NET Core, ya que aún no está lista ...
Parece que han mejorado bastante en el punto de referencia del archivo de texto sin procesar, pero por otro lado, se ha vuelto bastante defectuoso. Además, se deterioró aún más en los puntos de referencia JSON. También es curioso que el marco de la entidad sea más rápido para las actualizaciones que Dapper, aunque ambos con una lentitud récord. Es muy poco probable que esto sea cierto. Parece que todavía hay más que unos pocos errores para cazar.
Además, parece haber alivio en el frente de Linux IDE.
JetBrains lanzó "Project Rider", una vista previa de acceso anticipado de un IDE C # / .NET Core para Linux (y Mac y Windows), que puede manejar archivos de Visual Studio Project. Finalmente, un IDE de C # que se puede usar y que no es tan lento como el infierno.
Conclusión: .NET Core sigue siendo un software de calidad de prelanzamiento a medida que avanzamos en 2017. Transfiera sus bibliotecas, pero manténgase alejado de él para el uso de producción, hasta que la calidad del marco se estabilice.
Y vigile Project Rider.
Actualización 2017
He migrado mi página de inicio (de hermano) a .NET Core por ahora.
Hasta ahora, el tiempo de ejecución en Linux parece ser lo suficientemente estable (al menos para proyectos pequeños), sobrevivió a una prueba de carga con facilidad, mono nunca lo hizo.
Además, parece que mezclé .NET-Core-native y .NET-Core-self-contenido-implementación. La implementación autónoma funciona, pero está un poco subdocumentada, aunque es súper fácil (las herramientas de compilación / publicación son un poco inestables, sin embargo, si encuentra "Se requiere un número positivo. - FALLO de compilación". y funciona).
Tu puedes correr
dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64
Nota: Según .NET Core 3, puede publicar todo minimizado como un solo archivo :
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true
Sin embargo, a diferencia de go, no es un archivo ejecutable vinculado estáticamente, sino un archivo zip autoextraíble, por lo que al implementarlo, puede tener problemas, especialmente si el directorio temporal está bloqueado por la política de grupo u otros problemas . Sin embargo, funciona bien para un programa hello-world. Y si no minimiza, el tamaño del archivo ejecutable alcanzará los 100 MB.
Y obtiene un archivo .exe autónomo (en el directorio de publicación), que puede mover a una máquina con Windows 8.1 sin .NET Framework instalado y dejar que se ejecute. Agradable. Es aquí donde dotNET-Core comienza a ponerse interesante. (tenga en cuenta las lagunas, SkiaSharp no funciona en Windows 8.1 / Windows Server 2012 R2, [todavía] - el ecosistema tiene que ponerse al día primero, pero curiosamente, Skia-dll-load-fail no bloquea todo el servidor / aplicación - entonces todo lo demás funciona)
(Nota: a SkiaSharp en Windows 8.1 le faltan los archivos de tiempo de ejecución de VC adecuados: msvcp140.dll y vcruntime140.dll. Cópielos en el directorio de publicación y Skia funcionará en Windows 8.1).
Agosto de 2017 Actualización
.NET Core 2.0 lanzada.
Tenga cuidado: viene con cambios (grandes interrupciones) en la autenticación ...
Por el lado positivo, trajo de regreso las clases DataTable / DataAdaper / DataSet, y muchas más.
Realizado .NET Core aún no tiene soporte para Apache SparkSQL, porque Mobius aún no está portado. Eso es malo, porque eso significa que no hay soporte de SparkSQL para mi IoT Cassandra Cluster, por lo que no se une ...
Soporte experimental de ARM (solo tiempo de ejecución, no SDK, demasiado malo para el trabajo en mi Chromebook, esperando 2.1 o 3.0).
PdfSharp ahora está portado experimentalmente a .NET Core.
Jinete de JetBrainsEAP izquierdo. Ahora puede usarlo para desarrollar y depurar .NET Core en Linux, aunque hasta ahora solo .NET Core 1.1 hasta que se active la actualización para el soporte de .NET Core 2.0.
Actualización de mayo de 2018
.NET Core 2.1 inminente. Tal vez esto arregle la autenticación NTLM en Linux (la autenticación NTLM no funciona en Linux {y posiblemente Mac} en .NET-Core 2.0 con múltiples encabezados de autenticación, como negociar, comúnmente enviados con ms-exchange, y aparentemente son solo lo solucionó en v2.1, no hay versión de corrección de errores para 2.0).
Pero no estoy instalando versiones preliminares en mi máquina. Entonces esperando.
También se dice que v2.1 reduce en gran medida los tiempos de compilación. Eso sería bueno.
Además, tenga en cuenta que en Linux, .NET Core es solo de 64 bits .
No hay, y no habrá, la versión x86-32 de .NET Core en Linux .
Y el puerto ARM es solo ARM-32. No ARM-64, todavía.
Y en ARM, usted (en la actualidad) solo tiene el tiempo de ejecución, no el dotnet-SDK.
Y una cosa más:
debido a que .NET-Core usa OpenSSL 1.0, .NET Core en Linux no se ejecuta en Arch Linux, y por derivación no en Manjaro (la distribución de Linux más popular hasta ahora en este momento), porque Arch Linux usa OpenSSL 1.1. Entonces, si está utilizando Arch Linux, no tiene suerte (con Gentoo también).
Editar:
La última versión de .NET Core 2.2+ es compatible con OpenSSL 1.1. Entonces puede usarlo en Arch o (k) Ubuntu 19.04+. Sin embargo, es posible que deba usar el script de instalación de .NET-Core porque todavía no hay paquetes.
Por el lado positivo, el rendimiento definitivamente ha mejorado:
.NET Core 3:
se dice que .NET-Core v 3.0 trae WinForms y WPF a .NET-Core.
Sin embargo, mientras que WinForms y WPF serán .NET Core, WinForms y WPF en .NET-Core se ejecutarán solo en Windows, porque WinForms / WPF usará la API de Windows.
Nota:
.NET Core 3.0 ya está disponible (RTM), y hay compatibilidad con WinForms y WPF, pero solo para C # (en Windows). No hay WinForms-Core-Designer . El diseñador, eventualmente, vendrá con una actualización de Visual Studio, en algún momento. La compatibilidad con WinForms para VB.NET no es compatible , pero está planificada para .NET 5.0 en 2020 .
PD:
echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1
Si lo ha usado en Windows, probablemente nunca haya visto esto:
Las herramientas .NET Core recopilan datos de uso para mejorar su experiencia.
Los datos son anónimos y no incluyen argumentos de línea de comandos.
Microsoft recopila los datos y los comparte con la comunidad.
Puede optar por no recibir telemetría configurando una variable de entorno DOTNET_CLI_TELEMETRY_OPTOUT en 1 utilizando su shell favorito.
Puede leer más sobre la telemetría de las herramientas .NET Core en
https://aka.ms/dotnet-cli-telemetry .
Pensé en mencionar que creo que monodevelop (también conocido como Xamarin Studio, Mono IDE o Visual Studio Mac como ahora se llama en Mac) ha evolucionado bastante bien y, mientras tanto, es en gran medida utilizable.
Sin embargo, JetBrains Rider (EAP 2018 en este momento) es definitivamente mucho más agradable y confiable (y el descompilador incluido es más seguro), es decir, si desarrolla .NET-Core en Linux o Mac. Sin embargo, MonoDevelop no admite Debug-StepThrough en Linux en .NET Core, ya que MS no licencia su dll API de depuración (a excepción de VisualStudio Mac ...). Sin embargo, puede usar el depurador de Samsung para .NET Core a través de la extensión del depurador de .NET Core para Samsung Debugger para MonoDevelop
Descargo de responsabilidad:
no uso Mac, por lo que no puedo decir si lo que escribí aquí se aplica también a Mac basado en FreeBSD-Unix. Me refiero a la versión de Linux (Debian / Ubuntu / Mint) de JetBrains Rider, mono, MonoDevelop / VisualStudioMac / XamarinStudio y .NET-Core. Además, Apple está considerando pasar de los procesadores Intel a los procesadores basados en ARM (ARM-64?) De fabricación propia, por lo que gran parte de lo que se aplica a Mac en este momento podría no aplicarse a Mac en el futuro (2020+).
Además, cuando escribo "mono es bastante inestable y lento", lo inestable se relaciona con las aplicaciones WinFroms y WebForms, específicamente ejecutando aplicaciones web a través de fastcgi o con XSP (en la versión 4.x de mono), así como la serialización XML peculiaridades de manejo, y lo bastante lento se relaciona con WinForms, y las expresiones regulares en particular (ASP.NET-MVC también usa expresiones regulares para el enrutamiento).
Cuando escribo sobre mi experiencia con mono 2.x, 3.xy 4.x, eso tampoco significa necesariamente que estos problemas no se hayan resuelto hasta ahora, o para el momento en que esté leyendo esto, ni tampoco si lo están solucionado ahora, que no puede haber una regresión posterior que reintroduzca ninguno de estos errores / características. Tampoco significa que si incrusta el tiempo de ejecución mono, obtendrá los mismos resultados que cuando utiliza el tiempo de ejecución mono del sistema (dev). Tampoco significa que incrustar el tiempo de ejecución mono (en cualquier lugar) sea necesariamente gratuito.
Todo lo que no necesariamente significa que mono no es adecuado para iOS o Android, o que tiene los mismos problemas allí. No uso mono en Android o IOS, por lo que no estoy seguro de decir nada sobre estabilidad, usabilidad, costos y rendimiento en estas plataformas. Obviamente, si usa .NET en Android, también debe tener en cuenta otros costos, como ponderar los costos de xamarin en comparación con los costos y el tiempo para portar el código existente a Java. Uno escucha mono en Android y iOS será bastante bueno. Tómelo con un grano de sal. Por un lado, no espere que la codificación predeterminada del sistema sea la misma en Android / iOS frente a Windows, y no espere que el sistema de archivos de Android no distinga entre mayúsculas y minúsculas, y no espere que las fuentes de Windows estén presentes .