Visual Studio Code, Debugger For Chrome and ASP.NET 5

During the Connect(); //2015 event held by Microsoft recently, Microsoft made Visual Studio Code open source, so yay! This was something the community had wanted for a long time.

Visual Studio Code Extensions is Awesomesauce TypeScript Tutorial How-To

But I think the thing that exited VS Code users the most was the announcement that they now supports extensions! This in my mind took VS Code from “a great editor” to “Pure AwesomeSauce”.

The Debugger For Chrome Extension

I wanted to test the Debugger for Chrome extension when playing around with some TypeScript dev in an ASP.NET 5 Project. But I ran in to problems.

At first I tried getting the extension to start Chrome and connect to my localhost, using the standard section recommended in launch.json, like this:

{
	"name": "Launch localhost with sourcemaps",
	"type": "chrome",
	"request": "launch",
	"url": "http://localhost:5000/index.html"
}

However that didn’t work as the extension could not find my default Chrome installation and gave me the error:
[webkit-debug-adapter] Can't find Chrome - install it or set the "runtimeExecutable" field in the launch config.

So I set the runtimeExecutable to point at my Chrome installation and also added the runtimeArgs to make Chrome start with the remote debugging port set correctly.

This worked and I could fire up the extension by pressing F5. But to my dismay, no breakpoints were hit, however the Console worked and logs were piped over to VS Code.

After lurking the extensions GitHub repo it seemed more people were having the same problem. Seems setting the root for content delivery was key!

{
	"name": "Launch",
	"type": "chrome",
	"request": "launch",
	"url": "http://localhost:5000/index.html",
	"runtimeExecutable": "C:/Users/_usr_/AppData/Local/Google/Chrome/Application/chrome.exe",
	"runtimeArgs": [
		"--remote-debugging-port=9222"
	],
	"cwd": ".\\wwwroot\\"
}

(If you are planning to use the above config, replace the _usr_ part of the path to your correct user!)

After setting the root path to the webroot, the extension worked like a charm, but the extension has a few quirks to be aware of:

  1. When starting debugging with F5 from VS Code, Chrome starts but won’t hit any breakpoints. You need to refresh the page in Chrome to hit your breakpoints!
  2. If opening several tabs when debugging (possible if more tabs are open before starting debugging), the most recent tab opened in Chrome most likely won’t be the one connected to Visual Studio Code, but the first one is!

In Closing

If you haven’t tested Visual Studio Code yet, download it and give it a try. It’s a lean, quick install!

Check out all the new cool VS Code extensions in the Visual Studio Marketplace!

Watch all the announcements and videos from Connect(); //2015 on channel 9.

Interested in getting started with ASP.NET 5 and TypeScript in Visual Studio code, check out this post.

Happy coding! 🙂

VS Code, Debugger For Chrome and ASP.NET 5
Tagged on:             

6 thoughts on “VS Code, Debugger For Chrome and ASP.NET 5

  • December 2, 2015 at 22:56
    Permalink

    Hi, I’m the dev behind the “Debugger for Chrome” extension. Thanks for writing about it! I filed a bug to look for chrome.exe in AppData. Any thoughts on what we could do to make this more useful?

    Reply
    • December 4, 2015 at 03:05
      Permalink

      Hi Rob!

      Sorry for the late reply, I wanted to test it some more before I gave you feedback. The following are things that I could think of:

      1. I couldn’t get my old “launch”-config to work after I updated the extension, but I managed to get an “attach” going. Saw that “attach” also needs a “webRoot” set (at least for ASP.NET 5), but I kind of missed this since there is none in the default launch.json. (Yeah I know, RTFM – but it was silly late in my defense :)) I propose you put a “webRoot” in the example attach in launch.json, just for clarity.
      2. Since the Console can’t scroll sideways – is it possible to enable wrapping of text lines to be able to see long prints? This kind of hampers clarity of reading exceptions right now.
      3. Mousing over variables to inspect values when hitting a breakpoint seems sketchy. For ex I can get it to work on a variable, but on just one or two lines above, the same variable refuses to show a tooltip. Both instances are in scope so it shouldn’t be an issue?
      4. The Reconnect button is slightly confusing. At first look it implies a reload, so unless reading the tooltip you might think that it should trigger a reload in Chrome. Maybe change the icon for it?
      5. While on the topic of refresh – it would be great to be able to trigger a Chrome reload from within the extension, if possible?

      Hope this helps a little, and BIG thanks for a great extension! 🙂

      Edit: I saw there’s work planned for improving the console in the VS @Code December sprint, so point no 2 in the list is probably superfluous now.

      Reply
  • December 10, 2015 at 02:18
    Permalink

    Thanks for the feedback, Andreas!
    1. I heard something similar from one other person although I’m not sure what the issue is because launch and attach are pretty much identical except that launch starts chrome.exe first. ‘webRoot’ depends on your particular config, and I totally agree that it’s annoying to set up. In theory I can have the extension determine webRoot automatically to simplify the config, I have a task tracking this.
    2. I don’t have control over this, I’m not on the actual Code team, but I know they are working on it.
    3. I’ve seen the same, also when debugging Node. It’s not something that my extension can fix unfortunately.
    4. Yeah maybe there is a better icon they could use, but my extension can’t customize that at the moment. If you are using a launch config, it will refresh the browser by relaunching it though 🙂
    5. You can run location.reload() in the console, but I can’t add my own button for it – extensions can’t add UI.

    Reply
    • December 10, 2015 at 09:30
      Permalink

      Seems 2, 3, 4 and 5 is up to the VS Code team then! We’ll just sit and wait for the goodies to roll in 😉

      I’ll work a bit more with no 1 and see if I can get it working, and get back to you should I find something.

      Thanks for taking your time to answer so thoroughly, really appreciate it.

      Cheers!

      Reply
  • December 22, 2015 at 10:57
    Permalink

    Thanks for an awesome article unblocked me straight away when my Angular2 app was not hitting break points. Thanks you rock!

    Reply
    • December 22, 2015 at 14:29
      Permalink

      Glad to hear it helped, it’s feedback like this that makes it worth to keep blogging 🙂

      Happy Coding & Merry Holidays! 🙂

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.