Para soluções empresariais baseadas em janelas, o .NET às vezes é a melhor opção. Como o Mono é visto pelas empresas que precisam usar o Linux (ou preferem usar o Linux)? Supondo que os desenvolvedores não sejam um problema e estejam familiarizados com o .NET / Mono e outros possíveis concorrentes, como Java.
Uma empresa de médio / grande porte executaria o Mono em seus servidores em oposição a tecnologias como Java? Você conhece alguma dessas empresas?
Respostas:
Nós o usamos na grande corporação em que trabalho. Nós não planejamos isso desde o início do projeto, mas funcionou dessa maneira.
Tivemos um projeto interno que desenvolvemos no .NET. Quando entramos no UAT, o proprietário da empresa queria abrir o aplicativo para alguns clientes e para a equipe interna. A maioria dos nossos servidores externos (DMZ) é baseada em Linux e os servidores Windows que estão na DMZ não eram adequados (muito próximos da capacidade). Em vez de comprar um novo hardware, alguém sugeriu executar o aplicativo no Mono. Passamos alguns dias fazendo nossos próprios testes e, em seguida, lançamos o aplicativo para controle de qualidade e depois para UAT. Não tivemos problemas.
Se tivéssemos recebido o requisito no início do projeto, talvez não tivéssemos optado por escrevê-lo no .NET, mas esse foi um bom resultado para uma alteração de requisito muito, muito tardia. Agora, estamos bastante confiantes de que, se surgir novamente, poderemos implantar com sucesso no Mono (embora eu ache que, eventualmente, teremos que ajustar algum código, acho que tivemos sorte).
Não uso mono comercialmente, mas uso-o em particular, porque trabalho em uma empresa Windows, mas sou um usuário Linux em particular (para poder reutilizar o que faço no trabalho).
No geral, concordo com Miguel de Icaza, que diz:
- 25% dos aplicativos .NET funcionam imediatamente com mono
- outros 25% podem funcionar dentro de um dia ou menos
- mais 25% podem funcionar dentro de uma semana
- Os últimos 25% exigem uma reescrita completa do aplicativo (WinForms / COM)
Mono funciona razoavelmente bem, mas existem alguns problemas:
- Suporte VB.NET apenas para .NET <= 2.0
- Autenticação do Windows não implementada
- WPF não implementado
- Suporte WCF incompleto
- Entity Framework não implementado e nenhum plano para implementar
- "ASP.NET Web Parts" não implementado
- Sem suporte de interoperabilidade COM
- A conexão Sybase para a versão 15.5 (mais recente) não funciona
- Erros e incompletude na biblioteca de classes C # (por exemplo, XML estava com erros em mono <2.6)
- O controle do navegador da web Linux requer GTK #
Então os pequenos problemas:
- O Windows Forms funciona, mas nem sempre é renderizado corretamente
- O MonoDevelop não pode criar formulários do Windows
- A depuração 'passo a passo' do MonoDevelop não funciona realmente
- O serviço mono falha após 5 horas ...
Forme o que posso dizer:
- WebServices funcionam excelentemente
- Se você executar um WebApplication, ele funcionará bem (se não usar WebParts).
- Se você executar o WindowsForms, nem sempre será muito bom (para dizer o mínimo).
- Não existe um equivalente funcional para o Microsoft Reporting Service (o relatório de EF é o mais próximo, mas é lento, com erros e muito incompleto, além de nenhuma atividade há mais de um ano)
- Você terá problemas se precisar criar documentos do Word ou Excel.
Se você deseja desenvolver o .NET no Linux
- Você pode desenvolver o ASP.NET lá (a depuração e o passo a passo funcionam muito mal)
- Você não pode realmente desenvolver o WinForms no Linux
- Você precisa usar o GTK # em vez do WinForms
Em outras palavras:
- O Mono ocupa seu lugar na execução de aplicativos Web e WebServices e MailServers.
- Mas não é viável executar aplicativos WindowsForms, você precisa escrever aplicativos com GTK #
- Falta uma solução de relatório e suporte ao formato de arquivo MS (ou bibliotecas funcionando, portanto)
Editar (atualização de 2015):
Eu gostaria de acrescentar que, a depuração 'passo a passo' funciona excelentemente, e você pode usar o MonoDevelop para desenvolver aplicativos da Web no Linux, mesmo com as dependências do nuGet. O problema com as bibliotecas do Excel e do Word também desapareceu, e a estrutura da entidade agora é de código aberto. O resto é praticamente "como está" (não sei se o serviço mono é fixo, mas eu espero que sim).
O que melhorou também é que agora você pode ter pacotes atuais para sua distribuição, o que significa que você não precisa esperar até o próximo lançamento, digamos Debian / Ubuntu, até obter a versão mono mais recente (sem precisar compilá-los por conta própria) ) Esta é uma grande economia de tempo.
Além disso, com o lançamento do Roslyn, o suporte ao VB.NET deve melhorar muito no futuro próximo.
Minha empresa desenvolve um dos principais aplicativos de área de trabalho.NET e libera versões do Linux em execução no Mono, então eu diria que sim, definitivamente há um lugar para o Mono nas soluções empresariais baseadas em Windows.
Empacotamos o Mono com a instalação do nosso aplicativo, não exigindo que os usuários o instalem separadamente (e dessa forma controlamos a versão também).
Eu acho que a principal preocupação que muitas empresas teriam seria com os problemas de licença entre a Mono e a Microsoft. Meu entendimento é que, embora a Microsoft tenha concordado formalmente que o Mono possa usar as principais tecnologias .NET, mas fora isso, incluindo algumas das coisas mais usadas, existe mais uma área cinzenta legalmente, pois a Microsoft não declara uma posição firme de uma maneira ou de outra. de outros.
Obviamente, isso deixa em aberto a possibilidade de que eles exijam taxas de licença ou simplesmente processem por violação de patente. É improvável que isso aconteça da maneira como está se comportando agora, mas a maioria das empresas não gosta desse tipo de incerteza, principalmente quando se trata de possíveis passivos e custos associados.
Não acho que haja muito espaço para o Mono lá:
O Java já é uma plataforma estabelecida no Linux, com grande comunidade e abundância de bibliotecas e ferramentas de qualidade corporativa, tanto comerciais quanto de código aberto. Não vejo motivo para escolher o Mono sobre Java ao iniciar um novo projeto direcionado ao Linux (ou Mac), a menos que haja alguma circunstância específica (consulte a resposta de Walter).
Antes de usar o mono, precisamos garantir que não haja '\' codificado para a cadeia de caminho (use Path.Combine ()) ou prefixo "COM" (simplesmente aceite cadeia de caracteres em vez de inteiro) para a porta serial no programa.
O que funciona bem:
Problemas encontrados:
É melhor usar o mono internamente (como o sistema ERP) como um ambiente controlado.
Mono é uma ótima alternativa se você já possui código .NET que precisa ser executado em um ambiente de plataforma cruzada. O mono é usado bastante extensivamente no mundo dos negócios especificamente para resolver esse mesmo problema.
Eu argumentaria contra o uso da existência do Mono como uma desculpa para iniciar um projeto com o .NET que você sabe que precisará ser de plataforma cruzada. A razão para isso é o atraso entre o estado da arte do .NET e a velocidade de desenvolvimento do Mono.
Por outro lado, se você não pretende usar Mono em um projeto futuro, gostaria de adverti-lo para atingir o quadro Mono e executado em .NET como uma alternativa secundário desde Mono é em grande parte um subconjunto da funcionalidade completa .NET.