O Mono está pronto para o horário nobre? [fechadas]

Alguém já usou o Mono, a implementação .NET de código aberto em um projeto de tamanho grande ou médio? Gostaria de saber se está pronto para o mundo real, ambientes de produção. É estável, rápido, compatível, ... o suficiente para usar? É preciso muito esforço para portar projetos para o tempo de execução Mono, ou é realmente compatível com o suficiente para apenas pegar e executar o código já escrito para o tempo de execução da Microsoft?

Existem alguns cenários a serem considerados: (a) se você está portando um aplicativo existente e se perguntando se o Mono é bom o suficiente para esta tarefa; (b) você está começando a escrever um novo código e deseja saber se o Mono é maduro o suficiente.

Para o primeiro caso, você pode usar a ferramenta Moma ( Mono Migration Analyzer ) para avaliar a distância de execução do aplicativo no Mono. Se a avaliação voltar com cores vivas, você deve iniciar os testes e o controle de qualidade e se preparar para enviar.

Se sua avaliação voltar com um relatório destacando os recursos ausentes ou que diferem significativamente em sua semântica no Mono, será necessário avaliar se o código pode ser adaptado, reescrito ou, na pior das hipóteses, se seu aplicativo pode funcionar com funcionalidade reduzida.

De acordo com nossas estatísticas Moma baseadas em envios de usuários (isso é de memória), cerca de 50% dos aplicativos funcionam imediatamente, cerca de 25% exigem cerca de uma semana de trabalho (refatoração, adaptação) outros 15% exigem um sério compromisso de refaça partes do seu código, e o resto simplesmente não vale a pena incomodar a portabilidade, pois elas estão incrivelmente ligadas ao Win32. Nesse ponto, você começa do zero ou uma decisão de negócios direcionará o esforço para tornar seu código portátil, mas estamos falando em meses de trabalho (pelo menos nos relatórios que temos).

Se você está começando do zero, a situação é muito mais simples, porque você usará apenas as APIs presentes no Mono. Contanto que você permaneça com a pilha suportada (que é praticamente o .NET 2.0, além de todas as atualizações principais no 3.5, incluindo LINQ e System.Core, além de qualquer uma das APIs Mono entre plataformas), você estará bem.

De vez em quando, você pode encontrar bugs no Mono ou limitações e pode precisar contorná-los, mas isso não é diferente de qualquer outro sistema.

Quanto à portabilidade: os aplicativos ASP.NET são os mais fáceis de portar, pois eles têm pouca ou nenhuma dependência do Win32 e você pode até usar o SQL server ou outros bancos de dados populares (existem muitos provedores de banco de dados em pacote com Mono).

A portabilidade do Windows.Forms às vezes é mais complicada porque os desenvolvedores gostam de escapar da sandbox do .NET e P / Invocar seus cérebros para configurar coisas tão úteis quanto a alteração da taxa de piscar do cursor, expressa como dois pontos de bezier codificados no formato BCD em um wParam. Ou algum lixo assim.

Ele possui uma cobertura bastante extensa até o .NET 4.0 e até inclui alguns recursos das APIs do .NET 4.5, mas há algumas áreas que optamos por não implementar devido ao fato de as APIs estarem obsoletas, novas alternativas sendo criadas ou o escopo muito ampla. As seguintes APIs não estão disponíveis no Mono:

• Windows Presentation Foundation
• Windows Workflow Foundation (nenhuma das duas versões)
• Estrutura de entidade
• Os "complementos" WSE1 / WSE2 para a pilha padrão de Serviços da Web

Além disso, nossa implementação do WCF é limitada ao suporte ao Silverlight.

A maneira mais fácil de verificar seu projeto específico é executar o Mono Migration Analyzer (MoMA) . O benefício é que ele notificará a equipe Mono sobre problemas que o impedirão de usar o Mono (se houver), o que lhes permitirá priorizar seu trabalho.

