Mono é frequentemente usado para dizer "Sim, o .NET é multiplataforma". Qual é a validade dessa reivindicação? [fechadas]

Em O que você escolheria para o seu projeto entre .NET e Java neste momento? Eu digo que consideraria "Você sempre implantará no Windows?" a decisão técnica mais importante a ser apresentada em um novo projeto da Web e, se a resposta for "não", eu recomendaria o Java em vez do .NET.

Um contra-argumento muito comum é que "se quisermos rodar no Linux / OS X / Whatever, rodaremos o Mono" ¹ , que é um argumento muito convincente na superfície, mas não concordo com vários razões.

• O OpenJDK e todos os fornecedores fornecidos pelas JVM passaram pelo Sun TCK oficial, garantindo que as coisas funcionem corretamente. Não estou ciente de que o Mono seja aprovado em um Microsoft TCK.
• Mono rastreia as versões do .NET. Qual nível do .NET é atualmente totalmente suportado?
• Todos os elementos da GUI (WinForms?) Funcionam corretamente no Mono?
• As empresas podem não querer depender das estruturas de código aberto como o plano oficial B.

Estou ciente de que, com a nova governança de Java da Oracle, o futuro é inseguro, mas, por exemplo, a IBM fornece JDKs para muitas plataformas , incluindo Linux. Eles simplesmente não são de código aberto.

Então, sob quais circunstâncias o Mono é uma estratégia comercial válida para aplicativos .NET?

¹ _{Mark H resumiu-o como : "Se a afirmação é de que " eu tenho um aplicativo do Windows escrito em .NET, ele deve ser executado em mono " , não é uma afirmação válida - mas a Mono se esforçou para fazer a portabilidade desses aplicativos mais simples. "}

A resposta de Sparkie entendeu, deixe-me complementar um pouco.

".NET é multiplataforma" é uma declaração ambígua demais, pois a estrutura e o mundo para o qual foi originalmente criada mudaram e evoluíram.

A resposta curta é:

O mecanismo subjacente que alimenta o .NET e seus derivados, o Common Language Infrastructure Standard, é multiplataforma e, como se você deseja que seu código vá para várias plataformas, é necessário planejar o uso das APIs certas na plataforma certa para fornecer a melhor experiência em cada plataforma.

A família CLI não tentou a abordagem "Write Once, Run Anywhere", pois as diferenças de um telefone para um mainframe são muito grandes. Em vez disso, surgiu um universo de recursos de API e tempo de execução específicos da plataforma para fornecer aos desenvolvedores as ferramentas certas para criar ótimas experiências em cada plataforma.

Pense bem: os programadores não têm mais como alvo PCs Windows ou Servidores Unix. Agora, mais do que nunca, o mundo está cercado por plataformas fascinantes de PCs, consoles de jogos, telefones poderosos, decodificadores, grandes servidores e aglomerados de máquinas distribuídos. Um tamanho único em todas as plataformas se sentiria inchado em dispositivos minúsculos e com pouca potência em sistemas grandes .

O produto .NET Framework da Microsoft não é multiplataforma, é executado apenas no Windows. Existem variações do .NET Framework da Microsoft que são executadas em outros sistemas como o Windows Phone 7, o XBox360 e navegadores através do Silverlight, mas todos são perfis ligeiramente diferentes.

Hoje você pode segmentar todos os principais sistemas operacionais, telefones, dispositivos móveis, sistemas e servidores incorporados com as tecnologias baseadas em .NET. Aqui está uma lista que mostra qual implementação de CLI você usaria em cada caso (esta lista não é abrangente, mas deve cobrir 99% dos casos):

• Computadores PC baseados em x86 e x86-64:
  • executando Windows -> Normalmente, você executa o .NET ou o Silverlight, mas também pode usar o Mono completo aqui.
  • executando Linux, BSD ou Solaris -> Você executa o Mono ou Silverlight completo
  • executando o MacOS X -> Você executa o Mono ou o Silverlight completo
  • executando Android -> Você executa o subconjunto Mono / Android
