I was asked by an MS Product Manager, about 3 years ago, as a result of some rather strong posts about the weaknesses of .Net compared to Visual FoxPro, exactly what I thought .Net was missing, besides data access, which the Product Manager admitted was an issue.
I said "ASELOBJ()." Now, since this individual had used that function to write some very useful add-ons to VFP, I thought for sure he'd run off and either write an equivalent function himself, or have someone else do it, or work to get it included into a future version of .Net (this was prior to the release of VS2005). None of the above happened.
ASELOBJ() is a function in VFP that allows one to get a reference to the current design object (form, visual class) in design mode. (There are other options, but that's the gist of it.) From there, properties can be inspected, added (persistently), modified as to initial value, and removed. Methods can be inspected and modified. With all the metadata we have at our disposal, we can (and do) perform some very useful actions in design mode, once we have the form reference. Which of course is a single line of code in VFP. Nothing like it as a function exists in .Net, including in VS2008 (Orcas).
Frank and I have been discussing, over the past few years, the ProSysPlus Libraries and xCase integration move over to .Net. And each time, we would conclude after all the other issues were settled, that, that we had no hope of equaling our productivity in VFP without the ability to quickly build "builders" as we have in VFP.
Yesterday, Melanie notice that Frank's tag on GTalk is that he has created ASELOBJ() in .Net. I knew he was working on it, because we had discussed it last week, but once again he has moved faster than light, in software development terms.
His plans, as we discussed it last week, were to release this to the .Net community, so I suspect we will be putting it up on Codeplex, along with an instructional video (the purpose of which will be to show me how to use it <s>), but we'll have to see how those plans shape up. In the meantime, one more barrier to our creating a productive (compared to VFP) software development framework in .Net has been removed. That is a good thing.