Connect(); Special Issue 2018

Volume 33 Number 13

[Visual Studio]

Collaborative Development with Visual Studio Live Share

By Julie Lerman; Special Issue 2018

I hope I’m not embarrassing myself to express how excited I am by Visual Studio Live Share! The first time I saw a demonstration of an early preview, I immediately found an excuse to use it in a live streaming session where Jeff Fritz and I worked on a .NET Core project together, each on our own computer, nearly 400 miles apart.

Live sharing is not a screen-sharing session, of the sort I use to help non-techie friends when they’re confounded by some software on their computer. Jeff was coding on his computer in Visual Studio in Windows while I worked on the same code on my MacBook in Visual Studio Code. What he typed, deleted or debugged, showed up in my code. Whatever I did to affect the code appeared in Visual Studio on his machine. When he opened a file in Visual Studio, that file opened up in Visual Studio Code on my machine. Yet we had our own cursors, and could work both together and independently.

Sounds magical? I thought so, too. So I have really dug in further with my usual battery of “what-if” questions and learned so much more about this incredible new tool. Let’s take a look.

Under the Covers

Once you’ve authenticated for a session using either your Microsoft or GitHub credentials, Live Share attempts to connect with other developers in a peer-to-peer fashion, but will fall back to an Azure relay if necessary. When collaborating with an external participant, this happens through Azure and it does mean you need to be on the Internet. To provide guests with full access to your solution, without actually requiring you to upload any of your code, Live Share communicates only the file system structure of your project to others. When someone opens a file, it sends the file contents. As changes are being made, it sends the character differences. When debugging, it sends debug steps and debug state. Shared testing is coming in the near future. Live Share collects that data coming in and displays it in your IDE. It can respond to a collaborator opening files and automatically open that file in another’s IDE. But because you may want to edit different files at the same time, you can disable that automatic file switching.

Collaboration Game Changer

This experience is so many times better than having a client show me their code on a screen-share session in Skype. I live on a mountainside with limited Internet speed, and the fact that Live Share  transmits only text file contents and minimal data when edits are being made means sharing can be much faster than transmitting entire screen images across the Internet. Moreover, when working with others over Skype, I have to constantly ask, “Can you click on this,” or, “Scroll to that,” or, “What happens if you change that code on line … oh wait, can you open settings and get line numbers to show?” Even if I use a tool that allows me to control their mouse, such as LogMeIn, it’s cumbersome. There are always latency issues, and working in someone else’s IDE is not always fun. They often have things set up differently. Sometimes their color schemes make it hard for me to see. Or their fonts are too small. All of these things get in the way of smooth, effective collaboration. This has been my experience for years collaborating with or coaching developers and teams without having to get on a plane. I’m sure for any of you with distributed teams, it all sounds much too familiar.

This is why I’m so excited by what Live Share can do. Whether I’m doing code reviews, helping someone solve a “works on my machine but not theirs” problem or doing pair programming with someone, Live Share is an enormous game changer. And it’s not just me having this reaction. You might find the #vsliveshare hashtag on twitter to be entertaining as you scroll through tweets by developers as they are first discovering it.

Live Share can be used with a wide variety of languages and platforms. I’ve even used it with an old .NET 4 WinForms solution that uses VB.NET! The language support is broader for VS Code than Visual Studio, but in Visual Studio you can use C#, VB.NET, F#, C++, Python and more. Check out the Language and Platform Support page at bit.ly/2Oqjds3.

But enough teasing—let’s take a look at how to work with Live Share. I’m going to demonstrate using multiple instances of Visual Studio on a single computer so you can follow along if you’d like without having to find a collaborator right away. And it’s a great way to practice and explore the features on your own.

Activating a Live Share Session

Live Share is currently available as an extension for Visual Studio Code and Visual Studio 2017, although it will be a built-in feature of Visual Studio 2019. As an extension, it’s still called a preview. I’ll focus on the experience in Visual Studio 2017.

Live Share is, by default, associated with your Visual Studio login and the extension adds indicators next to your login information and avatar in the UI (see Figure 1).  The Live Share button lets you activate a session and requires that you already have your target solution, project or folder open in Visual Studio. You can also initiate a session from the File menu. Once you click it, the text will change from “Live Share” to “Sharing.”

Figure 1 The Live Share Button Lets You Activate a New Live Share Session

The first time you activate Live Share in Visual Studio, it will alert you to the fact that it’s defaulting to collaborating through a local network connection and that you’ll be prompted to allow relevant firewall settings. If you choose to deny opening those ports, it will change its behavior to route all of the connections—even those on the same network—through Azure instead. This is something you can change as needed down the road.