• Computadores ARM:
  • Executando o Windows Phone 7: você executa o Compact Framework 2010
  • Executando o Windows 6.5 e anterior: você executa o antigo Compact Framework
  • Dispositivos Android: você executa Mono / Android
• Computadores PowerPC:
  • Você executa o Mono completo para sistemas operacionais Linux, BSD ou Unix completos
  • Você roda o Mono incorporado para PS3, Wii ou outros sistemas embarcados.
  • No XBox360, você executa o CompactFramework
• Computadores S390, S390x, Itanium, SPARC:
  • Você executa Mono completo
• Outros sistemas operacionais incorporados:
  • Você executa o .NET MicroFramework ou Mono com o perfil móvel.

Dependendo das suas necessidades, as opções acima podem ser suficientes ou não. Você dificilmente conseguirá o mesmo código fonte para rodar em qualquer lugar. Por exemplo, o código XNA não será executado em todas as áreas de trabalho, enquanto o software .NET Desktop não será executado no XNA ou no telefone. Você normalmente precisa fazer alterações no seu código para executar em outros perfis do .NET Framework. Aqui estão alguns dos perfis que eu conheço:

• Perfil do .NET 4.0
• Perfil do Silverlight
• Perfil do Windows Phone 7
• Perfil do XBox360
• Perfil mono core - segue o perfil .NET e está disponível no Linux, MacOS X, Solaris, Windows e BSD.
• .NET Micro Framework
• Mono no perfil do iPhone
• Mono no perfil do Android
• Mono no perfil PS3
• Mono no perfil do Wii
• Perfil Moonlight (compatível com Silverlight)
• Perfil estendido Moonlight (Silverlight + acesso completo à API .NET 4)

Portanto, cada um desses perfis é realmente um pouco diferente, e isso não é uma coisa ruim. Cada perfil é projetado para caber em sua plataforma host e expor as APIs que fazem sentido e remover as que não fazem sentido.

Por exemplo, as APIs do Silverlight para controlar o navegador host não fazem sentido no telefone. E os shaders no XNA não fazem sentido no hardware de PC que não possui o suporte equivalente.

Quanto mais cedo você perceber que o .NET não é uma solução para isolar o desenvolvedor dos recursos subjacentes do hardware e da plataforma nativa, melhor será.

Dito isso, algumas APIs e pilhas estão disponíveis em várias plataformas, por exemplo, o ASP.NET pode ser usado no Windows, no Linux, no Solaris, no MacOS X porque essas APIs existem no .NET e no Mono. O ASP.NET não está disponível em algumas plataformas suportadas pela Microsoft, como XBox ou Windows Phone 7, nem em outras plataformas suportadas pelo Mono, como o Wii ou o iPhone.

As informações a seguir estão corretas somente a partir de 21 de novembro, e muitas coisas no mundo Mono provavelmente mudarão.

Os mesmos princípios podem ser aplicados a outras pilhas; uma lista completa exigiria uma tabela adequada, que não tenho idéia de como apresentar aqui, mas aqui está uma lista de tecnologias que podem não estar presentes em uma plataforma específica. Você pode supor que qualquer coisa não listada aqui esteja disponível (sinta-se à vontade para me enviar edições pelas coisas que perdi):

Mecanismo de tempo de execução principal [em todos os lugares]

• Suporte Reflection.Emit [em todos os lugares, exceto WP7, CF, Xbox, MonoTouch, PS3]
• Suporte para CPU SIMD [Linux, BSD, Solaris, MacOS X; Em breve PS3, MonoTouch e MonoDroid]
• Continuações - Mono.Tasklets [Linux, BSD, Solaris, MacOS, PS3, Wii]
• Descarregamento de montagem [somente Windows]
• Injeção de VM [Linux, BSD, MacOS X, Solaris]
• DLR [Windows, Linux, MacOS X, Solaris, MonoDroid]
• Genéricos [algumas limitações no PS3 e iPhone].

línguas

