.NET Framework - .NET Framework

.NET Framework
.NET Logo.svg
DotNet.svg
Pilha de componentes do .NET Framework
Desenvolvedor (s) Microsoft
lançamento inicial 14 de fevereiro de 2002 ; 19 anos atras ( 14/02/2002 )
Último lançamento
4.8.0 Versão 3928/25 de julho de 2019 ; 2 anos atrás ( 25/07/2019 )
Sistema operacional Windows 98 ou posterior, Windows NT 4.0 ou posterior
Plataforma IA-32 , x86-64 e ARM
Sucessor .INTERNET
Modelo Framework de software
Licença Misturado; ver § Licenciamento
Local na rede Internet dotnet .microsoft .com Edite isso no Wikidata

O .NET Framework (pronuncia-se " dot net" ) é um framework de software desenvolvido pela Microsoft que roda principalmente no Microsoft Windows . Inclui uma grande biblioteca de classes chamada Framework Class Library (FCL) e fornece interoperabilidade de linguagem (cada linguagem pode usar código escrito em outras linguagens) em várias linguagens de programação . Os programas escritos para .NET Framework são executados em um ambiente de software (em contraste com um ambiente de hardware ) denominado Common Language Runtime (CLR). O CLR é uma máquina virtual de aplicativo que fornece serviços como segurança, gerenciamento de memória e tratamento de exceções . Como tal, o código de computador escrito usando o .NET Framework é chamado de " código gerenciado ". O FCL e o CLR juntos constituem o .NET Framework.

FCL fornece a interface do usuário , acesso a dados , conectividade de banco de dados , criptografia , desenvolvimento de aplicativos da web , algoritmos numéricos e comunicações de rede . Os programadores produzem software combinando seu código-fonte com .NET Framework e outras bibliotecas. A estrutura deve ser usada pela maioria dos novos aplicativos criados para a plataforma Windows. A Microsoft também produz um ambiente de desenvolvimento integrado para software .NET chamado Visual Studio .

O .NET Framework começou como software proprietário , embora a empresa tenha trabalhado para padronizar a pilha de software quase imediatamente, mesmo antes de seu primeiro lançamento. Apesar dos esforços de padronização, os desenvolvedores, principalmente aqueles nas comunidades de software livre e de código aberto , expressaram seu desconforto com os termos selecionados e as perspectivas de qualquer implementação de código aberto e livre, especialmente no que diz respeito a patentes de software . Desde então, a Microsoft mudou o desenvolvimento do .NET para seguir mais de perto um modelo contemporâneo de um projeto de software desenvolvido pela comunidade, incluindo a publicação de uma atualização de sua patente prometendo resolver as preocupações.

Em abril de 2019, a Microsoft lançou o .NET Framework 4.8, a última versão do framework como uma oferta proprietária. Desde então, apenas correções de bugs de segurança e confiabilidade mensais para essa versão foram lançadas. Nenhuma mudança adicional para essa versão está planejada.

História

A Microsoft começou a desenvolver o .NET Framework no final dos anos 1990, originalmente com o nome de Next Generation Windows Services (NGWS), como parte da estratégia .NET . No início de 2000, as primeiras versões beta do .NET 1.0 foram lançadas.

Em agosto de 2000, a Microsoft e a Intel trabalharam para padronizar a Common Language Infrastructure (CLI) e o C # . Em dezembro de 2001, ambos foram ratificados os padrões da Ecma International (ECMA). Organização Internacional de Padronização (ISO) seguida em abril de 2003. A versão atual dos padrões ISO são ISO / IEC 23271: 2012 e ISO / IEC 23270: 2006.

Embora a Microsoft e seus parceiros detenham patentes para CLI e C #, ECMA e ISO exigem que todas as patentes essenciais para a implementação sejam disponibilizadas sob "termos razoáveis ​​e não discriminatórios ". As empresas concordaram em cumprir esses termos e em disponibilizar as patentes sem royalties. No entanto, isso não se aplicava à parte do .NET Framework não coberta pelos padrões ECMA-ISO, que incluíam Windows Forms , ADO.NET e ASP.NET . As patentes que a Microsoft detém nessas áreas podem ter impedido as implementações da estrutura completa que não eram da Microsoft.

