Provide an option to launch external scripts via launchSettings.json

[alex-jitbit]

Currently in Visual Studio 2022 there's no way to execute debug tasks/scripts when testing an ASP.NET Core app locally.

It would be beneficial to be able to launch external tools/scripts/watchers in addition to the main application, when debug session is being started (mainly - watchers)

Examples:

• launch an npm file-watcher task that compiles LESS/SASS/CSS files
• launch an npm watcher that minifies JS files
• launch tailwind-cli process that scans the code for unused utility classes
• etc. etc.

In modern front-end almost everything is being BUILT. Tailwind CSS generates a file, TypeScript is compiled to JavaScript etc.etc. To enable live-reload we need file-watchers to launch these builds. And in Visual Studio there's literally no way to run, for example, a simple npm script when I start debugging a web app.

The only thing we have are MSBuild events, but they can't be used to launch long-running tasks (like file watchers) in parallel with debug.

Currently, if you're a front-end dev that makes a lot of changes to CSS/JS, the only way to update the browser is to run npm run build every time you make any change in your files. This is painful. Or - stop and restart the app altogether, to re-run all the MSBuild scripts.

P.S, Another option would be to offer us a way to hook into Hot Reload events and add custom commands there.

[ViIvanov]

• launch an npm file-watcher task that compiles LESS/SASS/CSS files
• launch an npm watcher that minifies JS files
• launch tailwind-cli process that scans the code for unused utility classes

Why not do it after the build instead of before debugging?

[alex-jitbit]

@ViIvanov watcher processes never "end" so the build will never finish.

[kvenkatrajan]

@sayedihashimi thoughts on this? Have there been any similar requests on the webtools side?

[sayedihashimi]

I don't think we have ever had good support for running external apps along with the project in Visual Studio. We have heard numerous requests for better support for these scenarios.

I think this is more important given the rise of Cloud Native app development. I'm adding @DamianEdwards and @bradygaster to see if they have additional comments.

[DamianEdwards]

Adding @javiercn who has prototyped an MSBuild->npm integration solution (https://devblogs.microsoft.com/dotnet/build-client-web-assets-for-your-razor-class-library/) in this space.

One thing to consider is that launchSettings.json isn't just for VS, but aspects of it are read by and supported by dotnet run and dotnet watch too. Anytime we think about adding properties to launch profiles we need to consider the behavior in those modalities too.

We basically have these integration points today:

• MSBuild (targets brought in my the project file and/or referenced SDKs)
• Launch profiles (launchSettings.json, with behavior actually implemented in the launch host, e.g. VS, dotnet run, dotnet watch, etc.)
• Directly in the IDE (e.g. selecting which browser to launch is only supported in Visual Studio directly)

Integrating watcher-type build toolchains is a bit more complicated as others have pointed out and generally speaking is difficult in modalities that don't have an obvious session semantic in their use, e.g. dotnet build and dotnet run execute and then end, whereas dotnet watch keeps running until the user terminates it. If build kicks off a watcher, careful consideration has to be given to who owns the lifetime of that process, timeouts, re-use for subsequent runs, cache invalidation, etc.

Generally speaking, I think that MSBuild is the right integration point for kicking of anything associated with processing project source files into application assets, i.e. "building" the project. All the other user interactions during the inner-loop are higher level than this (VS build/launch/debug, dotnet run/watch, etc.) so they get the benefit automatically. I really like the prototype @javiercn built for this reason.

Launch profiles are the integration point for changing aspects of the launch UX itself, e.g. setting environment variables for the launched process, whether to launch a browser or not, the verbosity of messages the launch command displays, the URL/port to launch the application at, etc. If there are scenarios where launching another executable/script is desirable only in the context of launching the project during the developer inner-loop, then extending launch profiles to support that might be useful.