Configurar um Dev Drive no Windows 11

O Dev Drive é uma nova forma de volume de armazenamento disponível para aprimorar o desempenho das principais cargas de trabalho do desenvolvedor.

O Dev Drive baseia-se na tecnologia ReFS para empregar otimizações de sistema de arquivos direcionadas e fornecer mais controle sobre as configurações de volume de armazenamento e segurança, incluindo atribuição de confiança, configuração antivírus e controle administrativo sobre quais filtros estão anexados.

Consulte a postagem no blog: Unidade de Desenvolvimento para melhorias de desempenho no Visual Studio e Computadores de Desenvolvimento para obter algumas medidas médias de melhoria em operações comuns de desenvolvimento.

Como configurar um Dev Drive

Para configurar um novo Dev Drive, abra as Configurações do Windows e navegue até Sistema>Armazenamento>Configurações Avançadas de Armazenamento>Discos e volumes. Selecione Criar Dev Drive. *Antes de configurar um Dev Drive, verifique se os pré-requisitos foram atendidos. Você também pode configurar um Dev Drive usando a configuração de Computador do Dev Home.

Pré-requisitos

• Windows 11, Build n.º 10.0.22621.2338 ou posterior (Verificar se há atualizações do Windows)
• Recomendar memória de 16 GB (mínimo de 8 GB)
• Espaço livre mínimo em disco 50 GB
• Os Dev Drives estão disponíveis em todas as versões do SKU do Windows.

Ao atualizar para a última versão do Windows 11, talvez você precise de uma reinicialização adicional antes que o recurso de unidade de desenvolvimento fique disponível. Se você estiver trabalhando em um ambiente empresarial de negócios, o administrador da segurança precisará configurar a política de segurança da unidade de desenvolvimento para habilitar a unidade de desenvolvimento.

Aviso

O Dev Drive destina-se apenas aos principais cenários de desenvolvedor e as configurações personalizadas ainda serão cobertas pelas configurações de Política de Grupo em ambientes de trabalho Business ou Enterprise. Saiba mais sobre como Configurar a política de segurança da unidade de desenvolvimento.

Opções de configuração

Você receberá três opções:

1. Criar um VHD – Criar um volume em um novo disco rígido virtual
2. Redimensionar um volume existente – Criar um espaço não alocado no qual compilar
3. Espaço não alocado no disco – Usar o espaço não alocado em um disco existente. *Essa opção só será exibida se você tiver configurado espaço não alocado anteriormente em seu armazenamento.

Criar um VHD

Ao escolher a opção Criar VHD para configurar um Dev Drive, você precisará determinar o seguinte:

• Nome do disco rígido virtual: dê um nome ao VHD (Dev Drive).
• Local: atribua um caminho de diretório em que o VHD do Dev Drive estará localizado em seu computador. O local padrão é C:\, a menos que crie uma Unidade de Desenvolvimento usando a Página inicial para desenvolvedores, nesse caso, o local padrão é %userprofile%\DevDrives. É recomendável usar um local de caminho de diretório por usuário para armazenar sua Unidade de Desenvolvimento para evitar qualquer compartilhamento não intencional.
• Tamanho do disco rígido virtual: atribua a quantidade de espaço em disco que será alocada para o volume a ser utilizado; o tamanho mínimo é de 50 GB.
• Formato do disco rígido virtual:
  • VHD: suporta discos virtuais de até 2040 GB.
  • VHDX (Recomendado): suporta discos virtuais de até 64 TB de tamanho e oferece proteção mais resiliente contra falhas inesperadas de E/S (causadas por problemas como interrupção de energia). Saiba mais sobre gerenciamento VHDs.
• Tipo de disco:
  • Tamanho fixo – esse arquivo de disco rígido virtual é alocado para o tamanho máximo quando criado.
  • Expansão dinâmica - O arquivo de disco rígido virtual cresce até seu tamanho máximo à medida que os dados são gravados no disco. (Recomendado)

Depois de concluir o processo de seleção entre essas opções, o Dev Drive será criado.

Os volumes de armazenamento existentes não podem ser convertidos para serem um Dev Drive. A designação de Dev Drive ocorre somente no momento do formato original.

