Well I must say that this point of view is far away from the truth. All this new stuff is so facilitated that it can take days to understand what is going on behind the ready-to-use-and-drag-and-drop-friendly programming framework.
Let me share some of my experience with it.
First of all – use IIS whenever possible. I found out that the ASP.NET development web server (the one that comes integrated with VS2005) is too slow. It can also cause timeouts during debugging sessions and problems with detaching from the debugger. At last you do not have any way to control the properties of this web server so troubleshooting problems become pain in the neck.
Next – use SQL Server 2005 whenever possible too. When you first start using ASP.NET 2.0 a lot of things will not work from the first time. Chances that that will be data related problems are big. If you use SQL 2005 Express there will be no SQL Profiler either and that’s a big step back in data related problem solving.
Avoid the new feature that allows hot swapping and XCOPY deployment of SQL databases on your development machine. (Basically this is a new option in the connection string that allows you to point out where the .mdf file resides eliminating the need to create database in some SQL instance.) This feature may be useful in production site, but it has some side effects.
Beware that the windows account of the user that first creates the connection in this databaseless manner, becomes exclusive user for this file and no other windows account will be able to create a connection to this file. The error is quite useless in this case:
“An attempt to attach an auto-named database for file C:\acme.mdf failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.”
Also keep in mind that in one occasion I had to give write access to NETWORK SERVICE account to the folder above the one that was holding my .mdf file. I have not research it what is the case however.