DevDrive in Win 11 - Yay or nay?

When it comes to operating systems, Windows has been the most common OS used by software developers with a steady market share of around 60%. And with OS being the foundation for anything else within your setup it's crucial to get it set up right. Let's check out Dev Drive functionality that aims to make your projects feel and build snappier.

What is Dev Drive

According to Microsoft, Dev Drive is a virtual drive that aims to speed up file-related tasks. This makes it ideal for many daily development-related jobs such as building applications, installing packages, running test suites, transpilations and many more. Besides tweaking internal parameters in Windows, Dev Drives are built on the Resilient File System (ReFS). That system alone is hardly a novelty as it was introduced alongside Windows 8 over 11 years ago - times flies right? When launched it aimed to overcome problems that had become significant since NTFS was conceived. ReFS introduced a bunch of new features for virtualised and performance-sensitive workloads, making it also great for development purposes. According to Microsoft themselves and independent testers it provides around 30% better performance for overall build times compared to current, in-market Windows 11.

How to use it

Setting up Dev Drive is incredibly easy and well-covered by numerous tutorials online, including the official Microsoft documentation, so I'll not plan on taking up more internet storage for another recap. There are however a few tricks & tips to consider to make the most out of the refreshed drive.

Putting up the repositories on the Dev Drive is rather an obvious one - like, that's what this thing should be used for. But why stop there? Moving package manager directories and temp storage to Dev Drive is a pro move that will not only improve build times but also install and restore time.

Although tempting, I would not install your IDEs there. It can be done, but the important thing is that Dev Drives are excluded from Windows AntiMalware scans. It can improve the launch time, but truth be told, most of the time spent there is loading the repo anyway, not IDE files, thus the benefit may be smaller. An additional touch with Visual Studio is that starting with version 17.7 it will recognize if you have a Dev Drive created on your Windows machine and when you’re creating a new project, pick that filepath as a default one.

Another trick is utilising a functionality called Copy-on-Write. By using a ReFS feature called block cloning it avoids fully copying a file by instead creating a metadata reference to the original data on disk. By that, it optimises space used, but also it's much faster than the full copy procedure. To use that leverage all you have to do is to include Microsoft.Build.CopyOnWrite package to your .Net project.

<Project>
  <ItemGroup>
    <!-- <PackageVersion> elements here -->
  </ItemGroup>
  <ItemGroup>
    <GlobalPackageReference Include="Microsoft.Build.CopyOnWrite" Version="1.0.0" />
  </ItemGroup>
</Project>

Dev Home

Besides the Dev Drive, there is one more feature targeting software developers named Dev Home. The selling headline for it states that:

Dev Home is a new control center for Windows providing the ability to monitor projects in your dashboard using customisable widgets, set up your dev environment by downloading apps, packages, or repositories, connect to your developer accounts and tools.

That's great, a dashboard tool to check up on the state of your projects, repos and machines. However, it also doesn't give you anything over what you already can check out in properly set up Azure DevOps or Github. Having a persistent view of your CPU usage or fan speed is a nice quirk, but definitely not a novelty. SSH keychain viewer is also a nice touch if you happen to be a Win terminal user. Besides that, there is not much of the functionality there. It's a great concept, yet it feels like Microsoft is still figuring out what could be its utility. But in my case, I see one major drawback...

... it is just notoriously unstable. I'm constantly getting exceptions thrown for the machine state widgets and Azure DevOps tend to be really laggy to the point where I receive notifications faster through email than see changes in Dev Home. I'm sure the situation will get better with upcoming updates. All in all, great concept awaiting equal good execution!