Recentemente, executei o MoMA no SubSonic e encontrei apenas um problema - um uso estranho de tipos Nullable. Essa é uma grande base de código, então a cobertura foi bastante impressionante.

O Mono está em uso ativo em vários produtos comerciais e de código aberto . Ele está em uso em alguns aplicativos grandes, como a Wikipedia e o Mozilla Developer Center , e foi usado em aplicativos incorporados, como os MP3 players Sansa, e alimenta milhares de jogos publicados.

No nível do idioma, o compilador Mono é totalmente compatível com a especificação de idioma do C # 5.0 .

No lado da área de trabalho, o Mono funciona muito bem se você se comprometer a usar o GTK #. A implementação do Windows.Forms ainda é um pouco complicada (por exemplo, o TrayIcon não funciona), mas já percorreu um longo caminho. Além disso, o GTK # é um kit de ferramentas melhor do que o Windows Forms.

No lado da Web, o Mono implementou o ASP.NET suficiente para executar a maioria dos sites perfeitamente. A dificuldade aqui é encontrar um host que tenha o mod_mono instalado no apache, ou faça você mesmo se você tiver acesso shell ao seu host.

De qualquer maneira, o Mono é ótimo e estável.

Itens importantes a serem lembrados ao criar um programa de plataforma cruzada:

• Use GTK # em vez de Windows.Forms
• Certifique-se de colocar corretamente os nomes dos seus arquivos
• Use em Path.Separatorvez de codificar "\", também use em Environment.NewLinevez de "\n".
• Não use chamadas P / chamadas para a API do Win32.
• Não use o registro do Windows.

Eu pessoalmente uso o Mono em um ambiente no horário nobre. Eu corro servidores mono lidando com giga-bytes de tarefas relacionadas ao processamento de dados udp / tcp e não poderia estar mais feliz.

Existem peculiaridades e uma das coisas mais irritantes é que você não pode simplesmente "construir" seus arquivos msbuild devido ao estado atual do Mono:

• O MonoDevelop (o IDE) tem algum suporte parcial a msbuild, mas basicamente trabalha em qualquer conf "build" REAL além de um simples olá mundo (tarefas personalizadas de compilação, "propriedades" dinâmicas como $ (SolutionDir), configuração real para citar alguns mortos) -ends)
• O xbuild, que DEVE ter sido o sistema mono-fornecido-msbuild-totalmente-compatível-com-build, é ainda mais horrível, portanto, construir a partir da linha de comando é realmente uma experiência pior do que usar a GUI, que é um estado muito "não-ortodoxo" do união para ambientes Linux ...

Uma vez / durante a construção das suas coisas, você pode ver algumas wildernesses, mesmo para códigos que DEVEM ser suportados, como:

• o compilador sendo borked em certas construções
• e algumas classes .NET mais avançadas / novas, lançando uma porcaria inesperada em você (XLinq alguém?)
• alguns "recursos" de tempo de execução imaturos (limite de heap de 3 GB ON x64 ... WTF!)

No entanto, ponderar disse que, de um modo geral, as coisas começam a funcionar muito rapidamente, e as soluções / soluções alternativas são abundantes .

Depois de superar esses obstáculos iniciais, minha experiência é que o ROCK mono fica cada vez melhor a cada iteração .

Eu tive servidores rodando em mono, processando 300 GB de dados por dia, com toneladas de p / invocações e, de modo geral, fazendo MUITO trabalho e permanecendo em atividade por 5-6 meses, mesmo com o mono "de ponta".

Espero que isto ajude.

As recomendações para a resposta aceita estão um pouco desatualizadas agora.