• C # 4 [em todos os lugares]
• Compilador C # como serviço (Linux, MacOS, Solaris, BSD, Android)
• IronRuby [em todos os lugares, executivo WP7, CF, Xbox, MonoTouch, PS3]
• IronPython [em todos os lugares, WP7, CF, Xbox, MonoTouch, PS3]
• F # [em todos os lugares, WP7, CF, Xbox, MonoTouch, PS3]

Pilhas de servidor

• ASP.NET [Windows, Linux, MacOS, BSD, Solaris]
• ADO.NET [em todos os lugares]
• LINQ to SQL [em todos os lugares]
• Estrutura de entidades [em todos os lugares]
• Pilha XML principal [em todos os lugares]
  • Serialização XML [em todos os lugares, exceto WP7, CF, Xbox)
• LINQ to XML (em qualquer lugar)
• System.Json [Silverlight, Linux, MacOS, MonoTouch, MonoDroid]
• System.Messaging [Windows; no Linux, MacOS e Solaris requer RabbitMQ]
• .NET 1 Enterprise Services [somente Windows]
• WCF [completo no Windows; pequeno subconjunto no Silverlight, Solaris, MacOS, Linux, MonoTouch, MonoDroid]
• Fluxo de trabalho do Windows [somente Windows]
• Identidade do espaço do cartão [somente Windows]

Pilhas da GUI

• Silverlight (Windows, Mac, Linux - com Moonlight)
• WPF (somente Windows)
• Gtk # (Windows, Mac, Linux, BSD)
• Windows.Forms (Windows, Mac, Linux, BSD)
• MonoMac - Integração nativa com Mac (somente Mac)
• MonoTouch - Integração nativa do iPhone (somente iPhone / iPad)
• MonoDroid - Integração nativa com Android (apenas Android)
• APIs do Media Center - apenas Windows
• Desorganização (Windows e Linux)

Bibliotecas Gráficas

• GDI + (Windows, Linux, BSD, MacOS)
• Quartzo (MacOS X, iPhone, iPad)
• Cairo (Windows, Linux, BSD, MacOS, iPhone, iPad, MacOS X, PS3, Wii)

Bibliotecas Mono - Plataforma cruzada, podem ser usadas no .NET, mas exigem a criação manual

• Compilador C # 4 como um serviço
• Cecil - CIL Manipulação, fluxo de trabalho, instrumentação de CIL, Linkers
• Bibliotecas RelaxNG
• Provedores de banco de dados Mono.Data. *
• System.Xaml completo (para uso em configurações nas quais o .NET não oferece a pilha)

MonoTouch significa Mono em execução no iPhone; MonoDroid significa Mono rodando no Android; As portas PS3 e Wii estão disponíveis apenas para desenvolvedores qualificados da Sony e Nintendo.

Peço desculpas pela falta de formalidade.

Primeiro, você precisa fazer uma distinção entre a Common Language Infrastructure (padrão aberto) e o .NET (implementação desse padrão pela Microsoft). Mono é uma implementação da CLI e nunca afirmou ser um ".NET portátil". Além disso, a linguagem C # é um padrão aberto e não está estritamente vinculado ao .NET.

Não sei se a Microsoft tem alguma ferramenta para validar que uma implementação é compatível, mas, se o fizerem, tenho certeza de que os mono caras a usam e a usam.

Mono está atrás do .Net, mas mal. Mono pode executar o código C # 4.0 (versão atual do .NET). Além disso, a Microsoft criou recentemente todo o código DLR e as bibliotecas de código aberto (sob a licença Apache 2.0), que permitiu que o mono utilizasse idiomas como IronPython, IronRuby e F # foi disponibilizado apenas na semana passada. Além disso, a Microsoft libera regularmente CTPs dos recursos futuros do .NET, o que permite que os desenvolvedores mono se mantenham atualizados com as versões atuais.

Há várias ferramentas e extensões no .NET, por exemplo, Code Contracts. Estes nem sempre são totalmente implementados em mono. (No momento, acho que existe um validador de contrato parcial para contratos Requer). De qualquer forma, eles não são usados ​​em aplicativos .NET, mas se sua popularidade aumentasse, aumentaria a taxa na qual eles seriam implementados em mono.

