So, I've had a fair amount of experience programming database driven web apps using php and coldfusion (not together, at different times) and I'm starting to look into the asp.net world (I have a project coming up at work that is all asp.net/c#.)
My question is: there seems to be a lot of stuff to get mired in and if I'm just making web-based applications (mostly CRUD-type stuff - no mind-bending logic) what are the topics I should be focusing on? I just don't want to go down the rabbit trail of something to find out later that it's not really used too much by the development community. In reading some books (ASP.net 3.5 step by step and ASP.net 3.5 unleashed) I'm finding some area's where a topic will be explained but at the end of the chapter it'll say "this stuff is cool but not for use in multi-tiered applications..."
The topics I've looked at so far (that seem to differ greatly from the applications I'm used to building) are:
Good question! I'm assuming that you can pick up the C# syntax as you go so I'll focus on the big picture.
To get started with a WebForms application, you must understand the page lifecycle and the application lifecycle. This is your first priority. The model used by ASP.NET is based on Windows form-based programming and this has implications for how you think about the entire software production process. Now, I'm assuming that you will be building a WebForms application because WebForms technology (in ASP.NET) is more mature, has better third-party support and has far more documentation. If you are inclined to MVC, then just keep in mind that a good design will be one or the other - MVC isn't a part of WebForms, it is an alternative to it.
Next, you have some decisions. Will you be using standard data access (e.g. SQLClient) tools, rolling your own data access layer (or using DAL), or using linq to SQL? I say "decisions" because everyone on the team will have to be together on this one. I heartily recommend building a DAL as you can optimize it for your needs. Linq is nice as well but there are some ominous clouds on the horizon. Coordinate, decide and stay with it.
While not mandatory, you should seriously consider building your Business Logic in a separate Class Library (DLL). Visual Studio / ASP.NET make it trivially easy to create your own Class Library and to fold it into your solution. Learn how to do this and you'll be a better developer for years. People usually argue for this on the basis that it will insulate your UI from your data access. While true, that isn't really the advantage - the advantage comes down the road when you are ready to learn and do Unit testing. Just start out with the assumption that you'll split UI from logic and you'll thank me down the road.
At this point, you can (A) build web pages and (B) show dynamic, database-based content in them. Make sure that you master the GridView and the ObjectDataSource objects used to fill them. Note: the ObjectDataSource is what shuttles data from your Business Class Library to your UI. If you don't use a Business Layer, then you'll use SQLDataSource or LinqDataSource objects to access your data directly from the UI.
Don't be settling on your architecture yet!
You now need to decide whether you want to use Microsoft's WebParts, Login and Navigation components. These lock you in to a specific approach to site navigation, UI, etc. but can save you loads of time if appropriate.
Once you know if you'll be using these and you have had a chance to get used to them, then I would recommend getting familiar with Master Pages. I use them extensively and they are great for standardizing the overall look and feel of the site.
Finally, every professional ASP.NET developer must derive their own Page class (e.g. "MyPageClass") so that they can encapsulate common actions at the Page level. For example, I've built a session management object so that I can access all of my commonly-used session variables in a type-safe manner. The derived page class is responsible for providing the sessionObj instance so that every page can access it without any additional work.
Now you are ready to begin building an enterprise class web app!