I have been spending a bit of time on the Microsoft Managed newsgroups answering various questions about .NET, ASP.NET, VB.NET etc. I find myself quite often replying that the user has several options.

This is one of the areas that separates the coders from the developers (definitely give this article a read); understanding which of the many available options is the correct one for a given scenario.

While some questions have pretty straight-forward answers, such as:

"How can I get ASP.NET to not show the right arrow symbol that appears alongside top level menu items which contain lower level menu items?"

(The answer is to set staticEnableDefaultPopOutImage= False or dynamicEnableDefaultPopOutImage= False depending on which model you are using.)

Others require a deeper understanding of the requirements and underlying architecture. For example, someone just posted a message asking how to read an Excel 2000 file in VB.NET. The answer is "it depends". If you have the luxury (read budget), there are third party controls out there that can handle all the grunt work for you. You can also use the Microsoft Office Automation APIs or VSTO. If you really wanted to get crazy, you could go study the Excel 2000 specification, and roll your own. Partly it depends on performance, partly on budget, partly on ease of implementation and maintenance, and partly on whether it is worth it to spend dozens or hundreds of hours developing a feature that will be used once in a blue moon.

As much as some of us hate it (did I say me?), there is significant value in understanding the mechanics and infrastructure behind the code that we write. Such questions as "Should I use a data reader or a datatable?" seem to be good at invoking a strong discussion between coders and developers.

Which one are you?