 Hi, I'm John Chu, a Program Manager on the Visual Studio team. Today, I'm here to give you an overview of Visual Studio LiveShare and how it can enable you to more easily collaborate with your teammates when developing your apps. Whether you're working together in person or in the same office, working remotely or from home, or even across the world, you can use LiveShare to get real-time collaborative development from the comfort of your favorite tools. Let's dive into the demo. I have here a Node.js guestbook app that I've been working on. I was looking into a bug that was causing the guestbook to not display any of the profile pictures that the people had signed in. I think I fixed the issue, but before I push this up to my team's repo, I want to have a colleague do a review of my code. So I'm going to use LiveShare to do that review. In VS Code, I can click on the LiveShare icon on the left activity bar to open up the LiveShare Viewlet. I can click Start Collaboration Session, and that will start sharing out my code. Additionally, as you can see in the Viewlet, I could have joined a session or I could have started a read-only collaboration session. This is useful if I wanted to share my project without having unnecessary edits made, or in the case of an interactive lecture, I could share this out with students to follow along. LiveShare supports up to 30 guests joining a session. After the code has been shared, I get a link to the session that I can share out with my colleague. Additionally, you'll notice in the Viewlet that there are a couple of things that I have already been shared. I have a shared server for the local host 3000 for the run-in, as well as a terminal with the node that I did when I started the app. You'll see that there's a listing for audio call and that I could start an audio call. This is because I have the LiveShare audio extension installed. With this extension, I can start up an audio call that is tied to my LiveShare session. With that, any guests joining my session from VS Code and that has the extension installed can join into this call, and we can communicate about what we are working on. With the link, let me send it to my teammate, JC, and have him look at my code. So let me message him on Teams. On his side, he'll get the link and it will open up his browser. From there, it will detect that he has LiveShare installed on his machine and launch Visual Studio, and this will join him into my code. Hey JC, thanks so much for looking at my code. No problem, always happy to help. Now that Jonathan is joined into the session, the first thing you'll notice is that on both of our screens, we can see each other's cursors and highlights. So as I highlight and move around the file, he can see it on his editor and I can see his movements and highlights on my side as well. Additionally, JC is set to follow me. So as I scroll through the file or change files, his editor follows along with me. So in this file, let me show you, I made this change over here to make the title a little bit clearer. All right, that change looks good, but I'm curious to see the set of changes that you've made within this review and other files. So if I switch to the Team Explorer tool window, I can see that you've made some changes as well as in header.js, also in signature matrix, js and guestbook grid. So let me click signature matrix and I want to see a diff you to know exactly what you've changed in this file. So once I enable the diff you, I can see that okay, you've changed unshift to shift. I'm curious, John, why does he made that change? So yeah, so while I was looking into this issue, I found that unshift wasn't actually returning the right things that I needed for the matrix. So upon changing it to shift, it looks like it fixed the issue. Okay. I guess that makes sense. Now in addition to being able to see the set of changed files that John has made, I can also leverage all of the language services I would come to expect from Visual Studio, even though I'm looking at his remote code. So for example, if I wanted to see the definition of the signatures variable in general, I could simply right-click and say peak definition to verify that okay, this is in fact the set of signature data that the application is running against and therefore this change to shift makes sense to me. Now, I'm also able to go and look at other files independent of John. So even though I'm able to follow him as we showed earlier, I can also look and explore ideas on my own. So I'm going to go to guestbookgrid.js, and I'll toggle off the diff you because I'm curious to take a look at this with a little bit more screen real estate. In addition to the navigation capabilities that I get from his remote language services, I also get all of the linting errors and diagnostic information as well. So I can immediately see that this line has an error with it, and if I hover over I can determine that it's because it's using a var when our application is configured to use the letter const. Now beyond error information and navigation, I as a guest in a live share session can also make edits collaboratively. So I'm going to just change this var const, and as soon as I start typing, I get the completion list once again as I would expect when editing locally in Visual Studio, even though I'm able to work with John and he can see these changes as well. So at this point, John and I are in different files, and if I want to pull his attention to see the change I just made, I can perform a focus operation, which will send a request to him to come and join me in this file so that we can take a look at this change together. On my end, I get a request for that, so I can click follow, and that will jump me to JC's location, and I can see what he's been talking about, and see what he's been working on. All right, John. So I think the changes that you've made look good, and I just fixed the lingering error that you had, but I'm curious to do a little bit of debugging and just make sure that functionally, the app still works correctly. Sure. Let's try debugging this app. All right. So I think what I want to do is go to signaturematrix.js and actually run this specific algorithm to make sure everything is good. So I'm going to set a breakpoint on line seven, and then also line 19. Can we go ahead and run this? Yeah. So as a guess, how about you try running it and starting debugging session? Okay. So I think we're going to go ahead and launch this using Chrome, which because you're on a Mac, that's the browser that you're using. So even though this app and this code is not local to my machine here on Windows, I can simply press the play button to launch the app and the debugger into a new session. Yeah. So now that we're in a debugging session, I see that the breakpoints that JC has put down earlier are synced on my machine. Additionally, if I were to put down breakpoints as well, you'd see them reflected on his machine. So with the app now debugging, both of our debuggers are attached to the running app on my machine. Our debuggers are stopped at the breakpoint JC set earlier. Additionally, as a guess in a live share session, I'm able to independently inspect all of the local state of the running application. For example, I have access to all of the local variables. I can see the call stack and walk back on individual frames to see where the application was at at that point in time, and I can even hover over variables to see what their state is currently. Even cooler though, I can even step the debugger. So in this case, I want to jump from line seven to the breakpoint we have on 19, and I can simply click continue to make that change. So yeah. So on my end, what I can do is I can inspect the matrix and see that it's properly populated and seems to be getting the right things inside of it. So yeah. So let's continue debugging and have the app running. So I'll click continue and between the two of us, we can step through the app while debugging together to be able to figure out issues or bugs. Now beyond being able to step through the application to verify that the logic looks correct, I want to also verify visually that the app is functioning as I would expect. Now with live share, as John pointed out earlier, the local host server that he was running was automatically shared with me. So I can come to this list of shared servers, choose to open that in my browser, and here even though this is running on his machine because I have none of the code locally, I can in fact verify that the application is continuing to function as expected. Yeah. So with sharing these servers, you can share the ports that your app uses with your guests for them to use. In this case, it was the front end, but you can also share things like our REST API or MongoDB port. So the last thing I think we need to verify John is that we haven't broken any of the tests with this change. Can we go ahead and spin up a new terminal and take a look at those? Okay. Sounds good. In JC's VS, he can go into the sharing menu and select show shared terminals. Like with the server for the front end, since I had a terminal open initially when I ran the start of the app, that terminal was automatically shared with him. In this case, it was shared as read only, so he could see what commands I had previously run and how that they had executed. In order to run tests, how about I share out a new terminal by going into the Live Share Viewlet and selecting the ability to share a new terminal, and I'll make this one read write, so you can type into it and execute commands. All right. So with that terminal shared, let me go ahead and run MPM test to verify if our tests are passing, and I can in fact see that everything is still green. So I think John, these changes look good and they're ready to push up to the repo. Yeah. So on my side, I see how that executed because he was running this command as if it was on my machine, and yeah, the tests are great. I think everything looks great, so thanks for reviewing this. Absolutely. Great. So once we're done collaborating, I can end a session from the Viewlet by clicking End Session and that will end it, and on JC's machine, he will get a notification that the session has ended and he will not have access to the code, I shared it anymore. I hope that gave you an idea of all the collaborative things you can do with Visual Studio Live Share, with the ability to collaboratively edit and debug while sharing audio, servers, terminals, diffs and more, Live Share can enable you to collaborate with your teammates wherever you are. From code reviews to Paraprogramming, hackathons, interactive lectures, and so much more, collaborating and working together has never been easier. Visual Studio Live Share is available now for download in the Visual Studio Marketplace for Visual Studio 2017 and Visual Studio Code, and starting with Visual Studio 2019, it comes already installed. You can learn more about getting started or get the links to the extension downloads by visiting our website at aka.ms.vsls. Also, check out our docs site for more in-depth guides about using Live Share. We'd love for you to give it a try and let us know how it goes. Thanks and happy collaborating.