Why would you need it for a local network connection? It turns out that Live Share is already being widely adopted by teams that are co-located. Imagine being able to help someone on your team with a quick problem with only a minor interruption to your workflow. When pair programming with someone, you’re usually both hovering over one keyboard and one screen, and elbow room can be an issue. When teams are mob programming, everyone’s looking at a projected screen from one computer. Instead, you could sit side by side (or across the hall or on another floor) and still work together but with each developer looking at an IDE set up the way they like, allowing each user to truly participate. When it’s time to switch hands on a keyboard, although the action of physically moving into “driver” position has a lot of merits, it’s a lot easier and again, nobody has to work on an unfamiliar machine with an environment that might be awkward for them.

After initiating the session, the very next thing you’ll see is a yellow bar below the menu, as shown in Figure 2, telling you that the invitation link has been copied to your clipboard so you can share with any guests. This is a good reminder that the person whose code is to be worked on is the one who needs to initiate the session. You can’t switch directions in the same way you may be used to with screen sharing.

Figure 2 The Information Bar Displayed upon Starting a Live Share Session

A “More info” link opens a window with some Getting Started information about Live Share.

Amazingly, you can invite up to five people to your session. However, this can be potentially chaotic, but you can control who can interact with the code and who can only view what’s happening. A separate link makes the collaboration session read-only to a guest.

The invitation link is a URL that you can either paste into a browser or directly into Visual Studio under the File | Join Collaboration session menu option. If you’re a guest using a browser, you’ll be brought to a Web page showing the identity of the user that created the invitation and a pop-up window prompting you to open the “Pick an app” Windows interface. From there you can select either Visual Studio or Visual Studio Code, and the chosen IDE will open and set up the Live Share session. As a guest, you’ll see indicators next to your account showing that you’ve joined a session with, in this case, “JL” (see Figure 3). The solution, project or folder shared through the link will be open in Solution Explorer. In my Solution Explorer, I can see that the code that was relayed to my machine is temporarily stored in a folder inside C:\Users\Julie\AppData\Local\Temp\. Note that only the file structure and code files have come across. When I look in the temp folder, I see no .csproj or .sln files. And building leaves no bin or debug in the temp folder. Even if you change the defaults and allow guests to trigger a build, that build happens on the host. It’s all about displaying the files on the guest, not recreating the solution or projects.

Figure 3 Visual Studio Showing That It Has Joined a Live Share Session with JL

On the Web page that opened from the invitation link, there are also links for guests to install the extension to either of these IDEs if they don’t already have it. I like that it’s this simple and discoverable, so you don’t need to send lots of instructions along with the link.

And as mentioned earlier, you don’t need to use the same OS or IDE that initiates the session. I have both Visual Studio 2017 and VS Code on my Windows machine. I’ll use Visual Studio 2017 as an invited collaborator. Notice that I’m playing both host and guest. You can do this with multiple instances of Visual Studio or VS Code on the same machine, which is a great way to get familiar with Live Share. Note that currently there’s no Live Share extension for Visual Studio for Mac.

Once connected, a guest machine will have some bling added to its UI, including an icon, referred to as a badge, with the initials of the host. That’s the blue circle in Figure 3. (I’ll explain the ring around the circle shortly.) The Live Share button indicates the guest has Joined a session. The Live Share button on my host instance of Visual Studio has a “Sharing” dropdown similar to the “Joined” dropdown in Figure 3. It also shows a prompt telling me that a guest has joined the session and I can accept or reject this connection. I’ve clicked OK to accept it. When using two instances of Visual Studio on one computer, you can’t have two different Visual Studio login identities, so I’ll be Julie Lerman with a blue JL badge in both instances.

By default, the guest will follow the host wherever the host wanders in the solution. So, if I open up the program.cs file in the host instance, that file opens in the guest’s IDE. But if the guest opens up a different file, that file won’t automatically open on any other participant’s IDE. This behavior is controlled by actions in the Live Share button dropdowns, as well as the badge. The dropdowns—Joined or Sharing (Figure 4) both have a “Focus Participants” option. When that’s selected, the other participants will be notified that they’ll now follow the focus of that collaborator. Notice the extra ring around the blue badge in Figure 3. This indicates that this IDE is following the other collaborator. You can click the badge to toggle the focus on and off. This is super handy when your collaboration changes from, “Let’s work together on the same file,” to, “Oh, wait, can you go check out a different file to copy some text?”

Figure 4 The Sharing Menu Dropdown with Host-Specific Options

