The .NET Framework has unmanaged debugging and profiling APIs that I assume people/companies are familiar with. If someone was implementing debugger and profiler support for a new CLI runtime¹:
- What would be the pros/cons of basic their operation on these existing APIs?
- These APIs retain backward compatibility² by incrementing interface extension numbers to indicate support for later features. I would have the opportunity to combine these interfaces and remove deprecated methods since there is no “backwards” to be compatible with. Would that be a good idea? One point of interest here is this would not remove source code compatibility with existing debuggers because my system would require the debugger be implemented in managed code & managed API, and the existing ones are written in unmanaged code.
- Are there other documented debugging/profiling APIs available? Is their feature set anywhere near as complete as the ones mentioned above?
¹ I like working advanced, long-term projects at home to keep me learning and thinking about solutions to large problems. I know there are others available, but I want to work on one to really see what’s involved, and I’m already a decent way into it.
² I can’t find a link describing this, but it’s extensively used in the Visual Studio API as well. I believe I saw it in a “COM interface naming guidelines” document? You see it as the ICorDebugClass2 interface showing up to extend ICorDebugClass interface without altering the original.
I’m working with the profiling API so most of my comments are about the CLR profiler.
The MSDN documentation is quit bad.
You get a general description of the what a method or a class is doing and a short description of the method arguments that’s it. No examples.
If you are lucky you can find some blog about your problem.
Some links that can be helpful with the profiler API are:
This MSDN magazine artical – old but a good starting point.
David Borman’s blog – Does not update very often but the information worth gold 🙂
The CLR team blog – Update few times a month.
Rotor The CLR source code
And you can always try to mail the CLR team if you get stuck they actually been very helpful when we needed their help.
About the compatibility issues:
Not sure I understand what you are asking here, what I do know is this:
If you don’t have to support previous versions go to the latest CLR 4.
CLR 4 includes some major changes (few instances of the CLR can run side by side in the same process) read this post and decide how you should deal with it.
As far as I know you can download the source code of managed wrapper API for the debugger API. (Can’t find the link right now)
Hope it helps.