C# Dev Kit 11.0: meça o projeto utilizável, não apenas a janela aberta
O pré-lançamento prioriza o arquivo ativo e reduz processos. Os ganhos de memória divulgados não representam toda a IDE.
A Microsoft reestruturou o C# Dev Kit 11.0, disponível no canal de pré-lançamento, não no estável.[18] A mudança combina caches de projeto, prioridade ao arquivo ativo, modelo de dados mais compacto e consolidação de seis processos gerenciados em um servidor nativo compilado com Native AOT.[18] Para desenvolvimento humano e com agentes, o resultado que vale medir é quando o projeto permite trabalhar, não quando a interface apareceu.
O que muda para quem desenvolve
Nos testes divulgados, a solução Orleans, com 155 projetos, teve o arquivo ativo pronto em 0,53 segundo e a solução inteira pronta em 2,3 segundos.[18] Em Aspire, com 407 projetos, os tempos foram 0,47 segundo e 3,0 segundos.[18] As comparações dependem dos cenários e do cache construído no primeiro carregamento.[18]
O artigo define arquivo ativo pronto como disponibilidade de completions, diagnósticos, navegação e correções; solução pronta acrescenta todos os projetos, descoberta de testes e referências globais.[18] A separação é uma boa ideia de medição: uma tarefa pequena pode não precisar esperar por tudo, mas outra depende da visão completa.
A memória dos processos do servidor caiu de 1.307 MB para 208 MB em Orleans e de 2.072 MB para 316 MB em Aspire.[18] Os números não incluem o serviço de linguagem Roslyn nem a memória do VS Code.[18] Portanto, não descrevem uma redução equivalente de toda a IDE.
Minha leitura é que priorização e eliminação de inicialização redundante são decisões mais transferíveis do que um percentual de benchmark. Ao avaliar sua ferramenta, defina qual capacidade precisa estar pronta para a tarefa e quais processos entram no consumo medido.
Como aplicar
Teste o pré-lançamento em um ambiente isolado com um repositório representativo. Prepare uma comparação entre a configuração atual e a nova, conservando máquina, solução e extensões auxiliares quando possível.
Registre separadamente:
- Primeiro carregamento, antes de existir cache.
- Carregamento posterior com cache.
- Tempo até navegar e obter diagnósticos no arquivo necessário.
- Tempo até descobrir e executar os testes relevantes.
- Build sem mudanças e build após uma alteração pequena.
- Memória total e memória por processo.
A proposta não pressupõe que os resultados do fornecedor serão reproduzidos. Também inclua correção funcional: uma ferramenta rápida que deixa de identificar um erro necessário não completou a tarefa.
A versão melhora edição de arquivos MSBuild e apresenta o C# Doctor para verificar SDK, runtime, framework alvo, restauração e vulnerabilidades.[18] Avalie essas funções com um problema ambiental controlado, registrando se o diagnóstico ajuda a localizar a causa.
Cuidados e limites
Os caches podem ser compartilhados por controle de versão para acelerar clones e worktrees, conforme a proposta da Microsoft.[18] Antes de adotar esse fluxo, confira o conteúdo gerado e sua política de versionamento. Não inclua artefatos automaticamente só porque aceleram uma demonstração.
O canal continua sendo de pré-lançamento.[18] Preserve uma forma simples de voltar à configuração anterior. O experimento útil combina tempo, memória e qualidade do trabalho entregue, sem vender uma métrica parcial como retrato de toda a experiência.
Fonte
[18] Fonte: Microsoft .NET Blog. Data/hora no feed: 06/10/2026 às 14:05:00.