•  03-07-2019
  •  | 
  •  

Pergunta

Eu tenho usado C # no Visual Studio .NET com, e eu brinquei um pouco com Mono no openSUSE Linux, mas eu realmente não entendo como ele funciona.

Se eu escrever um aplicativo no Windows em .NET, como isso se relaciona com Mono? Eu não posso simplesmente executar o arquivo de um Windows exe no Linux sem vinho, por isso não me ajuda a executar aplicativos desenvolvidos no Windows.

É o propósito puramente para ter um equivalente biblioteca .NET em Linux (e outros) para tornar o desenvolvimento multi-plataforma mais fácil? Por exemplo, se eu fosse um negócio e queria atingir os clientes Linux, mas realmente queria usar NET, em seguida, Mono deve ser minha escolha? Ou há algo mais que eu estou perdendo?

Foi útil?

Solução

A do Windows EXE contém várias "partes". simplificado , o código .NET (= MSIL) é apenas uma parte do EXE, e há também uma "real" Windows Parte nativa dentro do EXE que serve como uma espécie de lançador para o .net quadro que então executa o MSIL.

Mono só vai tomar o MSIL e executá-lo, ignorando o material nativo do Windows Launcher.

Mais uma vez, esta é uma visão simplificada.

Editar: Tenho medo do meu compreensão dos detalhes profundos profundos não é bom o suficiente para realmente muitos detalhes (eu sei mais ou menos o que é um cabeçalho PE é, mas não é realmente os detalhes), mas eu encontrei estes Links úteis:

Estrutura Assembléia NET - Parte II

.NET Fundações - estrutura de montagem .NET

Outras dicas

Esta é uma questão de idade (com uma resposta já seleccionada), mas eu não acredito que a questão tem realmente sido bem atendida.

Primeiro, um pouco de fundo ...

Como funciona o .NET?

Um arquivo tradicional do Windows .EXE é um arquivo binário que representa uma série de instruções em linguagem de máquina que o computador entende e que faz chamadas para a API Win32 que são partes do Windows que oferecem serviços que os aplicativos podem aproveitar. A linguagem de máquina usada é muito específico para o seu tipo de computador e as chamadas Win32 fazer o executável muito dependente do Windows. A NET executável não é assim.

É importante perceber que a NET executável (.EXE) não é realmente uma aplicação nativa do Windows. O próprio Windows não entender como executar o código em um .NET executável. Seu computador não compreender.

Assim como Java, um aplicativo .NET é composta de instruções em uma linguagem chamada CIL (Common Intermediate Language) que você pode pensar em como a linguagem de máquina para um computador idealizado que realmente não existe. Em .NET, a implementação desta máquina idealizada software é chamado de Common Language Runtime (CLR). O equivalente no mundo Java é chamado o Java Virtual Machine (JVM). Em Java, o equivalente a CIL é chamado bytecode Java. CIL é às vezes chamado de MSIL (Microsoft Intermediate Language).

CIL é projetado para ser executado no CLR (uma máquina idealizada) mas de resto é independente de plataforma, o que significa que a CIL não se importa que tipo de computador que você tem ou o que sistema operacional você está executando.

Assim como você precisa de uma versão nativa do Java JVM em cada plataforma na qual você deseja executar o Java, você precisa de uma versão nativa do CLR para executar executáveis ??.NET CIL. O CLR é um aplicativo nativo do Windows, assim como os arquivos tradicionais Win32 EXE descrito acima. O CLR em si é específico para a implementação do Windows e arquitetura computador no qual ele foi projetado para ser executado.

