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

168

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" 1 , 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?


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

Comunidade
fonte
24
Só para esclarecer, o .NET é a implementação da CLI da Microsoft. Mono é uma implementação de CLI, com a Novell assumindo a liderança.
ChaosPandion
Isso parece muito mais uma resposta à pergunta anterior do que uma pergunta por si só. Sugiro que você considere editar sua pergunta para torná-la mais independente.
Walter
2
@walter, o ponto principal é que estou ciente dos argumentos usuais "java é mais multiplataforma que .NET" e os listo para que as respostas incorporem os melhores contra-argumentos possíveis.
1
Isso é fora de tópico para a pergunta. Vá para um site de planejamento de negócios e navegue em alguns exemplos de planos para ver o que é realmente crucial para uma empresa ... A tecnologia X vs A tecnologia Y é tão crucial quanto a FedEx debater Ford vs. GM para vans de entrega.
Red-dirt

Respostas:

194

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.

miguel.de.icaza
fonte
2
IBM, se você ler isso, eu gostaria que o AIX (ou mesmo o AS / 400) estivesse na lista Miguels !!
4
obrigado por uma resposta definitiva e autorizada (sp?)!
10
Sabemos que a IBM fez pelo menos duas portas do Mono para o AIX, mas as equipes que fizeram a porta não tiveram permissão para liberar as alterações novamente.
Miguel.de.icaza 23/11
3
+1 - Esse cara deveria estar trabalhando no Projeto Mono! Por favor, não
morda
1
@JeffO: Esse cara é o criador do Mono ;-)
Seul
114

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.

Mark H
fonte
20
+1 no último parágrafo.
Davy8
4
the C# language is an open standard, and is not strictly tied to .NET.e C# 4.0 code (current .NET version)são contraditórios
Jader Dias
9
Seu último ponto é bom e se aplica igualmente ao Java. Só porque você codificou seu aplicativo em Java não significa que ele é automaticamente portátil para todas as plataformas que suportam Java. Especialmente para projetos mais complexos, você encontra muitos aplicativos Java com código específico da plataforma.
Dean Harding
5
@ user8057: Winforms é 100% implementado? A sério? Confira o componente RichTextBox. Confira a funcionalidade de arrastar e soltar no componente Árvore. O swing é 100% multiplataforma, por outro lado, embora isso possa significar sucção em todas as plataformas.
precisa saber é o seguinte
2
@Yar: LOL para "embora isso possa significar sugando em todas as plataformas" :-)
Wizard79
14

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.

Joel Coehoorn
fonte
Apenas para esclarecer a questão do "código aberto": eu estava pensando em um projeto de código aberto como não sendo apoiado por uma entidade comercial aceitável, não como um negócio com um código fonte da GPL.
3
A Novell não é "uma entidade comercial adequada"?
svick
@ Rick - Eu não acho que "suable" é um erro de digitação. Ele está preocupado com questões legais em torno dos apoiadores do projeto.
Joel Coehoorn
@Thorbj Do ponto de vista comercial, é melhor ter uma entidade de suporte forte como a Novell do que uma entidade abstrata como o JCP.
Joel Coehoorn
@ user8057 Ah, nunca ouvi essa palavra. Parecia um erro de digitação estranho.
svick
11

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.

Robert Harvey
fonte
É claro que o Mono não é um clone exato, mas pelo que vi, é uma opção muito viável ao iniciar novos projetos.
ChaosPandion
O personagem em sua foto é me3i? de 美国?
Jader Dias
1
@Jader, totalmente alheios - mas isso é o caráter chinês para o belo e美国(quando combinado significa US, também significa literalmente belo país)
aggietech
AFAIK Clojure e Scala são idiomas, não plataformas. E (novamente AFAIK) Scala deve ser executado em qualquer implementação da JVM na qual o Java possa ser executado.
Giorgio
9

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.

tylerl
fonte
Engraçado você mencionar o Fortran, pois ele está evoluindo constantemente, com ênfase na concordância e paralaxe, bem como nos princípios de POO. Então, sim, o Fortran 77 é estável, mas desde que o Fortran 90 foi lançado, cada revisão fica cada vez melhor. O Fortran 2008 é "quase" uma linguagem moderna.
ja72
4
Eu diria que o .Net / C # 1.0 era, na melhor das hipóteses, um clone de Java ruim, mas pelo .Net 2.0 havia uma paridade de recursos muito boa entre as duas plataformas. Indo de lá para .Net 3.5 / C # 3, a plataforma da Microsoft deixou o Java para trás na maioria das áreas e continua a ganhar terreno com novos recursos, como digitação dinâmica, e recursos futuros, como simultaneidade assíncrona. Dito isso, uma grande razão pela qual a .Net é capaz de se mover tão rápido é a trilha deixada pelo Java. Se a Oracle quiser avançar o Java, eles poderão seguir rapidamente a trilha semelhante agora deixada pela Microsoft.
Joel Coehoorn
"o universo .NET / mono se move muito rápido". Ironicamente, a principal razão pela qual não usamos o Mono é que seu desenvolvimento de GC tem sido terrivelmente lento. Eles descreveram o atual GC estável como uma "medida provisória" em 2003! lists.ximian.com/pipermail/mono-gc-list/2003-August/000012.html
Jon Harrop -
Ou você pode simplesmente executar o Debian / Ubuntu, usar alguns repositórios apt externos e brincar com as crianças legais sem compilar o mono do zero.
Quandary
7

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.

digitxp
fonte
5
Com que rapidez as coisas mudam. A Nokia não vende mais os telefones que as pessoas desejam e a Novell não existe mais com o futuro de Qt e Mono em dúvida. Essa é provavelmente a razão pela qual as empresas não gostam de usar nada além de sistemas 'com suporte primário', como a Microsoft. É por isso que o código aberto é uma boa idéia.
Gbjbaanb
4

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.

Michael Stum
fonte
2

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.

Casper Bang
fonte
A abertura do Java não é a parte importante como tal. É minha experiência que meus programas rodam bem nas JVMs que passaram no TCK, portanto esse é um parâmetro importante.
1

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.

Lloeki
fonte
0

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.

Michael Shaw
fonte