.NET Core frente a Mono

292

¿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 a través de pilas de aplicaciones, como Mono".

Mi objetivo es usar C #, LINQ, EF7 y Visual Studio para crear un sitio web que se pueda ejecutar / hospedar 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". Tampoco sé lo que eso significa.

¿Puede ayudarme a entender todos estos términos y si mis expectativas son realistas?

6
  • 2
    No estoy seguro de que .NET Core sea compatible con Mono (o si incluso necesita mono, ¿ahora?), Al menos no del todo. Eche un vistazo aquí para ver lo que es compatible con Mono. FastCGI es simplemente el servidor que ejecuta código ASP.NET con mono. Ahora, habiendo dicho eso, ¿hay alguna razón en particular por la que necesite ejecutarlo en Linux? Si no hay una razón urgente (que no sea solo querer usar Linux), probablemente sea mejor tomar un servidor de Windows para ejecutar código .NET, al menos por el momento. Rob 10/06/2016 a las 0:17
  • Sí, el servidor en el que se alojará definitivamente será Linux. No es una opción utilizar el servidor de Windows. Dijiste que no estás seguro de si .NET core es compatible con Mono. pero no sé qué es Mono. ¿Cuál sería un argumento para usar .Net Core en lugar de Mono? Captainlonate 10 de junio de 2016 a las 0:28
  • 13
    Para ser generales sobre lo que es mono: es esencialmente una implementación de código abierto de las bibliotecas .net (más compilaciones e intérpretes). Por ejemplo, cuando escribe Math.Pow(2, 3), los binarios que contienen la implementación son de código cerrado y son solo para Windows. Algunas personas decidieron que les gustaba .NET lo suficiente como para quererlo para * nix. Así que escribieron su propia versión de los binarios de código cerrado. Luego escribieron un compilador y un intérprete. Mono es esencialmente una reimplementación de todo lo que anteriormente era de código cerrado y escrito para ejecutarse en windows / linux / osx. Rob 10/06/2016 a las 0:34
  • 2
    Escribí una publicación de blog el año pasado, blog.lextudio.com/2015/12/… Puede usar cualquiera de los dos, pero .NET Core será el futuro más brillante. Lex Li 10 de junio de 2016 a las 3:10
  • 3
    La palabra "Core" en ".NET Core" puede ser la fuente de un error. ¡Dé a sus bebés nombres propios! Make Me Smarter Every Day 1 de junio de 2018 a las 20:18
290

Nigromante.
Proporcionar una respuesta real.