• A implementação do Windows Forms é muito boa agora. (Consulte o Paint-Mono para uma porta do Paint.net, que é um aplicativo de formulários do Windows bastante envolvido. Tudo o que era necessário era uma camada de emulação para algumas chamadas do sistema P-Invoke e não suportadas).
• Path.Combine e Path.Seperator para unir caminhos e nomes de arquivos.
• O Registro do Windows está OK, desde que você o utilize apenas para armazenar e recuperar dados de seus aplicativos (ou seja, você não pode obter nenhuma informação sobre o Windows, pois é basicamente um registro para aplicativos Mono).

Se você deseja usar o WPF, está sem sorte no momento, o Mono não tem planos de implementá-lo.

http://www.mono-project.com/WPF

Bem, o mono é ótimo, mas até onde posso ver, é instável. Funciona, mas falha quando você dá ao processo mono um trabalho sério a fazer.

TL; DR - Não use mono se você:

• use AppDomains (Assembly Load \ Unload) em ambientes multithread
• Não é possível sustentar o modelo 'deixe-falhar'
• Experimente eventos ocasionais de carga pesada durante a execução do processo

Então, os fatos.

Usamos mono-2.6.7 (.net v 3.5) no RHEL5, Ubuntu e, do meu ponto de vista, é a versão mais estável criada pela Novell. Ele tem um problema com o Descarregamento de AppDomains (segfaults), no entanto, falha muito raro e isso, de longe, é aceitável (por nós).

OK. Mas se você quiser usar os recursos do .net 4.0, precisará mudar para as versões 2.10.x ou 3.x, e é aí que os problemas começam.

Comparado ao 2.6.7, novas versões são apenas inaceitáveis ​​para serem usadas. Eu escrevi um aplicativo simples de teste de estresse para testar instalações mono.

Está aqui, com instruções para usar: https://github.com/head-thrash/stress_test_mono

Ele usa Threads de Trabalho do Conjunto de Threads. O Worker carrega a dll no AppDomain e tenta fazer algum trabalho de matemática. Parte do trabalho é multifacetada, parte é única. Quase todo o trabalho é vinculado à CPU, embora haja algumas leituras de arquivos do disco.

Os resultados não são muito bons. De fato, para a versão 3.0.12:

• sgen GC segfaults processam quase imediatamente
• mono com boehm dura mais (de 2 a 5 horas), mas as segfaults eventualmente

Como mencionado acima, o sgen gc simplesmente não funciona (mono construído a partir da fonte):

* Assertion: should not be reached at sgen-scan-object.h:111

Stacktrace:


Native stacktrace:

    mono() [0x4ab0ad]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x2b61ea830cb0]
    /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x2b61eaa74425]
    /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x2b61eaa77b8b]
    mono() [0x62b49d]
    mono() [0x62b5d6]
    mono() [0x5d4f84]
    mono() [0x5cb0af]
    mono() [0x5cb2cc]
    mono() [0x5cccfd]
    mono() [0x5cd944]
    mono() [0x5d12b6]
    mono(mono_gc_collect+0x28) [0x5d16f8]
    mono(mono_domain_finalize+0x7c) [0x59fb1c]
    mono() [0x596ef0]
    mono() [0x616f13]
    mono() [0x626ee0]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x2b61ea828e9a]
    /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x2b61eab31ccd]

Quanto ao boehm segfauls - por exemplo (Ubuntu 13.04, mono construído a partir do código-fonte):

mono: mini-amd64.c:492: amd64_patch: Assertion `0' failed.
Stacktrace:
at <unknown> <0xffffffff>
at System.Collections.Generic.Dictionary`2.Init (int,System.Collections.Generic.IEqualityComparer`1<TKey>) [0x00012] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:264
at System.Collections.Generic.Dictionary`2..ctor () [0x00006] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:222
at System.Security.Cryptography.CryptoConfig/CryptoHandler..ctor (System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00014] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/Crypto
Config.cs:582
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00013] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoCo
nfig.cs:473
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /home/bkmz/my/mono/mcs/class/corlib/System/Guid.cs:492

Ou (RHEL5, mono é obtido do rpm aqui ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/vmas%3A/mono-centos5 )

