Existe uma maneira suportada de executar aplicativos .NET 4.0 nativamente em um Mac?

Quais são as opções suportadas pela Microsoft para executar o código C # / .NET 4.0 nativamente no Mac? Sim, eu sei sobre o Mono, mas, entre outras coisas, fica atrás da Microsoft. E o Silverlight funciona apenas em um navegador da web. Uma solução do tipo VMWare também não é suficiente.

Existe alguma resposta semi-oficial para o motivo pelo qual a Microsoft simplesmente não suporta .NET no próprio Mac? Parece que eles poderiam usar o Silverlight e / ou comprar o Mono e rapidamente estar lá. Não há necessidade de Visual Studio nativo; compilação cruzada e depuração remota estão bem.

A razão é que, onde trabalho, há uma quantidade crescente de incerteza sobre o futuro, o que está causando muito mais desenvolvimento em C ++ em vez de C #; novos projetos estão optando por usar C ++. Ninguém quer dizer à gerência daqui a 18 a 24 meses "desculpe" se o Mac (ou iPad) se tornar um requisito. O C ++ é visto como a opção mais segura, mesmo que isso signifique uma perda de produtividade hoje.

existe alguma resposta semi-autorizada para o motivo pelo qual a Microsoft simplesmente não suporta .NET no próprio Mac?

A melhor resposta é provavelmente que você "não suporta" apenas o .NET no Mac. Você gasta centenas de milhões de dólares e vários anos portando o .NET no Mac.

Embora algumas coisas sejam totalmente gerenciadas e não exijam portabilidade, a maioria delas envolve a API do Win32 (janelas, controles, gdi +, criptografia, diretório ativo, COM, serviços corporativos, acesso a dispositivos, som, vídeo, codecs, winforms, etc., etc).

Cada um deles teria que ser abstraído no back-end e remapeado para bibliotecas nativas equivalentes no OSX. Obviamente, não haverá um bom mapeamento limpo, então você também precisa escrever hacks sobre hacks para fazê-lo funcionar exatamente da mesma maneira.

Depois, há o problema de que essas APIs no OSX podem ser quebradiças e a Apple não é muito boa em compatibilidade com versões anteriores, então você pode refazer seus hacks a cada versão principal (e às vezes versões menores e hotfixes), acumulando um alto custo de manutenção.

Basicamente, é uma quantidade enorme de dinheiro e trabalha com muito pouco ganho em uma plataforma cujo proprietário seria contra você de qualquer maneira. E você realmente não deseja gastar dinheiro para ajudar as pessoas a migrar da sua própria plataforma para a de um concorrente.

Portanto, você tem opções não perfeitas de plataforma cruzada:

• C ++, que ainda exigirá portar no futuro
• Silverlight fora do navegador, para suporte da Microsoft
• Mono, que trabalha para oferecer suporte a um subconjunto saudável do .NET, mas não é o Microsoft

Não, o Silverlight é a única opção da Microsoft do .Net no OS X. O Mono não fica "atrasado" tanto quanto você pensa; suporta .Net 4.0 e C # 4, por exemplo. No entanto, os kits de ferramentas da interface do usuário (WinForms e WPF) não são bem suportados no OS X. O Mono não oferece suporte a WPF. A Microsoft também não poderia reescrever todo o mecanismo de renderização. Provavelmente tudo bem. Se você deseja escrever um aplicativo nativo do Mac, deve escrever uma interface do usuário nativa (talvez usando o MonoMac).

Não. Mono é sua melhor aposta.

Outros projetos de código aberto como o DotGNU também podem atendê-lo. http://www.gnu.org/software/dotgnu/ Mas nada disso é suportado pelo MSFT.

O Silverlight não é apenas um navegador . Desde a versão 3 OOB já existia e seria o caminho que eu seguiria se uma plataforma suportada pela Microsoft fosse obrigatória.

Embora o Mono possa ficar atrasado, ele não é tão removido da pilha do .NET quanto você imagina e não deve ser descartado como uma opção viável.

Por que a Microsoft não implementa toda a pilha .NET; ROI.

A maior parte do lucro da Microsoft vem de dois produtos - Windows e Office. A compatibilidade entre plataformas prejudicaria o Windows.

Se você realmente deseja que o mesmo código seja executado em várias plataformas, escreva um aplicativo da web. Não soa como você faz. "Só por precaução" não é um bom motivo, é a fluência do escopo.

Mesmo que você decida segmentar o Mac OS X ou iOS daqui a 16 meses, você realmente acha que poderia pegar o código C ++ existente e transformá-lo em um bom aplicativo nativo (ou mesmo funcional)? A menos que você esteja trabalhando em um jogo em tela cheia, a resposta é não.

Economize tempo com o C # agora e, se você decidir mudar para o Mac, reescreva-o da maneira Mac com Objective-C e Cocoa - seus usuários agradecerão.