But the dropdown and badge provide only session-specific actions. The extension also adds a few dozen settings in Tools | Options in a section called Live Share, as shown in Figure 5.

Figure 5 Controlling Live Share Behavior Using Settings in Tools | Options

Another interesting aspect of the guest IDE is that if you right-click on projects or files in Solution Explorer, you’ll see only one item on the context menu—“Go to Git Changes.” In my case, this was initially disabled. Right-clicking the solution in Solution Explorer reveals a menu with options to add a file or folder, as well as modify, debug and launch settings. The reason for the limited context menus is, again, because the solution and project files aren’t available. So Visual Studio treats these as simple files, not .NET projects.

Co-Editing with Your Collaborators

Anyone who has default (as opposed to read-only) access can edit files. A host can add or rename folders and files in Solution Explorer.

The default editing behavior, whether by host or guest, begins with mouse clicks to select text or a location in code. When a participant moves their cursor, the other participants will see a marker in their text. For example, in Figure 6, the guest, Julie Lerman, notices a method beginning on line 22 that isn’t even implemented and recommends refactoring it out. Host Julie says, “Go for it!” The guest begins by clicking at the start of that line, and a marker shows up in the other participants’ IDEs, as well as the name of the user who performed the action. The name will fade away, but the marker remains.

Figure 6 A Notation Appeared When a Participant Moved Their Cursor to the Beginning of This Line

As the guest selects the four lines of the method, the other users can see the selection expand in their own IDEs, along with her name (see Figure 7).

Figure 7 All Participants Can See When Julie Lerman Selects Text

And when she hits the delete key, the lines are also cut from the other participants’ code.

When the host is using source control, the change also appears as a change in Team Explorer.

That’s really the meat of co-editing. So, let’s move on to another fun feature—co-debugging.

Co-Debugging

Earlier I mentioned that debugging steps and breakpoints are captured and transmitted by Live Share. This is another cool feature to see in action.

When one participant sets a breakpoint, that breakpoint is auto­matically set across all the participant IDEs. If the host changes the default setting (see Figure 5) to allow guests to debug, guests can also trigger debugging on the host. Then each IDE will run and stop at the breakpoints displaying available details. However, viewing those details is up to each guest. One might have the errors window open; another might prefer to hover over the breakpoint code to view debug information.

This brings up the question of building projects or solutions. I mentioned earlier that, by default, guests aren’t allowed to build. In fact, the Visual Studio BUILD menu is removed from guest IDEs during a sharing session, and to keep things secure by default, only the host can build. In this case, the guest will display build output, but on careful inspection, I noticed that the output was coming from the host; that is, the build output was displaying the file paths of the host. That’s because the build is happening on the host. If you revisit Figure 5, you’ll see there’s an option to allow guests to build. But if you enable that setting, you’ll need to begin a new session for it to kick in on the guest machines. Debugging is the same. By default, guests can’t trigger a debug session, but you can change that setting on the host. Note that guests can’t skirt this limitation and use command-line interface (CLI) commands to build or debug. Remember, the projects are not on their computers. In a bit I’ll tell you about using the Shared Terminal feature to share the host’s terminal, which allows users to see and run command-line commands on the host.

Debug actions, such as step or skip-over, are also relayed to collaborators. As you step through your code, they’re following along, even if they’ve disabled follow mode (by clicking on the collaborator badge to remove the ring around it, as shown in Figure 3).

Debugging can mean more than just stepping through code. If you’re working in an ASP.NET Core project such as a Web site or a Web API, you can share the server used by the host so that guests can physically browse across the network or Internet to the host’s server. I was a little confused by this at first because it seems a little scary to think that my dev machine’s server would be accessible on the Internet. But the sharing is done using a secure SSH or SSL tunnel. By default (and configurable), the server will be shared automatically when you start debugging (F5) or run (Shift F5). If you prefer to explicitly share servers, you can do so through the Manage Shared Servers option on the host’s Sharing dropdown, as shown in Figure 8.

Figure 8 Setting Up a Shared Server

It’s also possible to explicitly share other servers hosted on TCP. For example, if you have a SQL Server available on TCP, you could expose its port and let your collaborators connect to that database. Read more about shared servers, as well as some precautions around this feature at bit.ly/2FlWnlU.

Once the servers are shared and the application is running on the host, guests can use their Live Share dropdown list to select the View Shared Servers option. This displays a list of servers the host has shared. Figure 9 shows an interesting feature in action: Port 3358 is already in use on my machine, so Live Share has enlisted an available port (3407) to expose 3358 through on my machine.

Figure 9 Exposing an Available Port for Sharing Servers

