Exposing internal things publicly about clrmd HOT 7 CLOSED

I'm already working on a sensible way to expose MethodTable/EEClass/MethodDescs, etc. That should be implemented within the next two weeks (or I may start working on it this week if I have time), so you should hopefully not have to worry about that soon.

In general, here is my thinking on where I'd like ClrMD to land on these topics:

1. Everything implemented needs to be done in a way that's sensible for all flavors of CLR: Desktop, Coreclr, and .NetNative. (.Net Native isn't supported yet, but I still build features assuming it will be one day.)
2. With that said, it's ok to have APIs that only work on certain flavors of the runtime, as long as they fail sensibly (generally without exceptions) on other platforms and doesn't make it hard to code against.
3. ClrMD is meant to be a wrapper over the dac private interfaces (IXClr*, ISOSDac, etc). I will never expose the raw interfaces directly (ISOSDac will never be marked public in the main repo, for example). Instead I would prefer to take the functionality you need and add it to the regular public surface area of ClrMD.
4. If there are places where we need to cache data that aren't currently, please file an issue for that or create a pull request (if you implement the change yourself, just make sure those caches are cleared or irrelevant if the user calls ClrRuntime.Flush). Those will get fixed asap.
5. If there is missing functionality you are looking for, please open specific issues for them. I'd be more than happy to take a look.

So to answer your question, I definitely do have plans to extend a lot of what you are talking about. I encourage you to please open individual issues for every place in your code you use "InternalsVisibleTo", missing caches, or other missing functionality and I'll be happy to take a look. Also if you have the time and interest to implement them yourself I do accept pull requests as long as the resulting feature/change fits in with the rest of ClrMD.

Next week I'll be on vacation and plan to bring my laptop to work on ClrMD while on the plane, in the car, or otherwise bored, so now's an excellent time to file bugs and feature requests.

from clrmd.

+1 on extending ClrMD rather than exposing the internal DAC interfaces!

As for MethodTable addresses, after using ClrMD for all new code for over a year, I don't miss them. Honestly, I don't see the need to expose them anymore.

However, there is one sore spot that is often what people want when talking about MT addresses: A stable way to address CLR types across debug sessions. Right now, the closest we have is ClrType.Index, which is.... next to useless most of the time.

I'd be perfectly happy with a stable way to reference types that worked in some other way. As for the EEClass/MDs, haven't needed those in a long time in my specific use cases :)

from clrmd.

Ah, I'll also be removing ClrType.Index (well, marking obsolete, but I'm not sure I'll leave its functionality). This was originally thought up as a lightweight way to refer to types, but as you mention it's not resilient to second processes. That will go in with changes to add MethodTable support.

I agree I haven't needed MT support after using ClrMD for a while, but at the same time other tools use MTs and other internal descriptors, so I've been planning to add them so you can interop with other tools (not generally as a mainline scenario).

from clrmd.

I can live with that, sounds good.

from clrmd.

I am going to use this issue request to track adding MethodTable/EEClass/etc support in ClrMD. Thanks!

from clrmd.

Thank you for your answer - really appreciated. Sorry for the belated reply - didn't have enough time today to answer here.

I'll review my projects and will issue you a couple of related issues. Also, I'll issue standalone ticket for MT/EEClass/etc, so this one could be closed.

from clrmd.

Sounds good, thanks!

from clrmd.