net c# .net mono .net-core

c# - net - monodevelop



.NET Core vs Mono (7)

Para ser simple,

Mono es la implementación de terceros de .Net framework para Linux / Android / iOs

.Net Core es la propia implementación de Microsoft para lo mismo.

.Net Core es el futuro. y Mono finalmente estará muerto. Dicho esto, .Net Core no ha madurado lo suficiente. Estaba luchando por implementarlo con IBM Bluemix y luego abandoné la idea. Abajo el tiempo (puede ser 1-2 años), debería ser mejor.

¿Cuál es la diferencia entre .NET Core y Mono?

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".

Mi objetivo es usar C #, LINQ, EF7 y Visual Studio para crear un sitio web que se pueda ejecutar / alojar en Linux.

Alguien me dijo que quería que fuera "en Mono", pero no sé qué significa eso. Sé que quiero usar .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.

¿Me pueden ayudar a entender todos estos términos y si mis expectativas son realistas?

.Net Core no requiere mono en el sentido del marco mono. .Net Core es un marco que funcionará en múltiples plataformas, incluyendo Linux. Referencia https://dotnet.github.io/ .

Sin embargo, el núcleo .Net puede usar el marco mono. Referencia https://docs.asp.net/en/1.0.0-rc1/getting-started/choosing-the-right-dotnet.html (nota rc1 documentatiopn no rc2 disponible), sin embargo, mono no es un marco compatible con Microsoft y recomendaría usar un marco compatible

Ahora Entity Framework Core 7 ahora se llama Entity Framework Core y está disponible en múltiples plataformas, incluyendo Linux. Referencia https://github.com/aspnet/EntityFramework (revise la hoja de ruta)

Actualmente estoy usando estos dos marcos, sin embargo, debes entender que todavía está en la etapa de candidato de lanzamiento ( RC2 es la versión actual) y sobre los candidatos beta y de lanzamiento ha habido cambios masivos que generalmente terminan rascándote la cabeza.

Aquí hay un tutorial sobre cómo instalar MVC .Net Core en Linux. https://docs.asp.net/en/1.0.0-rc1/getting-started/installing-on-linux.html

Finalmente, tiene la opción de Servidores Web (de donde supongo que vino la referencia fast cgi ) para alojar su aplicación en Linux. Aquí hay un punto de referencia para instalar en un entorno Linux. https://docs.asp.net/en/1.0.0-rc1/publishing/linuxproduction.html

Me doy cuenta de que esta publicación termina siendo principalmente enlaces a documentación, pero en este punto esas son sus mejores fuentes de información. .Net core todavía es relativamente nuevo en la comunidad .Net y hasta que se lance por completo, dudaría en usarlo en un entorno de producto dados los cambios importantes entre la versión lanzada.

En el mundo .NET hay dos tipos de CLR, CLR "completos" y CLR principales, y estas son cosas muy diferentes.

Hay dos implementaciones CLR "completas", la .NET CLR nativa de Microsoft (para Windows) y la CLR Mono (que tiene implementaciones para Windows, Linux y Unix (Mac OS X y FreeBSD)). Un CLR completo es exactamente eso: todo lo que necesitas. Como tal, los CLR "completos" tienden a ser de gran tamaño.

Por otro lado, los CLR principales se reducen y son mucho más pequeños. Debido a que son solo una implementación central, es poco probable que tengan todo lo que necesita en ellos, por lo que con Core CLR agrega conjuntos de características al CLR que utiliza su producto de software específico, utilizando NuGet. Hay implementaciones de Core CLR para Windows, Linux (varios) y Unix (Mac OS X y FreeBSD) en la mezcla. Microsoft también tiene o está refactorizando las bibliotecas de .NET Framework para Core CLR, para que sean más portables para el contexto central. Dada la presencia de mono en los sistemas operativos * nix, sería una sorpresa si los CLR principales para * nix no incluyeran una base de código mono, pero solo la comunidad Mono y Microsoft podrían decirnos eso con seguridad.

Además, estaría de acuerdo con Nico en que los Core CLR son nuevos: creo que está en RC2 en este momento. Todavía no dependería de él para el código de producción.

