Assessing Microsoft Dev Box Cloud-Based Developer Workstationsv1.0

1. Executive Summary

This GigaOm Benchmark report was commissioned by Microsoft.

Microsoft Dev Box is a virtual desktop solution purpose-built for software development teams. Dev Box is equipped with a feature set designed to streamline the onboarding process for developers and expedite their path to productivity on projects. Using Microsoft Dev Box, developers can enjoy enhanced performance compared to developing locally, with scalable compute options and Premium SSD based storage ready to build projects of any size. Using the new Customizations for Microsoft Dev Box feature, teams can use a simple YAML configuration file to bring a newly deployed Dev Box to exactly the configuration the developer needs to be ready-to-code.

Our hands-on testing with Microsoft Dev Box shows that it delivers significant benefit over outfitting development teams with traditional laptops or VDI-served workstations. Our findings:

• Dev Box significantly improved developer productivity and reduced configuration time and IT overhead compared to VDI solutions.
• Developer typing experience felt as good as on a local machine, even over hotspot and public WiFi.
• Our testing revealed that a Visual Studio-equipped Dev Box setup produced better performance with the sample Chromium code base than VDI or local clients.

2. Introduction

Virtual desktops have paved the way for enhanced enterprise productivity in recent years. Their benefits include centralized management, facilitation of secure bring-your-own-device (BYOD) policies, and the simplification of corporate networking. However, there has been little advancement in the administration, automation, or defining of highly customized VDI solutions as Microsoft Dev Box provides —until now.

Security is a massive advantage of cloud-based developer workstations. Rather than publicly accessible databases and development environments, Dev Boxes keep all of your company’s proprietary data in a secure environment, with only the client connecting to the Dev Box via encrypted SSL traffic over port 443. Your source code, database, application binaries, and test data never leave the secure network. Data loss prevention is simplified as devices no longer need to be burdened with draconian protection software, which often significantly hampers performance. If a user is terminated or a contract is complete, there is no device to recover—the cloud desktop can immediately be shut off and, if necessary, the snapshots of its disk retained for forensic use.

We see an increasing drive for agility in organizing and deploying software development teams. Companies must be able to quickly onboard and re-allocate resources to new projects and minimize the time needed to achieve productivity. Additionally, as applications now run on numerous platforms and developers must support multiple versions, building software requires an ever-expanding suite of development tools and flexibility in the platforms used to build software. The need for agility is increasing, but development complexity is continuously pushing in the opposite direction and slowing down developer onboarding. A new tool set is needed to streamline onboarding and get new developers ready to code on projects.

While external DevOps pipelines, containerization, and ephemeral testing environments have paved the way for software integration testing once commits are pushed and merged, these technologies miss a fundamental aspect of software development: before merging, software is generally developed, built, and tested locally. There is a fundamental need for innovation focused on the developer experience for local development workflows. Developers need more resources, more flexibility, and more automation than a development environment on their laptops can offer.

Dev Box features highly scalable compute options that far exceed the capabilities of nearly every laptop on the market, and with support for GPU-enabled Dev Boxes expected in the future, these virtual workstations will soon be able to handle almost any type of development: from massive, CPU-intensive builds to GPU-driven AI/ML tools. In our testing, the largest Dev Box showed up to 64% faster software build performance than a median-spec physical device, as shown in Figure 1.

In this report, we are investigating Microsoft Dev Box, a cloud-based virtual desktop service focused on software development. A full suite of management features enables self-service provisioning for your developers, the ability to create project-specific dev box definitions and pre-populate developer tools, source code, and build caches. All of these features streamline the process for a developer to get started on a project or maintain multiple configuration versions in parallel.

Figure 1. Build Time in Seconds

3. Field Test Overview

New Developer Onboarding

The process of onboarding new developers involves several time-consuming tasks. Initially, setting up a new device—imaging, shipping, and configuring user accounts and permissions—can take administrators hours of work and days of delay before the end user receives their device.

Moreover, once they have the device, the subsequent steps of configuring access to the company’s shared resources, establishing VPN connections, installing necessary build tools, and syncing extensive source code repositories can take additional days to complete.