Redimensionar um volume existente ou usar espaço não alocado em um disco existente

Para redimensionar um volume existente:

1. Escolha um volume para redimensionar.

   

2. Escolha um novo tamanho para o volume. Você precisará ter pelo menos 50 GB de espaço não alocado disponível, o tamanho mínimo necessário para um Dev Drive. Depois que o tamanho for definido, selecione Avançar.

   

3. Para formatar um Dev Drive no novo espaço livre, especifique o Rótulo (nome da unidade), Letra da Unidade e Tamanho Local. O tamanho máximo será a quantidade de espaço livre alocado na etapa anterior, o tamanho mínimo para um Dev Drive é de 50 GB.

   

Parabéns! Você acabou de redimensionar o seu Dev Drive.

Para localizar e usar espaço não alocado em uma unidade existente, você pode abrir Sistema>Armazenamento>Discos e volumes e examinar a página para ver se algum espaço de armazenamento está listado como "Não alocado". Selecione Criar volume e você terá as opções para Criar Volume Simples (um volume de armazenamento NTFS padrão) ou Criar Dev Drive. Para criar um Dev Drive, as etapas são as mesmas acima, você precisará adicionar um Rótulo (nome da unidade), Letra da Unidade e confirmar o tamanho e o local.

Formatar um volume de armazenamento como uma Unidade de Desenvolvimento da linha de comando

Como alternativa ao uso de Configurações do Windows, há duas opções para criar volumes de armazenamento de Unidade de Desenvolvimento da linha de comando. Ambas as opções exigem que você abra a linha de comando como administrador. Você deve ser um membro do grupo de administradores para formatar um disco rígido. Esses métodos de formatação de linha de comando podem ser preferenciais ao criar várias Unidades de Desenvolvimento ou como administrador para vários computadores.

1. Usando a ferramenta de linha de comando Format do Windows CMD ou do PowerShell:

Format D: /DevDrv /Q

2. Usando o cmdlet Format-Volume do PowerShell:

Format-Volume -DriveLetter D -DevDrive

Esses exemplos de código exigem que você substitua D: pelo local da unidade que deseja direcionar. Confira os links para obter mais opções e parâmetros de comando.

Como o Dev Drive funciona?

Um Volume de Armazenamento especifica como os dados são armazenados no sistema de arquivos, por meio de diretórios e arquivos, em um formato específico. O Windows usa NTFS para a unidade do sistema e, por padrão, para a maioria das unidades não removíveis. O ReFS (Sistema de Arquivos Resiliente) é um mais novo sistema de arquivos da Microsoft, desenvolvido para maximizar a disponibilidade de dados, dimensionar de modo eficiente conjuntos de dados muito grandes em diversas cargas de trabalho e fornecer integridade dos dados com resiliência a corrupção. Ele procura lidar com um conjunto crescente de cenários de armazenamento e estabelecer uma base para inovações futuras.

O Dev Drive utiliza o ReFS, permitindo que você inicialize um volume de armazenamento especificamente para cargas de trabalho de desenvolvimento, fornecendo desempenho mais rápido e configurações personalizáveis otimizadas para cenários de desenvolvimento. O ReFS contém várias otimizações específicas do sistema de arquivos para aprimorar o desempenho dos principais cenários de desenvolvedor.

Saiba mais sobre como a Unidade de Desenvolvimento lida com a segurança.

O que devo colocar no meu Dev Drive?

O Dev Drive destina-se a:

• Repositórios de código-fonte e arquivos de projeto
• Caches de pacote
• Saída de build e arquivos intermediários

O Dev Drive não se destina a armazenar ferramentas de desenvolvedor, como:

• Visual Studio
• MSBuild
• SDK .NET
• SDK do Windows, etc.

Essas ferramentas devem ser armazenadas em sua unidade principal C:\.

Observação

Os administradores de TI desejarão criar pastas de ACL (Lista de Controle de Acesso) por usuário para dispositivos de vários usuários como uma prática recomendada para evitar ataques de EOP.

Armazenar o cache de pacote no Dev Drive

