1.) If you create a sample in the knowledgebase (not the complete samples from the demo pages), include the entire code as tested and working not just two lines of isolated abstracted code. We need to see how all the pieces fit together.
2.) You need to have sometype of standard, I have seen the same solution answered multiple times and each time the "How To" varies in the type of solution.
3.) Provide a solution that not only incudes building the solution through wizards BUT PLEASE show how to acomplish the same thing using pure code. The reasons for this are simple: By showing the underlying code you better describe and document the object model. By showing the code we as develpers get a better understanding of how everything works. There is an excellent quote from Scott Mitchell (http://aspnet.4guysfromrolla.com/articles/011106-1.aspx) about how this abstraction though efficient can also degrade competence.
However, anytime a new layer of abstraction is added on top of another, it permits developers to forgo education on the lower layers of abstraction. And this works well until something goes awry, and one layer of abstraction "leaks" into another. At this point developers only familiar with the data source controls and not their underlying architecture will be immobile.
I am not saying don't learn about and use the data source controls, nor am I saying that the days of not having to understand how to access data programmatically are nigh. Rather, let me give Joel Spolsky's advice from his great essay, The Law of Leaky Abstractions: "Learn how to do it manually first, then use [data source controls] to save time. Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don't save us time learning. And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder."
Thanks for the great, specific feedback, Donald.
We are working to continuously improve all aspects of our products, and specific, constructive feedback is always appreciated.