When this process is multiplied across various product teams, each with numerous developers, the collective time lost becomes fiscally significant. Streamlining these onboarding procedures is essential to minimize delays and meet development timelines.

Developing With Conflicting Configurations

Many programming languages support virtual environments to accommodate project-specific configurations or multiple versions installed in parallel. However, there are instances where certain dependencies or compatibility issues go beyond what standard virtual environments can manage. Operating system, patch-level, or SDK disparities might prevent versions from being built on a single device without significant reconfiguration.

When faced with such complexities, the ability to deploy multiple Dev Boxes in parallel can fundamentally shift how development teams test for hotfixes or conflicting configurations. Rather than contend with the limitations of a single device or relying on performance-inhibiting local virtual machines, deploying multiple Dev Boxes allows software to be built and tested in a fully isolated, distinct environment that can be tailored to specific versions, operating systems, or SDKs as required.

This approach significantly reduces the need for developers to repeatedly reconfigure their workstations to accommodate different project-specific configurations or to struggle with the administration of local virtual machines. With individualized Dev Boxes, developers can seamlessly switch between these isolated environments, enabling them to work on various projects with diverse technical requirements without encountering resource conflicts or performance degradation. This not only enhances efficiency but ensures a clean and isolated workspace for each project, removing the risk of interference between different configurations and minimizing the potential for errors stemming from conflicting versions.

Scaling Compute Resources for Intensive Project Builds

Dev Box allows you to deploy workstations with up to 32 vCPU, 128 GB of RAM, and 2 TB of storage on-demand for highly scalable builds. You can carry over the same ready-to-code configuration from smaller Dev Boxes to the new machine. This can be valuable if you need to iterate quickly on a mission-critical update or hotfix.

Temporary Employees and Contractors

Virtual desktop infrastructure (VDI) presents a compelling solution for businesses when managing contractors and third-party vendors compared to issuing physical devices. This technology offers numerous advantages in terms of flexibility, security, and streamlined access, catering to the specific needs and challenges that arise when collaborating with external entities.

Security is another crucial factor. Instead of granting access to sensitive company data on external devices beyond the organization’s direct control, virtual desktops enable a more secure approach. Contractors and vendors access a virtual desktop within the organization’s network, meaning sensitive data stays within the company’s secure environment. This centralized approach allows for stricter control, monitoring, and management of access, reducing the risk of data breaches or unauthorized use.

Security, Mobile Device Management, and DLP

Cloud-based desktops streamline and automate security best practices. As your proprietary data and application code never leave the secure cloud environment, it’s never at risk of being exfiltrated through a compromised device. Administrators can disable clipboard redirection and file sharing to the dev box using group policy, which can further segregate the Dev environment from the physical device used to access it. Microsoft Dev Box is built on top of Windows 365 and Microsoft Intune, which feature far more security options than mentioned here. For more information, see Intune Documentation.

Logging in to Dev Box automatically uses multi-factor authentication (MFA) based on the Azure Entra ID account (formerly Azure AD) assigned to the Dev Box. There is no additional setup required to enable MFA for Dev Box. The user account is preconfigured on the Dev Box for Microsoft 365 apps, and login requests are sent to the Microsoft Authenticator app, so the user does not even need to enter their password once logged into the Dev Box. Dev Box also allows developers to access their code from any device, including phones, tablets, and web browsers.

Using cloud-based development workstations reduces the attack surface area on your code bases and development infrastructure, as this infrastructure no longer needs to be publicly accessible. It need only be accessible to the virtual network you deploy for your Dev Box environment.

How quickly can you remove access to company data and resources from a terminated employee or contractor? If they have access to this data on a physical device, they may continue to have access after termination if the device is not connected to the internet or VPN to be disabled. This is a mobile device management (MDM) challenge that Dev Box simplifies, allowing for the immediate suspension of the developer’s environment while retaining backups for archival or discovery if needed.

In this Field Test, we measured the value we could achieve by using Dev Box to build a software project. We selected the open-source Chromium Project as our example application, as this represents a good example of a large-scale enterprise software project with numerous dependencies. Our specific tests address time to productivity and performance.

Time to Productivity