Em 3 de outubro de 2007, a Microsoft anunciou que o código-fonte das bibliotecas do .NET Framework 3.5 seria disponibilizado sob a Licença de Origem de Referência da Microsoft (Ms-RSL). O repositório de código-fonte tornou-se disponível online em 16 de janeiro de 2008 e incluía BCL, ASP.NET, ADO.NET, Windows Forms, WPF e XML. Scott Guthrie, da Microsoft, prometeu que as bibliotecas LINQ, WCF e WF estavam sendo adicionadas.

As variantes do .NET Compact Framework e do .NET Micro Framework do .NET Framework forneceram suporte para outras plataformas da Microsoft, como Windows Mobile , Windows CE e outros dispositivos incorporados com recursos limitados. O Silverlight forneceu suporte para navegadores da web por meio de plug-ins.

Logotipo do Microsoft .NET Framework v4.5

Em novembro de 2014, a Microsoft também produziu uma atualização em suas concessões de patentes, que estende ainda mais o escopo além de suas promessas anteriores. Projetos anteriores como o Mono existiam em uma área cinzenta legal porque as concessões anteriores da Microsoft aplicavam-se apenas à tecnologia em "especificações cobertas", incluindo estritamente as 4ª edições de cada ECMA-334 e ECMA-335. A nova promessa de patente, no entanto, não coloca nenhum limite na versão de especificação e até mesmo se estende a quaisquer tecnologias de runtime .NET documentadas no MSDN que não tenham sido formalmente especificadas pelo grupo ECMA, se um projeto decidir implementá-las. Isso permite que o Mono e outros projetos mantenham a paridade de recursos com os recursos .NET modernos que foram introduzidos desde a publicação da 4ª edição, sem correr o risco de litígio de patente sobre a implementação desses recursos. A nova concessão mantém a restrição de que qualquer implementação deve manter conformidade mínima com as partes obrigatórias da especificação CLI.

Em 31 de março de 2016, a Microsoft anunciou no Microsoft Build que relicenciará completamente o Mono sob uma Licença do MIT, mesmo em cenários onde antes era necessária uma licença comercial. A Microsoft também complementou sua promessa de patente anterior para o Mono, declarando que não reivindicará nenhuma "patente aplicável" contra partes que estejam "usando, vendendo, oferecendo para venda, importando ou distribuindo o Mono". Foi anunciado que o Projeto Mono foi contribuído para a .NET Foundation. Esses empreendimentos seguiram a aquisição da Xamarin , iniciada em fevereiro de 2016 e concluída em 18 de março de 2016.

O comunicado à imprensa da Microsoft destaca que o compromisso de plataforma cruzada agora permite uma pilha .NET moderna do lado do servidor de código aberto. A Microsoft lançou o código-fonte para WPF, Windows Forms e WinUI em 4 de dezembro de 2018.

Arquitetura

Visão geral da Common Language Infrastructure (CLI)

Infraestrutura de linguagem comum

Common Language Infrastructure (CLI) fornece uma plataforma de linguagem neutra para desenvolvimento e execução de aplicativos. Implementando os principais aspectos do .NET Framework dentro do escopo da CLI, essas funções não estarão vinculadas a uma linguagem, mas estarão disponíveis nas várias linguagens com suporte da estrutura.

Common Language Runtime

.NET Framework inclui o Common Language Runtime (CLR). Ele serve como mecanismo de execução do .NET Framework e oferece muitos serviços, como gerenciamento de memória , segurança de tipos , tratamento de exceções , coleta de lixo , segurança e gerenciamento de threads . Todos os programas escritos para .NET Framework são executados pelo CLR.

Os programas escritos para .NET Framework são compilados em código Common Intermediate Language (CIL), em vez de serem compilados diretamente em código de máquina . Durante a execução, um compilador just-in-time (JIT) específico da arquitetura transforma o código CIL em código de máquina.

Assembléias

O código CIL compilado é armazenado em assemblies CLI . Conforme exigido pela especificação, os assemblies são armazenados no formato de arquivo Portable Executable (PE), comum na plataforma Windows para todas as bibliotecas de vínculo dinâmico (DLL) e arquivos EXE executáveis . Cada assembly consiste em um ou mais arquivos, um dos quais deve conter um manifesto contendo os metadados do assembly. O nome completo de um assembly (não deve ser confundido com o nome do arquivo no disco) contém seu nome de texto simples, número de versão, cultura e token de chave pública . As montagens são consideradas equivalentes se compartilharem o mesmo nome completo.