Um cache de pacote é o local da pasta global usado pelos aplicativos para armazenar arquivos para software instalado. Esses arquivos-fonte são necessários quando você deseja atualizar, desinstalar ou reparar o software instalado. O Visual Studio é um desses aplicativos que armazena uma grande parte dos próprios dados no cache de pacote.

• Cache npm (NodeJS): crie um diretório de cache npm em seu Dev Drive, por exemplo, D:\packages\npm; em seguida, defina uma variável de ambiente global npm_config_cache para esse caminho, por exemplo, setx /M npm_config_cache D:\packages\npm. Se você já instalou o NodeJS em seu computador, mova o conteúdo de %AppData%\npm-cache para esse diretório. (Em alguns sistemas, o cache do npm pode estar em %LocalAppData%\npm-cache). Saiba mais nos documentos do npm: npm-cache e npm config: cache.

• Pasta global-packages do NuGet: a pasta global-packages do NuGet é usada por dotnet, MSBuild e Visual Studio. Crie um diretório NuGet específico do usuário em seu sistema de arquivos CopyOnWrite (CoW). Por exemplo: D:\<username>\.nuget\packages. Use uma das seguintes maneiras de alterar a pasta global-packages do local padrão para a pasta recém-criada (para gerenciar os pacotes instalados globalmente):

  • Defina uma variável de ambiente global NUGET_PACKAGES para esse caminho. Por exemplo: setx /M NUGET_PACKAGES D:\<username>\.nuget\packages.

  • Para esse caminho, nas definições de configuração, defina globalPackagesFolder ao usar PackageReference, ou repositoryPath ao usar packages.config.

  • Defina a propriedade RestorePackagesPath do MSBuild (somente MSBuild) para esse caminho.

    Para verificar a pasta global-packages, execute o comando dotnet nuget locals: dotnet nuget locals global-packages --list. A restauração instalará e baixará pacotes no novo caminho. A pasta padrão global-packages do NuGet pode ser excluída. Saiba mais em Documentos do NuGet: gerenciando os pacotes globais, o cache e as pastas temporárias.

• Cache vcpkg: crie um diretório de cache vcpkg em seu Dev Drive, por exemplo D:\packages\vcpkg; em seguida, defina uma variável de ambiente global VCPKG_DEFAULT_BINARY_CACHE para esse caminho, por exemplo, setx /M VCPKG_DEFAULT_BINARY_CACHE D:\packages\vcpkg. Se você já tiver instalado pacotes, mova o conteúdo de %LOCALAPPDATA%\vcpkg\archives ou %APPDATA%\vcpkg\archives para este diretório. Saiba mais nos documentos do vcpkg: cache binário vcpkg.

• Cache pip (Python): crie um diretório de cache pip em seu Dev Drive, por exemplo D:\packages\pip; em seguida, defina uma variável de ambiente global PIP_CACHE_DIR para esse caminho, por exemplo, setx /M PIP_CACHE_DIR D:\packages\pip. Se você já tiver restaurado pacotes pip e do Wheels em seu computador, mova o conteúdo de %LocalAppData%\pip\Cache para esse diretório. Saiba mais nos documentos do pip: cache pip e confira o StackOverflow para Alterar o diretório do cache pip no Linux?.

• Cache cargo (Rust): crie um diretório de cache Cargo em seu Dev Drive, por exemplo D:\packages\cargo; em seguida, defina uma variável de ambiente global CARGO_HOME para esse caminho, por exemplo, setx /M CARGO_HOME D:\packages\cargo. Se você já tiver restaurado pacotes do Cargo em seu computador, mova o conteúdo de %USERPROFILE%\.cargo para esse diretório. Saiba mais nos documentos do Cargo: Variáveis de ambiente do Cargo.

• Cache Maven (Java): crie um diretório de cache Maven em seu Dev Drive, por exemplo D:\packages\maven; em seguida, defina uma variável MAVEN_OPTS de ambiente global para adicionar uma configuração a esse caminho, por exemplo, setx /M MAVEN_OPTS "-Dmaven.repo.local=D:\packages\maven %MAVEN_OPTS%". Mova o conteúdo de %USERPROFILE%\.m2 para este diretório. Saiba mais nos documentos do Maven e consulte o StackOverflow para Como especificar um local alternativo para a pasta .m2 ou settings.xml permanentemente?.