While the overhead of physical devices varies by organization, the imaging, shipping, and initial login and configuration tasks generally involve days of effort from both the device recipient and administration staff. Contractual requirements may also impose delays on shipping devices to third-party vendors and contractors, which can delay projects by weeks.

Keeping in mind this highly variable initial latency, our tests compare the setup time of Microsoft Dev Box to a new physical device once a developer receives it. We begin by configuring a Dev Box from the default image, where the only built-in time savings is the pre-installation of Visual Studio. We then create a custom image with our project source code and prerequisites built-in and measure the time savings possible with further automation.

Performance

To determine performance, we perform three clean builds of the Chrome browser on a number of Dev Box configurations and measure the average time on each. We compare those times against results on our physical device, which was sized to approximate the median device specs of clients running Visual Studio (according to telemetry data provided by Microsoft). That median target configuration features 4 cores, 8 threads running at 2.7 GHz, and 16 GB of RAM. The tested configurations are as follows:

• Physical device: 4 Cores, 8 threads running at 2.8 GHz, 32 GB RAM
• Similarly sized Dev Box: 8 vCPU, 32 GB RAM
• Medium Dev Box: 16 vCPU, 64 GB RAM
• Largest available Dev Box: 32 vCPU, 128 GB RAM.

Note: While not a one-to-one comparison, each physical CPU core with hyperthreading enabled is roughly comparable to 2 virtual CPUs or “vCPUs” that would be assigned to a virtual machine by the hypervisor. Therefore, a 4-core physical device with hyperthreading provides comparable performance to a Dev Box with 8 virtual CPU cores.

4. Field Test Report

Dev Box Deployment

We followed the Microsoft developer guide found here to configure our Dev Box environment. See the ‘Initial Dev Box Deployment’ section of the Appendix for a detailed view of our deployment configurations.

Once our Dev center, project, Dev Box definitions, and network connections were deployed, we were able to begin testing Dev Box deployment.

The Dev Box UI suggests that it takes between 25 minutes and 65 minutes to deploy a new Dev Box. The deployment time depends on a number of factors including the type of Active Directory and any customizations that need to be applied. In our testing, it took approximately 30 minutes for our Dev Boxes to become available. Additionally, support tickets needed to be submitted to increase available core count quotas for Dev Boxes in our testing regions, which have a four- to five-day SLA on basic support. This is useful to keep in mind if a large influx of developers is planned or your organization is running near the limit of your quotas. Microsoft plans to incorporate Dev Box into Azure Quotas for self-service quota increases in the future.

Once deployed, the Dev Box was indeed ready-to-code with Visual Studio 2022 Enterprise preinstalled. Our local workstation required us to download and install Visual Studio 2022. We did not simulate any enterprise management features on the local workstation, but we estimate at least one hour to configure the device and install Visual Studio. We deployed our dev box to automatically hibernate and measured a wake time of approximately three to five minutes to become available. It’s worth noting that while hibernated, you do not pay for the compute resources of your Dev Box, but you do pay for storage. Pricing for running Dev Boxes is calculated hourly and caps at 80 hours per month.

We then followed the build guide for Chromium on Windows found here. Downloading Chromium source code using depot_tools takes approximately two hours on all tested devices. See the Chromium Build process section of the appendix for more information. All performance testing is based on the Windows build of Chromium, but we also completed a Linux build using Windows Subsystem for Linux. Note that for internal source code, configuring permissions to the repository, package management, and other resources would require additional configuration time to achieve manually.

Compared to a physical device, a fully automated Dev Box deployment using Azure VM Image Builder and Customizations for Dev Box sharply reduces time on task. This can slash the setup time for a new user from six or more hours of configuration work, and potentially days of shipping lag, to being ready-to-code in under an hour with all of the tools, prerequisites, network access, and the latest source code available by default.

Figure 2. Dev Box vs Physical Device Setup Time

Configuring a Custom Image and Visual Studio Build Caching

We followed guides to set up custom images and configure Visual Studio caching (more information can be found on the Microsoft site here and here). For a detailed rundown of our testing, see the Custom Image Pipeline section in the Appendix.

