More time diving into the peculiarities of the .Net Framework...
I have to say that I am not finding this very hard at all. Granted, I can't do UI design using Divs and such in ADO to save my life (mental block - I expect things to be rendered where I goddamn put them) the coding is nothing that any other experienced VFP-er would take very much time to learn.
In fact, I'm coming to actually love the way this all holds together. Mind you, this project is stuck with 2.0 Framework and I'm sure that a lot of what I'm grinding through is better handled in 3.0 and 3.5.
Still, though, there are weirdnesses that I guess are better handled by experience. It's the same in VFP, I suppose, but I had years and years and professional incentive to master those oddities. I'm now exposed to the firehose.
Example: If you include a column in a GridView but don't actually show it, the value is blank. WTF??? I can't count the number of times I had a primary key stashed in a ListBox or Grid in VFP and made it's length zero just so I could grab the value from the selected row when needed. Nope, not in .Net unless you use a Template field (I think that's what it is called - kinda away from .Net at the moment).
I'm finding that I leave a lot of my control state code (what's visible, read only, etc.. based on selections and environment after a postback) in the Page_PreRender method. Is that good practice? Dunno...works for me.
I'm heading in the direction of either being a damn good .Net coder or a damn bad one. Haven't figured that out yet; it may be years before I do. I wish I could get out to a con and bang heads and compare notes with McNeish or Markus to get a better feel. For now I have to operate under the guideline that if it works, it must be good code.