Para responder a su pregunta, puede entregar su sitio en Linux utilizando Core CLR o Mono, y estas son dos formas diferentes de hacerlo. Si quieres una apuesta segura en este momento, iría con mono en linux, luego haré el puerto si quieres más tarde, a Core.

En una palabra:

Mono = Compilador para C #

Mono Develop = Compilador + IDE

.Net Core = compilador ASP

El caso actual de .Net Core es web tan pronto como adopte algún estándar abierto de forma de victoria y una adopción de lenguaje más amplia, finalmente podría ser la potencia de desarrollo de Microsoft Killer. Teniendo en cuenta el reciente movimiento de licencias de Java de Oracle, Microsoft tiene un gran momento para brillar.

Esta pregunta es especialmente actual porque ayer Microsoft anunció oficialmente el lanzamiento de .NET Core 1.0 . Suponiendo que Mono implementa la mayoría de las bibliotecas .NET estándar, la diferencia entre Mono y .NET core se puede ver a través de la diferencia entre .NET Framework y .NET Core:

  • API: .NET Core contiene muchas de las mismas API, pero menos , que .NET Framework, y con una factorización diferente (los nombres de ensamblado son
    diferente; la forma del tipo difiere en casos clave). Estas diferencias
    actualmente normalmente requieren cambios en la fuente del puerto a .NET Core. .NET Core implementa la API de biblioteca estándar de .NET, que crecerá a
    incluya más API de .NET Framework BCL con el tiempo.
  • Subsistemas: .NET Core implementa un subconjunto de los subsistemas en .NET Framework, con el objetivo de una implementación más simple y
    modelo de programación Por ejemplo, Code Access Security (CAS) no es
    compatible, mientras que la reflexión es compatible.

Si necesita lanzar algo rápidamente, elija Mono porque actualmente es (junio de 2016) un producto más maduro, pero si está creando un sitio web a largo plazo, sugeriría .NET Core. Es oficialmente compatible con Microsoft y la diferencia en las API compatibles probablemente desaparecerá pronto, teniendo en cuenta el esfuerzo que Microsoft pone en el desarrollo de .NET Core.

Mi objetivo es usar C #, LINQ, EF7, visual studio para crear un sitio web que se pueda ejecutar / alojar en Linux.

Linq y Entity Framework están incluidos en .NET Core , por lo que es seguro tomar una foto.

Nigromancia
Proporcionar una respuesta real.

¿Cuál es la diferencia entre .Net Core y Mono?

.NET Core es, en su mayor parte, una reescritura del marco ASP.NET MVC (y las aplicaciones de consola) para reducir las dependencias, hacerlo más modular y aumentar el rendimiento.

<edit>Console Applications: this includes server applications IMHO</edit>

El punto principal es habilitar la "compilación nativa" / implementación independiente (por lo que no necesita .NET framework / VM instalado en la máquina de destino).
Esto es útil en la "computación en la nube", ya que puede usar cualquier versión del marco dotnet-CORE que desee, y no tiene que preocuparse de qué versión (s) del marco .NET tiene realmente el administrador del sistema instalado
.NET Core también es compatible con múltiples sistemas operativos como un espectáculo secundario.
Es compatible con Microsoft.
Dotnet Core no viene con Winforms o WPF ni nada por el estilo.

Mono es una implementación de .NET Framework para Linux (incluidos formularios web, Winforms, MVC). 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.
Es compatible con Xamarin, y no con Microsoft.
(dado que Xamarin fue comprado por Microsoft, eso es técnicamente, pero no realmente, Microsoft).
Por lo general, obtendrá sus cosas de C # para compilar en mono, pero no las cosas de VB.NET.
Faltan algunas características avanzadas, como WSE / WCF y WebParts.
Muchas de las implementaciones son incompletas (por ejemplo, lanzar NotImplementedException en el cifrado ECDSA), tienen errores (por ejemplo, ODBC / ADO.NET con Firebird), se comportan de manera diferente que en .NET (por ejemplo, serialización XML) o de otra manera inestable (ASP.NET MVC) y inaceptablemente lento (Regex).

Sin embargo, no espere que multiplataforma signifique que en realidad solo podría instalar apt .NET Core en ARM-Linux, como puede hacer con elasticsearch. Tendrás que compilar todo el marco desde la fuente.
Es decir, si tiene ese espacio (por ejemplo, en un Chromebook, que tiene un HD total de 16 a 32 GB).
Tanto 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 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, 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.