• Cache Gradle (Java): Crie um diretório de cache Gradle em seu Dev Drive, por exemplo, D:\packages\gradle. Em seguida, defina uma variável GRADLE_USER_HOME de ambiente global para apontar para esse caminho, por exemplo, use setx /M GRADLE_USER_HOME "D:\packages\gradle" na linha de comando para defini-la em todo o sistema. Depois de definir essa variável, o Gradle usará o diretório especificado (D:\packages\gradle) para seus caches e arquivos de configuração. Se você tiver arquivos Gradle existentes, mova o conteúdo de %USERPROFILE%\.gradle para esse novo diretório. Para obter informações mais detalhadas , consulte a documentação do Gradle e explore os recursos da comunidade, como o StackOverflow, para obter dicas sobre como gerenciar configurações e diretórios de cache do Gradle.

Noções básicas sobre riscos de segurança e confiança em relação ao Dev Drive

Segurança e confiança são considerações importantes ao trabalhar com arquivos de projeto. Normalmente, há uma compensação entre desempenho e segurança. O uso de uma Unidade de Desenvolvimento coloca o controle sobre esse equilíbrio nas mãos de desenvolvedores e administradores de segurança, com a responsabilidade de escolher quais filtros estão anexados e as configurações para verificações do Microsoft Defender Antivírus.

Os filtros antivírus, incluindo filtros antivírus Microsoft Defender e de terceiros, são anexados a uma Unidade de Desenvolvimento por padrão. O Microsoft Defender Antivírus usa como padrão a nova configuração de "modo de desempenho" em Unidades de Desenvolvimento, levando em conta a velocidade e o desempenho, ao mesmo tempo em que fornece uma alternativa segura às exclusões de pastas. Para um nível maior de proteção, o Microsoft Defender também oferece o "Modo de proteção em tempo real".

Qualquer produto ou recurso que exija filtros adicionais não funcionará, a menos que o filtro seja adicionado à Unidade de Desenvolvimento.

Aviso

As Unidades de Desenvolvimento podem ser executadas sem filtros de antivírus anexados. Tenha extrema cautela! Remover filtros de antivírus é um risco à segurança e significa que sua unidade de armazenamento não será coberta pelas verificações de segurança padrão. Você é responsável por avaliar os riscos associados à desanexação de filtros de antivírus e só deve fazê-lo quando tiver certeza de que seus arquivos armazenados na Unidade de Desenvolvimento não serão expostos a ataques mal-intencionados.

A Microsoft recomenda usar a configuração de modo de desempenho padrão ao usar uma Unidade de Desenvolvimento confiável.

O que é um Dev Drive "confiável"?

Os Dev Drives são designados automaticamente como confiáveis usando um sinalizador armazenado no registro do sistema durante o tempo de formatação original, fornecendo o melhor desempenho possível por padrão. Um Dev Drive confiável significa que o desenvolvedor que usa o volume tem alta confiança na segurança do conteúdo armazenado lá.

Semelhante a quando um desenvolvedor opta por Adicionar uma exclusão à Segurança do Windows, o desenvolvedor assume a responsabilidade de gerenciar a segurança do conteúdo armazenado para obter desempenho adicional.

Um Dev Drive marcado como confiável é um sinal para que o Microsoft Defender seja executado no modo de desempenho. Executar Microsoft Defender no modo de desempenho fornece um equilíbrio entre a proteção contra ameaças e o desempenho. A proteção em tempo real ainda será habilitada em todos os outros volumes de armazenamento.

Devido às considerações de segurança de ter filtros desanexados, o transporte de um Dev Drive entre computadores fará com que o volume seja tratado como um volume comum, sem políticas especiais de anexação de filtro. O volume precisa ser marcado como confiável quando é anexado a um novo computador. Confira Como designar um Dev Drive como confiável?.

Um Dev Drive não confiável não terá os mesmos privilégios que um confiável. A segurança será executada no modo de proteção em tempo real quando uma Unidade de Desenvolvimento não for confiável. Tenha cuidado ao designar confiança para um Dev Drive em outro momento que não quando ele é criado pela primeira vez.

