Dump in Grid format calls ToString
I've noticed that recent version of LINQPad (6 and 7) call ToString when dumping a class or an IEnumerable. The classes I dump are usually NHibernate Proxies and calling ToString on the lazy loaded properties immediately unproxy them causing several database calls and thus making almost impossible to use LINQPad Dump.
In the past (until v5) I suppose the GetType().Name was called instead of ToString().
Is there a way to customize the behavior or switch back to the old way ?
I can't easily identify a functional difference between LINQPad 5 and 6/7 in this regard. Is there an easy way to identify NHibernate proxies? The easiest solution will probably be to special-case these.
Yes, I can say that a given object "prop" is an NHibernateProxy if
prop.GetType().BaseType != null && prop.GetType().Name == (prop.GetType().BaseType.Name + "Proxy")
For Collection, I can say it's an Nhibernate Collection when
In my domain that's enough to identify when I don't want the ToString method to be called because it will trigger the tide of SQL queries.
How can I use this bits ? I've tried the ToDump way with no luck.
Giving that I use LINQPad with a custom Driver (dynamic) I've also tried GridOptions.MembersToExclude in
void DisplayObjectInGrid(object objectToDisplay, GridOptions options)to hide those properties but is far from optimal.
I've also thought to dinamically create a proxy around the object I dump thus supplying an object whose implementation override ToString() returning a simple GetType().Name or somthing like that, but is really an effort.
For completeness, what trigger the lazy load is the code in LINQPad.UI.ExplorerGrid.OnCellFormatting
Try the latest beta and let me know whether it helps.
That's PERFECT! It shows typename for both many to one and one to many relations!
Many thanks for your interventions. Attached a screenshot.
That saved me and the company I work for, hours of dealing with dynamic proxy construction (or even CLR methods injection) just to override ToString behavior.
Just for reference we use your product as something more than a learning/scratchpad tool, it's more of a Business Process Management tool. We write classes inside .linq files that are developed/debugged inside LINQPad, than those files are picked up in our product, compiled, stored and executed when certain business conditiosn are met.