Diving into Microsoft’s dev tunnels

One of Microsoft’s goals for recent releases of Windows was to improve the developer experience, with the aim of making it the preferred platform for modern application development. That goal has led to the release of the Windows Subsystems for Linux and Android, resilient Dev Drive storage based on the ReFS file system, the WinGet package manager, and the Dev Home control panel.

These tools help address many of the key issues that developers face, no matter what operating system they use. Together they support cross-platform development by helping you protect your code, manage your toolchain, and keep track of the resources used by your applications and tools.

Another key area is making development code available to remote users and devices, especially when you’re testing mobile and web applications. That brings us to Microsoft’s dev tunnels, which recently became available in Visual Studio 2022 and in Visual Studio Code (via the Remote – Tunnels extension). A dev tunnel command-line interface is also available for Windows, macOS, and Linux.

Ingress and dev tunnels

Ingress tools such as dev tunnels mix reverse proxies with an API and web gateway, tunneling into your development PC from external networks, while ensuring only the traffic you want pass through.

Access to local resources is essential when you’re building modern, cloud-native applications, working with remote RESTful APIs and providing their own APIs. It takes time to get network administrators to set up proxies on your firewall—time that gets in the way of ad hoc tests and demonstrations.

Instead, we can reflect access to debug code through a cloud service, using it to provide both a public IP address and, in some cases, a fully qualified domain name. These usually operate through a non-standard port, reducing the risk of an attacker connecting to a possibly buggy service.

Probably the best-known tool of this type is ngrok, which offers both free and paid plans. However, dev tunnels, recently introduced as part of Visual Studio 2022 v17.6, serves the same purpose. Initially designed as a debugging tool, dev tunnels exposes a specific port on your local machine to the public internet, so you can access it from other devices and services. You can even use it to provide demo access for stakeholders and customers, giving them insight into work in progress.

Perhaps the most significant benefit of a service like dev tunnels is that it allows you to work with real endpoints and APIs, rather than having to create mocks and use synthetic or sample data. Instead of spending time building and validating simulations, you can concentrate on writing code. This approach reduces the risk that your application will be designed around a buggy mock, along with making it far easier to test and debug code.

Getting started with dev tunnels

There are three ways to configure dev tunnels, from within Visual Studio 2022, from Visual Studio Code with the Remote – Tunnel extension installed, and from dev tunnels’ own command-line interface.

Setting up a dev tunnel in Visual Studio 2022 or in Visual Studio Code is relatively simple. In Visual Studio, you will find the dev tunnel management tools in the View menu, under Other Windows. Select ‘dev tunnels’ to open a list of available tunnels and click the plus sign to create a new instance.

Dev tunnels are associated with the account used to register Visual Studio, so can be either an Entra ID (what used to be Azure Active Directory) or a consumer Microsoft account (MSA). The latter is most likely for an individual using the Community edition of Visual Studio for personal or open-source development.

Start by naming your tunnel. You can build up a library of different combinations of tunnel names, types, and access controls that can be swapped in and out as necessary. Tunnels can be temporary or permanent, with temporary tunnels getting a new URL each time you start Visual Studio.

The final choice is to choose who has access. Private tunnels are tied to the ID of the user who created the tunnel, while Organizational tunnels are only for members of the same Entra group as the user. While you can create an Organizational scope for a tunnel with a consumer MSA, there’s really no point to doing so.

If you aren’t worried about who has access, or if you’re exposing a temporary tunnel to customers as part of a demo or a larger scale test, you could choose the public option. This doesn’t require authentication, so should be used only when you trust users or when the URL used will be recycled when the demo is complete.

Tunnel access is controlled via tokens. These can be accessed by right-clicking on the tunnel in the dev tunnels list, which copies them into the clipboard. Once you have a token and need to access a service, for example if you’re querying a RESTful service or a gRPC endpoint, you can add a temporary X-Tunnel-Authorization HTTP header to your call to authorize a client.

Using dev tunnels in Visual Studio or VS Code

To launch a tunnel from inside Visual Studio or VS Code, simply choose a tunnel to use from the application launch view, then build and run a debug session. This will open a local browser window that’s connected to the Microsoft-hosted endpoint for the tunnel. If you’re using an authenticated tunnel with a web application, you’ll be asked for credentials when accessing the generated URL. You can copy the tunnel URL and share it with colleagues as needed.

Scroll to the right of the Visual Studio Dev Tunnels window to manage your tunnel, clicking on the management icon. This shows the current connection for a tunnel, detailing the application that’s being tunneled and the port used. From this view click Inspect to launch an Edge-hosted network inspector as an additional debugging tool, to help understand how your code works with a browser or any other client.

Using the dev tunnels CLI

You’re not limited to using dev tunnels with Visual Studio, as they are also able to be managed using a CLI. This can be downloaded from Winget for Windows, and is also available for macOS and Linux.

CLI-based dev tunnels can even be created with GitHub accounts (if you install the separate GitHub tools) as well as Entra IDs and MSAs, allowing you to use GitHub device code logins as an alternative to the default browser-based authentication option. Once you’re logged in on the machine you want to host the tunnel, use the devtunnel host command to create a new tunnel. This command lets you choose a name for a tunnel, the ports it will forward, and whether anonymous access is allowed.

Once the tunnel is created, you’re presented with the tunnel URI, which can be copied and used in the code you’re testing or by a third-party. It’s possible to map ports as well, so an application that looks for an API on port 3000 can access a tunnel via that port. That’s because the underlying technology used by dev tunnels is based on SSH port forwarding, providing an easy-to-use front end to an often complex feature.

The CLI provides tools for managing your tunnels, including listing them, showing details of a specific tunnel, and creating persistent tunnels that can be used as part of client tests for mobile devices. There are more options in the CLI than in the Visual Studio counterpart. For example, using the CLI you can create tunnels that have a fixed life, or tag tunnels with descriptions that can be used to search for specific tunnels. Other commands add ports and protocols to a tunnel, letting you specify either HTTP or HTTPS.

The meter is running

Note there are limits to tunnel usage. An Enterprise subscription gives you 10 tunnels per user, with a bandwidth limit of 5 GB. Other limits control the number of supported connections and ports per tunnel, as well as request and transfer rates. That means you shouldn’t expect to be able to use dev tunnels for stress testing an application. Rather, they’re intended for feature and integration tests, as well as for quickly checking how your code looks on client devices.

Having an ingress proxy like dev tunnels in (and outside) Visual Studio should simplify constructing development toolchains. Up until now, if you were building and testing, say, Teams applications, you’d need to use ngrok or a similar third-party tool to link your development system to your organization’s Teams tenant. Now it’s simply part of your existing toolkit. Isn’t it nice when life gets simpler?