.NET Framework

Explore o Microsoft .NET Framework 4.5.1

Gaye Oncul Oncul

A versão Microsoft. NET Framework 4.5.1, juntamente com o Visual Studio 2013, apresenta recursos inovadores para aumentar a produtividade do desenvolvedor e o desempenho de aplicativos. Além disso, oferece novos recursos para melhorar a UX do consumo de pacotes .NET NuGet, o que é importante porque NuGet é um veículo de entrega primário para bibliotecas do .NET Framework.

O produto anterior, o .NET Framework 4.5, foi um grande lançamento com muitas novidades. Ele foi instalado em mais de 200 milhões de computadores. O .NET Framework 4.5.1 foi lançado cerca de 14 meses depois, em outubro de 2013, e apesar do curto espaço de tempo, ele vem repleto de muitos recursos solicitados pelos clientes. Neste artigo, falarei sobre os novos recursos do .NET Framework 4.5.1 e, para obter mais detalhes, você pode consultar os posts sobre o .NET Framework 4.5.1 RTM (bit.ly/1bBlEPN) e o .NET Framework 4.5.1 Preview (bit.ly/10Vr2ft) no blog do .NET Framework.

O .NET Framework 4.5.1 é apenas uma parte do que a equipe .NET (da qual sou membro) vem trabalhando desde o ano passado. Também enviamos várias bibliotecas em NuGet para preencher as lacunas da plataforma e permitir novos cenários. Farei uma visão geral de nossas bibliotecas .NET NuGet e também destacarei um dos nossos profundos investimentos, o novo compilador .NET just-in-time (JIT), que é fornecido como uma versão CTP (Community Technology Preview) na mesma época do .NET Framework 4.5.1.

Desenvolvimento mais produtivo

Vou começar com os novos recursos de depuração fornecidos com o .NET Framework 4.5.1 para melhorar a produtividade do desenvolvedor.

Melhorias da depuração assíncrona Depois de estabelecer uma base sólida e fácil de usar para o modelo de programação assíncrona nas versões anteriores do Framework, nosso objetivo era suavizar alguns aspectos restantes para a experiência geral do desenvolvedor com o .NET Framework 4.5.1. Duas questões são essenciais para a depuração de código assíncrono: “Como cheguei a este método assíncrono?” e "Qual é o estado de todas as tarefas no meu aplicativo?" O Visual Studio 2013 introduz melhorias às janelas Pilha de Chamadas e Tarefas para ajudá-lo encontrar as respostas para estas questões de forma muito mais intuitiva. Essas melhorias são aceitas para aplicativos de área de trabalho, Web e da Windows Store no Windows 8.1 e estão disponíveis para C++ e JavaScript também.

É comum ter chamadas de métodos aninhadas assíncronas em um aplicativo ou uma biblioteca, que contam com a palavra-chave await para gerenciar o fluxo de execução. Anteriormente, o Visual Studio não mostrava a cadeia de chamadas assíncronas quando parava em um ponto de interrupção em uma tarefa. O Visual Studio 2013 fornece uma exibição lógica e sequencial de métodos em uma cadeia aninhada de chamadas para métodos assíncrono e síncronos. Assim fica mais fácil entender como o programa chegou a um local dentro de uma chamada assíncrona.

A Figura 1 mostra um exemplo de código assíncrono. A Figura 2 e a Figura 3 demonstram a diferença entre as exibições de pilha de chamadas do Visual Studio 2012 e Visual Studio 2013 para esse código. Mais detalhes sobre este recurso podem ser encontrados no post “Depurando o código assíncrono no Visual Studio 2013 — aprimoramentos na pilha de chamadas” do blog bit.ly/19NTNez.

Figura 1 Exemplo de código assíncrono

