InteroperabilidadeEditar
Porque os sistemas informáticos normalmente requerem interacção entre aplicações mais recentes e mais antigas, .NET Framework fornece meios de acesso a funções implementadas em programas mais recentes e mais antigos que executam fora do ambiente .NET. O acesso aos componentes do Component Object Model (COM) é fornecido em System.Runtime.InteropServices e System.EnterpriseServices namespaces da estrutura. O acesso a outras funções é feito através dos Serviços de Invocação de Plataforma (P/Invoke). O acesso a funções .NET a partir de aplicações nativas é através de P/Invoke function.
Language independenceEdit
.NET Framework introduz um Common Type System (CTS) que define todos os tipos de dados possíveis e construções de programação suportadas por CLR e como podem ou não interagir em conformidade com a especificação CLI. Devido a esta característica, .NET Framework suporta a troca de tipos e instâncias de objectos entre bibliotecas e aplicações escritas usando qualquer linguagem .NET em conformidade.
Type safetyEdit
CTS e o CLR usado em .NET Framework também reforça a segurança do tipo. Isto evita fundições mal definidas, invocações de métodos errados, e problemas de tamanho de memória quando se acede a um objecto. Isto também faz com que a maioria das línguas CLI sejam tipadas estaticamente (com ou sem inferência de tipo). Contudo, a partir de .NET Framework 4.0, o Dynamic Language Runtime alargou o CLR, permitindo a implementação de linguagens tipadas dinamicamente a partir de CLI.
PortabilityEdit
Embora a Microsoft nunca tenha implementado a estrutura completa em qualquer sistema excepto o Microsoft Windows, ela concebeu a estrutura para ser multi-plataforma, e as implementações estão disponíveis para outros sistemas operativos (ver Silverlight e § Implementações alternativas). A Microsoft submeteu as especificações para CLI (que inclui as bibliotecas de classes centrais, CTS, e CIL), C#, e C++/CLI tanto à Ecma International (ECMA) como à International Organization for Standardization (ISO), tornando-as disponíveis como normas oficiais. Isto torna possível a terceiros criar implementações compatíveis da estrutura e das suas linguagens noutras plataformas.
SecurityEdit
.NET Framework tem o seu próprio mecanismo de segurança com duas características gerais: Segurança de Acesso ao Código (CAS), e validação e verificação. O CAS é baseado em provas associadas a uma montagem específica. Normalmente a prova é a fonte da montagem (quer esteja instalada na máquina local ou tenha sido descarregada a partir da Internet). CAS utiliza as provas para determinar as permissões concedidas ao código. Outros códigos podem exigir que seja concedida uma permissão específica ao código de chamada. A exigência faz com que o CLR execute uma caminhada na pilha de chamadas: cada montagem de cada método na pilha de chamadas é verificada para obter a permissão necessária; se não for concedida qualquer montagem, é lançada uma excepção de segurança.
O bytecode CIL gerido é mais fácil de inverter a engenharia do que o código nativo, a menos que seja ofuscado. Os programas de descompilador .NET permitem aos programadores sem conhecimentos de engenharia reversa visualizar o código fonte por detrás de conjuntos .NET desobstruídos. Em contraste, as aplicações compiladas em código de máquina nativo são muito mais difíceis de reverter a engenharia, e o código fonte quase nunca é produzido com sucesso, principalmente devido a optimizações de compilação e falta de reflexão. Isto cria preocupações na comunidade empresarial sobre a possível perda de segredos comerciais e sobre a evasão de mecanismos de controlo de licenças. Para mitigar isto, a Microsoft tem incluído o Dotfuscator Community Edition com Visual Studio .NET desde 2002. Ferramentas de ofuscação de terceiros também estão disponíveis em fornecedores tais como VMware, V.i. Labs, Turbo, e Red Gate Software. Ferramentas de encriptação a nível de método para código .NET estão disponíveis em fornecedores tais como SafeNet.
Memory managementEdit
CLR liberta o programador do fardo de gerir a memória (alocando e libertando quando terminado); trata da própria gestão da memória ao detectar quando a memória pode ser libertada em segurança. Instantâneos de tipos .NET (objectos) são atribuídos a partir da pilha gerida; um pool de memória gerido por CLR. Enquanto existir uma referência a um objecto, que pode ser directa, ou através de um gráfico de objectos, o objecto é considerado como estando a ser utilizado. Quando não existe nenhuma referência a um objecto, e este não pode ser alcançado ou utilizado, torna-se lixo, elegível para recolha.
.NET Framework inclui um colector de lixo (GC) que funciona periodicamente, num fio separado do fio da aplicação, que enumera todos os objectos inutilizáveis e recupera a memória que lhes foi atribuída. É um colector de lixo não determinístico, compacto, que marca e varre o lixo. GC só funciona quando uma quantidade definida de memória tiver sido utilizada ou quando houver 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 atingidas, as corridas de GC são não determinísticas. Cada aplicação .NET tem um conjunto de raízes, que são ponteiros para objectos sobre a pilha gerida (objectos geridos). Estes incluem referências a objectos estáticos, objectos definidos como variáveis locais ou parâmetros de método actualmente no âmbito, e objectos referidos por registos de CPU. Quando a GC é executada, faz uma pausa na aplicação e depois, para cada objecto referido na raiz, enumera recursivamente todos os objectos alcançáveis a partir dos objectos da raiz e marca-os como alcançáveis. Utiliza metadados e reflexão CLI para descobrir os objectos encapsulados por um objecto, e depois percorre-os recursivamente. Depois enumera todos os objectos na pilha (que foram inicialmente atribuídos de forma contígua) usando a reflexão. Todos os objectos não marcados como acessíveis são lixo. Esta é a fase de marcação. Uma vez que a memória retida pelo lixo não tem qualquer consequência, é considerada espaço livre. No entanto, isto deixa pedaços de espaço livre entre objectos que eram inicialmente contíguos. Os objectos são então compactados juntos para tornar novamente contíguos o espaço livre na pilha gerida. Qualquer referência a um objecto invalidado pela deslocação do objecto é actualizada por GC para reflectir a nova localização. A aplicação é retomada após o fim da recolha do lixo. A última versão de .NET Framework utiliza a recolha de lixo concorrente juntamente com o código do utilizador, tornando as pausas imperceptíveis, porque é feita em segundo plano.
O colector de lixo utilizado por .NET Framework é também geracional. Os objectos são atribuídos a uma geração. Os objectos recém-criados são etiquetados Geração 0. Os objectos que sobrevivem a uma recolha de lixo são etiquetados Geração 1. Os objectos da Geração 1 que sobrevivem a outra recolha são da Geração 2. A estrutura utiliza até objectos da Geração 2. Os objectos da Geração superior são objectos de lixo recolhidos com menos frequência do que os objectos da Geração inferior. Isto aumenta a eficiência da recolha de lixo, uma vez que os objectos mais velhos tendem a ter tempos de vida mais longos do que os objectos mais novos. Ao ignorar objectos mais antigos na maioria das execuções de recolha, são necessárias menos verificações e operações de compactação no total.
PerformanceEdit
Quando uma aplicação é lançada pela primeira vez, a estrutura .NET compila o código CIL em código executável usando o seu compilador just-in-time, e coloca em cache o programa executável na Cache de Imagem Nativa .NET. Devido ao cache, a aplicação é lançada mais rapidamente para lançamentos subsequentes, embora o primeiro lançamento seja normalmente mais lento. Para acelerar o primeiro lançamento, os programadores podem utilizar o utilitário Native Image Generator para compilar e armazenar manualmente antecipadamente qualquer aplicação .NET.
O colector de lixo, que está integrado no ambiente, pode introduzir atrasos de execução imprevistos sobre os quais o programador tem pouco controlo directo. “Em grandes aplicações, o número de objectos com que o lixeiro precisa de trabalhar pode tornar-se muito grande, o que significa que pode demorar muito tempo a visitar e reorganizar todos eles”
.NET Framework fornece suporte para chamar Streaming SIMD Extensions (SSE) através de código gerido 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 dentro do namespace Mono.Simd em 2009. O programador principal da Mono, Miguel de Icaza, manifestou a esperança de que este apoio SIMD seja adoptado pela norma ECMA do CLR. As extensões SIMD em fluxo contínuo estão disponíveis em x86 CPUs desde a introdução do Pentium III. Algumas outras arquitecturas tais como ARM e MIPS também têm extensões SIMD. No caso da CPU não ter suporte para essas extensões, as instruções são simuladas em software.