Assertion at mini.c:3783, condition `code' not met
Stacktrace:
at <unknown> <0xffffffff>
at System.IO.StreamReader.ReadBuffer () [0x00012] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:394
at System.IO.StreamReader.Peek () [0x00006] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:429
at Mono.Xml.SmallXmlParser.Peek () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:271
at Mono.Xml.SmallXmlParser.Parse (System.IO.TextReader,Mono.Xml.SmallXmlParser/IContentHandler) [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:346
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00021] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptog
raphy/CryptoConfig.cs:475
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/Guid.cs:483
at System.Runtime.Remoting.RemotingServices.NewUri () [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:356
at System.Runtime.Remoting.RemotingServices.Marshal (System.MarshalByRefObject,string,System.Type) [0x000ba] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:329
at System.AppDomain.GetMarshalledDomainObjRef () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/AppDomain.cs:1363

As duas falhas estão de alguma forma conectadas à lógica do AppDomains, portanto, você deve ficar longe delas em mono.

Aliás, o programa testado funcionou 24 horas na máquina Windows no ambiente MS .NET 4.5 sem falhas.

Então, em conclusão, eu gostaria de dizer - use o mono com cautela. Funciona desde o primeiro olhar, mas pode falhar facilmente sempre que. Você ficaria com um monte de core dumps e uma grande perda de fé em projetos de código aberto.

O MoMA é uma ótima ferramenta para isso, como alguém sugeriu. As maiores fontes de incompatibilidade atualmente são aplicativos que DllImport (ou P / Invoke) nas bibliotecas Win32. Alguns assemblies não são implementados, mas a maioria deles é apenas para Windows e realmente não faria sentido no Linux. Eu acho que é bastante seguro dizer que a maioria dos aplicativos ASP.NET pode ser executada no Mono com modificações limitadas.

(Divulgação: contribuí com o próprio Mono, além de aplicativos escritos executados em cima dele.)

Em muitos casos, você pode pegar o código existente e executá-lo no Mono, principalmente se estiver portando um aplicativo ASP.NET.

Em alguns casos, você pode precisar de seções totalmente novas de código para fazê-lo funcionar. Se você usar System.Windows.Forms, por exemplo, o aplicativo não funcionará sem modificações. Da mesma forma, se você usar qualquer código específico do Windows (código de acesso ao registro, por exemplo). Mas acho que o pior infrator é o código da interface do usuário. Isso é particularmente ruim nos sistemas Macintosh.

Nós o usamos para um projeto aqui no trabalho que precisava ser executado no Linux, mas reutilizar algumas bibliotecas .NET que construímos no Managed C ++. Fiquei muito surpreso com o resultado. Nosso executável principal está sendo escrito em C # e podemos apenas referenciar nossos binários C ++ gerenciados sem problemas. A única diferença no código C # entre Windows e Linux é o código da porta serial RS232.

O único grande problema em que posso pensar aconteceu cerca de um mês atrás. A versão do Linux teve um vazamento de memória que não foi visto na versão do Windows. Depois de fazer uma depuração manual (os criadores de perfil básicos do Mono no Linux não ajudaram muito), conseguimos restringir o problema a um pedaço específico de código. Acabamos corrigindo uma solução alternativa, mas ainda preciso encontrar algum tempo para voltar e descobrir qual foi a causa raiz do vazamento.

Você sabe o quão bom é o suporte à visualização do Mono 2.0 para o Windows Forms 2.0?

Pelo pouco que brinquei, parecia relativamente completo e quase utilizável. Ele simplesmente não parecia certo em alguns lugares e ainda é um pouco de acerto ou erro no geral. Surpreendeu-me que funcionasse tão bem quanto em algumas de nossas formas, embora honestamente.

Sim, definitivamente é (se você for cuidadoso) Apoiamos o Mono no Ra-Ajax (biblioteca do Ajax encontrada em http://ra-ajax.org ) e, na maioria das vezes, não estamos tendo problemas. Você precisa ter cuidado com algumas das "coisas mais insanas" do .Net, como WSE, etc, e provavelmente alguns de seus projetos existentes não serão 100% compatíveis com Mono, mas novos projetos se você os testar durante o desenvolvimento, principalmente seja compatível sem problemas com o Mono. E o ganho do suporte ao Linux, etc, usando o Mono é muito legal;)

Uma grande parte do segredo de apoiar o Mono, acho que é usar as ferramentas certas desde o início, por exemplo, ActiveRecord, log4net, ra-ajax etc ...

Infelizmente, para o tipo de aplicativo que estamos criando, o Mono não parece pronto para produção. Ficamos impressionados com isso no geral e impressionados com seu desempenho tanto em máquinas Windows quanto em máquinas EC2; no entanto, nosso programa travou de maneira consistente com erros de coleta de lixo no Windows e no linux.

A mensagem de erro é: "erros fatais no GC: muitas seções de heap", aqui está um link para outra pessoa com o problema de uma maneira ligeiramente diferente:

http://bugzilla.novell.com/show_bug.cgi?id=435906

O primeiro pedaço de código que executamos no Mono foi um simples desafio de programação que havíamos desenvolvido ... O código carrega cerca de 10mb de dados em algumas estruturas de dados (por exemplo, HashSets) e depois executa 10 consultas nos dados. Executamos as consultas 100 vezes para cronometrá-las e obter uma média.

O código falhou em torno da 55ª consulta no Windows. No Linux, funcionou, mas assim que passamos para um conjunto de dados maior, ele também travava.

Esse código é muito simples, por exemplo, coloque alguns dados no HashSets e, em seguida, consulte esses HashSets etc., todos os c # nativos, nada inseguro, nenhuma chamada de API. No Microsoft CLR, ele nunca falha e é executado em enormes conjuntos de dados 1000 vezes.

Um de nossos funcionários enviou um e-mail a Miguel e incluiu o código que causou o problema, sem resposta ainda. :(

Também parece que muitas outras pessoas encontraram esse problema sem solução - uma solução foi sugerida para recompilar o Mono com diferentes configurações de GC, mas isso parece aumentar o limite antes do travamento.

Basta verificar www.plasticscm.com. Tudo (cliente, servidor, GUI, ferramentas de mesclagem) é escrito em mono.

Realmente depende dos namespaces e classes que você está usando da estrutura .NET. Eu tinha interesse em converter um dos meus serviços do Windows para executar no meu servidor de email, que é o Suse, mas encontramos vários obstáculos difíceis com APIs que não haviam sido completamente implementadas. Há um gráfico em algum lugar do site Mono que lista todas as classes e seu nível de conclusão. Se o seu aplicativo estiver coberto, faça-o.

Como qualquer outro aplicativo, faça prototipagem e teste antes de se comprometer totalmente, é claro.

Outro problema que encontramos foi o software licenciado: se você estiver referenciando a DLL de outra pessoa, não poderá codificar seu caminho em torno de incompatibilidades ocultas nesse assembly.

Eu imagino que, se você tiver um aplicativo com alguns componentes de terceiros, poderá estar cheio. Duvido que muitos fornecedores se desenvolvam com o Mono em mente

Exemplo: http://community.devexpress.com/forums/p/55085/185853.aspx

Não, o mono não está pronto para um trabalho sério. Escrevi alguns programas no Windows usando F # e os executei no Mono. Esses programas usavam disco, memória e CPU intensivamente. Vi falhas nas bibliotecas mono (código gerenciado), falhas no código nativo e falhas na máquina virtual. Quando o mono funcionava, os programas eram pelo menos duas vezes mais lentos que no .Net no Windows e consumiam muito mais memória. Fique longe do mono para um trabalho sério.