O WinForms não é (totalmente) portátil. Eles são específicos do .NET e não fazem parte da CLI. A CLI não especifica nenhum conjunto de widgets específico. No entanto, existem conjuntos de widgets entre plataformas (GTK # e Silverlight). Se você estivesse escrevendo um aplicativo desde o início com a portabilidade em mente, usaria um deles em vez do Winforms / WPF. Além disso, o mono fornece um invólucro fino para a API do Winforms - que permite que os aplicativos existentes do winforms sejam portados com mais facilidade no GTK # (sem reescrita completa).

O Mono fornece uma ferramenta, o Mono Migration Analyzer (MoMA), que pode pegar um aplicativo .Net existente e falar sobre sua portabilidade. (por exemplo, identifique bibliotecas não portáveis ​​usadas, P / Invoca etc.).

Para empresas que não desejam depender de código aberto, o mono pode ser licenciado novamente. A propriedade do código adicionado ao mono é transferida para o novell, que pode licenciá-lo de outras maneiras que não a licença LGPL usual (que tem poucas restrições de qualquer maneira).

Portanto, quanto à afirmação "O .NET é portátil", acho que isso pode ser uma afirmação válida se você estiver escrevendo código desde o início e está ciente dos problemas de portabilidade com a estrutura. Se a afirmação é de que "eu tenho um aplicativo do Windows escrito em .NET, ele deve ser executado em mono", não é uma afirmação válida - mas a Mono se esforçou para simplificar a portabilidade desses aplicativos.

Ponto por ponto:

• O OpenJDK e todos os fornecedores fornecidos pelas JVM passaram pelo Sun TCK oficial, garantindo que as coisas funcionem corretamente. Não estou ciente de que o Mono seja aprovado no Microsoft TCK.
  Há uma especificação que o Microsoft CLR está em conformidade. Mono não é um clone do CLR da Microsoft, mas uma implementação dessa mesma especificação. Por um lado, há a chance de isso resultar em incompatibilidade ainda maior. Na prática, isso funcionou muito bem para mono.
• Mono rastreia as versões do .NET. Qual nível do .NET é atualmente totalmente suportado?
  Como a documentação do .Net precede o lançamento real, o mono realmente havia concluído (não uma versão beta) o suporte ao .Net 4 antes do lançamento oficial da Microsoft. Além disso, o mono faz um excelente trabalho ao documentar o que não é suportado, e possui algumas ferramentas que você pode executar no projeto existente para ajudá-lo a identificar locais com potencial de incompatibilidade.
• Todos os elementos da GUI (WinForms?) Funcionam corretamente no Mono?
  A grande maioria dos winforms funciona muito bem. WPF, nem tanto. Ouvi dizer que o mesmo se aplica ao Java - muitos dos kits de ferramentas de widget / GUI avançados não são tão bem suportados em todas as plataformas.
• As empresas podem não querer depender das estruturas de código-fonte aberto como o plano oficial B.
  Se for esse o caso, elas definitivamente não seguirão o Java, pois isso eleva ainda mais a estrutura de código-fonte aberto no plano A.

Em resumo, se você deseja criar um aplicativo de plataforma cruzada agora , não há nada de errado em começar com o mono desde o início e usá-lo como sua estrutura. Você pode até implantar mono no Windows, se quiser.

Por outro lado, se você está pensando em criar um aplicativo para Windows hoje e achar que talvez seja uma plataforma cruzada em algum momento desconhecido no futuro, provavelmente desejará usar os widgets e ferramentas nativos do Windows. O .Net faz um trabalho muito melhor aqui do que o Java, e o mono é um retorno perfeitamente aceitável nesse cenário.

Em outras palavras: Sim, .Net se for multiplataforma de todos os modos que importam para sua pergunta. Não, o mono não executa apenas todos os programas .Net imediatamente, mas sua pergunta está no contexto de um novo projeto. Não é preciso muito trabalho para manter novos projetos fora de problemas e evitar problemas de compatibilidade, especialmente se você pensar em termos de desenvolvimento para mono, em vez de desenvolvimento para .Net.

Acima de tudo, porém, acho que essa é a pergunta errada em primeiro lugar. A menos que você esteja construindo uma nova equipe de desenvolvimento do zero, você está começando com programadores com experiência em uma área ou outra. Seus melhores resultados serão alcançados seguindo o que seus programadores já sabem. Por mais importante que possa parecer a criação de um aplicativo de plataforma cruzada, se você tem uma equipe cheia de programadores .Net com pouca experiência em java, é improvável que você os demita ou faça com que todos aprendam java para o seu próximo projeto. Se você tem uma equipe cheia de programadores java, não solicitará que eles aprendam .Net para um projeto somente para Windows. Qualquer um desses seria louco.

Eu trabalhei com o Mono e diria que é o melhor possível com uma plataforma alternativa de código aberto e sem suporte direto da Microsoft. Se você se sentir confortável usando uma plataforma alternativa de código aberto , como Clojure ou Scala, provavelmente poderá se sentir confortável usando o Mono.

O nível do .NET suportado pelo Mono sempre pode ser encontrado na página Mono Roadmap .

Todos os elementos da GUI funcionam? Tanto quanto eu sei, eles fazem, embora eu não tenha tentado exaustivamente todos os elementos.

O Mono é idêntico ao .NET? Não. Suspeito que haverá pequenos ajustes (e talvez grandes) necessários aqui e ali. No momento, você não pode executar o Entity Framework com ele, por exemplo.

Como alvo, o universo .NET / mono se move muito rápido .

A cada poucos anos, a Microsoft lança algumas mudanças e inovações atraentes em relação ao idioma, tempo de execução e infraestrutura em torno do .NET. Por exemplo: Genéricos, LINQ, DLR, Entity Framework - a cada nova revisão do Visual Studio, geralmente há um aumento bastante significativo no conjunto de recursos e na utilidade da estrutura destinada.

Embora o aprimoramento constante da estrutura seja bem-vindo, também é problemático se você deseja compatibilidade entre várias plataformas. Plataformas de suporte de longo prazo, como o Red Hat Enterprise Linux, ficam muito lentas em relação à adoção de novas tecnologias e, a qualquer momento, haverá melhorias significativas na plataforma Mono que aconteceram nos últimos meses. Portanto, se você quiser executar as coisas que as crianças legais estão construindo, precisará compilar o Mono do zero e gerenciar seus próprios patches e atualizações. Isso não é legal.

Java, por outro lado, é tão estagnado quanto uma piscina infantil. Especialmente agora que ela é de propriedade de uma empresa que apenas queria o Java para os processos de patentes, você pode estar certo de que não haverá alterações detectáveis ​​na linguagem ou no tempo de execução no futuro próximo. Java é uma plataforma tão estável quanto o FORTRAN. Isso não é tão bom se você está esperando por algum tipo de aprimoramento, mas não tão ruim se você está tentando implantar um aplicativo corporativo.

Do ponto de vista do usuário, o Mono é muito bom em tornar os aplicativos Windows .NET compatíveis com o Linux. Se você realmente tentar executar qualquer aplicativo Windows decentemente escrito no Mono, não funcionará.

Do ponto de vista de um empacotador (eu costumava trabalhar um pouco no PortableApps), o .NET pode ser uma bênção e uma maldição. Se você está apenas no Windows, o .NET facilita muito a implantação, porque mais bibliotecas significam menos coisas dependentes do sistema (principalmente entre as versões do Windows, acredito), mas também são extremamente confusas, mesmo no Windows, porque as versões do .NET não são inversas -compatível ou compatível com versões anteriores. Você precisa baixar diferentes versões do .NET para diferentes programas.

Dito isto, o Mono é um excelente ponto de partida para tornar os programas em C # multiplataforma. Apenas não empacote o programa com o WINE mais recente e conclua-o. Veja onde isso levou o Picasa.

Assim como a estabilidade política dos dois idiomas / plataformas, o RMS provavelmente começaria a reclamar sobre como o Mono é liderado pela Novell, cuja lua de mel com a Microsoft é bastante notória. Ambas as plataformas podem ser consideradas politicamente instáveis ​​no momento.

Se você realmente deseja uma plataforma cruzada fácil, o caminho testado e verdadeiro é o QT, que é bastante estável politicamente desde o momento: a) LGPL'd, b) feito com seus principais problemas de licenciamento anos atrás ec) apoiado pela Nokia, que vende telefones realmente populares.

