Treinamento
Certificação
Microsoft Certified: Azure Virtual Desktop Specialty - Certifications
在 Microsoft Azure 上为任何设备计划、交付、管理和监视虚拟桌面体验和远程应用。
Não há mais suporte para esse navegador.
Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.
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.
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. 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.
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.
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.
Você receberá três opções:
Há vantagens e compensações a serem consideradas ao escolher se deseja criar uma partição de disco ou criar um novo VHD para armazenar seu Dev Drive.
Crie uma partição de disco: armazenar seu Dev Drive em uma partição de disco geralmente oferece um desempenho mais rápido porque usa diretamente o disco físico sem camadas adicionais. As compensações são que o uso de um disco particionado será menos flexível, já que o redimensionamento de partições pode ser mais complexo e arriscado, e menos portabilidade, já que a partição está vinculada ao disco físico.
Criar um novo VHD: armazenar seu Dev Drive em um VHD (disco rígido virtual) pode ter um desempenho um pouco menor devido à sobrecarga de gerenciamento da camada de disco virtual. As compensações são que os VHDs oferecem mais flexibilidade para redimensionamento dinâmico (se você precisar gerenciar o espaço em disco com eficiência), mover ou fazer backup de dados. Os VHDs também são altamente portáteis, permitindo que o arquivo VHD seja transferido para outro computador ou local de backup. No entanto, tenha em mente que quando um VHD é hospedado em um disco fixo (HDD ou SSD), não é recomendado copiar o VHD, movê-lo para uma máquina diferente e continuar usando-o como um Dev Drive.
Ao escolher a opção Criar VHD para configurar um Dev Drive, você precisará determinar o seguinte:
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.Depois de concluir o processo de seleção entre essas opções, o Dev Drive será criado.
Para redimensionar um volume existente:
Escolha um volume para redimensionar.
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.
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 o espaço não alocado em uma unidade existente, abra Sistema>Armazenamento>Discos e volumes, e examine 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.
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.
Format D: /DevDrv /Q
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.
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 Dev Drive destina-se a:
Considerações sobre a instalação de ferramentas de desenvolvedor e SDKs no Dev Drive: as ferramentas de desenvolvedor e os SDKs normalmente são colocados em um local de administrador ou por usuário. Esses locais fornecem garantias específicas de segurança e isolamento no Windows e afetam o comportamento do Microsoft Defender. No entanto, muitas ferramentas oferecem a flexibilidade de escolher o local de instalação, incluindo um Dev Drive.
Antes de prosseguir com a instalação de ferramentas de desenvolvedor ou SDKs em um Dev Drive, avalie as compensações associadas ao sistema e à verificação assíncrona para garantir que ele esteja alinhado com os requisitos de segurança do seu dispositivo e organização. Você tem a opção de criar uma pasta de administrador ou por usuário no Dev Drive. Além disso, é importante verificar se o Modo de Desempenho do Microsoft Defender (por exemplo, verificação assíncrona) atende às suas necessidades de manipulação de binários.
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.
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. Depois de alterar as variáveis de ambiente, talvez seja necessário reiniciar todas as janelas abertas do console ou reinicializar o dispositivo para que os novos valores sejam aplicados.
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.
Observação
Atualmente, há um problema conhecido: o comando da ferramenta Dotnet não respeita o caminho dos pacotes nuget. A equipe do .NET está ciente e investigando uma correção para o .NET 10 e uma atualização de versão de manutenção para 8.0 e 9.0.
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"
. Mova o conteúdo de %USERPROFILE%\.m2\repository
para esse diretório (isso inclui apenas as dependências, plug-ins e outros artefatos que o Maven baixa na pasta repository
e usa para seus projetos). 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 documentação do Gradle e explore os recursos como StackOverflow para receber dicas sobre como gerenciar configurações e diretórios de cache do Gradle.
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.
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.
Para designar um Dev Drive como confiável:
<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: e não em um Dev Drive.
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".
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.
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.
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:
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.
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 |
Windows Defender Application Control (WDAC): acompanhamento do instalador gerenciado com serviços de identidade do AppLocker | applockerfltr |
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”.
Do Windows 11 24H2 & Windows Server 2025 em diante, a clonagem de bloco agora tem suporte no Dev Drive. Como o Dev Drive utiliza o formato de sistema de arquivos ReFS , o suporte à clonagem de blocos significará benefícios de desempenho gratuitos sempre que você copiar um arquivo usando o Dev Drive. Com a clonagem de blocos, o sistema de arquivos copia um intervalo de bytes de arquivo em nome de um aplicativo como uma operação de metadados de baixo custo, em vez de executar operações caras de leitura e gravação nos dados físicos subjacentes. Isso resulta em conclusão mais rápida da cópia de arquivos, E/S reduzida para o armazenamento subjacente e capacidade de armazenamento aprimorada, permitindo que vários arquivos compartilhem os mesmos clusters lógicos. Saiba mais sobre clonagem de blocos.
Há alguns cenários em que não recomendamos usar um Dev Drive. Estão incluídos:
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:
Algumas perguntas frequentes sobre o Dev Drive incluem:
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.
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.
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.
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.
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. Isso exigirá também a adição do filtro WinSetupMon
, que é necessário para o processo do Windows Update. (Consulte Filtros para cenários comuns. 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.
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.
Confira MSFT_Volume class
nos documentos do Windows Driver.
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
Sim, o VHD da Unidade de Desenvolvimento será incluído na criptografia BitLocker do volume de hospedagem. Não é necessário habilitar o BitLocker no VHD montado.
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".
O Modo de Desempenho do Dev Drive é especificamente um recurso do Microsoft Defender Antivírus relacionado à proteção em tempo real do Defender. Ao usar programas antivírus alternativos com o Dev Drive, o Modo de Desempenho não será aplicado, mas é possível ajustar a lista de permissões de filtros de segurança anexados ao Dev Drive para encontrar o equilíbrio certo entre desempenho e segurança para seu trabalho de desenvolvimento. Você precisará garantir que entende a função de quaisquer filtros anexados ao fazer alterações na lista de filtros anexados. Encontre uma lista com descrições em Filtros para cenários comuns.
Quando um Dev Drive foi montado, mas você esqueceu onde ele está localizado, os seguintes métodos podem ser usados para encontrá-lo:
Use o Dev Drive Insights no recurso de personalização do Windows do Dev Home.
Use o DiskPart e o comando "list vdisk" para mostrar o caminho completo para o vhdx: 1) Abra uma linha de comando e digite diskpart
, 2) Assim que abrir o DiskPart, digite list vdisk
.
Use o Powershell e "Get-Disk | Select-Object FriendlyName,Location]": Abra o PowerShell e digite Get-Disk | Select-Object FriendlyName,Location
.
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.
Comentários do Windows developer
O Windows developer é um projeto código aberto. Selecione um link para fornecer comentários:
Treinamento
Certificação
Microsoft Certified: Azure Virtual Desktop Specialty - Certifications
在 Microsoft Azure 上为任何设备计划、交付、管理和监视虚拟桌面体验和远程应用。