Visual Studio + ASP.Net Core + Angular TypeScript debugging

[marczellm]

No, please bear with me, I am fully aware that the thread title already makes you suspect this belongs in a more WTF category...

Someone wrote a web app in which an Angular client talks to an ASP.NET Core server. I have to work on this app.

If I create a brand new project in Visual Studio with the same stack, out of the box I get the ability to debug the TypeScript code running in my browser, right there in the VS IDE.

If I open the aforementioned app's solution in VS, said debugging ability does not work.

Please help me out. I'm getting lost in the incomprehensible mess resulting from an unholy marriage of convention and configuration that is:

• undocumented (?) settings in the csproj (<SpaRoot>, what does that do?)
• hard to understand extension methods to be called in Startup.cs (https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.builder.spaapplicationbuilderextensions.usespa?view=aspnetcore-3.0, what does this do?)
• the angular/node build system and where it puts stuff? where are my compiled files? where are my source maps?
• undocumented (?) configuration values in angular.json and tsconfig.json, and what happens if they contradict each other?
• where do I specify what URL is automatically opened in the browser when I hit Run? I can see the page we open, and I can see which file it is in, but I can't find any references to that file.

etc.

[anonymous234]

@marczellm said in Visual Studio + ASP.Net Core + Angular TypeScript debugging:

hard to understand extension methods to be called in Startup.cs (https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.builder.spaapplicationbuilderextensions.usespa?view=aspnetcore-3.0, what does this do?)

The main thing this seems to do is redirect all requests that haven't already matched an endpoint to a specified default page. Because SPAs tend to operate with "virtual URLs" that are handled in the client and not the server.

Someone wrote a web app in which an Angular client talks to an ASP.NET Core server. I have to work on this app.

If I create a brand new project in Visual Studio with the same stack, out of the box I get the ability to debug the TypeScript code running in my browser, right there in the VS IDE.
If I open the aforementioned app's solution in VS, said debugging ability does not work.

What I usually do in these cases is just carefully copy all the code and files from the old project to the new one, and then start using the new one. It's faster than actually fixing the problem "in-place".

It's like if some Windows component stops working - if you can't find the fix after 20 minutes of googling you just have to give up and reinstall. You're not going to learn all the internals and diagnose the problem.

[anonymous234]

Update: if you open the project properties in Visual Studio there's a section named "TypeScript Build", have you checked that?

Also the browser URL is probably the one in /Properties/launchSettings.json.

[marczellm]

@anonymous234 said in Visual Studio + ASP.Net Core + Angular TypeScript debugging:

Update: if you open the project properties in Visual Studio there's a section named "TypeScript Build", have you checked that?

Another place to configure things? Great!
Will check tomorrow.

[Tsaukpaetra]

@marczellm said in Visual Studio + ASP.Net Core + Angular TypeScript debugging:

If I create a brand new project in Visual Studio with the same stack, out of the box I get the ability to debug the TypeScript code running in my browser, right there in the VS IDE.

What is this magic???!?

[marczellm]

@Tsaukpaetra said in Visual Studio + ASP.Net Core + Angular TypeScript debugging:

What is this magic???!?

As far as my understanding goes, there are two parts to that:

• the "Devtools Protocol", a standardized way for applications to debug stuff running in the browser, works in Chrome and both Edges
• source maps, which allow for debugging of a transpiled-to-JS source running in a browser by mapping back to the original source.

[Gąska]

@marczellm said in Visual Studio + ASP.Net Core + Angular TypeScript debugging:

undocumented (?) configuration values in angular.json and tsconfig.json, and what happens if they contradict each other?

It's possible they aren't as much undocumented as they were valid in some older version but have been since removed.

Anyway, the first thing I'd do is diff fresh solution/project files with what you have and see if there's something obviously wrong there. Maybe even try transplanting the source files to the new project and see if it works that way.

<SpaRoot> seems to be related to Amazon Web Services - a custom tag introduced by the extension. I don't know what it does, but I found it being used here. (Warning: clicking requires 20% of your monthly allowance of Medium articles.)

[marczellm]

@anonymous234 said in Visual Studio + ASP.Net Core + Angular TypeScript debugging:

Update: if you open the project properties in Visual Studio there's a section named "TypeScript Build", have you checked that?

It says "tsconfig.json detected, project properties are disabled". Huh, at least it's smart enough to not let me configure the same things in a third possible place.

[marczellm]

I managed to turn on source map generation.
If I set a breakpoint in app.component.ts in Visual Studio, it doesn't do anything and it tells me that "breakpoint not yet bound".
Now if I hunt for the app.component.ts file in Chrome Devtools and set a breakpoint and hit it, now it is being hit in VS too, but in a different instance of app.component.ts that says (under the tab, over the editor) that it belongs to "Script Documents" but is nowhere visible under Script Documents in Solution Explorer.

