Comments
2 comments
-
Hi marc,
Thanks for the feedback.
We'll have a think about more indication of progress. We have to balance that kind of feedback against keeping the UI simple, but it's certainly not clear-cut in this case.
We've actually decided exactly the same about the "Show me this when I start debugging" checkbox, the next build will default unchecked. The only worry was that people would miss the reflector menu, but we haven't seen that being a problem in usability trials so far.
I hope it was just taking a long time on mscorlib, it always succeeds for us.
Yes, it does use one core per assembly.
It doesn't use symbol servers. If you've embedded any code contract into the code itself to be checked at runtime, Reflector will decompile it as if it were normal lines of code in the method. So in that sense, it should work, yes. -
Much better now; thanks. There is still an unpredictable-length delay at the end of each assembly, but it is much easier to see how long it might take now.
Add comment
Please sign in to leave a comment.
It worked well, though, even stepping into LINQ query syntax (not just fluent syntax).
IMO the "Show me this dialog when I start debugging" should default to unchecked, but you only have to change it once, at least.
Some of the MS libs can take a while... (making the feedback loop even more important). It choked on mscorlib, too (or I gave up). (I thought I'd risk an "all"...)
Thoughts:
- Does it attempt to use the symbol servers at all?
- Would it work with code contracts in the split assembly configuration?
Update: I eventually gave up on some of the MS libs; if they are going to be too painful, maybe the "all" option is too inclusive? Or (as above) - set the user's expectation accordingly.
It looks like it throws an assembly at each core, which is great (it might be more granular - hard to tell from the outside; I'm just glad it isn't single-core throughout).