Uma chave privada também pode ser usada pelo criador do assembly para atribuição de nomes fortes . O token de chave pública identifica com qual chave privada um assembly está assinado. Apenas o criador do par de chaves (normalmente a pessoa que assina o assembly) pode assinar os assemblies que têm o mesmo nome forte de um assembly da versão anterior, uma vez que o criador possui a chave privada. A nomenclatura forte é necessária para adicionar assemblies ao Global Assembly Cache .

A partir do Visual Studio 2015, a tecnologia de compilação .NET Native permite a compilação de código .NET de aplicativos da Plataforma Universal do Windows diretamente para código de máquina em vez de código CIL, mas o aplicativo deve ser escrito em C # ou Visual Basic.NET.

Biblioteca de aulas

O .NET Framework inclui uma implementação das bibliotecas padrão básicas da CLI . A .NET Framework Class Library (FCL) é organizada em uma hierarquia de namespaces . A maioria dos embutidos de interfaces de programação de aplicações (API) fazem parte de qualquer um System.*ou Microsoft.*espaços de nomes. Essas bibliotecas de classes implementam muitas funções comuns, como leitura e gravação de arquivos, renderização gráfica, interação com banco de dados e manipulação de documentos XML. As bibliotecas de classes estão disponíveis para todas as linguagens compatíveis com CLI . O FCL implementa a CLI Base Class Library (BCL) e outras bibliotecas de classes - algumas são especificadas pela CLI e outras são específicas da Microsoft.

BCL inclui um pequeno subconjunto de toda a biblioteca de classes e é o conjunto principal de classes que servem como a API básica do CLR. Para .NET Framework, a maioria das classes consideradas parte do BCL residem em mscorlib.dll, System.dlle System.Core.dll. As classes BCL estão disponíveis no .NET Framework, bem como suas implementações alternativas, incluindo .NET Compact Framework , Microsoft Silverlight , .NET Core e Mono .

FCL refere-se a toda a biblioteca de classes fornecida com o .NET Framework. Inclui um conjunto expandido de bibliotecas, incluindo BCL, Windows Forms , ASP.NET e Windows Presentation Foundation (WPF), mas também extensões para as bibliotecas de classe base ADO.NET , Language Integrated Query (LINQ), Windows Communication Foundation (WCF) e Workflow Foundation (WF). FCL é muito maior em escopo do que bibliotecas padrão para linguagens como C ++ e comparável em escopo a bibliotecas padrão de Java .

Com a introdução de implementações alternativas (por exemplo, Silverlight), a Microsoft introduziu o conceito de Portable Class Libraries (PCL), permitindo que uma biblioteca de consumo rode em mais de uma plataforma. Com a proliferação das plataformas .NET, a abordagem PCL falhou em escalar (PCLs são interseções definidas da superfície da API entre duas ou mais plataformas). Como a próxima etapa evolutiva do PCL, a Biblioteca .NET Standard foi criada retroativamente com base nas System.Runtime.dllAPIs baseadas em UWP e Silverlight. Novas plataformas .NET são encorajadas a implementar uma versão da biblioteca padrão, permitindo que elas reutilizem bibliotecas de terceiros existentes para serem executadas sem novas versões delas. A Biblioteca .NET Standard permite uma evolução independente das camadas de biblioteca e modelo de aplicativo dentro da arquitetura .NET.

NuGet é o gerenciador de pacotes para todas as plataformas .NET. Ele é usado para recuperar bibliotecas de terceiros em um projeto .NET com um feed de biblioteca global em NuGet.org. Feeds privados podem ser mantidos separadamente, por exemplo, por um servidor de construção ou um diretório do sistema de arquivos.

C ++ / CLI

A Microsoft introduziu C ++ / CLI no Visual Studio 2005, que é uma linguagem e meio de compilar programas Visual C ++ para serem executados no .NET Framework. Algumas partes do programa C ++ ainda são executadas em um Visual C ++ Runtime não gerenciado , enquanto partes especialmente modificadas são traduzidas em código CIL e executadas com o CLR do .NET Framework .

