Good points all, Paul

>>
>>1. Language is irrelevent when at the ground-level. Walk away from the C# versus VB argument. From the VFP perspective, VB.NET is easier to understand and 99% as functional. What you'll find as you get more proficient is that it's just as easier to understand or code in either. So focus on VB.Net. Once you understand VB code without a reference manual, C# will make sense and you'll find yourself pretty much equally adept at either.
>
>You can't say walk away from the language argument then suggest one over the other <g> I actually started with VB.Net and switched over the C# within a month or so. I had a difficult time separating the syntax between the two languages so I kept tripping over things. C# was enough of a break that I seemed to be able to make the leap that "this isn't VFP and VFP isn't VB.Net".
>
>>2. Get foundational literature. Anything by Charles Petzold works for me (the Programming Windows series, for example). I found myself using old functions like Str() because I could when I should have been thinking x.ToString. I had to make a mental effort to break that pattern and it really pays off as you get more into the complex Framework types.
>
>I really liked Applied Microsoft® .NET Framework Programming from Jeffrey Richter. I thought it was a great foundational book.
>
>>3. Get a buddy. You are going to have, from a .NET developers perspective, stupid questions. It's inevitable. Have someone or someones who are willing to answer your seemingly dumb questions without issue.
>
>The UT should be good for that. But they have to take your advice that it's hard work and TRY to figure things out on their own. I think that's really the best way to learn - stumble through things, pound on them, then ask your question (but that doesn't mean waste a week trying to figure something out). I think some people get frustrated when it's obvious the person posting didn't spend more than 2 seconds thinking about the problem, or looking at the documentation.
>
>>4. Ignore the bleeding edge. If building a basic ASP.NET page befuddles you, you have no business looking at Silverlight or cloud computing. Get confident in the basics and it'll add tremendously to your understanding of the other stuff.
>
>Additionally, it's not just bleeding edge stuff you should stay away from. There are some things that are better left for later once you have a stronger handle on the basics, such as:
>
>- Multithreading (anything beyond BackgroundWorker for a WinForms app or maybe a timer).
>- Writing any kind of custom provider of anything until you've worked with one of the existing ones.
>- Security and/or encryption (sometimes you can't avoid them, but they're pretty hairy subjects in and of themselves).
>
>Another tip - If you're following any on-line example codes, don't deviate too far from the defaults. It leads to frustration when it inevitably doesn't work. Get it working, then customize.
>
>>7. Do not assume examples on the Web are canon, In the old Fox world, for the most part, people only posted code that they knew worked. Not so these days - there is a lot of crap out there. Take the ideas to heart as presented but be very leery of the code - especially if it's using Northwind or AdventureWorks since those dbs seem to be the refuges of the semi-competent.
>
>Stay far, far away from most of the drag-drop data interface examples. OK, go ahead and try them out. Just don't plan on using them in real code. Doing that only leads to headaches later. A lot of the ASP.NET examples are especially bad with this. Ooh, drop a *DataSource object on the form then run through the wizard to hook it up. It actually does work pretty nicely until you decide that you need to customize it a bit. Or start implementing common validation rules that should be available across forms. You will run into no end of headaches once you get past the "it works" stage.