Mono não é uma porta 1: 1 do .net da Microsoft. Existem tecnologias que o Mono simplesmente não implementa ou não tem planos de fazê-lo (por exemplo, Workflow Foundation ou WPF ), enquanto, por outro lado, elas têm algumas tecnologias próprias que o Microsoft .NET não usa, por exemplo, Extensões SIMD .

Resposta curta: Mono e Microsoft .NET são baseados na mesma base subjacente - CIL e BCL - mas são projetos separados.

Pequeno comentário às declarações no post original. Argumentarei que o TCK continua sendo uma ferramenta teórica que permite à Oracle afirmar que Java é um padrão aberto. Porque, se você perceber, o Apache Harmony está tentando obter a certificação como "Java" há vários anos, sem êxito. É claro que a Oracle realmente não está interessada em uma implementação de código aberto, além daquela a que está afiliada e com mais ou menos controle (OpenJDK), que é o mesmo. assim como o Mono, não está completo (ou seja, não há suporte para Java Web Start) e faltam algumas otimizações disponíveis na implementação do HotSpot de código fechado.

Então, sem dúvida, a partir de 2010; (a maioria dos) Java é de código aberto, mas não um padrão aberto, enquanto (a maioria dos) .NET não é de código aberto, mas um padrão aberto. Existem exceções, é claro, o DLR, o IronPython, o IronRuby e o F #, na verdade, são de código aberto. O mono é interessante porque fornece o melhor dos dois mundos, implementações de código aberto de padrões abertos.