Os assemblies compilados usando o compilador C ++ / CLI são chamados de assemblies de modo misto, pois contêm código nativo e gerenciado na mesma DLL. Esses assemblies são mais complexos para fazer a engenharia reversa, uma vez que os descompiladores .NET , como o .NET Reflector, revelam apenas o código gerenciado.

Princípio de design

Interoperabilidade

Como os sistemas de computador geralmente requerem interação entre aplicativos mais novos e mais antigos, o .NET Framework fornece meios para acessar funções implementadas em programas mais novos e mais antigos que são executados fora do ambiente .NET. O acesso aos componentes do Component Object Model (COM) é fornecido em System.Runtime.InteropServicese os System.EnterpriseServicesnamespaces da estrutura. O acesso a outras funções é via Platform Invocation Services (P / Invoke). O acesso às funções .NET a partir de aplicativos nativos é feito por meio da função reversa P / Invoke.

Independência de linguagem

.NET Framework apresenta um Common Type System (CTS) que define todos os tipos de dados possíveis e construções de programação com suporte por CLR e como eles podem ou não interagir em conformidade com a especificação CLI. Por causa desse recurso, o .NET Framework oferece suporte à troca de tipos e instâncias de objeto entre bibliotecas e aplicativos escritos usando qualquer linguagem .NET em conformidade .

Segurança de tipo

O CTS e o CLR usados ​​no .NET Framework também impõem a segurança de tipo . Isso evita conversões mal definidas, invocações de métodos erradas e problemas de tamanho de memória ao acessar um objeto. Isso também torna a maioria das linguagens CLI tipadas estaticamente (com ou sem inferência de tipo ). No entanto, a partir do .NET Framework 4.0, o Dynamic Language Runtime estendeu o CLR, permitindo que linguagens digitadas dinamicamente sejam implementadas no CLI.

Portabilidade

Embora a Microsoft nunca tenha implementado a estrutura completa em nenhum sistema, exceto o Microsoft Windows, ela projetou a estrutura para ser multiplataforma, e as implementações estão disponíveis para outros sistemas operacionais (consulte Silverlight e § Implementações alternativas ). A Microsoft enviou as especificações para CLI (que inclui as bibliotecas de classes principais, CTS e CIL), C # e C ++ / CLI para a Ecma International (ECMA) e para a International Organization for Standardization (ISO), disponibilizando-as como padrões oficiais. Isso possibilita que terceiros criem implementações compatíveis do framework e de suas linguagens em outras plataformas.

Segurança

.NET Framework tem seu próprio mecanismo de segurança com dois recursos gerais: Code Access Security (CAS) e validação e verificação. O CAS é baseado em evidências associadas a uma montagem específica. Normalmente, a evidência é a fonte do assembly (se ele está instalado na máquina local ou foi baixado da Internet). O CAS usa evidências para determinar as permissões concedidas ao código. Outro código pode exigir que o código de chamada receba uma permissão específica. A demanda faz com que o CLR execute uma caminhada na pilha de chamadas: cada assembly de cada método na pilha de chamadas é verificado quanto à permissão necessária; se algum assembly não tiver permissão, uma exceção de segurança será lançada.

O bytecode CIL gerenciado é mais fácil de fazer engenharia reversa do que o código nativo, a menos que seja ofuscado . Os programas descompiladores .NET permitem que os desenvolvedores sem habilidades de engenharia reversa visualizem o código-fonte por trás de assemblies .NET não ofuscados. Em contraste, os aplicativos compilados em código de máquina nativo são muito mais difíceis de fazer engenharia reversa, e o código-fonte quase nunca é produzido com sucesso, principalmente por causa das otimizações do compilador e da falta de reflexão . Isso cria preocupações na comunidade empresarial sobre a possível perda de segredos comerciais e a omissão de mecanismos de controle de licenças. Para atenuar isso, a Microsoft incluiu Dotfuscator Community Edition com Visual Studio .NET desde 2002. Ferramentas de ofuscação de terceiros também estão disponíveis em fornecedores como VMware , Vi Labs , Turbo e Red Gate Software . Ferramentas de criptografia de nível de método para código .NET estão disponíveis em fornecedores como a SafeNet .

Gerenciamento de memória

