-
Notifications
You must be signed in to change notification settings - Fork 259
WDBG
CS-Script Web Debugger is an experiential effort that was triggered by the requests from users for providing scaffolding for lightweight debugging of scripts hosted in the applications. However, the problem itself is generic by nature and simple debugging would be highly beneficial for both CLI and hosted execution scenarios.
Currently, CS-Script offers full integration with the two most popular IDEs Visual Studio and VSCode. Any other IDE or debugger capable of debugging managed applications can also be used for debugging scripts with only a few simple extra steps. Thus currently available tools fully cover an average developer debugging needs.
Though, when debugging is needed on the system where development tools (e.g. IDE) are not available or the user (not the developer) does not have adequate SW development skills, a simple low-dependency debugging infrastructure would be highly beneficial.
WDBG is an example of such infrastructure and a ready-to-go debugger with no dependency on any other product. While WDBG implementation is rather of a prototype level, it is fully capable to be used as is or as a starting point for further development of product-specific lightweight debuggers.
WDBG concept is simple. Before the start, the script is analysed and special inspection commands/routines are injected in every debuggable line of the script. Then when the script starts and the inspection command executes, it communicates with the debugger web server (REST interface) and enters a wait loop if the user requested the breakpoint stop. The same rest interface is used to analyse local variables and runtime objects while stopped in the breakpoint. The rest of the dev experience is roughly the same as with any debugger.
The important point of WDBG is that it is not relying on rather undocumented/unexposed largely proprietary debugging API and instead uses an injection technique well known in the AOP domain. Thus the only thing you need to have on your system is CS-Script and any web browser.
While the choice of this approach brings very strong benefits it also exhibits some strong limitations. Meaning that it's unlikely that it will ever replace proper, industry-strength debuggers. Thus before explaining in detail what WDBG is it's important to explain what it is not.
Pros
- No deployment dependency. You only need a browser and CS-Script present on the target system.
- Portable. Any OS can use it.
- A very simple architecture. Developers can use injection and dbg-runtime as is but they can easily replace the server and front end with their own implementation.
Cons
...
============== under construction ====================