private async void ShowSampleImg_Click(object sender, 
    RoutedEventArgs e)
{
  string imgUri = "http://example.com/sample.jpg";
  BitmapImage bitmap = new BitmapImage();
  bitmap.BeginInit();
  bitmap.StreamSource = await GetSampleImgMemStream(imgUri);
  bitmap.EndInit();
  sampleImg.Source = bitmap;
}
private async Task<MemoryStream> GetSampleImgMemStream(string srcUri)
{
  Stream stream = await GetSampleImage(srcUri);
  var memStream = new MemoryStream();
  await stream.CopyToAsync(memStream);
  memStream.Position = 0;
  return memStream;
}
private async Task<Stream> GetSampleImage(string srcUri)
{
  HttpClient client = new HttpClient();
  Stream stream = await client.GetStreamAsync(srcUri);
  return stream;
}

Figura 2 Janela de pilha de chamadas do Visual Studio 2012

Figura 3 Janela de pilha de chamadas do Visual Studio 2013

A janela Tarefas no Visual Studio 2013 é projetada para ajudar você a entender o estado de tarefas assíncronas em seus aplicativos, exibindo todas as tarefas atualmente em execução e programadas. Ela substitui a janela Tarefas Paralelas que estava disponível nas versões anteriores do Visual Studio. A Figura 4 mostra um instantâneo de uma janela Tarefas do Visual Studio 2013 para o exemplo de código da Figura 1.

Figura 4 Janela Tarefas do Visual Studio 2013

Editar e Continuar em x64 Esse foi um pedido de recurso depurador popular, com mais de 2.600 votos no site do Visual Studio UserVoice onde os usuários podem solicitar novos recursos (bit.ly/14YIM8X). Desenvolvedores têm adorado usar o recurso Editar e Continuar desde que foi apresentado com o Visual Studio 2005 e a versão .NET Framework 2.0, para projetos x86. Com o recurso Editar e Continuar fica mais fácil escrever o código correto permitindo que você altere o código-fonte durante uma sessão de depuração, enquanto o estado do aplicativo está disponível. Você pode até mesmo mover o ponteiro de instrução para poder reproduzir o código depois de fazer uma alteração. Ele proporciona uma experiência de desenvolvimento mais produtiva, porque você não precisa parar e reiniciar a sessão para validar as alterações.

O suporte do x64 para Editar e Continuar agora é habilitado com o Visual Studio 2013 e a versão .NET Framework 4.5.1. Você pode usar esse recurso para depurar aplicativos de área de trabalho (Windows Presentation Foundation, Windows Forms e assim por diante), aplicativos da Windows Store, aplicativos Web ASP.NET e projetos de Serviços em Nuvem do Windows Azure voltados para arquiteturas x64, AnyCPU ou x86.

Inspeção de Valor de Retorno Gerenciado O suporte do depurador para valores de retorno gerenciados é outro pedido popular com mais de 1.000 votos no site do UserVoice. O depurador do Visual C++ tem um recurso existente que permite que você observe os valores de retorno dos métodos, e queríamos a mesma capacidade para .NET também. Esse recurso é útil para muitos padrões de código. No entanto, você pode realmente ver seu valor com os métodos aninhados, como demonstrado na Figura 5. Com esse recurso, você não precisa mais se preocupar com o armazenamento dos resultados de seus métodos em locais exclusivamente para tornar a depuração mais fácil. Quando você faz a depuração parcial de uma chamada de método, os valores de retorno diretos e os valores de retorno dos métodos incorporados são exibidos na janela Autos juntamente com os valores dos parâmetros passados para as funções. Você também pode usar a janela Imediato para acessar o último valor de retorno pelo uso da nova pseudovariável $ReturnValue.

Figura 5 Janelas Autos e Imediato do Visual Studio 2013

Melhorias de Desenvolvimento da Windows Store Respondemos ao feedback e fornecemos suporte do .NET para os novos recursos Tempo de Execução do Windows (WinRT) para melhorar a experiência em desenvolvimento de aplicativos para a Windows Store no .NET.

