>but if you find yourself needing it in normal development work then it almost always implies a weakness in the design.
>
>I guess it depends what "normal development" work is. If you mean standard database apps, I'd tend to agree- though reflection has made sense in some areas (e.g. databinding) and there are apps out there making extensive use of it whose authors are unlikely to relish the thought of rewriting.
>
>TBH I don't think comparison with VFP makes too much sense on this issue. The reasons why you would do it and the way in which it is done are too different.....
>
>True. VFP did make it easy to use table-driven conditional logic with EVAL(), which is not a good reason to try the same in NET. ;-) But it's fairly easy to convert that sort of code to NET, fwiw- you can write quite a simple parser to generate C# (or Java, or Python, or PHP) conditional equivalents that don't need reflection, but can be very large.

OK - open question:

In any .NET application where you are *only* accessing code *that you have written* would you use System.Reflection or System.CodeDom?