We created an Azure Compute Gallery and then deployed a Windows 11 VM to create our custom image. We additionally tested an automated image pipeline using Azure VM Image Builder but found difficulty in getting all prerequisites and configurations to install without user input. A hybrid approach worked best—creating and sysprepping a starting image with prerequisites and frameworks installed, then using the pipeline to pull the latest source code for Chromium.

We reconfigured our Dev Box pool to use the new image from Azure Compute Gallery, which saves us the multi-hour process of installing prerequisites and downloading source code for each subsequent Dev Box deployed.

Configuring Visual Studio cache pre-population saves an astonishing 70%-plus on the time to open the chromium all.sln project on the mid-spec Dev Box, and nearly 80% on the 32 vCPU Dev Box. (See Figure 3)

Figure 3. Time to Open Chromium all.sln Project in Visual Studio

Dev Box Customizations
Dev Box team is soon releasing a feature called Dev Box customizations, which allows customizations to be defined in a YAML schema and run post-deployment for new Dev Boxes. The Dev Box customizations feature is available in private preview, which can be requested here.

Config-as-code customizations simplify management for IT teams, reducing the number of images organizations need to maintain, while giving developers the flexibility and control to update development environments. With customizations, admins can restrict the tasks and processes that are allowed to run with customizations, ensuring a safe and stable environment.

Performance Testing

We ran the Chromium build on our local workstation and each Dev Box configuration and recorded the build time. The physical machine built the project in 5.7 hours, marginally faster than the 8 vCPU Dev Box, which clocked in at 6 hours. The 16 vCPU Dev Box built the project in just over 3.8 hours, or 32% faster than the physical device. The 32 vCPU Dev Box built the project in just over 2 hours, producing a 64% performance gain compared to our physical device. For reference, the total size of the Chromium project source code is over 75 gigabytes.

RDP Performance

Our RDP testing was conducted in Denver, Colorado, where we connected to Dev Boxes deployed in West US 3 and East US 2. We tested using a variety of internet connections, including gigabit fiber, mobile hotspot (Verizon), and rate-limited public Wi-Fi. We measured the bandwidth usage and latency using metrics from the RDP client and the Connection Quality report from Microsoft Intune.

The mobile hotspot presented the highest 95th-percentile latency (122 ms round trip), while the public Wi-Fi gave us the lowest overall bandwidth (10 mbps). The minimum latency measured was through the gigabit fiber connection, which measured a 63 ms round trip to West US 3, and a 74 ms round trip to East US 2. The maximum measured bandwidth utilized by the RDP client was 34 mbps. In each of these cases, no significant performance degradation was measured when typing or performing typical software development tasks. Some visual artifacting was noticed on the rate-limited connection when a full-screen change was displayed, such as switching applications or minimizing to desktop, but these did not negatively impact the user experience.

Overall, Microsoft Dev Box has demonstrated like-local performance on a variety of connection methods, and is usable even on slow internet connections. Microsoft Dev Box additionally presents an inherent benefit to remote workers with slow or unreliable internet, as large source files or development environments don’t need to be downloaded to your local device — developing, building, and testing applications performs like you are in the datacenter.

Storage Performance

Microsoft Dev Box deploys with Premium SSD by default. We measured the performance of Dev Box using the DISKSPD utility. We tested this on the 32 Core Dev Box with 2048 GB SSD using a 200 GB test file. Read and write throughput were measured using a 128 K block size. IOPS were measured using a 50% read and 50% write workload and a 4 K block size. (Table 1)

Table 1: Premium SSD Performance Test

5. Conclusion

Our testing demonstrated a strong value proposition for utilizing Microsoft Dev Box to increase developer productivity.

Once configured, an organization can leverage these cloud-based virtual desktops to achieve massive improvements in developer productivity, innovation velocity, and reduction of logistics and physical device management.

In short, Microsoft Dev Box streamlines the onboarding and offboarding of developers from projects, enabling organizations to innovate faster with less toil. Administrators have total control over the security and management of the cloud-based developer workstations their developers deploy through Microsoft Intune. Security posture is further improved by all proprietary data remaining in the secure network—source code and test traffic never traverse the internet or exist on the developer’s physical device. And finally, with a like-local user experience, developers can enjoy improved build performance without any perceivable lag when typing or using applications such as Visual Studio.