Um dos pontos fracos foi a conversão de um Stream .NET em um IRandomAccessStream WinRT. No .NET Framework 4.5.1, adicionamos um novo método de extensão, AsRandomAccessStream, para o System.IO.Stream resolver esse problema. Agora você pode escrever o seguinte código, que permite fornecer facilmente um IRandomAccessStream:

// EXAMPLE: Get image from URL via networking I/O
var client = new HttpClient();
Stream stream = await client.GetStreamAsync(imageUrl);
var memStream = new MemoryStream();
await stream.CopyToAsync(memStream);
memStream.Position = 0;
var bitmap = new BitmapImage();
bitmap.SetSource(memStream.AsRandomAccessStream());
image.Source = bitmap;

Este código de exemplo lê uma imagem da Web e exibe em um controle de imagem XAML (representado pela variável "image").

Outra melhoria é a propagação de erro no Tempo de Execução do Windows. O Tempo de Execução do Windows, no Windows 8.1, permite que exceções passem entre os componentes do WinRT. Com esse suporte, uma exceção pode ser lançada a partir de um componente WinRT C++ e ser capturada em C# (ou vice-versa). Informações adicionais sobre a exceção estão agora disponíveis nas propriedades Message e StackTrace em System.Exception.

O Tempo de Execução do Windows também adicionou suporte para tipos de valor nulo em estruturas. Você pode construir componentes WinRT gerenciados que expõem estruturas com esse novo recurso, como neste exemplo de código:

public struct PatientRecord
{
  public string Name;
  public int Age;
  public string HomeAddress;
  // InsuranceID is nullable
  public int? InsuranceId;
}

Melhor desempenho dos aplicativos

O desempenho dos aplicativos é uma área de foco constante para a equipe do .NET Framework. Nesta versão, respondemos ao feedback sobre o coletor de lixo e melhoramos significativamente a inicialização de aplicativos ASP.NET.

Suspensão de aplicativos ASP.NET Esse recurso é um dos principais destaques do .NET Framework 4.5.1 devido ao ganho de desempenho significativo que ele proporciona, principalmente para cenários de hospedagem compartilhada, onde a densidade local e latência de inicialização são críticas. A suspensão de aplicativos ASP.NET permitirá que hosters compartilhados — empresas de hospedagem comerciais na Web ou sistemas de TI corporativos — hospedem muitos mais sites ASP.NET em um servidor com tempo de inicialização de aplicativo mais rápido.

A suspensão de aplicativos ASP.NET depende do IIS Idle Worker Process Page-Out, que é um novo recurso do IIS no Windows Server 2012 R2. O IIS Idle Worker Process Page-Out apresenta um novo estado "suspenso" além dos estados "inativos" e "ativos" existentes para sites. Esse novo estado "suspenso" libera recursos críticos usados pelo site para outros sites usarem, especificamente CPU e memória, enquanto ainda permite que o site seja retomado rapidamente.

A Figura 6 mostra as transições de estado de sites ASP.NET usando a suspensão de aplicativos. Um site começa no estado inativo. Ele é carregado na memória e muda para ativo com a primeira solicitação de página. Após um período de tempo ocioso, o site será suspenso, de acordo com a configuração do pool de aplicativos (bit.ly/1aajEeL). Após as solicitações subsequentes para o site, ele pode rapidamente retornar ao estado ativo. Esse ciclo pode acontecer muitas vezes. Até agora, os sites seriam encerrados e tornariam-se inativos após determinado período de ociosidade.

Figura 6 Transições de estado de sites ASP.NET

Não é necessária nenhuma mudança de código para usar esse novo recurso. A suspensão de aplicativos ASP.NET é habilitada automaticamente com a configuração de um pool de aplicativos do IIS para “suspender” no Windows Server 2012 R2.