Como posso designar um Dev Drive como confiável?

Para designar um Dev Drive como confiável:

1. Abra o PowerShell (ou CMD) com permissões elevadas, clique com o botão direito do mouse no ícone e selecione "Executar como Administrador".
2. Para designar o Dev Drive como confiável, insira o comando abaixo, substituindo <drive-letter> pela letra da unidade de armazenamento à qual você está designando confiança. Por exemplo, fsutil devdrv trust D:.

fsutil devdrv trust <drive-letter>:

Para confirmar se um Dev Drive é confiável, insira o comando:

fsutil devdrv query <drive-letter>:

A unidade C: em seu computador não pode ser designada como um Dev Drive. Ferramentas de desenvolvedor, como Visual Studio, MSBuild, SDK do .NET, SDK do Windows etc. devem ser armazenadas em sua unidade C:/ unidade e não em um Dev Drive.

O que é o modo de desempenho do Microsoft Defender?

O modo de desempenho agora está disponível no Windows 11 como uma nova funcionalidade do Microsoft Defender Antivírus. Essa funcionalidade reduz o impacto no desempenho de verificações do Microsoft Defender Antivírus para arquivos armazenados em um determinado Dev Drive.

Para saber mais sobre o modo de desempenho e como ele se compara com a proteção em tempo real, confira Microsoft Defender: Protegendo o Dev Drive usando o modo de desempenho.

Para que o modo de desempenho seja habilitado, o Dev Drive precisa ser designado como confiável e a proteção em tempo real do Microsoft Defender precisa ser definida como "Ativada".

Como configurar filtros de segurança adicionais na Unidade de Desenvolvimento?

Por padrão, o Gerenciador de Filtros desativará todos os filtros em um Dev Drive, com exceção dos filtros antivírus. Um filtro antivírus é um filtro anexado na faixa de altitude FSFilter Anti-Virus (ou seja, 320000-329999). FSFilter Anti-Virus inclui filtros que detectam e desinfetam vírus durante a E/S do arquivo.

A política padrão pode ser configurada para não anexar filtros de antivírus à Unidade de Desenvolvimento usando fsutil. CUIDADO: essa política se aplica a TODAS as Unidades de Desenvolvimento no sistema.

fsutil devdrv enable /disallowAv

O comando, fsutil devdrv enable [/allowAv|/disallowAv], inclui as duas seguintes opções:

• disallowAv: especifica que suas Unidades de Desenvolvimento não têm filtros anexados (nem mesmo antivírus). Os filtros podem ser adicionados novamente usando o comando fsutil devdrv setfiltersallowed <Filter-1>. (Substituindo <Filter-1> pelo nome do filtro desejado.)

• allowAv: especifica que as Unidades de Desenvolvimento devem ser protegidas pelo filtro de antivírus padrão.

Para obter ajuda, insira o comando: fsutil devdrv enable /?. Se nem /allowAv nem /disallowAv é especificado, a política de antivírus para a Unidade de Desenvolvimento não está configurada e o padrão do sistema é ter Unidades de Desenvolvimento protegidas pelo filtro de antivírus.

Aviso

Tenha extrema cautela ao desanexar filtros. Desanexar filtros antivírus é um risco de segurança e significa que o armazenamento não será coberto pelas verificações padrão do modo de desempenho ou proteção em tempo real do Microsoft Defender. Você é responsável por avaliar os riscos associados à desanexação de filtros de antivírus e só deve fazê-lo quando tiver certeza de que seus arquivos não serão expostos a ataques mal-intencionados.

Para saber mais sobre filtros, consulte Sobre drivers de filtro do sistema de arquivos, Instalar um driver de filtro, Conceitos do Gerenciador de Filtros, Grupos de pedidos de carga e altitudes para drivers de minifiltro.

Permitir que filtros selecionados se anexem na Unidade de Desenvolvimento