Não importa o que .NET idioma que você começar com (C #, VisualBasic, F #, IronPython, IronRuby, Boo, etc.), todos eles se compilado para baixo a CIL bytecode. Você pode facilmente "desmontar" um programa CIL em uma forma de linguagem assembly orientada a objeto que é facilmente legível por seres humanos. Você pode escrever um programa em CIL diretamente si mesmo, mas poucas pessoas fazem.

No Windows, o CLR compila este código CIL Just-in-Time (JIT) para a direita quando você executar o arquivo executável - pouco antes o código é realmente executado. Isto significa que o bytecode CIL é convertido (compilados) para código de máquina real que roda nativamente em seu computador. Esta parte do CLR é chamado o compilador JIT ou muitas vezes apenas o JIT.

Até à data, a Microsoft lançou quatro versões do CLR: 1.0, 1.1, 2.0 e 4.0. Você precisa ter a versão correta do CLR instalado em sua máquina, se você deseja executar .NET executáveis ??segmentação que tempo de execução. Os suportes CLR 2,0 NET 2.0, 3.0, e 3.5 aplicações. Para outras versões do .NET, a versão .NET mapeia limpa para a versão CLR.

Além do JIT / CLR, .NET fornece uma série de bibliotecas (assembléias) que compõem o resto do framework .NET e que oferecem uma série de recursos e serviços que aplicativos .NET pode recorrer. A grande maioria destes conjuntos são código CIL puro que é executado no CLR. No Windows, um Alguns fazem chamadas para a API Win32 também. Quando você instalar o .NET, você está instalando o CLR, as bibliotecas de classe (quadro) e um monte de ferramentas de desenvolvimento. Cada versão do CLR geralmente requer um conjunto completo destes conjuntos "quadro". Algumas versões do .NET (por exemplo. 3.0 e 3.5) adicionado montagens estruturais adicionais sem atualizar o CLR ou os conjuntos existentes associados com que CLR.

O formato de arquivo executável (PE) portátil que um arquivo do Windows .EXE é entregue em contém uma cabeçaer que descreve o executável e identifica o arquivo como um arquivo .NET ou um arquivo Win32 nativo. Quando o Windows tenta executar um arquivo NET, que vê esse cabeçalho e automaticamente invoca o CLR em seu nome. É por isso que os arquivos .NET EXE parecem rodar nativamente no Windows.

Ok, então como é que Mono trabalho?

Mono implementa o CLR em Linux, Mac e outras plataformas. O tempo de execução Mono (CLR) é um aplicativo nativo escrito principalmente na linguagem C e compilado para baixo para código de linguagem de máquina para o sistema de computador em que foi concebido para ser executado. Como no Windows, o tempo de execução Mono é específico para o sistema operacional e tipo de máquina que você está usando.

Assim como no Windows, o tempo de execução Mono (CLR) compila o bytecode CIL em sua NET executável Just-in-time para código nativo que o computador possa entender e executar. Desta forma, um arquivo .NET é tão "nativo" para o Linux, pois é para o Windows.

Para a porta Mono para uma nova arquitetura que você precisa para a porta do JIT / CLR. Este é apenas como portar qualquer aplicação nativa para uma nova plataforma.

Como bem executado NET no Linux ou Mac é realmente apenas uma questão de quão bem o CLR é implementado nesses sistemas. Em teoria, o Mono CLR poderia executar código .NET nesses sistemas muito melhor do que a versão MS de .NET faz no Windows. Na prática, a implementação MS é geralmente superior (embora não em todos os casos).

Além da CLR, Mono fornece a maior parte do resto das bibliotecas (assembléias) que compõem o .NET framework. Assim como com a versão da Microsoft do .NET (na verdade mais) as assembleias Mono são fornecidos como CIL bytecode. Isso torna possível para tirar uma .dll * ou * .exe arquivo a partir de Mono e executá-lo sem modificações no Windows, Mac ou Linux como CIL é a língua "nativa" das implementações CLR nesses sistemas.

Assim como no Windows, Mono suporta múltiplas versões do CLR e as montagens associadas:

versões muito adiantados da Mono (antes 1,2?) Suportado apenas CLR 1.0 ou 1.1. Mono não apoiar grandes pedaços do quadro 2.0 até a sua própria versão 2.0.

Mono versões até a versão 2.4 suportado tanto CLR 1.1 e CLR 2,0 aplicações.

A partir do Mono 2.6, foi adicionado CLR 4.0, mas CLR 2.0 ainda era o padrão.

A partir do Mono 2.8 do CLR 4.0 tornou-se o padrão e o CLR 1.1 não é mais suportado.

Mono 2.10 continua a usar o CLR 4.0 como padrão e também para apoiar o CLR 2.0.

Assim como o .NET real (mas em muito menos casos), existem algumas assembleias Mono que põem em bibliotecas nativas. A fim de fazer o trabalho de montagem System.Drawing em Mono, a equipe Mono escreveu um programa Linux para simular a parte de GDI + da API Win32 no Linux. Esta biblioteca é chamado de 'libgdiplus'. Se você compilar Mono partir do código, você vai notar que você precisa para construir este arquivo 'libgdiplus' antes que você pode construir 'mono'. Você não precisa 'libgdiplus' no Windows porque a parte GDI + da API Win32 já faz parte do Windows. Uma porta cheia de Mono para novas plataformas requer esta biblioteca 'libgdiplus' para ser portado bem.

Em áreas onde o projeto da biblioteca .NET é excessivamente influenciada pelo design do Windows, e um ajuste pobre para sistemas como Mac ou Linux, a equipe Mono tem escrito extensões para o .NET framework. As extensões Mono também estão a bytecode CIL e geralmente funcionam muito bem em .NET.

Ao contrário do Windows, Linux geralmente não detecta .NET executáveis ??e lançar o CLR, por padrão. O usuário normalmente deve executar o CLR diretamente digitando 'mono appname.exe' ou algo similar. Aqui 'mono' é a aplicação que implementa o CLR e 'appname.exe' é o arquivo EXE que contém o código .NET para ser executado.

Para tornar as coisas mais fáceis para os usuários, aplicações Mono são muitas vezes envolto em um shell script que lança o CLR. Este esconde o fato de que o CLR está sendo usado apenas como naJanelas. Também é possível dizer Linux para iniciar o CLR quando um arquivo usando o formato de arquivo PE é encontrado. Isso geralmente não é feito como o formato de arquivo PE também é usado para executáveis ??nativos Win32 do Windows que, naturalmente, o CLR (Mono) não suporta.

Não há nenhuma razão técnica pela qual um lançador de PE não poderia ser usado pelo Linux que então lançamentos tanto um sistema que compreende o código nativo do Windows (como o vinho) ou o CLR (Mono), conforme apropriado. Isto simplesmente não foi feito para o meu conhecimento.

Frente e para trás

Qualquer .NET código que adere ao código "totalmente gerenciado", o que significa que não põe em código non-.NET, deve funcionar bem em Mono em todas as plataformas. Eu rotineiramente usam conjuntos .NET compilados a partir do Windows (para o qual eu não tenho o código) em Linux e Mac.

Eu também pode tomar qualquer código que eu compilar em Mono e de execução que em .NET no Windows. Eu posso fornecer um cliente algum código que eu compilado com Mono e não se preocupar se ele está em 32 bits ou 64 bits do Windows, por exemplo. O cliente não precisa ter a versão correta do .NET (CLR direita) instalado fo curso. CLR 2.0 tem sido em torno de um tempo muito longo e você pode apostar quase todos os usuários de Windows tem instalado. Os compiladores Mono e outros códigos também são apenas executáveis ??CIL e assim que funcionam bem no Windows, se quiser.

compatibilidade Mono é bom o suficiente para que grandes pedaços de código real Microsoft, como ASP.NET MVC, podem ser tomadas (onde legal para fazê-lo) a partir da versão MS real de .NET e executado em Mac ou Linux. Em geral, a equipe Mono tem feito um grande trabalho de implementação tanto o CLR eo resto do quadro (bibliotecas de classes / montagens).

ASP.NET

No Windows, o Internet Information Server (IIS) sabe como chamar para o CLR para executar .NET como parte de uma aplicação web. No Linux / Mac não é um módulo do Apache (mod_mono) que fornece capacidades semelhantes para o servidor web Apache. Este aplicativo é escrito em C e também deve ser portado para novas arquiteturas.

Portando Mono

Esta discussão identificou partes do Mono que são construídos como executáveis ??"nativos" e devem existir em um sistema no qual você deseja executar aplicações .NET.

  • O CLR (incluindo compilador JIT) - geralmente conhecido como mono
  • libgdiplus (para sistemas que não suporta nativamente a API GDI + [somente para Windows faz])
  • mod_mono (para permitir Apache para invocar o CLR para aplicações web .NET)

Estes três componentes, com a adição de bibliotecas de classe, proporcionar um ambiente .NET que a aparência "nativo" para os arquivos executáveis ??de .NET que você precisa para ser executado.

Isso é como Mono funciona.

Você pode de fato executar um arquivo .exe .NET com Mono no Linux. Isso não exige Wine. Na verdade, Mono compila programas para arquivos .exe, que podem funcionar tanto com Mono no Linux ou como um executável no Windows.

Mono é uma implementação open-source do Microsofts .NET CLR (Common Language Runtime). Isto é o que corre parte de programas .NET que não são em código nativo, mas em CIL (Common Intermediate Language), uma linguagem e linguagem intermediária máquina neutro. O Runtime leva esse código intermediário e converte-o em código de máquina.

No actual estado de Mono, você pode tomar programas .NET que usam as partes principais do .NET (mscorlib.dll) e executá-los em todos os lugares Mono corridas, não apenas do Windows.

Mas, como está mencionado que Mono é open source e você não pode simplesmente confiar que ele será a implementação completa NET, que tem alguns controles que não estão funcionando, você também deve ser cuidado com P / Invoca que o seu aplicação irá utilizar, por exemplo, seu aplicativo irá se comunicar com MCI (Multimedia Controller interface) sob win32. Mas eu estava usando mono escrita GTK # Aplicações também, mas eu também usei meus aplicativos do Windows que trabalharam sem qualquer recompilação como mencionado nossos colegas programadores acima, isto é, mono é uma alternativa de fonte aberta do .NET da Microsoft, e por padrão se você está construindo WinForms ou aplicações Gtk # mono vai compilar e vai criar um arquivo .exe de montagem para cada arquivo, e, claro, se você quer que ele irá criar uma biblioteca de vínculo dinâmico (DLL), quase como é feito em .NET. Só por sugestão tentar escrever alguns Gtk # (com MonoDevelop IDE que tem a sua built-in designer de gui chamada Stetic). E, claro, mono pode ser um ótimo substituto para Web Services que você pode criá-los em .NET e você pode hospedá-los em Apache (porque o Linux hospedagem hoje em dia são mais baratos do que os do Windows) serviços web e outros aplicativos ASP.NET irá trabalhar sob apache com uma mod_mono módulo que devem ser incluídos no apache.

Um pouco fora do tópico, mas eu só queria dizer-lhe um sneak peek-da minha experiência.

Além disso, você pode dar uma olhada para MoMA (se o seu objetivo é portar aplicativos de vencer para Lin).

O Mono Migration Analyzer (MoMA) ferramenta ajuda a identificar problemas que você pode tem ao portar o seu .Net aplicativo para Mono. Ele ajuda a identificar chamadas plataforma específicos (P / invocação) e áreas que ainda não são suportados pelo o projeto Mono.

MoMA

Aqui é um webapp que compara os tipos de BCL já implementadas por Mono e .NET Framework 3.5

http://mono.ximian.com/class -status / 2,0-vs-3,5 / index.html

Para resposta ainda mais de Michael, eu acredito que você vai ter que recompilar em Mono para o aplicativo para ser executado no tempo de execução Mono. Exceções podem existir. Eu só brinquei com Mono só um pouco, e eu sempre re-compilado a fonte. Eu nunca tentou executar um aplicativo .NET diretamente no Mono.

Além disso, Mono 1.9 é suposto ser totalmente .NET 2.0. Mono Olive e luar são supostamente para adicionar .NET 3.0 (menos WPF) e funcionalidade Silverlight.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top