Necromante.
Fornecendo uma resposta real.
Qual é a diferença entre .Net Core e Mono?
O .NET Core agora oficialmente é o futuro do .NET. Começou na maior parte com uma reescrita da estrutura do ASP.NET MVC e dos aplicativos de console, que obviamente incluem aplicativos de servidor. (Como é Turing-complete e oferece suporte à interoperabilidade com C dlls, você também pode escrever seus próprios aplicativos de desktop, por exemplo, através de bibliotecas de terceiros como Avalonia, que eram um pouco muito básicos no momento em que escrevi isso, o que significava que você estava muito limitado às coisas da Web ou do servidor.) Com o tempo, muitas APIs foram adicionadas ao .NET Core, tanto que, após a versão 3.1, O .NET Core passará para a versão 5.0, conhecido como .NET 5.0 sem o "Core", e esse será o futuro do .NET Framework. O que costumava ser o .NET Framework completo permanecerá no modo de manutenção como o Full .NET Framework 4.8.x por algumas décadas, até que desapareça (talvez ainda haja algumas atualizações, mas duvido). Em outras palavras, o .NET Core é o futuro do .NET e o Full .NET Framework seguirá o caminho do Dodo / Silverlight / WindowsPhone .
O ponto principal do .NET Core, além do suporte a várias plataformas, é melhorar o desempenho e habilitar a "compilação nativa" / implantação independente (para que você não precise da estrutura / VM do .NET instalada na máquina de destino). .
por um lado, isso significa docker.io suporte no Linux, e por outro a implantação, auto-suficiente é útil em "cloud-computing", desde então você pode apenas usar qualquer versão do quadro dotnet-CORE você gosta, e você não precisa se preocupar com quais versões da estrutura .NET o sysadmin realmente instalou.
Enquanto o tempo de execução do .NET Core suporta vários sistemas operacionais e processadores, o SDK é uma história diferente. E enquanto o SDK suporta vários sistemas operacionais, o suporte ARM para o SDK ainda está em andamento. O .NET Core é suportado pela Microsoft. O Dotnet-Core não veio com o WinForms ou WPF ou qualquer coisa assim.
- A partir da versão 3.0, o WinForms e o WPF também são suportados pelo .NET Core, mas apenas no Windows e somente em C #. Não pelo VB.NET (suporte ao VB.NET planejado para v5 em 2020). E não há Forms Designer no .NET Core: ele está sendo enviado com uma atualização do Visual Studio posteriormente, em um horário não especificado.
- Os WebForms ainda não são suportados pelo .NET Core, e nunca há planos para apoiá-los ( Blazor é o novo garoto na cidade para isso).
- O .NET Core também vem com o System.Runtime, que substitui o mscorelib.
- Muitas vezes, o .NET Core é confundido com o NetStandard , que é um invólucro em torno do System.Runtime / mscorelib (e alguns outros), que permite gravar bibliotecas direcionadas ao .NET Core, Full .NET Framework e Xamarin (iOS / Android), tudo ao mesmo tempo.
- o .NET Core SDK não / não funcionou no ARM, pelo menos não da última vez que verifiquei.
"The Mono Project" é muito mais antigo que o .NET Core.
Mono é espanhol e significa macaco, e como observação lateral, o nome não tem nada a ver com mononucleose (dica: você pode obter uma lista de funcionários em http://primates.ximian.com /).
O Mono foi iniciado em 2005 por Miguel de Icaza (o cara que iniciou o GNOME - e alguns outros) como uma implementação do .NET Framework para Linux (Ximian / SuSe / Novell). O Mono inclui Web-Forms, Winforms, MVC, Olive e um IDE chamado MonoDevelop(também conhecido como Xamarin Studio ou Visual Studio Mac). Basicamente, o equivalente a (OpenJDK) JVM e (OpenJDK) JDK / JRE (em oposição ao SUN / Oracle JDK). Você pode usá-lo para que aplicativos ASP.NET-WebForms + WinForms + ASP.NET-MVC funcionem no Linux.
O Mono é suportado pelo Xamarin (o novo nome da empresa do que costumava ser o Ximian, quando se concentrava no mercado móvel, em vez do Linux), e não pela Microsoft.
(desde que o Xamarin foi comprado pela Microsoft, é tecnicamente [mas não culturalmente] a Microsoft.)
Geralmente, você compara seu material C # em mono, mas não o material VB.NET.
O Mono perde alguns recursos avançados, como WSE / WCF e WebParts.
Muitas das implementações Mono são incompletas (por exemplo, lançam NotImplementedException na criptografia ECDSA), com bugs (por exemplo, ODBC / ADO.NET com Firebird), se comportam de maneira diferente do .NET (por exemplo, serialização XML) ou são instáveis (ASP.NET MVC) e inaceitavelmente lento (Regex). No lado positivo, a cadeia de ferramentas Mono também funciona no ARM.
No que diz respeito ao .NET Core, quando se diz entre plataformas, não espere que essa plataforma signifique que você possa realmente instalar o .NET Core no ARM-Linux, como você pode fazer com o ElasticSearch. Você terá que compilar toda a estrutura a partir da fonte.
Ou seja, se você tiver esse espaço (por exemplo, em um Chromebook, que tenha um HD total de 16 a 32 GB).
Também costumava ter problemas de incompatibilidade com o OpenSSL 1.1 e libcurl.
Esses foram corrigidos na versão mais recente do .NET Core Versão 2.2.
Tanta coisa para várias plataformas.
Encontrei uma declaração no site oficial que dizia: "O código escrito para ele também é portátil em pilhas de aplicativos, como o Mono".
Desde que esse código não dependa de chamadas WinAPI, Windows-dll-pinvokes, COM-Components, um sistema de arquivos que não diferencia maiúsculas de minúsculas, a codificação do sistema padrão (página de códigos) e não possui problemas de separador de diretório, isso é corrigir. No entanto, o código do .NET Core é executado no .NET Core e não no Mono. Então, misturar os dois será difícil. E como o Mono é bastante instável e lento (para aplicativos da Web), eu não o recomendaria de qualquer maneira. Experimente o processamento de imagens no núcleo do .NET, por exemplo, WebP ou mova GIF ou texto de várias páginas ou escreva texto em uma imagem; você ficará surpreso.
Nota:
A partir do .NET Core 2.0, existe o System.Drawing.Common (NuGet), que contém a maioria das funcionalidades do System.Drawing. Ele deve ter mais ou menos recursos completos no .NET-Core 2.1. No entanto, System.Drawing.Common utiliza GDI + e, portanto, não vai funcionar no Azure (bibliotecas System.Drawing estão disponíveis em Azure Service Cloud [basicamente apenas uma VM], mas não em Azure Web App [basicamente de hospedagem compartilhada?])
Assim, Até agora, o System.Drawing.Common funciona bem no Linux / Mac, mas tem problemas no iOS / Android - se funcionar, existe.
Antes do .NET Core 2.0, ou seja, em meados de fevereiro de 2017, você poderia usar o SkiaSharp para geração de imagens (por exemplo) (você ainda pode).
Após o .net-core 2.0, você notará que o SixLabors ImageSharpé o caminho a percorrer, pois o System.Drawing não é necessariamente seguro e possui muitos vazamentos de memória reais ou potenciais, e é por isso que você não deve usar o GDI em aplicativos da Web; Observe que o SkiaSharp é muito mais rápido que o ImageSharp, porque usa bibliotecas nativas (o que também pode ser uma desvantagem). Além disso, observe que, embora o GDI + funcione no Linux e Mac, isso não significa que funcione no iOS / Android.
O código não gravado para .NET (não Core) não é portátil para o .NET Core.
Ou seja, se você deseja que uma biblioteca C # que não seja da GPL, como o PDFSharp, crie documentos em PDF (muito comum), estará sem sorte(no momento)( não mais ). Não importa o controle ReportViewer, que usa o Windows-pInvokes (para criptografar, criar documentos mcdf via COM, e obter informações sobre fontes, caracteres, kerning, incorporação de fontes, medir seqüências de caracteres e quebrar quebra de linha e realmente desenhar tiffs de qualidade aceitável) , e nem roda no Mono no Linux
( estou trabalhando nisso ).
Além disso, o código escrito no .NET Core não é portátil para o Mono, porque o Mono não possui as bibliotecas de tempo de execução do .NET Core (até o momento).
Meu objetivo é usar o C #, LINQ, EF7, visual studio para criar um site que possa ser executado / hospedado no linux.
A EF, em qualquer versão que eu tentei até agora, era muito lenta (mesmo em coisas simples como uma mesa com uma junção à esquerda), eu nunca a recomendaria - nem no Windows.
Eu particularmente não recomendaria a EF se você tiver um banco de dados com restrições exclusivas ou colunas varbinary / filestream / hierarchyid. (
Também não é para atualização de esquema.) E também não em uma situação em que o desempenho do banco de dados seja crítico (digamos 10+ a 100+ usuários simultâneos).
Além disso, a execução de um site / aplicativo da Web no Linux, mais cedo ou mais tarde, significa que você terá que depurá-lo.
Não há suporte para depuração do .NET Core no Linux.(Não é mais, mas requer o JetBrains Rider.) O
MonoDevelop (ainda) não suporta depuração de projetos do .NET Core.
Se você tiver problemas, estará por sua conta. Você precisará usar o log extensivo.
Cuidado, lembre-se de que o registro extensivo preencherá seu disco rapidamente, principalmente se o programa entrar em um loop infinito ou recursão.
Isso é especialmente perigoso se o aplicativo da web for executado como raiz, pois o login requer espaço no arquivo de log - se não houver mais espaço livre, você não poderá mais fazer login.
(Normalmente, cerca de 5% do espaço em disco é reservado para o usuário root (também conhecido como administrador no Windows), portanto, pelo menos, o administrador ainda pode efetuar login se o disco estiver quase cheio. Mas se os aplicativos executarem como root, essa restrição não se aplicará uso de disco e, portanto, seus arquivos de log podem usar 100% do espaço livre restante, para que nem mesmo o administrador possa fazer login mais.)
Portanto, é melhor não criptografar esse disco, ou seja, se você valoriza seus dados / sistema.
Alguém me disse que ele queria que fosse "em mono", mas eu não sei o que isso significa.
Isso significa que ele não deseja usar o .NET Core ou apenas o C # no Linux / Mac. Meu palpite é que ele só quer usar C # para um aplicativo Web no Linux. O .NET Core é o caminho a seguir, se você absolutamente deseja fazê-lo em C #. Não vá com "Mono apropriado"; na superfície, parece funcionar a princípio - mas acredite que você vai se arrepender, porque o ASP.NET MVC da Mono não é estável quando o servidor é executado a longo prazo (mais de um dia) - você foi avisado. Consulte também as referências "não concluídas" ao medir o desempenho Mono nos benchmarks de techempower.
Eu sei que quero usar a estrutura do .Net Core 1.0 com as tecnologias listadas acima. Ele também disse que queria usar o "cgi rápido". Também não sei o que isso significa.
Isso significa que ele deseja usar um servidor da Web de alto desempenho e com todos os recursos, como o nginx (Engine-X), possivelmente o Apache.
Em seguida, ele pode executar o mono / dotnetCore com hospedagem baseada em nome virtual (vários nomes de domínio no mesmo IP) e / ou balanceamento de carga. Ele também pode executar outros sites com outras tecnologias, sem exigir um número de porta diferente no servidor da web. Isso significa que seu site é executado em um servidor fastcgi e o nginx encaminha todas as solicitações da web para um determinado domínio por meio do protocolo fastcgi para esse servidor. Isso também significa que seu site é executado em um pipeline fastcgi e você precisa ter cuidado com o que faz, por exemplo, não pode usar o HTTP 1.1 ao transmitir arquivos.
Caso contrário, os arquivos serão distorcidos no destino.
Veja também aqui e aqui .
Para concluir: o
.NET Core atualmente (28-09-2016) não é realmente portátil, nem é realmente multiplataforma (em particular as ferramentas de depuração).
A compilação nativa também não é fácil, especialmente para ARM.
E para mim, também não parece que seu desenvolvimento esteja "realmente concluído", ainda.
Por exemplo, System.Data.DataTable / DataAdaper.Update está ausente ...
(não mais com o .NET Core 2.0)
Juntamente com as interfaces System.Data.Common.IDB *.(não mais com o .NET Core 1.1),
se alguma vez houver uma classe usada com frequência, será a DataTable / DataAdapter ...
Além disso, o instalador do Linux (.deb) falha, pelo menos na minha máquina e eu ' Tenho certeza de que não sou o único que tem esse problema.
Depure, talvez com o Visual Studio Code, se você puder construí-lo no ARM (eu consegui fazer isso - NÃO siga o post do Scott Hanselman se você fizer isso - há um tutorial no wiki do VS-Code no github), porque eles não oferecem o executável.
Yeoman também falha. (Eu acho que tem algo a ver com a versão do nodejs que você instalou - o VS Code requer uma versão, Yeoman outra ... mas deve ser executada no mesmo computador. Bastante lamentável
Não importa se ele deve ser executado na versão do nó fornecida por padrão no sistema operacional.
Não importa que não deva haver dependência do NodeJS em primeiro lugar.
O servidor kestell também está em andamento.
E, a julgar pela minha experiência com o projeto único, duvido muito que eles tenham testado o .NET Core no FastCGI ou que tenham alguma idéia do significado do suporte do FastCGI para sua estrutura, muito menos que eles o testaram para garantir que "tudo funcione " Na verdade, eu apenas tentei fazer um aplicativo fastcgi com o .NET Core e percebi que não há biblioteca FastCGI para o .NET Core "RTM" ...
Portanto, quando você executar o .NET Core "RTM" por trás do nginx, só poderá fazê-lo por proxy de solicitações ao kestrell (aquele servidor da Web derivado de JS derivado de nodeJS) - não há suporte a fastcgi no .NET Core atualmente "RTM", AFAIK. Como não existe uma biblioteca fastcgi principal .net e nenhuma amostra, também é altamente improvável que alguém tenha testado a estrutura para garantir que o fastcgi funcione conforme o esperado.
Eu também questiono o desempenho.
No (preliminar) techempower-benchmark (rodada 13) , o aspnetcore-linux ocupa 25% em relação ao melhor desempenho, enquanto estruturas comparáveis como Go (golang) têm 96,9% do desempenho máximo (e é ao retornar texto sem arquivo somente acesso ao sistema). O .NET Core se sai um pouco melhor na serialização JSON, mas também não parece atraente (atinge 98,5% do pico, .NET core 65%). Dito isto, não pode ser pior do que "mono adequado".
Além disso, como ainda é relativamente nova, nem todas as principais bibliotecas foram portadas (ainda), e duvido que algumas delas sejam portadas.
O suporte a imagens também é questionável, na melhor das hipóteses.
Para qualquer criptografia, use BouncyCastle.
Você pode me ajudar a entender todos esses termos e se minhas expectativas são realistas ?
Espero ter ajudado você a fazer mais sentido com todos esses termos.
No que diz respeito às suas expectativas:
Desenvolver um aplicativo Linux sem saber nada sobre o Linux é uma ideia realmente estúpida em primeiro lugar, e também pode falhar de uma maneira horrível, de um jeito ou de outro. Dito isto, como o Linux não tem custos de licenciamento, é uma boa idéia em princípio, MAS SOMENTE SE VOCÊ SABE O QUE FAZ.
Desenvolver um aplicativo para uma plataforma na qual você não pode depurar seu aplicativo é outra péssima idéia.
Desenvolver para fastcgi sem saber quais são as consequências, é outra idéia muito ruim.
Fazer tudo isso em uma plataforma "experimental" sem nenhum conhecimento específico da plataforma e sem o suporte à depuração é suicídio, se o seu projeto for mais do que apenas uma página pessoal. Por outro lado, acho que fazê-lo com sua página inicial pessoal para fins de aprendizado provavelmente seria uma experiência muito boa - então você saberá qual é a estrutura e quais são os problemas que não são estrutura.
Você pode, por exemplo (programaticamente) montar em loop um fat32, hfs ou JFS que não diferencia maiúsculas de minúsculas do seu aplicativo, para solucionar os problemas de distinção entre maiúsculas e minúsculas (montagem em loop não recomendada na produção).
Para resumir
No momento (28/09/2016), eu ficaria longe do .NET Core (para uso em produção). Talvez daqui a um ou dois anos, você possa dar uma outra olhada, mas provavelmente não antes.
Se você tiver um novo projeto da Web que você desenvolve, inicie-o no .NET Core, não mono.
Se você deseja uma estrutura que funcione no Linux (x86 / AMD64 / ARMhf) e Windows e Mac, que não tem dependências, ou seja, apenas vinculação estática e nenhuma dependência no .NET, Java ou Windows, use Golang. É mais maduro e seu desempenho é comprovado (o Baidu o usa com 1 milhão de usuários simultâneos), e o golang tem uma pegada de memória significativamente menor. Também golang está nos repositórios, o .deb é instalado sem problemas, o código-fonte é compilado - sem a necessidade de alterações - e o golang (enquanto isso) tem suporte para depuração com delve e JetBrainsGogland no Linux (e Windows e Mac). O processo de construção (e o tempo de execução) de Golang também não depende do NodeJS, que é mais uma vantagem.
No que diz respeito ao mono, fique longe dele.
É incrível o quão longe o mono chegou, mas infelizmente isso não substitui seus problemas de desempenho / escalabilidade e estabilidade para aplicativos de produção.
Além disso, o monodesenvolvimento está bastante morto, em grande parte apenas desenvolvem as partes relevantes para Android e iOS, porque é aí que a Xamarin ganha seu dinheiro.
Não espere que o desenvolvimento da Web seja um cidadão Xamarin / mono de primeira classe.
O .NET Core pode valer a pena, se você iniciar um novo projeto, mas para projetos grandes de formulários da web existentes, a transferência de informações está amplamente fora de questão, as alterações necessárias são enormes. Se você possui um projeto MVC, a quantidade de alterações pode ser gerenciável, se o design original do seu aplicativo for sensato, o que geralmente não é o caso da maioria dos chamados aplicativos "crescidos historicamente".
Atualização de dezembro de 2016:
A compilação nativa foi removida da visualização do .NET Core, pois ainda não está pronta ...
Parece que eles melhoraram bastante no benchmark de arquivo de texto bruto, mas, por outro lado, ficou bastante complicado. Além disso, deteriorou-se ainda mais nos benchmarks JSON. Curioso também que a estrutura da entidade seja mais rápida para atualizações do que o Dapper - embora ambos com lentidão recorde. É muito improvável que isso seja verdade. Parece que ainda existem mais do que alguns bugs para caçar.
Além disso, parece haver alívio na frente do Linux IDE.
O JetBrains lançou o "Project Rider", uma prévia de acesso antecipado de um C # / .NET NET IDE para Linux (e Mac e Windows), que pode manipular arquivos do Visual Studio Project. Finalmente, um IDE C # que pode ser usado e não é lento como o inferno.
Conclusão: O .NET Core ainda é um software de qualidade de pré-lançamento à medida que avançamos para 2017. Portar suas bibliotecas, mas fique longe delas para uso em produção, até que a qualidade da estrutura se estabilize.
E fique de olho no Project Rider.
Atualização de 2017
Migrou a página inicial da minha (irmão) para o .NET Core por enquanto.
Até agora, o tempo de execução no Linux parece estável o suficiente (pelo menos para projetos pequenos) - ele sobreviveu a um teste de carga com facilidade - o mono nunca.
Além disso, parece que eu misturei o .NET-Core-native e o .NET-Core-self-contains-deployment. A implantação autônoma funciona, mas é um pouco sub-documentada, embora seja super fácil (as ferramentas de compilação / publicação são um pouco instáveis, ainda assim - se você encontrar "Número positivo necessário. - Compilação FAILED") - execute o mesmo comando novamente, e funciona).
Você pode correr
dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64
Nota: Conforme o .NET Core 3, você pode publicar tudo minificado como um único arquivo :
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true
No entanto, ao contrário do que ocorre, não é um executável vinculado estaticamente, mas um arquivo zip auto-extraível. Portanto, ao implantar, você pode ter problemas, principalmente se o diretório temporário estiver bloqueado pela diretiva de grupo ou por outros problemas . No entanto, funciona bem para um programa olá mundo. E se você não minificar, o tamanho do executável atingirá cerca de 100 MB.
E você obtém um arquivo .exe independente (no diretório de publicação), que pode ser movido para uma máquina Windows 8.1 sem o .NET framework instalado e deixá-lo em execução. Agradável. É aqui que o dotNET-Core começa a ficar interessante.(observe as lacunas, o SkiaSharp não funciona no Windows 8.1 / Windows Server 2012 R2, [ainda] - o ecossistema precisa recuperar o atraso primeiro - mas, curiosamente, o Skia-dll-load-fail não trava o servidor inteiro / aplicação - para que tudo funcione)
(Nota: O SkiaSharp no Windows 8.1 está ausente nos arquivos de tempo de execução do VC apropriados - msvcp140.dll e vcruntime140.dll. Copie-os no diretório de publicação e o Skia funcionará no Windows 8.1.)
Atualização de agosto de 2017
.NET Core 2.0 lançada.
Tenha cuidado - vem com (grandes interrupções) alterações na autenticação ...
Em contrapartida, trouxe de volta as classes DataTable / DataAdaper / DataSet e muito mais.
Ainda falta suporte ao .NET Core para o Apache SparkSQL, porque o Mobius ainda não foi portado. Isso é ruim, porque isso significa que não há suporte ao SparkSQL para meu IoT Cassandra Cluster, portanto não há associação ...
Suporte experimental ao ARM (somente tempo de execução, não SDK - muito ruim para devwork no meu Chromebook - ansioso para 2.1 ou 3.0).
O PdfSharp agora é portado experimentalmente para o .NET Core.
JetBrains Riderdeixou EAP. Agora você pode usá-lo para desenvolver e depurar o .NET Core no Linux - embora até agora apenas o .NET Core 1.1 até a atualização do suporte ao .NET Core 2.0 seja lançada.
Em maio de 2018, a atualização do
.NET Core 2.1 é iminente. Talvez isso conserte a autenticação NTLM no Linux (a autenticação NTLM não funciona no Linux {e possivelmente Mac} no .NET-Core 2.0 com vários cabeçalhos autenticados, como negociar, normalmente enviados com o ms-exchange, e eles aparentemente apenas corrigindo-o na v2.1, nenhuma versão de correção de bug para 2.0).
Mas não estou instalando versões de pré-visualização na minha máquina. Tão esperando.
Também é dito que a v2.1 reduz bastante os tempos de compilação. Isso seria bom.
Além disso, observe que no Linux, o .NET Core é apenas de 64 bits !
Não existe, e não haverá, a versão x86-32 do .NET Core no Linux .
E a porta ARM é apenas ARM-32. No ARM-64, ainda.
E no ARM, você (atualmente) possui apenas o tempo de execução, não o dotnet-SDK.
E mais uma coisa:
como o .NET-Core usa o OpenSSL 1.0, o .NET Core no Linux não roda no Arch Linux e, por derivação, não no Manjaro (a distribuição mais popular do Linux até agora), porque o Arch O Linux usa o OpenSSL 1.1. Portanto, se você estiver usando o Arch Linux, não terá sorte (também com o Gentoo).
Editar:
A versão mais recente do .NET Core 2.2+ suporta o OpenSSL 1.1. Então você pode usá-lo no Arch ou (k) Ubuntu 19.04+. Talvez você precise usar o script de instalação do .NET-Core , porque ainda não há pacotes.
No lado positivo, o desempenho definitivamente melhorou:
.NET Core 3:
Diz-se que o .NET-Core v 3.0 traz o WinForms e o WPF para o .NET-Core.
No entanto, enquanto o WinForms e o WPF serão .NET Core, o WinForms e o WPF no .NET-Core serão executados apenas no Windows, porque o WinForms / WPF usará a API do Windows.
Nota: O
.NET Core 3.0 já saiu (RTM) e há suporte para WinForms e WPF, mas apenas para C # (no Windows). Não há WinForms-Core-Designer . Eventualmente, o designer virá com uma atualização do Visual Studio. O suporte do WinForms ao VB.NET não é suportado , mas está planejado para o .NET 5.0 em algum momento de 2020 .
PS:
echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1
Se você o usou no Windows, provavelmente nunca viu isso:
As ferramentas do .NET Core coletam dados de uso para melhorar sua experiência.
Os dados são anônimos e não incluem argumentos de linha de comando.
Os dados são coletados pela Microsoft e compartilhados com a comunidade.
Você pode desativar a telemetria configurando uma variável de ambiente DOTNET_CLI_TELEMETRY_OPTOUT como 1 usando seu shell favorito.
Você pode ler mais sobre a telemetria das ferramentas do .NET Core em
https://aka.ms/dotnet-cli-telemetry .
Eu pensei em mencionar que acho que o monodesenvolvimento (também conhecido como Xamarin Studio, IDE Mono ou Visual Studio Mac, como agora é chamado no Mac) evoluiu bastante bem e é - entretanto, amplamente utilizável.
No entanto, o JetBrains Rider (EAP 2018 neste momento) é definitivamente muito melhor e mais confiável (e o descompilador incluído é mais seguro para a vida), ou seja, se você desenvolver o .NET-Core no Linux ou Mac. O MonoDevelop não suporta Debug-StepThrough no Linux no .NET Core, no entanto, uma vez que a MS não licencia sua DLL da API de depuração (exceto o VisualStudio Mac ...). No entanto, você pode usar o depurador Samsung para .NET Core por meio da extensão do depurador .NET Core para Samsung Debugger for MonoDevelop
Aviso Legal:
Eu não uso Mac, por isso não posso dizer se o que escrevi aqui se aplica ao Mac baseado no FreeBSD-Unix também. Estou me referindo à versão Linux (Debian / Ubuntu / Mint) do JetBrains Rider, mono, MonoDevelop / VisualStudioMac / XamarinStudio e .NET-Core. Além disso, a Apple está pensando em mudar de processadores Intel para processadores baseados em ARM (ARM-64?), Muito do que se aplica ao Mac no momento pode não se aplicar ao Mac no futuro (2020+).
Além disso, quando escrevo "mono é bastante instável e lento", o instável se refere aos aplicativos WinFroms e WebForms, executando especificamente aplicativos da web via fastcgi ou com XSP (na versão 4.x do mono), bem como serialização XML peculiaridades de manipulação, e o bastante lento está relacionado ao WinForms e às expressões regulares em particular (o ASP.NET-MVC também usa expressões regulares para roteamento).
When I write about my experience about mono 2.x, 3.x and 4.x, that also does not necessarely mean these issues haven't been resolved by now, or by the time you are reading this, nor that if they are fixed now, that there can't be a regression later that reintroduces any of these bugs/features. Nor does that mean that if you embed the mono-runtime, you'll get the same results as when you use the (dev) system's mono runtime. It also doesn't mean that embedding the mono-runtime (anywhere) is necessarely free.
Tudo isso não significa necessariamente que o mono não é adequado para iOS ou Android, ou que possui os mesmos problemas. Como não uso mono no Android ou IOS, não posso dizer nada sobre estabilidade, usabilidade, custos e desempenho nessas plataformas. Obviamente, se você usa o .NET no Android, também tem outras considerações de custos, como ponderar xamarin-custos x custos e tempo para portar o código existente para Java. Ouve-se mono no Android e IOS deve ser muito bom. Tome com um grão de sal. Por um lado, não espere que a codificação do sistema padrão seja a mesma no android / ios vs. Windows e não espere que o sistema de arquivos do Android seja sensível a maiúsculas e minúsculas e não espere que nenhuma fonte do Windows esteja presente .