Se você estiver trabalhando em um ambiente empresarial ou corporativo, a política de grupo da sua empresa poderá ser configurada para determinados filtros serem anexados a Unidades de Desenvolvimento, além da política acima. Um administrador do sistema pode anexar filtros adicionais a uma Unidade de Desenvolvimento específica ou a todas as Unidades de Desenvolvimento usando uma lista de permissões.

Um administrador do sistema pode querer adicionar um filtro chamado "Foo"; vamos nos referir a ele como FooFlt. Talvez eles só queiram que o filtro seja habilitado na Unidade de Desenvolvimento montada como D:. Eles não precisam desse filtro em outro Dev Drive montado como E:. O administrador pode fazer alterações em uma lista de permissões de filtros no Dev Drive usando fsutil.exe, um utilitário de linha de comando fornecido pelo sistema.

Os filtros definidos especificamente como Permitido podem ser anexados a uma Unidade de Desenvolvimento, além da política de filtro de antivírus discutida acima.

Exemplos de filtro da lista de permissões

Os exemplos a seguir demonstram a capacidade de um administrador de definir filtros permitidos em todos os Dev Drives em um computador, usando uma lista de permissões.

Para usar o comando setfiltersallowed para permitir Filter-01 e Filter-02 em todos os Dev Drives, use o comando:

fsutil devdrv setfiltersallowed Filter-01, Filter-02

Para exibir a política de anexação de filtro para todos os Dev Drives, use o comando:

fsutil devdrv query

O resultado exibirá o seguinte:

• Os volumes do desenvolvedor estão habilitados.
• Os volumes de desenvolvedor são protegidos pelo filtro antivírus.
• Filtros permitidos em qualquer Dev Drive: Filter-01, Filter-02

Para alterar essa configuração de Dev Drive para permitir somente Filter-03 em seus Dev Drives, não permitindo mais que Filter-01 e Filter-02 sejam anexados, use o comando:

fsutil devdrv setfiltersallowed Filter-03

Confira fsutil devdrv /? para outros comandos relacionados.

Filtros para cenários comuns

Os seguintes filtros podem ser usados com o Dev Drive:

Cenário: descrição	Nome do filtro
GVFS: inscrições esparsas do Windows	PrjFlt
MSSense: Microsoft Defender para Ponto de Extremidade para o sensor EDR	MsSecFlt
Defender: filtro do Windows Defender	WdFilter
Docker: como executar contêineres fora da unidade de desenvolvimento	bindFlt, wcifs
Windows Performance Recorder: medir operações do sistema de arquivos	FileInfo
Monitor de Recursos: mostra o uso de recursos. Necessário para mostrar nomes de arquivo em Atividade de Disco	FileInfo
Monitor do Processo – Sysinternals: monitorar as atividades do sistema de arquivos	ProcMon24
Atualização do Windows: Usada durante a atualização do sistema operacional. Necessário se o usuário mover a variável de ambiente TEMP para a unidade de desenvolvimento	WinSetupMon

O WdFilter é anexado por padrão. O seguinte comando é um exemplo que demonstra como anexar todos esses filtros adicionais a um Dev Drive:

fsutil devdrv setfiltersallowed PrjFlt, MsSecFlt, WdFilter, bindFlt, wcifs, FileInfo, ProcMon24

Dica

Para determinar os filtros necessários para um cenário específico, talvez seja necessário marcar temporariamente um Dev Drive como não confiável. Em seguida, execute o cenário e anote todos os filtros anexados ao volume. Designe o Dev Drive como confiável novamente e adicione os filtros à lista de permissões para esse Dev Drive para garantir que o cenário seja bem-sucedido. Por fim, remova todos os filtros que podem não ser necessários, um de cada vez, garantindo que o cenário funcione conforme o esperado.

Dica

O nome do filtro do Monitor do Processo pode ser alterado. Se a adição do nome do filtro “ProcMon24” não parecer capturar as atividades do sistema de arquivos em uma unidade de desenvolvimento, liste os filtros usando o comando fltmc filters, localize o nome do filtro do Monitor do Processo e use esse nome em vez de “ProcMon24”.

Quais cenários não são compatíveis com o Dev Drive? Quais são as limitações?

Há alguns cenários em que não recomendamos usar um Dev Drive. Estão incluídos:

