The issues I see most often are:
- Choosing to use custom client rather than a browser. Developing your own client provides you with a much more powerful and robust user interface (especially for real-time apps that require callback functionality from the server) but with the task of maintaining and deploying the software on all of your clients. Using a browser-based interface allows you to maintain the application in one central location but limits functionality (or creates more work) for supporting more robust user interfaces. There is plenty you can do in a Web-based UI, but sometimes it just won't cut it.
- Interfacing with third-party database engines. I've seen plenty of bugs as a result of this issue. At a low level, these engines still must provide an OLE DB or ODBC interface that ADO.NET must consume. If these database engines don't live up to the spec completely (and many really don't), then you'll run into problems down the road. Stick with SQL Server or the MS Jet engine if at all possible. If you must interface with another database, research all of the known issues of that database integrating with MS technology. Be sure to search both the vendor's knowledge base articles as well as Microsoft's.
- Security issues are important and escalating. This is true of any Web-based business platform, but knowing the authentication options and security technologies supported by .NET are critical to developing a secure application. And if you haven't read Writing Secure Code by Michael Howard and David LeBlanc, go get that book today!
This was first published in March 2004