Anteriormente, mencionei um "ganho de desempenho significativo" obtido com esse recurso, e eu gostaria de respaldar isso com alguns números provenientes de nossos laboratórios de desempenho. Fizemos experiências abrangentes de desempenho para mensurar o ganho de tempo de inicialização para "sair de uma suspensão" em comparação com "iniciar após encerrar". Fizemos essas experiências em um computador sob uma carga significativa de solicitações, acessando a uma grande quantidade de pools de aplicativos, com o intuito de recriar um ambiente de "hospedagem compartilhada". Os resultados mostraram uma redução de 90% no tempo de inicialização para os sites que foram acessados após a suspensão. Também mensuramos a melhoria da densidade do site. Conseguimos hospedar cerca de sete vezes mais sites ASP.NET no Windows Server 2012 R2 quando a suspensão de aplicativos ASP.NET estava habilitada. A Figura 7 mostra os resultados dessas experiências. Mais dados dessas experiências podem ser encontrados no post “ASP.NET App Suspend – responsive shared .NET Web hosting” no blog em bit.ly/17fI6dM.

Figura 7 Números de desempenho da suspensão de aplicativos ASP.NET vistos no laboratório do .NET

Melhorias de compilação JIT de vários núcleos Agora a compilação JIT de vários núcleos é habilitada por padrão para aplicativos ASP.NET. As medidas de desempenho mostram até 40% de redução no tempo de inicialização a frio com o JIT de vários núcleos ativado. Ele fornece benefícios de inicialização por meio da compilação JIT em vários núcleos, em paralelo à execução de código. Por debaixo dos panos, o JIT de vários núcleos foi estendido para suportar conjuntos carregados dinamicamente, que são comuns em aplicativos ASP.NET. O suporte adicional também beneficia aplicativos cliente, onde o JIT de vários núcleos continua a ser um recurso opcional. Mais detalhes sobre o recurso JIT de vários núcleos podem ser encontrados no post do blog do .NET Framework, “An easy solution for improving app launch performance”, em bit.ly/RDZ4eE.

Compactação LOH (Large Object Heap) sob demanda A compactação LOH é um requisito importante para alguns cenários, e agora está disponível nesta versão. Primeiramente, um pouco de contexto, pois você pode não estar familiarizado com a LOH. O coletor de lixo armazena objetos com mais de 85.000 bytes na LOH. A LOH pode ficar fragmentada e, em alguns casos, isso pode levar a tamanhos de heap relativamente grandes ou até mesmo exceções OutOfMemoryException. Essas situações, embora raras, ocorrem porque não há número suficiente de blocos de memória contíguos disponíveis na LOH para satisfazer uma solicitação de alocação, embora possa haver espaço suficiente no total.

Com a compactação LOH, você pode recuperar e mesclar blocos menores de memória não utilizados, tornando-os disponíveis para alocações maiores, o que permite um melhor uso global da memória do computador. Embora essa ideia soe atraente, o recurso não é destinado ao uso comum. A compactação LOH é um processo caro e pode causar longas pausas em um aplicativo, por isso só deve ser implantada em produção após análise e testes.

Uso mais fácil das bibliotecas NuGet do .NET Framework

Temos a intenção de fornecer versões do .NET Framework com mais frequência para disponibilizar novos recursos e correções mais rapidamente. Na verdade, isso já começou com o .NET Framework 4.5.1. Além disso, usamos o NuGet como um veículo de lançamento para fornecer nossos recursos de biblioteca e correções mais rapidamente em resposta ao feedback dos clientes.

O NuGet é um formato de pacote relativamente novo para o .NET Framework. Ele fornece um formato padrão para empacotar bibliotecas que têm como alvo um ou mais perfis .NET e pode ser consistentemente consumido por ferramentas para desenvolvedores, como o Visual Studio. NuGet.org é o repositório NuGet principal e o único usado pela equipe .NET. O Visual Studio vem com um cliente NuGet integrado para referenciar e usar pacotes NuGet em seus projetos.

