 On today's Visual Studio Toolbox, Burke is going to show us how you can get access to your Visual Studio Code Dev environment from wherever you are. Hi, welcome to Visual Studio Toolbox. I'm your host Robert Green, and joining me today is Burke Holland. Hey, Burke. Hey, Robert. How are you? I'm good. Welcome to the show. Thank you so much for having me. I appreciate it. Now, you are a Cloud Advocate here at Microsoft LAN? That is correct. What does that mean? Well, it means that I go to conferences, and I write blog posts, and I wear shirts with oversized cassette tapes on them, very retro, but mostly I focus on JavaScript and just making the experience for JavaScript developers in Azure better. Okay, cool. Just how can we make it better? Cool. Today, you are going to show us something called Visual Studio Online. That is correct. Which was recently announced? Yes, it's quite new. Yes. So, this is very inside. I said when I saw that, oh, we should do an episode on that, and here we are doing an episode that's going to show that. Right, lucky you. Here we are. All right. So, what is it? Good question. Why is it? Let's answer that question first. So, you've got your editor, you have your machine, you get your whole development environment set up, and that takes a lot of work. People take put a lot of time, love and tenderness into their development environments, and they're very particular about their machines. You can't just run it on any machine, it needs to have enough power, it has to have enough beef in order to get the job done. Right. So, the problem then becomes that your machine is the only place where you can code, literally the only place. So, if you don't have it when you go home and you need to get back online, you may end up like, remoting into some VM somewhere via remote desktop. Exactly. You have two machines but they're never in sync. Exactly. Or you have a machine that's underpowered. So, you get to the point where you actually can't run something anymore because the machine's underpowered, that's the one that you've got. You can always spin up an Azure VM. That is true. You could spin up a VM, or you could use VS online, which is what we're going to do today. Cool. So, let's take a look at that. I'm going to pop over to the browser here. So, everything that we're going to do today is going to be done inside of the browser. There's an experience for this where you can use Visual Studio Code and have the same experience, but you can also just be in a browser. Cool. That's pretty cool. So, the first thing we need to do is create an environment. This is where you're actually selecting that VM. If you were going to make a VM. Weren't signed in, there'd be a place here to sign in with your Microsoft account that's tied to your Azure subscription, or your Azure DevOps, etc. That's correct. I have spared you the tedious details of watching you log in and type my password wrong multiple times. But if you've ever logged into Azure or logged into Azure DevOps, you've logged into Visual Studio online as the same person. That is correct. Yes. That is right. Tied at the same account. All right. Then you're going to put in the Git repository where your code is, and you can do the URL, but you can actually just do the repo name, and then like this. So, this is the repo that we're going to clone from GitHub into our new environment. In the instance type here, you can see that I'm pulling in, I've got a standard Linux box here with four cores and eight gigabytes of RAM, and I can change that. I could get more if I wanted. I can go up to 16 gigs, or I can look at some pricing information. You have to be Linux? Let's see here. Apparently, at the moment, it does. Okay. Then this suspend idle environment, what this does is after a certain amount of time, it just puts the environment to sleep, so that you're not being charged for it actually running, because you do get billed as it runs in addition to the fact that it actually exists. Okay. So, we're going to just leave it at 30 minutes here. Then one thing that we could do here is we could pull in dot files. Dot files? Right. Now, if you're not familiar with dot files, it's a very Linux-specific piece of terminology, but in a Linux Bash shell, you can customize the Bash shell, you can customize the prompt, you can put in shortcuts, you can put in what they call aliases, so you can just type a command and then something more elaborate happens. We store that in what's called a dot file, and it's literally dot something configuration file. So, usually dot ZSHRC or dot BashRC. Then what people do frequently is they'll put those in a GitHub repository so that they can then pull them down whenever they set up a new machine. So, what we have the opportunity to do here is pull in dot files to configure the Linux box that's being created in Azure. We're not going to do that though, we're just going to go ahead and create this environment here. So, this is going to create this machine, it's going to spin it up in an Azure data center here in East US, and you can see here it's creating. So, that's what's happening right now is this VM's actually being spun up for us in the cloud. Now- So, the fact that it's a Linux machine obviously says this, you can do dotnet core stuff here, you can do JavaScript stuff here, you can do anything that you can do in Linux, but you can't do Windows-only stuff, presumably. I don't know what the availability of Windows is, but I would imagine somebody from the, good question for the VS online team, but for this demo we've only got access to Linux. All right. Keep in mind that we are still in preview here. Got it. And so, for easy environment, normally you would have your environment already set up so you'd go back in, right? But we've created this, so let's just go ahead and go into the environment here. So, I'm just going to click on it. And what you're going to see is something that looks awfully familiar. That looks like Visual Studio Code. It does. It looks a lot like Visual Studio Code, doesn't it? Right there in the browser. I assume there's some shared code going on. There is. There is. So, for those who don't know, Visual Studio Code is actually built with TypeScript. And so, a lot of the code that actually runs the native platform can be used to build a web client because TypeScript is just JavaScript. Right. Right, it's a very flexible editor. So, now we've got it running inside of VS code here and let's just pull up the readme file and all of our keyboard shortcuts still work. So, I'm just going to do control shift V to get a preview of this readme file. So, now I'm previewing the readme file right from within VS code. And we can pull up a terminal. So, let's just do that. So, I'm going to pull up a bash terminal here. So, this is our full bash terminal. So, now we're actually on the Linux box with the terminal open. Right. And any commands are good, right? So, we can run an LS command, any of your Linux commands you'll find here. So, you can traverse the file system of this machine as if it was an actual machine. Cool. Now, notice here that we have a node modules folder. So, I'm just going to expand that. Now, that folder isn't in the repo. Okay, so when we cloned it, there's a package.json file and VS online is smart enough to look at that and say, oh, there's dependencies in this project. I'm just going to go ahead and install those for you. So, by the time you open the environment, they're already there. Which is just one less step that you have to do. Yeah, it's pretty neat. Now, in JavaScript, we don't have, you may know this, we don't have a compiler. Right. There's no compiler for JavaScript. And so, we don't know at design time when we're actually writing the code, whether or not there are any errors in the code. We just sort of throw it up and pray that it works. And so, we have some tools to help us do that. You know, TypeScript has a transpiler that will do that. In this case, we're just using JavaScript, but we have ESLint in here as well. And so, VS code, because we have this ESLint rc.json file over here, VS online looks at that and says, oh, you want me to what's called Lint your JavaScript, but just basically check it for errors. Right. And that's what it's doing right here. So, it's automatically running ESLint on our code and showing us that we've got some errors or some warnings here. So, we can see these. I'm going to press Control, Shift, M. That's just going to show us the different errors that we've got. And these are all warnings. This code will still work, but it's actually better not to use var anymore. We want to use let or const are the new variable types. Good to know. So, we can fix this. Let's just highlight this line. I'll just do control period and that will give me some options on how to fix this. So, notice all of the keyboard shortcuts that I would use in VS code just work inside of the browser like you would expect them to. So, I'm going to fix this no var problem and it will do that. Now, I could go and do that for the rest of them or we can just go down and say, fix them all. We'll fix all our no var problems and now we know more problems detected. Yeah, pretty neat. So, now the next thing we need to do is because we are developing, this is a little web server. It basically just says hello world, which you can see here, sets the port, sets the host, says hello world. And then it's going to run this little server so that we can serve up some content. So, the next thing we want to do is actually run this. So, let's do that. I'm going to come over here. A couple ways to do this. We could just press F5, but we can also open up the debug bar and just go ahead and launch it. And you'll see that we've launched and you can see that it's running on localhost 3000. What's even more interesting is that if I put a break point here. Running on localhost 3000 locally? It doesn't make any sense, does it? Localhost 3000 on the machine this is running on. Doesn't make any sense, does it? Bear with me. We're going to talk about that. So, I'm going to restart this. Because first I want to show you that we can actually hit break points in here. So, we've hit a break point and we can examine and see that host is localhost, which you caught, and port is 3000. So, this thing is running on localhost 3000. So, let's go ahead and continue on. So, that's where it's running. All right, so let's access localhost 3000. Because we can do that. So, let's just come over here to a browser tab. And you know what? I'm in a browser. I totally forgot I was. Did you see me just go looking for the browser? Yeah. That's crazy. So, let's open a new tab. Let's go to localhost 3000. And that's going to work, right? That's the question. That's the question on everybody's list. Oh! It's not going to work. Now, why doesn't that work? Because this code is running on a server somewhere and up in Azure. Right, and this is the problem. And how do we as developers effectively develop in an environment that's not local? We need to be able to run things on localhost. All right, so here's how we handle that. Visual Studio Online. So, let me come back over here to this tab. And we have this little remote explorer that's automatically there when you pull up VS Online. And you can see down here in our environment details, you see this section where it says forwarded ports. So, what we're going to do is we're going to forward a port. And we're going to forward port 3000 because that's the port that this app is running on. Hit enter. And it wants to know, just you can give this a nifty name. This is just how it shows up in the sidebar here. So, we'll say enter on that. And now, it's running on localhost 3000. Now, we can't access it on localhost 3000 though because, again, that's not our machine. But if we click on it over here on the side, what it does is it opens and you can see it's connecting to the forwarded port and wait for it, boom, there's our application. Because I was going, if it was running locally and the server was pushing stuff down that raises all kinds of firewall issues and blah, blah, blah, it's a much better. Correct, right. So, now basically getting to localhost 3000 on the machine this is running on without having to care what it's literally called. Correct, because you really don't care that the URL is localhost. You just wanna be able to access the Dev environment. So, let's check this out. Let's go in and make, let's make a change here. So, we'll just say hello, VS Toolbox. And then, let's go ahead and save that. And I'm gonna restart the debugger. And you can see it's awful fast. That's because we are running on a pretty beefy machine. And then, let's just stick a break point in here. Let's come back over to our localhost here. Refresh, and you'll notice that this is just gonna kind of spin and spin and spin. And that's because we have hit the break point inside of Visual Studio Online. So, what's really cool about this is- How many times does that happen to you? You set a break point and then you go to the browser just spins and spins and spins. Actually, actually multiple times. Remind yourself. Right, I can see a feature we add where the tab flashes or something to show you. That hasn't happened to me since this morning. Right, exactly. Like, why is this not responding? Oh, I set a break point. Well, a lot of times in native apps it forwards the application. Like I know in VS Code, if you break, it will bring VS Code to the front to show you that. In a browser, it's a little bit different. Yeah, so we're broken in here. We can debug, do any debugging we need to do. Step over, step out, continue on. It's basically like a local development environment. But inside of your browser. So, a couple of questions. I assume, so what version of Visual Studio Code is this? How does it relate to the one that I actually have on my machine? And can I install all of my same extensions? And can I save the environment? Yeah, that's a great question. So, let's see here. Let me go to settings here. So, the answer is, is this the same version as VS Code that's running on your desktop? No, it's not. It looks like VS Code in the browser, but it is not the same thing that's running on the desktop. But it's probably pretty darn similar. It's very similar. So, all of the settings are gonna be there. Most of the things that you would do, tweaks that you would provide in settings like themes and things like this, you can totally add in. You can add your extensions. You can add extensions, not all extensions are supported at the moment, but many extensions are. And then you can save the environment. You can, you can save the environment, goes into the .VS Code file like you normally would. So, if you were working locally and you have that .VS Code folder with the settings.json, put your settings in there, put it in GitHub, pull it into VS Online, and it will automatically pick up those settings. Awesome. And then you can check things into source control. So, right, you're working off a repo. That's correct. So, you have source control. So, if you go home or you're, you know, away for the weekend or whatever and you need to make a change, you don't have your computer with you, you just need to be able to get to your environment, you check out your code, you make your change, you check it back in, and it's just all the same workflow. Correct. So, you can imagine that you have access to a computer. Maybe it's not even a very beefy computer, but it doesn't matter. And when you pull up your environment, it's already pre-configured. It already looks like your VS Code. It's as if you launched your own VS Code installation from your own machine, but from within the browser. Does it work on your phone? Haven't tried it. That would be interesting. Not supported. Cool. That's awesome. So, for other questions, I know there's good docs about it. People can go and read up more about this, particularly about pricing, et cetera. I saw that there were some pricing plans. Yes, absolutely. There's good docs on this. There was a talk and an announcement from Ignite that people can check out. So, we can go ahead and link to that. We'll link to that. Yeah, that would be a good one to check out as well. Cool. This is awesome stuff. All right. Thanks for having me. Appreciate it. Hope you enjoyed that, and we will see you next time on Visual Studio Toolbox.