6. Appendix

Hardware Specification

The Visual Studio team at Microsoft provided metrics for the median configuration for a developer workstation: 8 vCPU @ 2.7 GHz, 16 GB RAM, and 256 GB SSD.

We simulated this hardware specification using a local server running an Intel Xeon E-2378G (8 cores, 16 threads running at 2.8 Ghz). We deployed a Windows VM using Hyper-V to approach the 8 vCPU and 32 GB RAM of the target hardware specification.

Each of our Dev Boxes were created on Intel Xeon Platinum 8370C processors running at 2.8 Ghz, with max turbo clock of 4.00 Ghz. These processors have a total of 26 cores and 52 threads, of which our Dev Box uses only a subset.

Useful Links

• Dev Box FAQ: https://learn.microsoft.com/en-us/azure/dev-box/dev-box-faq
• Azure Hybrid Benefit Licensing: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/hybrid-use-benefit-licensing
• Azure Compute Gallery: https://learn.microsoft.com/en-us/azure/virtual-machines/azure-compute-gallery

Dev Box Pricing

Dev Box features usage-based pricing, which means you only pay for compute resources while they are running. Shut down and hibernated VMs do not incur compute costs, only storage.

Dev Box additionally lists the maximum price per month for each SKU on their pricing page: https://azure.microsoft.com/en-us/pricing/details/dev-box/

Dev Boxes reach the “maximum monthly price” after approximately 80 hours of use per month, per instance.

Table 2: Tested Configuration Pricing

Initial Dev Box Deployment

Step 1: Acquire Licenses
Dev Box requires the following licenses available to your Azure subscription:

• Microsoft Intune
• Microsoft Entra ID P1
• Windows 10 Enterprise or Windows 11 Enterprise

These licenses are included in a number of Microsoft 365 bundles, such as:

• Microsoft 365 F3
• Microsoft 365 E3, Microsoft 365 E5
• Microsoft 365 A3, Microsoft 365 A5
• Microsoft 365 Business Premium
• Microsoft 365 Education Student Use Benefit

We selected Microsoft 365 E3 for this benchmark, which was priced at $36 per month per user with a 12-month commitment.

Note that if you see the error in Figure 4, it is most likely a licensing issue and not a permissions issue.

Figure 4. A Common Licensing Issue can Produce a Status Warning

Step 2: Deploy a Dev Center
As of November 2023, Dev Box is available in the following regions: Australia East, Canada Central, Central India, East Asia, East US, East US 2, Japan East, Korea Central, North Europe, South Central US, UK South, West Europe, and West US 3.

We selected West US 3 and East US 2 for our test locations. Performance testing numbers within this report were gathered from the West US 3 testing location. Figure 5 depicts the user interface.

It’s important to note that Dev Centers can have a one-to-many relationship with Azure network connections, which function as the regions your Dev Boxes are deployed to. Dev Centers function as the administration front end for your projects, dev box definitions, environments, and networks.

Figure 5. Create a Dev Center Dialog Box

Step 3: Attach a Network Connection
We deployed a virtual network in each of the testing regions, as shown in Figure 6. For the purposes of our testing, the default values for the network and subnet were adequate, but for production deployments, additional configurations will be required. Dev Box requires the same connectivity as the Windows 365 service, which can be found here: https://learn.microsoft.com/en-us/windows-365/enterprise/requirements-network?tabs=enterprise%2Cent

Figure 6. Setting Up the Virtual Network

Next, we deployed an Azure network connection corresponding to each of these virtual networks. Our testing did not involve any on-premises Active Directory infrastructure, but if we intended to join to a hybrid environment, this would be the place we would configure the Active Directory connection.

Figure 7. Creating an Azure Network Connection

Once created, we added our network connections to our Dev Center through the Networking panel, as shown in Figure 8.

Figure 8. Adding a Network Connection to Azure Dev Center

Step 4: Create a Project
We created a project within our Dev Center. The creation page shown in Figure 9 allows you to set a limit on the number of Dev Boxes per developer on the project. This setting can also be enabled, disabled, or modified after deployment.