O CLR libera o desenvolvedor da carga de gerenciamento de memória (alocação e liberação quando concluído); ele lida com o próprio gerenciamento de memória, detectando quando a memória pode ser liberada com segurança. Instanciações de tipos .NET (objetos) são alocadas a partir do heap gerenciado; um pool de memória gerenciado pelo CLR. Enquanto existir uma referência a um objeto, que pode ser direta ou por meio de um gráfico de objetos, o objeto é considerado em uso. Quando não existe nenhuma referência a um objeto e ele não pode ser alcançado ou usado, ele se torna lixo, elegível para coleta.

.NET Framework inclui um coletor de lixo (GC) que é executado periodicamente, em um thread separado do thread do aplicativo, que enumera todos os objetos inutilizáveis ​​e recupera a memória alocada para eles. É um coletor de lixo não determinístico, compactador e com marcação e varredura . O GC é executado apenas quando uma determinada quantidade de memória foi usada ou quando há pressão suficiente para a memória no sistema. Uma vez que não é garantido quando as condições para recuperar a memória são alcançadas, as execuções do GC são não determinísticas . Cada aplicativo .NET possui um conjunto de raízes, que são ponteiros para objetos no heap gerenciado ( objetos gerenciados ). Isso inclui referências a objetos estáticos, objetos definidos como variáveis ​​locais ou parâmetros de método atualmente no escopo e objetos referidos por registros de CPU. Quando o GC é executado, ele pausa o aplicativo e, em seguida, para cada objeto referido na raiz, enumera recursivamente todos os objetos alcançáveis ​​dos objetos raiz e os marca como alcançáveis. Ele usa metadados CLI e reflexão para descobrir os objetos encapsulados por um objeto e, em seguida, percorrê-los recursivamente. Em seguida, ele enumera todos os objetos no heap (que foram inicialmente alocados de forma contígua) usando reflexão. Todos os objetos não marcados como alcançáveis ​​são lixo. Esta é a fase de marcação . Como a memória mantida pelo lixo não tem consequências, ela é considerada espaço livre. No entanto, isso deixa pedaços de espaço livre entre objetos que eram inicialmente contíguos. Os objetos são então compactados juntos para tornar o espaço livre no heap gerenciado contíguo novamente. Qualquer referência a um objeto invalidado pela movimentação do objeto é atualizada pelo GC para refletir a nova localização. O aplicativo é retomado após o término da coleta de lixo. A versão mais recente do .NET framework usa coleta de lixo simultânea junto com o código do usuário, tornando as pausas imperceptíveis, porque é feito em segundo plano.

O coletor de lixo usado pelo .NET Framework também é geracional . Os objetos são atribuídos a uma geração . Objetos recém-criados são marcados como Geração 0 . Os objetos que sobrevivem a uma coleta de lixo são marcados como Geração 1 . Os objetos da geração 1 que sobrevivem a outra coleção são a geração 2 . A estrutura usa até objetos da Geração 2. Objetos de geração superior são coletados como lixo com menos frequência do que objetos de geração inferior. Isso aumenta a eficiência da coleta de lixo, pois os objetos mais antigos tendem a ter uma vida útil mais longa do que os objetos mais novos. Ao ignorar objetos mais antigos na maioria das execuções de coleção, menos verificações e operações de compactação são necessárias no total.

atuação

Quando um aplicativo é iniciado pela primeira vez, o .NET Framework compila o código CIL em código executável usando seu compilador just-in-time e armazena em cache o programa executável no .NET Native Image Cache. Devido ao armazenamento em cache, o aplicativo é iniciado mais rapidamente para inicializações subsequentes, embora a primeira inicialização geralmente seja mais lenta. Para acelerar o primeiro lançamento, os desenvolvedores podem usar o utilitário Native Image Generator para compilar manualmente com antecedência e armazenar em cache qualquer aplicativo .NET.

O coletor de lixo, que é integrado ao ambiente, pode introduzir atrasos imprevistos de execução sobre os quais o desenvolvedor tem pouco controle direto. "Em aplicações grandes, o número de objetos com os quais o coletor de lixo precisa trabalhar pode se tornar muito grande, o que significa que pode demorar muito para visitar e reorganizar todos eles."