As a guest, I chose Open in Browser and thought at first that something was wrong because I got a 404 error: “No webpage was found for the web address: https://localhost:3407/.” But that’s because I was running a Web API and needed to navigate to the proper URL—“https://localhost:3407/api/values.” Once I did, there was the output from the API in my guest’s browser.

If you’re debugging a Console application, note that VS Code can open up the console window in a guest session, but Visual Studio 2017 is not yet able to do that.

Shared Terminals, Too!

If you’re building .NET Core apps in Visual Studio 2017, you may not be relying a lot on the .NET CLI or other command-line tools. VS Code users are much more likely to be using the CLI, as they don’t have all of the bells and whistles Visual Studio brings to the table. However, if you are running terminal commands in the context of writing, running or debugging your app, you might also want to use the shared terminal feature to share the console window among participants.

The host can share a read-only or read/write terminal from the Sharing dropdown. This immediately opens a terminal window on both host and guest machines. Note that if you’ve installed the Whack Whack Terminal extension (bit.ly/2PuVDzu), which enables an integrated terminal in Visual Studio 2017, Live Share will use that instead. As the host types, the guests can see each keystroke hitting their terminal window. If the guests have write access, anything they type will show on the other participants’ terminals. If a guest runs, for example, the “dotnet build” command, the build will take place, although just like building from Visual Studio, that happens on the host’s machine.

Yes, It’s Secure!

I’ve already noted a number of behaviors related to security. Hosts and guests are validated using either their Microsoft or GitHub credentials. Sessions are shared by default as editable, but there’s a read-only invitation link to share, as well. When guests join a session, the host is notified and can accept or reject that guest, as well as kick a guest off any time. By default, guests can’t trigger builds or debugging, and project and solution files aren’t even available on a guest computer.

There are other security features that the host can control. You can:

• Delay guests connecting to a shared session through the “Require guest approval” setting under Authentication, as shown in Figure 5. Think of this as a Skype lobby.
• Control file access and visibility to a folder or project using a file named .vsls.json, where you can specify which files should be limited.
• Control guest access even more strictly in an Active Directory environment

These are all important considerations when employing Live Share to collaborate in your small or large enterprise teams. You’ll find more details about these features in the Security Features of Live Share document at bit.ly/2AMyobo.

Ending a Session

The host can end a session from the Sharing dropdown and all of the guests will be kicked out of the session (with a friendly notification). The temp files will also get cleaned up on the guest machines. Of course, guests can leave a session at any time and the host will get a notification when that happens.

Interestingly, my Internet connection dropped during the session (something odd with my router). Live Share responded with a notification in the host system that the relay listener had gone offline and that I should consider resharing when it came back online.

Live Share Has a Big Future!

Visual Studio Live Share is a “sea change” feature for developers using Visual Studio and Visual Studio Code for a wide array of use cases. Distributed teams are becoming more and more common, so the ability of team members to work together on code in this way is extraordinary. But the benefits are not only for distributed teams, and there are so many other use cases—mentoring, code reviews, teaching, helping with problems. I can’t tell you how many times someone has asked me about a strange problem they were having with their code and I responded that I really couldn’t tell off the top of my head and would need to watch them debug through it myself. Live Share can make this so easy to do now. The docs even have a page with all types of use case ideas for you (aka.ms/vsls-usecases). Some I hadn’t even thought of myself, such as coding interviews. This beats a whiteboard interview every time—and can also be done remotely! 

A final thought—compared to sharing screens over Skype, the minimal data transfer can offer significant benefits for developers with slow or undependable Internet connections. My own Internet speeds are limiting because I live in a rural location in the United States. But this is a small inconvenience: usually means turning off the camera when I’m using Skype for voice and screensharing. But I’ve also mentored some developer friends in Lagos, Nigeria (an amazing tech hub), and other parts of the world, where the Internet connection is intermittent and, if I recall correctly, they used their cell phones to relay Internet access to their computers. For me, that really nails it—that not only does Live Share bring enhanced productivity to developers in general, it can also be an amazing game changer for developing communities.

Julie Lerman is a Microsoft Regional Director, Microsoft MVP, software team coach and consultant who lives in the hills of Vermont. You can find her presenting on data access and other topics at user groups and conferences around the world. She blogs at the thedatafarm.com/blog and is the author of “Programming Entity Framework,” as well as a Code First and a DbContext edition, all from O’Reilly Media. Follow her on Twitter: @julielerman and see her Pluralsight courses at bit.ly/PS-Julie.

Thanks to the following Microsoft technical expert for reviewing this article: Jonathan Carter

Discuss this article in the MSDN Magazine forum