Nos últimos anos, estamos fornecendo bibliotecas .NET em NuGet. Descobrimos que o NuGet é uma ótima maneira de fornecer bibliotecas para um grande número de desenvolvedores e várias plataformas .NET ao mesmo tempo. Melhoramos o NuGet UX no Visual Studio 2013 com base em amplo feedback, especialmente em cenários empresariais.

Melhor capacidade de descoberta e suporte oficial O feed da Microsoft e do .NET NuGet foi criado para melhorar a capacidade de descoberta de pacotes Microsoft. O NuGet.org hospeda milhares de pacotes, o que poderia dificultar a descoberta dos novos pacotes .NET entre todos os outros. Esse novo feed auxiliar oferece uma exibição de escopo dos pacotes oficiais da Microsoft e do .NET no NuGet.org. Pretendemos adicionar a esse feed somente pacotes que cumpram os mesmos requisitos de qualidade e suporte como o .NET Framework. Portanto, você pode usar esses pacotes em todos os mesmos lugares que você usa APIs .NET. Também criamos uma exibição na Web desse feed na página “Microsoft .NET Framework NuGet Packages” (bit.ly/19D5QLE), hospedada no blog do .NET Framework.

A equipe NuGet nos ajudou a viabilizar essa experiência atualizando seu cliente no Visual Studio para incluir a filtragem por feeds auxiliares. A Figura 8 mostra o cliente NuGet no Visual Studio 2013.

Figura 8 O cliente NuGet no Visual Studio 2013

Facilidade de manutenção Alguns clientes da empresa nos disseram que eles estavam esperando para adotar nossos pacotes NuGet até que a manutenção central fosse oferecida para essas bibliotecas por meio do Microsoft Update. Adicionamos esse recurso de atualização no .NET Framework 4.5.1, permitindo que os aplicativos aproveitem o novo recurso. O Microsoft Update será um veículo adicional de lançamento para bibliotecas .NET NuGet no caso improvável de que precisamos atualizar de forma rápida e abrangente uma biblioteca para resolver um problema de segurança crítico. Mesmo com essa nova opção implantada, vamos continuar a usar o NuGet como veículo principal para atualizações e correções da biblioteca.

Resolução automática de conflitos da versão Os aplicativos podem fazer referência a mais de uma versão de um pacote NuGet. Para aplicativos de área de trabalho e Web, você precisava resolver manualmente os conflitos de versão para assegurar que um conjunto consistente de bibliotecas fosse carregado no tempo de execução, o que pode ser difícil e inconveniente. Para resolver isso, o Visual Studio 2013 configura automaticamente os aplicativos para usar a versão mais referenciada de cada biblioteca, o que resolve o problema por meio de uma política simples. Também obedece à política já usada para os aplicativos do Windows Phone e da Windows Store.

O Visual Studio 2013 irá gerar automaticamente redirecionamentos de associação no app.config no momento da compilação se conflitos de versão forem encontrados no aplicativo. Esses redirecionamentos de ligação mapeiam cada uma das versões encontradas para determinada biblioteca para a versão mais alta encontrada. No tempo de execução, o aplicativo usará uma única versão – a mais alta referenciada – de cada biblioteca. A principal motivação desse recurso era proporcionar uma melhor experiência para o consumo de bibliotecas NuGet; no entanto, ele funciona para qualquer biblioteca. O tópico “Como habilitar e desabilitar o redirecionamento automático de associações” na Biblioteca do MSDN (bit.ly/1eOi3zW) fornece mais detalhes sobre esse recurso.

E muito mais...

Até aqui, eu resumi o que foi fornecido na versão .NET Framework 4.5.1. No mesmo período, fornecemos alguns novos componentes e recursos importantes por meio de outros veículos de lançamento também.

