Microsoft Dev Home - First Thoughts

Developers love to develop. Do you know what they mostly hate? Having to install and configure the universe (and keep in updated) to be productive, or figure out why their local build is taking so long.

Over recent years, Microsoft has put an increased focus on removing barriers for developers getting to their first commit.

We've been spoilt for choice with Windows Subsystem for Linux (WSL), Development Containers, GitHub Codespaces, and more recently, Microsoft Dev Box.

To this continuum of developer productivity we can now add Dev Home, which I am going to take for a bit of a test drive in this post.

What problem is Dev Home trying to solve?

This is an excellent question, and I think one that Dev Home is still working to answer.

Here's my thinking.

In my list of options above, I mention Dev Containers.

One of the joys of using Dev Containers is you can define all your Visual Studio Code extensions as part of your devcontainer.json configuration which means they will be reprovisioned for you whenever you spin up a new Dev Container. _ chef's kiss _

Now, you can run Dev Containers on Windows, but you need to run Docker Desktop or Podman, along with WSL, which for some folks is a lot of work they can't or want to undertake (remember: developers love to develop).

I think Dev Home is the beginning of Microsoft trying to deliver a Dev Container-like experience to Windows-based developers without all the Containers kerfuffle!

So, without any further delay, let's explore what Dev Home has to offer today!

Getting Started

You can grab Dev Home via a number of channels today:

Winget - I will get to this below! If you've never come across winget, fear not!
Update Windows 11 - as of September 2023 Dev Home will ship as part of Windows 11.

It looks like the Dev Home app has been removed from the Microsoft Store with the Windows 11 announcement, though this link still seems to work.

🔥Note: you'll need local Windows Adminstrator rights to perform a lot of the tasks.

Feature - Dev Drive

While it gets mentioned along with Dev Home, Drive Drive is actually a stand-alone capabilitity in Windows 11. It's designed to provide a high-performance virtual disk for key artifacts for developers - cloned source control repositories and build outputs. Don't install your tools like Visual Studio here though!

By using a virtual hard disk with a new file system (ReFS), along with a specific set of anti-virus settings, the goal of Dev Drive is boost performance of disk read/write operations - something that can be quite a bottleneck during build operations, especially in large solutions.

At time of writing I haven't had a chance to try this out as it requires a specific Windows 11 release which I am yet to get my hands on.

Feature - Dashboards

As it currently exists, this is probably the least interesting piece of Dev Home to me. Apart from the SSH keychain widget, everything else is one click away with Task Manager - a tool every developer on Windows should know. I honestly don't see a lot of value in doubling up on an existing Windows feature.

The GitHub extension has more value, though it will be a separate install going forward with Dev Home shipping with Windows. I am guessing this is to encourage other vendors to build their own extensions (a process which is fully documented).

I am also struggling with the disconnect between the Dashboad feature and what I setup on my machine. It's almost like Dashboard is a different app smushed into the Dev Home scaffold. It feels like there needs to be more of a relationship between a dashboard and a project you setup.

I think there should be a Dev Home artefact hierarchy (like below) that would allow you to source control your entire Dev Home experience. Change project? Get new dashboards, extensions and apps. 👍

.
├── .configurations
│   └── configuration.dsc.yaml
├── .devhome
│   ├── default.dashboard.yaml
│   └── extensions.yaml
└── src
    ├── WindowsARMViewer.sln
    └── ...

Next, let's talk about Dev Home's end-to-end setup feature.

Feature - End-to-end setup

This seems like the logical place to start with Dev Home. Perhaps when I open Dev Home after installation I should start on this?

This feature allows you to configure a source code repository and the software you need to work on the source code.

Let's take a walk through the process.

First we need to add a repository by selecting the "+ Add repository" button. You have two choices - use a source control extension or provide a direct URL for a repository you want to clone.

Today there is only one extension available, which is for GitHub. If you use it you can log into your GitHub account and then browse your repositories to clone.

If you don't use GitHub then you can clone a repository directly using a URL. At time of writing only HTTPS connections to source control are supported.

As an aside, you will already hit a chicken/egg situation here as you will need to have the appropriate source control client already installed.

I'm going to go ahead and authorise the extension for my GitHub account and then browse my repositories.

Note that you can add multiple repositories to clone in one setup flow.

Next you can select which applications you want to install. The list of applications is provided by Microsoft's default Windows Package Manager, but hopefully in future you'll be able to add a curated list of self-hosted applications too. Dev Home will filter this list based on what you already have installed, which is nice.

🔥Note: you'll need local Windows Adminstrator rights to perform some installs.

Finally, agree that you're licensed to use any applications you've selected to install and then hit setup.

⚠️ Thought: there is one big missing feature here - the ability to export this exact configuration so it can be shared or re-used, particularly given the new winget configure capabilities. This feature is already noted on DevHome's GitHub Issues list, so I think it will come eventually.

At this point, Dev Home will clone your repositories and install any applications.