<edit> A mediados de febrero de 2017: puede usar SkiaSharp para eso ahora (example) </edit>

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 hosting compartido?])
Hasta ahora, System.Drawing.Common funciona bien en Linux / Mac.

El código no escrito para .NET (no básico) 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 (por cualquier razón), 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 a mono, porque mono carece de las bibliotecas de tiempo de ejecución de .NET core (todavía).

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. (no para actualización de esquema tampoco)
Y tampoco en una situación en la que el rendimiento de DB es crítico (por ejemplo, más 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, especialmente si su programa entra en un ciclo de infine 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 su uso de disco y, por lo tanto, sus archivos de registro pueden usar el 100% del espacio libre restante, por lo que ni siquiera el administrador puede 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 lo lamentará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 mono en los puntos de referencia de Techempower.

SkiaSharp

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 cuando transmite archivos.
De lo contrario, los archivos serán ilegibles en el destino.
Ver también here y here .

Para concluir:
.NET Core en la actualidad 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 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.
No importa que deba ejecutarse 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 mono-proyecto, 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 cuanto a tus expectativas:
Desarrollar una aplicación Linux sin saber nada sobre Linux es una idea realmente estúpida en primer lugar, y también está destinada a fallar de una manera horrible de una forma 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 para usted, luego podrá conocer cuál es el marco y cuáles son los problemas no relacionados.
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, 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. También 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 JetBrains Gogland 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 más.

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, ya que en gran medida solo desarrollan las partes relevantes para Android e iOS, porque ahí es 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 no está permitida, 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 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. Curioso también 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.

here

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 muy fácil (las herramientas de compilación / publicación son un poco inestables, sin embargo, si encuentra "Se requiere un número positivo. - FALLA de compilación". - ejecute el mismo comando nuevamente, 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

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 apropiados: msvcp140.dll y vcruntime140.dll. Cópielos en el directorio de publicación y Skia funcionará en Windows 8.1).

Actualización de agosto de 2017
.NET Core 2.0 lanzado.
Tenga cuidado: viene con cambios (grandes interrupciones) en la autenticación ...
Por el lado positivo, trajo de vuelta 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 en 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.
JetBrains Rider dejó EAP. 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
Lanzamiento de .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 lanzamiento 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 (actualmente) 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).

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.

PD:

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é mencionar que creo que monodevelop (también conocido como Xamarin Studio, el mono IDE) ha evolucionado bastante bien y, mientras tanto, es en gran medida utilizable.
Sin embargo, JetBrains Rider (EAP 2018 en este momento) es definitivamente mucho mejor y más confiable (y el descompilador incluido es más seguro), es decir, si desarrolla .NET-Core en Linux o Mac.

Descargo de responsabilidad:
No uso Mac, así 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 4.x, eso tampoco significa necesariamente que estos problemas no se hayan resuelto en este momento, o en el momento en que esté leyendo esto, ni que si se solucionan ahora, no se puede será una regresión posterior que reintroduzca cualquiera 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 incorporar 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, así 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.

Usted ha elegido no solo un camino realista, sino posiblemente uno de los mejores ecosistemas fuertemente respaldados (también plataformas X) por MS. Aún así, debe considerar los siguientes puntos:

  • Actualización: el documento principal sobre el estándar de la plataforma .Net está aquí: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
  • Actualización: Mono 4.4.1 actual no puede ejecutar la última versión de Asp.Net core 1.0 RTM
  • Aunque mono tiene más funciones completas, su futuro no está claro, porque MS lo posee desde hace algunos meses y es un trabajo duplicado para que lo respalden. Pero MS está definitivamente comprometido con .Net Core y apostando fuerte por él.
  • Aunque se lanzó .Net core, el ecosistema de terceros no está del todo allí. Por ejemplo, Nhibernate, Umbraco, etc., aún no pueden ejecutarse en .Net core. Pero tienen un plan.
  • Faltan algunas características en .Net Core, como System.Drawing, debe buscar bibliotecas de terceros
  • Debe usar nginx como servidor frontal con kestrelserver para aplicaciones asp.net, porque kestrelserver no está listo para la producción. Por ejemplo, HTTP / 2 no está implementado.

Espero que ayude