Figure 9. Create a Project in Dev Center

Step 5: Create a Dev Box Definition
Next, we define the Dev Box definition which includes the OS version, compute SKU, and storage, as shown in Figure 10. This is also where we will configure Dev Boxes to use our customized image later on.

Figure 10. Create the Dev Box Definition

There is an extensive list of images available by default, including numerous versions of Visual Studio on both Windows 10 and Windows 11. The screenshot in (Figure 11) shows the list.

Figure 11. List of Available Images

Our initial configuration testing started with the Visual Studio 2022 Enterprise on Windows 11 Enterprise image.

Step 6: Create a Dev Box Pool
To create a Pool, we first navigate to the specific project to create the pool under, then under the “Dev Box Pools” panel, create a new pool (shown in Figure 12). This associates a Dev Box definition, network connection, user privileges, and auto-stop configuration together.

Figure 12. Creating a Dev Box Pool

You must also assert here that you have valid Windows licenses for the Azure Hybrid Benefit (AHB). This is because Dev Box pricing only reflects the cost of the compute resources used, and Windows licenses are handled through Azure Hybrid Benefit. For more information on Dev Box licensing requirements, see here: https://docs.microsoft.com/azure/virtual-machines/windows/windows-desktop-multitenant-hosting-deployment

Step 7: Configure Access to the Pool
Our initial testing was conducted from our admin account, which has inherited user and administrative permissions to the pool. The IAM section of the Project allows you to granularly define permissions per-user as either a Dev Box User or Project Admin.

For more information on configuring project-specific settings, see the documentation here: https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal?tabs=delegate-condition

Step 8: Deploy a Dev Box
Log in to the Developer Portal here: https://devportal.microsoft.com

Once logged in, click “New Dev Box” and select from your available Dev Box Pools the dev box definition you wish to deploy.

After deployment, we were able to connect to our Dev Box through the browser or through Microsoft Remote Desktop app for both Mac and Windows.

Custom Image Pipeline

We began by following the documentation in Microsoft Docs: https://learn.microsoft.com/en-us/azure/dev-box/how-to-customize-devbox-azure-image-builder

However, many components we needed to install proved difficult to download and run unattended. We instead created a golden image from a VM, following the basic Azure Compute Gallery setup found here: https://learn.microsoft.com/en-us/azure/dev-box/how-to-configure-azure-compute-gallery

Chromium Build Process – Windows

For our tests, we follow the official Chromium build process for Windows, which can be found here: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/windows_build_instructions.md. We then add some additional context based on the Dev Box image.

Step 1: Installing Prerequisites
Windows 11 comes with a PATH entry added that automatically redirects you to the Microsoft Store to install Python. If you do not install Python through the Windows store, this PATH entry will remain above your new Python installation and prevent Python from working correctly. The following Powershell script removes the shortcuts to the Microsoft store and downloads and installs Python 3.12.0.

# Install Python
Remove-Item $env:USERPROFILE\AppData\Local\Microsoft\WindowsApps\python*.exe
Invoke-WebRequest "https://www.python.org/ftp/python/3.12.0/python-3.12.0-amd64.exe" -OutFile "C:\src\python-install.exe"
& "C:\src\python-install.exe" /quiet InstallAllUsers=1 PrependPath=1

We also need a few Visual Studio components that we can add through the Visual Studio installer:

$installer = "C:\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exe"
& $installer modify --installPath "C:\Program Files\Microsoft Visual Studio\2022\Enterprise" --add Microsoft.VisualStudio.Workload.NativeDesktop --add Microsoft.VisualStudio.Component.VC.ATLMFC --includeRecommended –quiet
[Environment]::SetEnvironmentVariable("PATH", $env:Path + ";C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE", "Machine")

Chromium on Windows also requires a specific version of the Windows SDK and debugging tools, so we download this from Microsoft and run the installer. Note: We are not sure if this direct link to the installer will change; this file can be found here: Windows 11 SDK version 10.0.22621.0