existe alguma resposta semi-autorizada para o motivo pelo qual a Microsoft simplesmente não suporta .NET no próprio Mac?

Onde está o mercado que justificaria a MS gastando o tesouro codificando-o? Para fazer isso, eles teriam que gastar muito dinheiro - milhões de dólares em salário. Um processo contínuo, conforme correções e atualizações.

E para quê? Direito de se gabar? Tudo o que eles conseguem é a capacidade das pessoas abandonarem o Windows para a Apple e ainda poderem executar seus aplicativos.

Se alguém lucrasse com isso, seria a Apple. Facilite a transição das pessoas para sua plataforma e os desenvolvedores (DEVELOPERS DEVELOPERS) a codificarem. Mas você acha que SJ se importa? Eles preferem inventar coisas novas para manter um i Infront. Além disso, a maior parte da estrutura é OS e as especificações do CLR são gratuitas para qualquer pessoa implementar. Você não pode colocar um NDA imundo em nada disso.

Você pode achar o projeto MonoMac útil - http://www.mono-project.com/MonoMac

Ele permite o desenvolvimento de aplicativos Cocoa estilo Mono, que pode ser implantado na Mac App Store.

Eu consideraria fortemente essa abordagem para um desenvolvedor não familiarizado com o Objective-C, mas com o .NET / Mono / Java que precisa entregar um aplicativo em um cenário com restrição de tempo.

Nenhum.

Eu recomendo que você escreva um aplicativo C ++ compilável de forma cruzada - você pode se divertir nele - ou use Ruby com wxWidgets.

Considero o .NET uma péssima proposta para desenvolvimento de plataforma cruzada e manutenção de produtos a longo prazo. Embora, cara, você pode aplicar aplicativos rapidamente nele. : - /

Queria que Delphi ainda fosse um grande concorrente.

Se você deseja executar o .NET nativamente em um Mac, pode usar o BootCamp para fazer isso (por exemplo, você executa o Windows no Mac e seus aplicativos .NET no Windows).

Se você quis dizer o Mac OS X em vez de apenas o hardware, pode usar o VMWare ou o Parallels para executar os aplicativos .NET no Windows (emulação) no OS X. Ambos têm modos visuais que permitem que o aplicativo apareça como se estivesse executando apenas no OS X (ele parecerá e se comportará como um aplicativo do Windows, mas se você estiver escrevendo um aplicativo que não seja da Web de plataforma cruzada sem uma interface personalizada para cada sistema operacional, sempre terá esse problema).

Você obterá a mesma quantidade de "suporte" ao fazer isso, pois está executando o aplicativo no Windows, embora virtualizado. É claro que qualquer pessoa que esteja executando o aplicativo precisará de uma cópia do software de virtualização e do Windows e estará disposta a aceitar um aplicativo que não se comporte como um aplicativo do OS X - mas é a única maneira de ter "nativo" .NET rodando em um Mac.

Dan, eu não acho que você pode fazer isso. No entanto, uma solução possível (ainda vapourware) é usar o Embarcadero Rad Studio C ++ Builder, que possui uma boa VCL para o desenvolvimento de aplicativos visuais (nos quais se baseia grande parte do .net), e eles são rumores de que haverá suporte para várias plataformas. no próximo lançamento.

Isso será desenvolvido no Windows, direcionado para Mac ou Linux. Ou assim diz o roteiro deles.

O ambiente C ++ é razoável e, se você desenvolver o VCL, em teoria, o aplicativo funcionará apenas nas outras plataformas.

É claro que até que seja realmente enviado, resta ver como isso é realmente eficaz.

A resposta é não.

Na verdade, seu caso parece ser um bom exemplo de quando não escolher o .NET.

Se você deseja desenvolver um sistema operacional, use as ferramentas certas. Não há aplicativos verdadeiramente profissionais escritos em mono para o Mac. Por outro lado, há muitos desenvolvedores não profissionais usando muitas ferramentas, criando muito lixo. Veja as avaliações de aplicativos mono que foram escritas para o OSX. Os desenvolvedores estão escrevendo usando uma estrutura incompleta hackeada para combinar com a plataforma OSX. Comece a escrever - se você usou o C # Objetivo C é um aprendizado rápido.

Desenvolvedores profissionais para mac usam C ++, Objective C, Cocoa e Xcode. Desenvolvo em várias plataformas e cada uma tem suas melhores ferramentas. Use o Xcode para Mac e iOS.

Assim como uma observação lateral, o Xcode não é o Visual Studio, não é tão estável e é uma desgraça para a apple em comparação, mas funciona bem quando você se acostuma com as peculiaridades dele. É muito difícil vencer as ferramentas Microsofts - mas elas foram escritas para Windows, não para Linux, iOS, OSX, AIX etc.