Colocando todos os aspectos técnicos de lado, uma parte muito importante ocorre ao realmente escrever o código.

Como em qualquer tecnologia de plataforma cruzada (seja Java, Python, Ruby ...), se o código não for escrito com a portabilidade em mente, você deve assumir que há basicamente zero chance de o código ser executado corretamente (mesmo que essa chance seja na realidade, muito, muito mais alto), pois o mau comportamento estranho pode ser bastante crítico. Leia: não pegue a montagem aleatória e execute-a em Mono.

No entanto, para um novo projeto (ou um que você pode refatorar facilmente), escolher .Net / Mono como um tempo de execução potencialmente portátil faz sentido, mas você economiza muitos aborrecimentos ao testar seu código no Mono muito cedo, mesmo se o projeto tiver apenas uma ligeira mudança de multiplataforma. Se você usar um servidor de integração contínua, isso pode ser tão simples quanto configurar um nó de construção Mono. Muitos problemas podem ser resolvidos durante o desenvolvimento, apenas criando um hábito (como criar seqüências de caminho) e uma grande parte do seu código pode ser portátil e testada em unidade no Mono apenas usando práticas sãs e um pouco de premeditação. O restante (ou seja, falha nos testes de unidade) é específico da plataforma (como código usando o PInvoke), mas deve ser encapsulado o suficiente para poder fornecer uma implementação alternativa por plataforma de destino.

Obviamente, o uso de uma biblioteca não disponível (.Net) ou compatível (terceiros) no Mono impede isso, mas no meu campo isso ainda não foi visto. Essa é a estratégia que realmente usamos no trabalho e, ao aplicá-la, não tenho medo de afirmar que o .Net + Mono é multiplataforma.

Varia é a resposta honesta. Vi pequenas coisas de servidor da Web serem movidas do IIS para o Apache, rodando em mono sem quase nenhuma dificuldade. Executei aplicativos Windows .Net inalterados usando o Win Forms no Linux com êxito.

No entanto, embora funcione, se você estiver usando uma chamada de API que não foi implementada em mono, ela não funcionará, e as únicas soluções são reescrever seu aplicativo, ficar com o Windows ou gravar o material extra em mono.