What is the difference between .Net Core and 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 la interoperabilidad con C dlls, podría, si lo deseara absolutamente, escribir sus propias aplicaciones de escritorio con él, por ejemplo, a través de bibliotecas de terceros como Avalonia, que eran un poco muy básicos en el momento en que escribí esto por primera vez, lo que significaba que estaba bastante limitado a la web o al 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 el .NET Framework completo permanecerá en modo de mantenimiento como .NET Framework 4.8.x completo durante algunas décadas, hasta que muera (tal vez todavía haya 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, además del soporte multiplataforma, es mejorar el rendimiento y habilitar la "compilación nativa" / implementación autónoma (por lo que no necesita .NET framework / VM instalado en la máquina de destino .
Por un lado, esto significa compatibilidad con docker.io en Linux y, por otro, la implementación autónoma es útil en "computación en la nube", ya que entonces puede usar cualquier versión del marco dotnet-CORE que desee, y no tiene que preocuparse por la (s) versión (s) de .NET framework que el administrador de sistemas ha instalado realmente.

Si bien el tiempo de ejecución de .NET Core admite varios sistemas operativos y procesadores, el SDK es una historia diferente. Y aunque el SDK admite varios sistemas operativos, la compatibilidad con ARM para el SDK aún está en proceso. .NET Core es compatible con Microsoft. Dotnet-Core no vino con WinForms o WPF ni nada por el estilo.

  • 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 de VB.NET planeado para v5 en 2020). Y no hay diseñador de formularios en .NET Core: se enviará con una actualización de Visual Studio más adelante, en un momento no especificado.
  • Los WebForms todavía no son compatibles con .NET Core, y no hay planes para admitirlos nunca ( 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 una especie de envoltura de System.Runtime / mscorelib (y algunos otros), que le permite escribir bibliotecas destinadas 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 verifiqué.

"The Mono Project" es mucho más antiguo que .NET Core.
Mono es español y significa mono, y como comentario al margen, 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 Web-Forms, 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 (a diferencia de 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 enfocaban 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 de C # para compilar en mono, pero no el material de VB.NET.
Mono pierde algunas funciones avanzadas, como WSE / WCF y WebParts.
Muchas de las implementaciones de Mono están incompletas (por ejemplo, lanzan NotImplementedException en el cifrado ECDSA), tienen errores (por ejemplo, ODBC / ADO.NET con Firebird), se comportan de manera diferente a .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 espere que multiplataforma signifique que en realidad podría instalar .NET Core en ARM-Linux, como puede hacerlo con ElasticSearch. Tendrá que compilar todo el marco desde la fuente.
Es decir, si tiene ese espacio (por ejemplo, en un Chromebook, que tiene un disco duro total de 16 a 32 GB).
También solía tener problemas de incompatibilidad con OpenSSL 1.1 y libcurl.
Aquellos se han rectificado en la última versión de .NET Core Versión 2.2.
Demasiado para multiplataforma.

I found a statement on the official site that said, "Code written for it is also portable across application stacks, such as Mono".

Siempre que 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 del sistema predeterminado (página de códigos) y no tiene problemas con el separador 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 GIF en movimiento o tiff de varias páginas o escribiendo texto en una imagen, se sorprenderá desagradablemente.

Note:
As of .NET Core 2.0, there is System.Drawing.Common (NuGet), which contains most of the functionality of System.Drawing. It should be more or less feature-complete in .NET-Core 2.1. However, System.Drawing.Common uses GDI+, and therefore won't work on Azure (System.Drawing libraries are available in Azure Cloud Service [basically just a VM], but not in Azure Web App [basically shared hosting?])
So far, System.Drawing.Common works fine on Linux/Mac, but has issues on iOS/Android - if it works at all, there.
Prior to .NET Core 2.0, that is to say sometime mid-February 2017, you could use SkiaSharp for imaging (example) (you still can).
Post .net-core 2.0, you'll notice that SixLabors ImageSharp is the way to go, since System.Drawing is not necessarely secure, and has a lot of potential or real memory leaks, which is why you shouldn't use GDI in web-applications; Note that SkiaSharp is a lot faster than ImageSharp, because it uses native-libraries (which can also be a drawback). Also, note that while GDI+ works on Linux & Mac, that doesn't mean it works on iOS/Android.

El código no escrito para .NET (no Core) no es portátil a .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 este momento)( ya no ). No importa el control ReportViewer, que utiliza Windows-pInvokes (para cifrar, crear documentos mcdf a través de COM y obtener información de fuentes, caracteres, interletraje, incrustación de fuentes, medir cadenas y saltos de línea, y para dibujar 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).

My goal is to use C#, LINQ, EF7, visual studio to create a website that can be ran/hosted in linux.

EF en cualquier versión que probé hasta ahora fue tan malditamente lento (incluso en cosas tan simples como una tabla con una unión a la 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 esquemas).
Y tampoco en una situación en la que el rendimiento de la base de datos sea crítico (digamos 10+ a 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 no admite (todavía) la depuración de proyectos .NET Core.
Si tiene problemas, está solo. Tendrá que utilizar 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 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, alrededor del 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 del disco, por lo que 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.

Someone told me that he wanted it to be "in Mono", but I don't know what that means.

O 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 desea hacerlo en C #. No vayas con "Mono propiamente dicho"; En la superficie, parecería funcionar al principio, pero créame, se arrepentirá porque ASP.NET MVC de Mono no es estable cuando su servidor se ejecuta a largo plazo (más de 1 día). Ahora ha recibido una advertencia. Consulte también las referencias "no completo" al medir el rendimiento de Mono en los puntos de referencia de techempower.

fortunas

I know I want to use the .Net Core 1.0 framework with the technologies I listed above. He also said he wanted to use "fast cgi". I don't know what that means either.

Significa que quiere usar un servidor web de alto rendimiento con todas las funciones como nginx (Engine-X), posiblemente Apache.
Luego, puede ejecutar mono / dotnetCore con alojamiento virtual basado en nombres (varios 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 para un determinado dominio a través del protocolo fastcgi a ese servidor. También significa que su sitio web se ejecuta en fastcgi-pipeline, y debe tener cuidado con lo que hace, por ejemplo, no puede usar HTTP 1.1 al transmitir archivos.
De lo contrario, los archivos se distorsionarán en el destino.
Consulte 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 puedes compilarlo en ARM (me las arreglé para hacer eso, NO sigas la publicación del blog de Scott Hanselman si haces eso , hay un cómo 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 que ha instalado nodejs - Código VS requiere una versión, Yeoman otra ... pero debe ejecutar en el mismo equipo bastante cojo.
No importa que debería funcionar en la versión nodo enviado por defecto en el sistema operativo.
No importa que no debería haber dependencia de 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 hayan probado para asegurarse de que "todo funciona ". De hecho, acabo de intentar crear una aplicación fastcgi con .NET Core y me di cuenta de que no existe una biblioteca FastCGI para .NET Core "RTM" ...

Entonces, cuando vaya a ejecutar .NET Core "RTM" detrás de nginx, solo puede hacerlo enviando solicitudes a kestrell (ese servidor web semielaborado derivado de nodeJS); actualmente no hay soporte de fastcgi en .NET Core "RTM", AFAIK. Dado que no hay una biblioteca .net core fastcgi, y no hay muestras, también es muy poco probable que alguien haya hecho alguna prueba en el marco para asegurarse de que fastcgi funcione como se esperaba.

También cuestiono el desempeño.
En el (preliminar) techempower-benchmark (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 ubican en el 96,9% del rendimiento máximo (y eso es cuando se devuelve texto plano sin archivo -sólo acceso al sistema). .NET Core funciona un poco mejor en la serialización JSON, pero tampoco parece atractivo (go 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 han sido portadas (todavía), y dudo que algunas de ellas alguna vez lo sean.
El soporte de imágenes también es cuestionable en el mejor de los casos.
Para cualquier cifrado, use BouncyCastle en su lugar.

Can you help me make sense of all these terms and if my expectations are realistic?

Espero haberte ayudado a entender mejor todos estos términos.
En lo que respecta a sus expectativas:
desarrollar una aplicación de Linux sin saber nada sobre Linux es una idea realmente estúpida en primer lugar, y también está destinada a fallar de alguna manera horrible de una forma u otra. Dicho esto, debido a que Linux no tiene costos de licencia, es una buena idea en principio, PERO SOLO SI SABE LO QUE HACE.
Desarrollar una aplicación para una plataforma en la que no puedes depurar tu 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 sería una muy buena experiencia; luego, conocerá cuál es el marco y cuáles son los problemas fuera del marco.
Por ejemplo, puede montar en bucle (mediante programación) un fat32, hfs o JFS que no distinga entre mayúsculas y minúsculas para su aplicación, para evitar los problemas de sensibilidad a las mayúsculas y minúsculas (el montaje en bucle no se recomienda en producción).

Para resumir
En la actualidad (2016-09-28), me mantendría alejado de .NET Core (para uso en producción). Tal vez en uno o dos años puedas echar otro vistazo, pero probablemente no antes.
Si tiene un nuevo proyecto web que desarrolla, inícielo en .NET Core, no 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 no dependa de .NET, Java o Windows, utilice 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 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 la mononucleosis, manténgase alejado de ella.
Es asombroso lo lejos que ha llegado el mono, pero desafortunadamente eso no sustituye a 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 ahí es donde Xamarin gana dinero.
No espere que Web-Development sea un ciudadano de Xamarin / mono de primera clase.
.NET Core puede valer la pena, si comienza un nuevo proyecto, pero para los grandes proyectos de formularios web existentes, la migración está fuera de discusión, los cambios requeridos son enormes. Si tiene un proyecto MVC, la cantidad de cambios podría ser manejable, si el diseño de su aplicación original era sensato, lo cual no es el caso de la mayoría de las aplicaciones llamadas "históricamente desarrolladas".

Actualización de diciembre de 2016:
La compilación nativa se eliminó de la vista previa de .NET Core, ya que aún no está lista ...

Parece que han mejorado bastante en el punto de referencia de archivos de texto sin procesar, pero por otro lado, se han vuelto bastante defectuosos. 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 un alivio en el frente del IDE de Linux.
JetBrains lanzó "Project Rider", una vista previa de acceso anticipado de un IDE de C # / .NET Core para Linux (y Mac y Windows), que puede manejar archivos de proyectos de Visual Studio. 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 previa al lanzamiento a medida que avanzamos hacia 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 no pierdas de vista Project Rider.

buggy .net core

Actualización de 2017
He migrado la página de inicio de mi (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-content-deployment. La implementación autónoma funciona, pero está un poco poco documentada, aunque es muy fácil (las herramientas de compilación / publicación son un poco inestables, sin embargo, si encuentra "Número positivo requerido. - Build FAILED." - 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

Note: As per .NET Core 3, you can publish everything minified as a single file:

dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true

However, unlike go, it's not a statically linked executable, but a self-extracting zip file, so when deploying, you might run into problems, especially if the temp directory is locked down by group policy, or some other issues. Works fine for a hello-world program, though. And if you don't minify, the executable size will clock in at something around 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. Bonito. 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, para que todo lo demás funcione)

(Nota: SkiaSharp en Windows 8.1 no tiene 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 lanzada.
Tenga cuidado, viene con cambios (enormes) en la autenticación ...
Por el lado positivo, trajo de vuelta las clases DataTable / DataAdaper / DataSet, y muchas más.
Se ha dado cuenta de que .NET Core aún no es compatible con Apache SparkSQL, porque Mobius aún no se ha adaptado. Eso es malo, porque eso significa que no hay compatibilidad con SparkSQL para mi IoT Cassandra Cluster, por lo que no hay uniones ...
Compatibilidad con ARM experimental (solo en tiempo de ejecución, no SDK, una lástima para el trabajo de desarrollo en mi Chromebook, con ganas de 2.1 o 3.0).
PdfSharp ahora se ha portado experimentalmente a .NET Core.
Jinete de JetBrainsdejó 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 solucione 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 corrigiéndolo en v2.1, sin versión de corrección de errores para 2.0).
Pero no estoy instalando versiones de vista previa en mi máquina. Tan 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. Aún no hay ARM-64.
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 en este momento), porque Arch Linux usa OpenSSL 1.1. Entonces, si está usando Arch Linux, no tiene suerte (con Gentoo también).

Editar:

Latest version of .NET Core 2.2+ supports OpenSSL 1.1. So you can use it on Arch or (k)Ubuntu 19.04+. You might have to use the .NET-Core install script though, because there are no packages, yet.

Por el lado positivo, el rendimiento definitivamente ha mejorado: fortunas

Texto sin formato

.NET Core 3:
Se dice que .NET-Core v 3.0 lleva WinForms y WPF a .NET-Core.
Sin embargo, mientras que WinForms y WPF serán .NET Core, WinForms y WPF en .NET-Core solo se ejecutarán 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. El soporte de WinForms para VB.NET no es compatible , pero está previsto para .NET 5.0 en algún momento de 2020 .

PD:

echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1 

Si lo ha usado en Windows, probablemente nunca vio esto:

The .NET Core tools collect usage data in order to improve your experience.
The data is anonymous and does not include command-line arguments.
The data is collected by Microsoft and shared with the community.
You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell.
You can read more about .NET Core tools telemetry @ 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, se puede usar en gran medida.
Sin embargo, JetBrains Rider (2018 EAP en este momento) es definitivamente mucho más agradable y confiable (y el descompilador incluido es más seguro para la vida), 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 API de depuración dll (excepto 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 el depurador de Samsung para MonoDevelop

Descargo de responsabilidad:
no uso Mac, por lo que no puedo decir si lo que escribí aquí también se aplica a Mac basado en FreeBSD-Unix. Me refiero a la versión Linux (Debian / Ubuntu / Mint) de JetBrains Rider, mono, MonoDevelop / VisualStudioMac / XamarinStudio y .NET-Core. Además, Apple está contemplando pasar de los procesadores Intel a los procesadores basados ​​en ARM de fabricación propia (¿ARM-64?), 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 la ejecución de aplicaciones web a través de fastcgi o con XSP (en la versión 4.x de mono), así como la serialización XML. -Manipulación de peculiaridades, y la bastante lenta 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 sobre mono 2.x, 3.xy 4.x, eso tampoco significa necesariamente que estos problemas no se hayan resuelto hasta ahora, o cuando esté leyendo esto, ni que si lo están arreglado ahora, que no puede haber una regresión más adelante que reintroduzca cualquiera de estos errores / características. Eso tampoco significa que si incrusta el tiempo de ejecución mono, obtendrá los mismos resultados que cuando usa 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 eso no significa necesariamente que mono no sea adecuado para iOS o Android, o que tenga los mismos problemas allí. No uso mono en Android o IOS, por lo que no estoy en posición de decir nada sobre estabilidad, usabilidad, costos y rendimiento en estas plataformas. Obviamente, si usa .NET en Android, también tiene que hacer otras consideraciones de costos, como ponderar los costos de xamarin frente a los costos y el tiempo para migrar 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 del sistema predeterminado sea la misma en android / ios que en Windows, y no espere que el sistema de archivos de Android no distinga entre mayúsculas y minúsculas, y no espere que haya fuentes de Windows presentes. .

46
  • 6
    @Tseng: Ah, sí, ¿es bs? ¿Ha visto Winforms Core o WPF Core entonces? Sí, técnicamente es un puerto multiplataforma de .NET Framework y no tiene nada que ver con MVC. Pero las aplicaciones web (ASP.NET MVC) y las aplicaciones de consola son lo único que puede hacer con .NET Core en este momento ... Y sí MVC, porque no hay WebForms Core. Eso es lo que es en este momento, simple y llanamente. Pero es cierto, no tiene que usar MVC en sus aplicaciones web solo porque usa .NET Core. También puede crear una aplicación web sin MVC. Pero en cuanto a SEO, no tendría mucho sentido hacerlo. Stefan Steiger 17 de febrero de 2017 a las 7:53
  • 19
    Decir que Mono es "bastante inestable y lento" es infundado, si no erróneo. Pero aparte de eso, buena información aquí. Noldorin 17/04/2017 a las 15:54
  • 75
    Esta respuesta tiene muchas opiniones y contiene muchas referencias puntuales. Caleb 1 de agosto de 2017 a las 13:01
  • 24
    Me duele ver que la primera oración de esta respuesta altamente calificada es tan descaradamente incorrecta. .NET Core no es una reescritura del marco ASP.NET MVC. JHo 16 nov 2017 a las 18:10
  • 6
    @ stefan-steiger Incluso decir "en su mayor parte" es completamente incorrecto y no es en absoluto el propósito de .NET Core. "De nuevo"? En lugar de repetirte, ¿por qué no lo cambias? JHo 19/11/2017 a las 16:29
54

En el mundo .NET hay dos tipos de CLR, CLR "completos" y CLR Core, y son cosas bastante diferentes.

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

Los CLR básicos, por otro lado, 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 funciones al CLR que usa su producto de software específico, usando NuGet. Hay implementaciones Core CLR para Windows, Linux (varios) y Unix (Mac OS X y FreeBSD) en la mezcla. Microsoft también ha refactorizado o está refactorizando las bibliotecas de .NET Framework para Core CLR, para hacerlas más portátiles para el contexto central. Dada la presencia de mono en los sistemas operativos * nix, sería una sorpresa que los Core CLR para * nix no incluyeran alguna base de código mono, pero solo la comunidad Mono y Microsoft podrían decirnos eso con seguridad.

Además, estoy 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 enviar su sitio en Linux usando 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 lo harías con el puerto si quieres más tarde, a Core.

3
  • 2
    No entraría en Mono sabiendo que no es un host permanente para mi aplicación web de producción, ¡especialmente sabiendo desde el principio que me costaría un esfuerzo adicional portarlo a Core! Panayiotis Hiripis 5 de agosto de 2017 a las 6:47
  • @Panayiotis Hiripis: depurar las desviaciones de comportamiento mono, lidiar con servidores web mono inestables y excepciones no implementadas, así como los costos de interrupción cuando un servidor mono inestable falla, también le costará, y probablemente mucho más que la migración a .NET Centro. Si dedico tiempo, preferiría pasar el tiempo actualizándome a versiones más nuevas, más rápidas y mejor diseñadas, en lugar de corregir errores en versiones antiguas y mantener un proyecto con tecnología heredada. Mudarse a tiempo le ahorrará muchos dolores de cabeza más adelante. En algún momento, tendrás que migrar de todos modos ... TheSoonerYouMove, theLessYouPort más tarde. Stefan Steiger 20 de septiembre de 2017 a las 11:32
  • Vale la pena señalar el tiovivo que está vinculado al administrador de la biblioteca. En un momento (¡no hace tanto tiempo!) Tuvimos esta cosa llamada DLL Hell. Ocurrió porque se lanzaron múltiples copias de dlls (a veces versiones diferentes) con diferentes aplicaciones. Java todavía tiene este problema. Microsoft intentó resolver esto con el registro COM y luego el .NET GAC. .NET Core lo reintroduce. Un día todos daremos vueltas, después de algunos años de jugar con dlls e implementaciones, volveremos a crear: un registro. NuGet, Maven, Gradle: estas son solo formas de administrar en lugar de resolver. muszeo 30 oct 2018 a las 1:38
15

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 actual 4.4.1 no puede ejecutar el último 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 lanza .Net core, el ecosistema de terceros no está del todo ahí. Por ejemplo, Nhibernate, Umbraco, etc., aún no se pueden ejecutar sobre .Net core. Pero tienen un plan.
  • Hay algunas características que faltan 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

3
  • Hay un servidor web llamado jexusque puede alojar el sitio web ASP.NET en Linux. Mi sitio personal está escrito con NancyFx (originalmente ASP.NET MVC4) que se ejecuta en él. zwcloud 1 de nov. De 2016 a las 7:59
  • La segunda viñeta es incorrecta. Actualmente estoy enviando una aplicación ASP.NET Core 1.0 en Mono 4.4.0 y desde entonces he estado aproximadamente en beta8. Ben Collins 21/11/2016 a las 18:30
  • @zwcloud: ¿Por qué no usar mono.xsp4 /4.5 con nginx? Realmente no hay necesidad de jexus. Stefan Steiger 19/12/2016 a las 9:51
11

.Net Core no requiere mono en el sentido del marco mono. .Net Core es un marco que funcionará en múltiples plataformas, incluido 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 sin RC2 disponible), sin embargo mono no es un marco de trabajo y soporte de Microsoft recomendaría usar un marco compatible

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

Actualmente estoy usando ambos marcos, sin embargo, debe comprender que todavía se encuentra en la etapa de candidato de lanzamiento ( RC2es la versión actual) y sobre los candidatos de lanzamiento y beta ha habido cambios masivos que generalmente terminan rascándose 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 una opción de servidores web (de donde supongo que fast cgiproviene la referencia) 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 en su mayoría enlaces a documentación, pero en este punto esas son sus mejores fuentes de información. .Net core es todavía relativamente nuevo en la comunidad .Net y hasta que se publique por completo, dudaría en usarlo en un entorno de producto debido a los cambios importantes entre las versiones publicadas.

4
  • 6
    Microsoft ahora es propietario de Xamarin, que desarrolla mono. Así que tanto mono como .Net Core son compatibles con MS. Joel Coehoorn 10 de junio de 2016 a las 1:34
  • @JoelCoehoorn Entiendo que Microsoft es propietario de Xamarin, pero no sé si Xamarin es propietario de Mono. Sin embargo, de los documentos docs.asp.net/en/1.0.0-rc1/getting-started/… indica que no es compatible. Mono no es una plataforma compatible con Microsoft; sin embargo, es un buen campo de pruebas para el desarrollo multiplataforma mientras madura el soporte multiplataforma en .NET Core. Ahora bien, esto puede estar mal o desactualizado. Nico 10 de junio de 2016 a las 2:13
  • @Nico en RC1 time, Xamarin aún no fue adquirido por Microsoft. Puede consultar la línea de tiempo para obtener más detalles, corefx.strikingly.comLex Li 10 de junio de 2016 a las 3:08
  • Mono no es compatible con Microsoft. MS admite la organización de Xamarin, pero no hacen nada por el proyecto Mono. Kotauskas 21/07/2018 a las 13:31
9

Esta pregunta es especialmente real 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:

  • APIs — .NET Core contains many of the same, but fewer, APIs as the .NET Framework, and with a different factoring (assembly names are
    different; type shape differs in key cases). These differences
    currently typically require changes to port source to .NET Core. .NET Core implements the .NET Standard Library API, which will grow to
    include more of the .NET Framework BCL APIs over time.
  • Subsystems — .NET Core implements a subset of the subsystems in the .NET Framework, with the goal of a simpler implementation and
    programming model. For example, Code Access Security (CAS) is not
    supported, while reflection is supported.

Si necesita lanzar algo rápidamente, elija Mono porque actualmente (junio de 2016) es un producto más maduro, pero si está creando un sitio web a largo plazo, sugeriría .NET Core. Es compatible oficialmente 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.

My goal is to use C#, LINQ, EF7, visual studio to create a website that can be ran/hosted in linux.

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

9

Esto ya no es .NET Core frente a Mono. Está unificado.

Actualización de noviembre de 2020 : lanzamiento de .NET 5 que unifica .NET Framework y .NET Core

.NET y Mono se unificarán bajo .NET 6 que se lanzará en noviembre de 2021

  • .NET 6.0 agregará net6.0-iosy net6.0-android.
  • Los nombres específicos del sistema operativo pueden incluir números de versión del sistema operativo, como net6.0-ios14.

Consulte los artículos a continuación:

7

Para ser simple

Mono is third party implementation of .Net framework for Linux/Android/iOs

.Net Core is microsoft's own implementation for same.

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

1
  • 9
    Este no parece ser el caso, sino que está expresando suposiciones / opiniones. Oficialmente, este es el futuro de mono: mono-project.com/news/2016/11/29/mono-code-sharing Parece que mantendrá como .net core es solo ese "core" un subconjunto del marco completo y mono seguirá siendo el único marco multiplataforma, aunque con .net el código estándar se puede compartir con mono y el marco .net completo (y otros Implementaciones .net también como .net core, por supuesto)pqsk 12/04/2017 a las 16:28
1

Este es uno de mis temas favoritos y el contenido aquí fue simplemente increíble. Estaba pensando si valdría la pena o sería efectivo comparar los métodos disponibles en Runtime vs. Mono. Espero entender bien mis términos, pero creo que ya sabes a qué me refiero. Para tener una mejor comprensión de lo que cada Runtime soporta actualmente, ¿tendría sentido comparar los métodos que ofrecen? Me doy cuenta de que las implementaciones pueden variar, y no he considerado las bibliotecas Framework Class ni la gran cantidad de otras bibliotecas disponibles en un entorno frente al otro. También me doy cuenta de que es posible que alguien ya haya hecho este trabajo de manera aún más eficiente. Le agradecería mucho que me lo hiciera saber para poder revisarlo. Siento que hacer una diferencia entre el resultado de dicha actividad sería valioso y quería ver cómo se sienten los desarrolladores más experimentados al respecto.y proporcionarían una guía útil. Mientras estaba jugando con la reflexión, escribí algunaslíneas que atraviesan el directorio .net y enumeran los ensamblados.

-15

En una palabra:

Mono = compilador para C #

Desarrollo mono = compilador + IDE

.Net Core = Compilador ASP

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

1
  • 15
    Casi todo en esta respuesta es tremendamente incorrecto. Douglas Gaskell 23 de marzo de 2019 a las 3:22