• Reformatar um volume de armazenamento existente para ser um "Dev Drive" destruirá qualquer conteúdo armazenado nesse volume. Não há suporte para reformatar um volume existente preservando o conteúdo armazenado lá.
• Quando você cria um VHD (Disco Rígido Virtual) hospedado em um disco fixo (HDD ou SSD), não é recomendável copiar o VHD, movê-lo para um computador diferente e, em seguida, continuar a usá-lo como uma Unidade de Desenvolvimento.
• Um volume armazenado em um disco removível ou conectável em funcionamento (como uma unidade externa USB, HDD ou SSD) não dá suporte à designação como um Dev Drive.
• Um volume em um VHD hospedado por um disco removível ou conectável em funcionamento não dá suporte à designação como um Dev Drive.
• A unidade C: em seu computador não pode ser designada como um Dev Drive.
• A finalidade de um Dev Drive é hospedar arquivos para criar e depurar projetos de software designados para armazenar repositórios, caches de pacotes, diretórios de trabalho e pastas temporárias. Não recomendamos instalar aplicativos em um Dev Drive.
• O uso da Unidade de Desenvolvimento nos Discos Dinâmicos não tem suporte. Em vez disso, use Espaços de Armazenamento, o que ajudará a proteger seus dados contra falhas de unidade e estender o armazenamento ao longo do tempo à medida que você adiciona unidades ao computador.

Como excluir uma Unidade de Desenvolvimento

Você pode excluir uma Unidade de Desenvolvimento nas Configurações do Sistema do Windows 11: System>Storage>Disks & volumes.

Abra o menu Configurações do Windows, escolha Armazenamento, Configurações Avançadas de Armazenamento e, em seguida, Discos e Volumes, onde você encontrará uma lista dos volumes de armazenamento no seu dispositivo. Selecione Propriedades, ao lado do volume de armazenamento da Unidade de Desenvolvimento que você quer excluir. Nas propriedades da unidade, você encontrará a opção Excluir, sob o rótulo Formatar.

A unidade de desenvolvimento agora será excluída. No entanto, se a Unidade de Desenvolvimento tiver sido criada como um novo VHD, o VHD precisará ser excluído para recuperar o espaço de armazenamento usado por esse VHD. Para fazer isso, você deverá desanexar o disco virtual para que o arquivo VHD que hospeda a unidade de desenvolvimento possa ser excluído, seguindo estas etapas:

1. Abra a ferramenta Gerenciamento de disco digitando "Gerenciamento do computador" na caixa de pesquisa na barra de tarefas. Selecione Gerenciamento de disco sob o título Armazenamento. Selecione o disco (não o volume) da unidade de desenvolvimento. Clique com o botão direito do mouse no disco selecionado que hospeda a unidade de desenvolvimento e, no menu resultante, selecione Desanexar VHD.
2. Uma janela pop-up aparecerá informando que desanexar um disco rígido virtual o tornará indisponível.
3. Uma vez desanexado, o VHD pode ser excluído.

Perguntas frequentes sobre Dev Drive

Algumas perguntas frequentes sobre o Dev Drive incluem:

Como personalizar um Dev Drive para atender às minhas necessidades?

As configurações padrão do Dev Drive foram otimizadas para cenários comuns de desenvolvimento, mas podem ser personalizadas, permitindo o controle sobre drivers e serviços executados no volume de armazenamento. Para personalizar as configurações do Dev Drive, abra o menu Configurações . Em Sistema>Armazenamento>Discos e volumes, acesse Propriedades.

Importante

Se estiver trabalhando para uma empresa ou empresa, o Dev Drive ainda será gerenciado pelas configurações da sua empresa. Algumas personalizações podem, portanto, ficar indisponíveis dependendo da política da empresa.

Preciso reinstalar meus aplicativos para usar um Dev Drive?

Não, aplicativos ou ferramentas instalados na unidade C: do computador podem utilizar arquivos de um Dev Drive. No entanto, para projetos de desenvolvimento, recomendamos armazenar diretórios, arquivos e caches específicos do projeto dentro do Dev Drive. O Dev Drive pode ser fixado no Acesso Rápido do Explorador de Arquivos como um lembrete.