# Install Windows SDK
Invoke-WebRequest "https://download.microsoft.com/download/b/8/5/b85bd06f-491c-4c1c-923e-75ce2fe2378e/windowssdk/winsdksetup.exe" -OutFile "C:\src\winsdksetup.exe"
& "C:\src\winsdksetup.exe" /features + /q /norestart

Next, we configure our git settings:

git config --global user.name "My Name"
$ git config --global user.email "my-name@chromium.org"
$ git config --global core.autocrlf false
$ git config --global core.filemode false
$ git config --global branch.autosetuprebase always

Finally, we require the depot_tools package from the Chromium Project, as well as a number of environment variables.

# Install Depot_Tools
Invoke-WebRequest "https://storage.googleapis.com/chrome-infra/depot_tools.zip" -OutFile "C:\src\depot_tools.zip"
Expand-Archive -Path "C:\src\depot_tools.zip" -DestinationPath "C:\src\depot_tools" -Force
[Environment]::SetEnvironmentVariable("PATH", $env:Path + ";C:\src\depot_tools", "Machine")
$env:Path = $env:Path + ";C:\src\depot_tools"
[Environment]::SetEnvironmentVariable("DEPOT_TOOLS_WIN_TOOLCHAIN", 0, "Machine")
$env:DEPOT_TOOLS_WIN_TOOLCHAIN=0

Step 2: Download Chromium Source

Set-Location C:\src\
mkdir chromium && cd chromium
fetch chromium
gclient sync
cd src

This download process takes multiple hours to complete.

Step 3: Build Chromium

We use gn to generate our build targets, configure ninja to generate a performance report of our build, and then use ninja to build the chrome executable.

gn gen out\Default
gn gen --ide=vs out\Default
$env:ninja_summarize_build=1
autoninja -C out\Default chrome

Chromium Build Process – Linux

Windows 11 on Microsoft Dev Box includes full support for Windows Subsystem for Linux. We installed Ubuntu under WSL and were able to successfully build Chromium for Linux. We followed the chromium build documentation for Linux here: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux/build_instructions.md

~$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
~$ export PATH="${HOME}/depot_tools:$PATH"
~$ mkdir ~/chromium && cd ~/chromium
~/chromium$ fetch --nohooks --no-history chromium
~/chromium$ cd src
~/src$ ./build/install-build-deps.sh
~/src$ gclient runhooks
~/src$ gn gen out/Default
~/src$ export ninja_summarize_build=1
~/src$ autoninja -c out/Default chrome

7. About Eric Phenix

Eric Phenix is Engineering Manager at GigaOm and responsible for our cloud platforms and guiding the engineering behind our research. He has worked as a senior consultant for Amazon Web Services, where he consulted for and designed both systems and teams for over 20 Fortune 1000 enterprises; and as cloud architect for BP, where he helped BPX Energy migrate their process control network from on-premises to AWS, creating the first 100% public cloud control network, operating over $10 billion in energy assets in the Permian Basin.

8. About GigaOm

GigaOm provides technical, operational, and business advice for IT’s strategic digital enterprise and business initiatives. Enterprise business leaders, CIOs, and technology organizations partner with GigaOm for practical, actionable, strategic, and visionary advice for modernizing and transforming their business. GigaOm’s advice empowers enterprises to successfully compete in an increasingly complicated business atmosphere that requires a solid understanding of constantly changing customer demands.

GigaOm works directly with enterprises both inside and outside of the IT organization to apply proven research and methodologies designed to avoid pitfalls and roadblocks while balancing risk and innovation. Research methodologies include but are not limited to adoption and benchmarking surveys, use cases, interviews, ROI/TCO, market landscapes, strategic trends, and technical benchmarks. Our analysts possess 20+ years of experience advising a spectrum of clients from early adopters to mainstream enterprises.

GigaOm’s perspective is that of the unbiased enterprise practitioner. Through this perspective, GigaOm connects with engaged and loyal subscribers on a deep and meaningful level.

9. Copyright

© Knowingly, Inc. 2024 "Assessing Microsoft Dev Box Cloud-Based Developer Workstations" is a trademark of Knowingly, Inc. For permission to reproduce this report, please contact sales@gigaom.com.