Developing with Visual Studio 2017, ASP.NET Core, Angular, TypeScript and Webpack is not always easy: sometimes you get caught in odd scenarious that you can’t decypher easily, mostly because the interoperability between these multiple components is often hard to get – and also still barely documented, both within the official docs and over the web.
A common issue most developers would most likely hit is the strange behaviour of the client-side breakpoints, which sometimes just seem to stop working: basically, whenever we put them on a TypeScript file before launching the project in Debug mode, we get the nasty yellow triangle with the message saying that these breakpoints won’t work:
The breakpoint will not currently being hit. No symbols have been loaded for this document.
This often happens when there’s something that blocks the debugger from being attached to the chosen browser, such as a broken Chrome plugin, the Chrome developer console being turned on or something like that – whenever these things happen, you can just switch away Chrome for IE and somewhat “fix” the problem, at least for the time being.
However, there are specific scenario where that’s not the case: the debugger gets attached with no issues, and all the .NET Core server-side breakpoints are working fine… The problem lies on the client-side breakpoints only.
Although I was still unable to figure out why it happens, experience led me to think that it’s not a Visual Studio 2017, nor an Angular issue: it’s something strictly related to TypeScript and Webpack. More specifically, I’m pretty sure it’s an odd behaviour of the TypeScript compiler when it’s forced to work together with the .NET Core Webpack Development Middleware. I understood that after I tried to switch components until I figured out that broken combo. As a matter of fact, this will also happen when switching away Angular in favor of React JS, Aurelia, VueJS and anything else – but only if Webpack is still there.
Luckily enough, I also managed to pull out a decent workaround to fix that: if I run the application using F5 before placing the breakpoints, and then put them in the Typescript files after the web application has been loaded, they will actually be hit, and everything will work just fine. Conversely, any breakpoints set before that won’t be hit and will report the warning message saying that the symbols are not loaded: however, if we remove these breakpoint and then turn them on again, they’ll come back working fine.
That’s it: I hope this will help other Visual Studio & Webpack developers to debug their TypeScript-based applications.