Pacote NuGet de bibliotecas para cliente HTTPA biblioteca para cliente HTTP fornece uma API .NET rede consistente e moderna. Ela permite que você escreva código intuitivo e assíncrono (usando a palavra-chave await) para acessar serviços expostos por HTTP com nomes de métodos que correspondem diretamente aos HTTP primitivos, como GET, PUT, POST e DELETE. Também oferece acesso direto a cabeçalhos HTTP e o corpo de resposta como qualquer um dos tipos String, Stream ou Byte[].

A princípio, o HttpClient só estava disponível para os aplicativos de área de trabalho .NET Framework 4.5 e da Windows Store. Os desenvolvedores de bibliotecas portáteis e aplicativos para o Windows Phone tinham de usar HttpWeb­Request e HttpWebResponse, com seu modelo de padrão assíncrono não baseado em tarefas (TAP). Com base na demanda popular de suporte para biblioteca portátil e Windows Phone, lançamos a versão portátil da biblioteca HttpClient em NuGet para preencher a lacuna da plataforma. Com isso, todos os desenvolvedores .NET têm acesso a HttpClient, com sua API TAP-async.

Após o lançamento das primeiras versões do pacote HttpClient NuGet, adicionamos a funcionalidade de descompactação automática ( bit.ly/13xWATe ) (bit.ly/13xWATe) em resposta ao feedback. A descompactação automática de respostas HTTP ajuda a minimizar os requisitos de dados, o que é útil não só em dispositivos móveis, mas também na percepção de desempenho na área de trabalho.

As bibliotecas para cliente HTTP em NuGet da Microsoft (bit.ly/1a2DPNY) foram amplamente adotadas, com mais de 1,3 milhão de downloads. Você pode usar este pacote em aplicativos destinados ao Windows Phone 7.5 e superior, Silverlight 4 e superior, .NET Framework 4 e superior, Windows Store e bibliotecas de classes portáteis (PCL).

Pacote NuGet de coleções imutáveis da Microsoft Esse é mais um pacote .NET popular, que fornece coleções imutáveis de alto desempenho fáceis de usar, como ImmutableList<T> e ImmutableDictionary<TKey, TValue>. As coleções imutáveis, uma vez construídas, não permitem modificação. Isso permite passar tipos imutáveis entre threads ou contextos assíncronos sem preocupação com operações simultâneas. Até o criador original da coleção não pode adicionar ou remover itens.

O .NET Framework tenha tipos de coleção somente leitura, como ReadOnlyCollection<T> e IReadOnlyList<T>. Esses tipos garantem que o consumidor não possa alterar os dados. No entanto, não há nenhuma garantia semelhante para o provedor. Isso pode causar o corrompimento dos dados, se o provedor e consumidor estiverem operando simultaneamente em diferentes threads. Com tipos de coleções imutáveis, você tem a garantia de que determinada instância nunca mudará.

O pacote NuGet de coleções imutáveis da Microsoft (bit.ly/18xhE5W) está disponível como biblioteca portátil e pode ser usado em aplicativos de área de trabalho e da Windows Store visando o .NET Framework 4.5 e superior, PCL e Windows Phone 8. Para saber mais detalhes, aconselho você a começar com o post “Immutable collections ready for prime time” (bit.ly/18Y3xp8) no blog do .NET Framework e a documentação do MSDN em bit.ly/189XR9U.

O novo compilador .NET JIT, RyuJIT O compilador JIT é uma das nossas principais áreas de investimento para melhorar o desempenho dos aplicativos. A equipe .NET anunciou recentemente a versão CTP do compilador JIT x64 de última geração, de codinome “RyuJIT”. O RyuJIT é duas vezes mais rápido na compilação de código em relação ao compilador JIT x64 existente, o que significa que os aplicativos que usam RyuJIT iniciam até 30% mais rápido dependendo da porcentagem do tempo de inicialização gasto na compilação JIT. (Observe que o tempo gasto no compilador JIT é apenas um componente de tempo de inicialização entre outros, assim, o aplicativo não é iniciado duas vezes mais rápido porque o JIT é duas vezes mais rápido.) Ao mesmo tempo, o RyuJIT não compromete a qualidade do código, e o compilador JIT moderno abre mais caminhos para futuras otimizações de qualidade de código.