Once repository cloning and app installations are finished you get a nice summary of activities performed.

Then your click Done... and nothing.

You've cloned your repository and installed your apps, then Dev Home seems to forget all about it.

Clicking on "Open Dashboard" just displays whatever you already had configured (in my case nothing).

I'm hoping this just an artefact of being in preview and is dealt with in a future release. You do all the work to install stuff then Dev Home just acts like you did nothing. 🙁

Next, up, the secret sauce!

Feature - Configuration file

Now, this one really caught my attention...

I have known many people who have uber-scripts that use PowerShell or Chocolatey to pre-configure new or reset Windows machines for developer use.

Winget, or the Windows Package Manager, has been with us for a while and can be used on Windows 10 or 11 by installing the App Installer Windows App.

When winget first launched it caused a bit of a storm as it seemed to land in the same space as the popular Chocolatey package manager which I am pleased to see is still going strong. It also seems that Dev Home already has a backlog item to add support for Chocolatey (and other) package managers in future.

I think the updates to Winget are the most important part of the launch of Dev Home, even though strictly speaking the updates are not directly a part of Dev Home.

If you've never used Winget previosuly, here's a basic example - installing Dev Home!

winget install --id Microsoft.DevHome -e

This is well-and-good for periodic, single installs. You could, theoretically write a script that simply invokes a series of winget calls. This is, however, brittle and becomes a hassle to maintain over time.

Introducing winget configure

This new winget capability - configure - allows you to build a defintion of everything you require to be installed and configured in a single YAML file. You can also set pre-requisites such as the Windows release required for installation to proceed, along with the series of Winget packages you'd like to install and any dependencies.

Here's a sample that installs PowerShell 7 on a Windows 11 machine.

configuration.dsc.yaml

# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2
properties:
  assertions:
    - resource: Microsoft.Windows.Developer/OsVersion
      directives:
        description: Verify at least Windows 11 22H2 installed
        allowPrerelease: true
      settings:
        MinVersion: '10.0.22621'
  resources:
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: pwsh
      directives:
        description: Install PowerShell
        allowPrerelease: true
      settings:
        id: Microsoft.PowerShell
        source: winget
  configurationVersion: 0.2.0

🔥Note: you'll need local Windows Adminstrator rights to perform some installs.

Now I can install any application and configuration listed using the configure command.

winget configure -f configuration.dsc.yaml

Microsoft has a series of examples already available that cover a range of different environments you might use. I've already started building out my own for future use, including how to get this running on Windows Server 2022 if you want to use a VM in Azure as a development machine.

You can also refer to an exported Visual Studio configuration file which defines the required installed workloads and setup for Visual Studio, which is great if you need to change between languages / application types for different solutions.

# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2
properties:
  assertions:
    - resource: Microsoft.Windows.Developer/OsVersion
      directives:
        description: Verify at least Windows 11 22H2 installed
        allowPrerelease: true
      settings:
        MinVersion: '10.0.22621'
  resources:
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: vs2022
      directives:
        description: Install Visual Studio 2022 Enterprise
        allowPrerelease: true
      settings:
        id: Microsoft.VisualStudio.2022.Enterprise
        source: winget
    - resource: Microsoft.VisualStudio.DSC/VSComponents
      dependsOn:
        - vs2022
      directives:
        description: Install required VS workloads from vsconfig file
        allowPrerelease: false
      settings:
        productId: Microsoft.VisualStudio.2022.Enterprise
        channelId: VisualStudio.17.Release
        vsConfigFile: '${WinGetConfigRoot}\..\.vsconfig'
        includeRecommended: true
  configurationVersion: 0.2.0

My hope is eventually Dev Home will automatically initialise your tools for you when you clone a repository. All you'd need to do is start defining configurations using YAML and add the file to your repositories using the convention Microsoft has published (create a top-level folder .configurations with a single file named configuration.dsc.yaml).

Submitting packages

If you build software and want to make it available for people to install, Microsoft has published the process required for your software to be included in the Windows Package Manager repository.

Alternative sources

There is the ability to define additional sources for Winget. It's important to consider the safety of third-party package providers, but you might want to create your own internal repository for use across teams.

To run your own package repository you would have to build a REST API conforming to the Winget spec. There's even a sample implementation you can review / reuse.

Finally, package your apps / installs as per the manfiest defintion.

Home is where the heart is

It's still early days for Dev Home, so I'm confident some of the challenges it currently has will disappear as it matures.

For me, winget configure is the immediate easy win, especially as you can source control it with your solutions. While it doesn't solve the age-old Admin privileges issue, it at least now gives you way to define what's required to work on a solution that lives with the source code and not in a "developer setup guide" that nobody maintains...

If you've been looking at Dev Home and have any thoughts, drop them in the comments below. I'll be keeping an eye on where Dev Home goes, and once I can, I'll be trying out Dev Drive.

Happy days! 😎

PS - I think Dev Home might be a good companion to Microsoft Dev Box as well.