O ReFS usa mais memória do que o NTFS?

Sim, o ReFS usa um pouco mais de memória do que o NTFS. Recomendamos um computador com pelo menos 8 GB de memória, idealmente 16 GB.

Posso ter mais de um Dev Drive em meu computador?

Sim. Se você tiver o espaço, poderá criar quantos Dev Drives desejar. O uso de um Dev Drive separado para cada projeto de desenvolvimento de software permitiria simplesmente excluir a unidade no final do desenvolvimento, em vez de reparticionar o disco novamente. No entanto, tenha em mente que o tamanho mínimo para um Dev Drive é de 50 GB.

O que preciso saber sobre como usar o Dev Drive com o Visual Studio?

Uma vez que você tenha criado uma Unidade de Desenvolvimento, o Visual Studio o reconhecerá automaticamente quando você estiver criando um novo projeto ou clonando um projeto existente e escolherá esse caminho de arquivo por padrão. Para otimizar o desempenho ao usar o Visual Studio, recomendamos mover para o Dev Drive qualquer código do projeto, caches de pacote e tarefas Copy on write do MS Build que podem ter sido salvos anteriormente em outro lugar. (Confira Como alterar o diretório de saída de build nos documentos do Visual Studio.) Também recomendamos que você considere redirecionar as variáveis de ambiente %TEMP% e %TMP% para o Dev Drive. Muitos programas usam essas variáveis, portanto, cuidado com possíveis efeitos colaterais. Também recomendamos usar o modo de desempenho para Microsoft Defender para ganhos de desempenho assíncronos usando o Dev Drive. Desativar o Microsoft Defender completamente pode resultar nos ganhos máximos de desempenho, mas isso pode aumentar os riscos de segurança e é uma configuração controlada pelo administrador do sistema.

Para obter mais informações, consulte a postagem no blog: Unidade de Desenvolvimento para melhorias de desempenho no Visual Studio e Computadores de Desenvolvimento.

O Dev Drive funciona com arquivos de projeto WSL?

Você pode acessar arquivos de projeto do Dev Drive, que são executados no sistema de arquivos do Windows, a partir de uma distribuição do Linux em execução por meio do WSL. No entanto, o WSL é executado em um VHD e, para obter o melhor desempenho, os arquivos devem ser armazenados no sistema de arquivos do Linux. O WSL está fora do escopo do sistema de arquivos do Windows, portanto, você não deve esperar ver nenhuma melhoria de desempenho ao acessar arquivos de projeto no Dev Drive de uma distribuição do Linux em execução por meio do WSL.

Qual método é usado para formatar um volume de armazenamento do Windows?

Confira MSFT_Volume class nos documentos do Windows Driver.

Como configurar e usar o Live Unit Testing com uma Unidade de Desenvolvimento?

Você pode encontrar diretrizes sobre Como configurar e usar o Live Unit Testing na documentação do Visual Studio. No entanto, lembre-se de que há uma dependência de ProjFS. Você precisará mover a raiz do workspace do Live Unit Testing para a Unidade de Desenvolvimento e adicionar o Sistema de Arquivos Projetado do Windows à lista de filtros permitida. Faça isso usando o seguinte comando no PowerShell:

fsutil devdrv setfiltersallowed PrjFlt

Um VHD criado para uso como uma Unidade de Desenvolvimento será criptografado quando a unidade que o armazena estiver habilitada para BitLocker?

Sim, o VHD da Unidade de Desenvolvimento será incluído na criptografia BitLocker do volume de hospedagem.

O Dev Drive pode tornar o desenvolvimento em Java mais rápido no Windows?

Sim, o uso de um Dev Drive pode aumentar a eficiência e reduzir os tempos de compilação ao trabalhar em um projeto de desenvolvimento em Java. Veja a postagem do blog "Acelere seu desenvolvimento em Java no Windows com o Dev Drive".

Como contribuir com esses documentos e perguntas frequentes?

Se você encontrar problemas nesta documentação ou quiser contribuir com sugestões de perguntas frequentes adicionais, visite o repositório de código aberto do Windows Dev Docs no GitHub.