Além dos ganhos de desempenho, o RyuJIT destaca o compromisso da equipe .NET da com o envolvimento dos clientes. Menos de um mês após o lançamento do CTP, lançamos uma versão atualizada que incorpora o feedback do cliente. Daremos continuidade ao nosso profundo comprometimento com os clientes e à cadência rápida de melhorias.

Começamos o RyuJIT com foco em x64 como parte da construção de uma plataforma em nuvem de primeira classe. Como a equipe avança, construiremos o suporte para outras arquiteturas. Você pode obter mais detalhes sobre o projeto RyuJIT e saber como baixar e usar o CTP no post “RyuJIT: The next-generation JIT compiler for .NET” do blog bit.ly/19RvBHf. Convido você a experimentá-lo e enviar-nos um feedback.

À procura de feedback

Neste artigo, forneci uma visão geral dos novos recursos da versão .NET Framework 4.5.1. A equipe .NET lançou muitos recursos importantes solicitados pelo cliente, juntamente com algumas surpresas inovadoras, como a suspensão de aplicativos ASP.NET e depuração com reconhecimento assíncrono.

Estamos moldando o futuro do .NET com projetos que muitas vezes se estendem por várias versões do .NET, em áreas-chave, como JIT, coleta de lixo e bibliotecas. Neste artigo, também forneci dados sobre um desses investimentos profundos, o novo compilador .NET JIT, o RyuJIT, que foi recentemente lançado como uma versão CTP.

Observe que a equipe .NET está ouvindo ativamente os feedbacks. Você pode acompanhar as novidades do .NET e dar feedback para a equipe usando os seguintes canais:

• Blog do .NET Framework (blogs.msdn.com/b/dotnet)
• Facebook (facebook.com/Dotnet)
• Twitter (twitter.com/DotNet)
• Email (dotnet@microsoft.com)
• Visual Studio UserVoice (bit.ly/K26kTu)
• Fóruns do MSDN (bit.ly/19cOuU3)

Gaye Oncul Kok é gerente de programa do CLR e do NET Framework na Microsoft, onde ela trabalha na equipe do ecossistema .NET.

Agradecemos aos seguintes especialistas técnicos da Microsoft pela revisão deste artigo: Habib Heydarian, Richard Lander, Immo Landwerth, Andrew Pardoe, Subramanian Ramaswamy e Alok Shriram
Richard Lander trabalha como gerente de programas na equipe .NET desde o .NET 2. Seus recursos .NET favoritos são genéricos e lambdas.

Immo Landwerth é gerente de programas da equipe do CLR na Microsoft e trabalha com a BCL do Microsoft .NET Framework, o projeto de APIs e as bibliotecas de classe portáteis.

Andrew Pardoe é gerente de programas da equipe .NET Runtime. Sua equipe é responsável por todos os aspectos do ambiente de execução virtual do .NET Framework.

Subramanian Ramaswamy é gerente de programas sênior da equipe .NET CLR. Ele entrou na Microsoft em 2008 e atualmente trabalha em estratégias de execução de código no tempo de execução. Ele é Ph.D. em engenharia elétrica e de computação do Georgia Institute of Technology e é autor de vários trabalhos apresentados em congressos e artigos da MSDN Magazine.

Alok Shriram é gerente de programas da equipe do Microsoft .NET Framework na Microsoft, antes ele trabalhava como desenvolvedor na equipe do Office 365. Ele trabalha na MEF (Managed Extensibility Framework), no DotNet Framework, nos pacotes NuGet e outras cortesias para desenvolvedores.