.NET Framework fornece suporte para chamar Streaming SIMD Extensions (SSE) por meio de código gerenciado a partir de abril de 2014 no Visual Studio 2013 Update 2. No entanto, Mono forneceu suporte para extensões SIMD a partir da versão 2.2 no namespace Mono.Simd em 2009. Mono's lead o desenvolvedor Miguel de Icaza expressou esperança de que este suporte SIMD seja adotado pelo padrão ECMA do CLR. As extensões de streaming SIMD estão disponíveis em CPUs x86 desde a introdução do Pentium III . Algumas outras arquiteturas, como ARM e MIPS, também possuem extensões SIMD. Caso a CPU não tenha suporte para essas extensões, as instruções são simuladas no software.

Implementações alternativas

.NET Framework foi a implementação predominante das tecnologias .NET, até o lançamento do .NET . Existem outras implementações para partes da estrutura. Embora o mecanismo de tempo de execução seja descrito por uma especificação ECMA-ISO, outras implementações dele podem ser sobrecarregadas por questões de patentes ; Os padrões ISO podem incluir a isenção de responsabilidade: "Chama-se a atenção para a possibilidade de alguns dos elementos deste documento estarem sujeitos a direitos de patente. A ISO não deve ser responsabilizada pela identificação de qualquer ou todos esses direitos de patente." É mais difícil desenvolver alternativas ao FCL, que não é descrito por um padrão aberto e pode estar sujeito a restrições de direitos autorais. Além disso, partes do FCL têm funções e comportamentos específicos do Windows, portanto, a implementação em plataformas não Windows pode ser problemática.

Algumas implementações alternativas de partes da estrutura estão listadas aqui.

  • .NET Micro Framework é uma plataforma .NET para dispositivos com recursos extremamente limitados. Inclui uma pequena versão do CLR e suporta desenvolvimento em C # (embora alguns desenvolvedores tenham sido capazes de usar VB.NET , embora com uma quantidade de hacking e com funcionalidades limitadas) e depuração (em um emulador ou em hardware), ambos usando Microsoft Visual Studio . Ele também apresenta um subconjunto da Biblioteca de Classes do .NET Framework (cerca de 70 classes com cerca de 420 métodos), uma estrutura de GUI vagamente baseada em WPF e bibliotecas adicionais específicas para aplicativos incorporados.
  • Mono é uma implementação de CLI e FCL e fornece funções adicionais. Ele é licenciado como software livre sob a Licença MIT . Inclui suporte para bibliotecas ASP.NET, ADO.NET e Windows Forms para uma ampla variedade de arquiteturas e sistemas operacionais. Também inclui compiladores C # e VB.NET.
  • Portable.NET (parte do DotGNU ) fornece uma implementação de CLI, partes de FCL e um compilador C #. Ele oferece suporte a uma variedade de CPUs e sistemas operacionais. O projeto foi descontinuado, com a última versão estável em 2009.
  • A infraestrutura de linguagem comum de fonte compartilhada da Microsoft é uma implementação gratuita do CLR. No entanto, a última versão é executada apenas no Windows XP SP2 e não foi atualizada desde 2006. Portanto, ela não contém todos os recursos da versão 2.0 do .NET Framework.
  • CrossNet é uma implementação de CLI e partes de FCL. É um software livre que usa uma Licença MIT de código aberto .

Licenciamento

As estruturas de código gerenciado da Microsoft e seus componentes são licenciados da seguinte forma:

Componente Licença
.NET Framework (pacote redistribuível) Software proprietário
Código-fonte de referência do .NET Framework 4.5 e anterior Licença de referência da Microsoft (Ms-RSL)
Código-fonte de referência do .NET Framework 4.6 Licença MIT
Mono Licença MIT
.NET (anteriormente .NET Core)
CoreFX, CoreCLR e CLI
Licença MIT
.NET Micro Framework Licença Apache 2.0
Plataforma de compilador .NET (codinome "Roslyn") Licença MIT
ASP.NET MVC , API da Web e páginas da Web ( Razor ) Licença Apache 2.0
ASP.NET Core Licença Apache 2.0
ASP.NET Ajax Control Toolkit Licença BSD
ASP.NET SignalR Licença Apache 2.0
Estrutura de entidade Licença Apache 2.0
NuGet Licença Apache 2.0

Veja também

Notas

Referências

links externos