When you run into an issue or have a question about ASP.NET Dynamic Data, the best place for it is the Dynamic Data Forum. When you write your question, there are a few simple things that you can do to make it easier for the ‘experts’ to answer (and hence to get an answer quicker!).
1. Mention what ORM framework you are using
Out of the box, Dynamic Data supports LINQ To SQL and Entity Framework. While they seem similar on the surface, they are actually fairly different once you get a little deeper into the API. Just mention which one you’re using and you’ll save a roundtrip.
2. Mention what release you’re using
The official release of Dynamic Data is the one that comes with .NET Framework 3.5 SP1 (or Visual Studio 2008 SP1). There are also various preview bits and samples that you can download from Codeplex. Just mention exactly what you are using. If you’re using some preview bits, you can include a link to them to them to remove any ambiguity.
3. When possible, report issues using a standard database
Obviously, we don’t expect you to use Northwind or Adventure Works in your real project. But when you run into an issue with your custom schema, you should always check whether you are able to see the same thing with the standard DBs. Those DBs have schemas which contain many of the common patterns that you may be using. e.g. For One to Many relationship, you Northwind’s Product/Category, and for Many To Many, use Employees/Territories.
There are a few reasons why doing this is preferred. First, most readers are familiar with those schemas, so they can make sense of the situation quicker without having to analyze a custom schema. It also makes it a lot easier for people to try to reproduce the issue you’re seeing, since everyone has those sample databases. And finally, if the issue calls for a sample that demonstrates a workaround, using the standard DB, makes it much more useful to everyone else who runs into it.
Clearly, there are some situation where your custom schema is just different and using the standard DBs will not work. In those cases, just try to precisely describe your schema. Including a diagram can help too. In a nutshell, make sure that a reader not familiar with your database will understand enough of it to make sense of your question.
4. Try to isolate the issue
If an issue you see in a complex scenario can also be seen in a simpler scenario, it is always better to report it on the simpler scenario. It makes the question shorter and easier to read, as it keeps it focused on the essential.
5. Disable AJAX partial rendering
If you’re getting Javascript errors, the first thing you should try to to disable AJAX partial rendering. Please see this post for more details on this.
6. Include complete stack traces
If you’re getting an error in the browser, make sure you include the full stack trace that you see in there, and not just the text of the error. Looking through a stack trace can reveal some important clues about the issue.
Read MOre...
No comments:
Post a Comment