[marczellm]

WTF is a webpack:// url? The source maps point to these.

BTW creating a new angular project in VS is totally different from my project. Even the configuration file name and values differ: my project must have been made in an earlier angular version. It has angular.json while the new blank one has .angular-cli.json. I'm not allowed to update the angular or other package versions just to enable debugging; last time we updated something incurred a serious performance drop that was hard to investigate and fix.

[marczellm]

https://docs.microsoft.com/en-us/visualstudio/javascript/debug-nodejs?view=vs-2019#generate_source_maps says:

if you are using webpack, references in the source map file include the webpack:/// prefix, which prevents Visual Studio from finding a TypeScript or JSX source file. Specifically, when you correct this for debugging purposes, the reference to the source file (such as app.tsx), must be changed from something like webpack:///./app.tsx to something like ./app.tsx, which enables debugging (the path is relative to your source file).

so I have to edit the webpack configuration file, which doesn't exist.

[marczellm]

what are these fake url schemes in devtools? how do they get there?

[marczellm]

Creating a new angular project in VS and running it now fails because some package in the default node.js dependencies pushed a borked update.

[error]

@marczellm said in Visual Studio + ASP.Net Core + Angular TypeScript debugging:

Creating a new angular project in VS and running it now fails because some package in the default node.js dependencies pushed a borked update.

This is why npm and yarn both have lockfiles now: each dependency gets locked to a specific build.

[Mason_Wheeler]

@error So then you never get security updates! Brillant!

[error]

@Mason_Wheeler said in Visual Studio + ASP.Net Core + Angular TypeScript debugging:

@error So then you never get security updates! Brillant!

No, updates are just opt-in.

[marczellm]

no it wasn't a borked update after all, just apparently if you try to install a javascript package which has another javascript package as a dependency which has c/c++ code in it and you have both VS2017 and VS2019 installed that breaks.

[marczellm]

I managed, on the second attempt to remove the webpack:/// urls from the source map that the VS documentation warned me to do, but this still hasn't restored VS's ability to bind breakpoints in my actual source files instead of the otherwise-invisible copies under "Script Documents". On the other hand it made these source files newly invisible in the browser devtools.

[Unperverted Vixen]

@marczellm said in Visual Studio + ASP.Net Core + Angular TypeScript debugging:

no it wasn't a borked update after all, just apparently if you try to install a javascript package which has another javascript package as a dependency which has c/c++ code in it and you have both VS2017 and VS2019 installed that breaks.

I tend to doubt that having VS2017 and VS2019 installed is relevant. JavaScript packages with C/C++ code can break things in VS even outside the TypeScript ecosystem (e.g. MVC with view compilation during build enabled). I've found that hiding the node_modules folder is generally a necessity...

[marczellm]

@Unperverted-Vixen talking about this: https://github.com/nodejs/node-gyp/issues/1747

[marczellm]

Okay I had to delete an optional dependency called 'node-sass', which was added by the VS project template, but was trying to install C stuff.

[Magus]

@marczellm I haven't used this stuff in over a year, but every problem I ever had was related to that sass package and gyp. There were things you could do that got it working for a week or two at a time, but it just kept breaking. I don't know what's with that package.

[marczellm]

Just for posterity here's what worked for me:

1. Add the ability to customize webpack build like so: https://alligator.io/angular/custom-webpack-config/
2. Customize webpack build like so:

const config = {
    plugins: [
        new webpack.SourceMapDevToolPlugin({
            moduleFilenameTemplate: 'file:///[absolute-resource-path]'
        })
    ]
};

module.exports = config;

Note: file:/// is only needed if you want to retain some semblance of debugging capability in the browser devtools: otherwise it breaks completely, this way it breaks only partially.
3. If you want to do debugging in VSCode too, you'll have to set webRoot in its launch.json - I set it to "${workspaceFolder}/angular" even though according to some sources that's not what you should do, but it worked.

[marczellm]

@marczellm said in Visual Studio + ASP.Net Core + Angular TypeScript debugging:

I'm not allowed to update the angular or other package versions just to enable debugging; last time we updated something incurred a serious performance drop that was hard to investigate and fix.

Actually the VS template is angular 5 while we are at 7. Should someday update to 8 as it supports incremental builds.

[boomzilla]

@marczellm said in Visual Studio + ASP.Net Core + Angular TypeScript debugging:

Should someday update to 8 as it supports incremental builds.

I believe it is 9 (just released in February 2020) that supports incremental builds.

[marczellm]

@boomzilla yep, just found that out the hard way.

Other info for posterity: updating to angular 8 broke debugging again, now I had to add

new webpack.SourceMapDevToolPlugin({
            moduleFilenameTemplate: 'file:///[absolute-resource-path]'
            sourceRoot: ''
        })