The MaxItemsInObjectGraph error message comes up fairly often in the WCF RIA Services forums and I just ran into it on a personal project so I thought I’d write a quick blog on how to fix this error.
The dreaded “The remote server returned an error: NotFound” error message in RIA Services can be frustrating if you are not aware of what it really means, and more importantly how to diagnose it.
This generic error message is due to network stack limitation in your browser, basically the browser is intercepting the error and not giving it all to Silverlight. That does not mean there isn’t good information to be found. Your friend here is Fiddler and/or WCF Service Tracing.
[WCF RIA Services Version 1 Service Pack 2 is compatible with either .NET framework 4 or .NET Framework 4.5, and with either Silverlight 4 or Silverlight 5.]
This is the first in a two-part article series on the WCF RIA Services Domain Context.
This article series is accompanied by source code, which can be downloaded here.
Almost a year ago, I posted a lengthy article on how to implement Async Validation with RIA Services and DataForm. It was hard; much harder than it should have been, and we all knew it. Since then, things have changed, and async validation is a lot simpler. Let’s take a look at why it’s easier and how you can easily perform async validation in your application.
For those of you familiar with the ViewModel (or MVVM) pattern, you are likely also familiar with a typical pain point regarding validation: you often need to duplicate your entity validation metadata onto your ViewModel classes. This can lead to burdensome dual maintenance of your validation rules, and it can seem very frustrating that with the server to client metadata propagation that RIA Services offers, your ViewModel classes are left dangling out there for you to manage yourself. In this post, I’ll illustrate a utility I created that allows a ViewModel to assume validation metadata from model classes or properties, eliminating the dual maintenance.
In our last post, we learned how ValidationContext can be used to provide and consume state and services for validation methods to use. Now, let’s take a quick look at how validation methods can actually use this information. I’m going to include a bunch of code in this post, and I will rely on the code to be rather self-explanatory.
Throughout this series on RIA Services Validation, I’ve mentioned and shown ValidationContext several times. In this post, we’ll learn about the purpose of ValidationContext, what types of context it can provide, and how it integrates with RIA Services. This will allow us to explore further topics such as cross-entity validation and open the door for other advanced validation scenarios.
In my last post, I went over some cross-field validation scenarios and provided some sample code, including a CompareValidatorAttribute. We’ve now covered single-field validation and cross-field validation, but there’s yet another level of validation supported by RIA Services—Entity-Level validation. As you’ll see in this post, entity-level validation is very similar to what we’ve already seen.
I frequently hear questions about how to perform cross-field validation in RIA Services. Before thoroughly covering this topic*, I wanted to be sure to go through some simple scenarios, show how to use CustomValidationAttribute, how to derive from ValidationAttribute, explain how validation rules are propagated to the client, and what triggers the validation. Hopefully by now, you’re getting pretty comfortable with the validation framework and you’re ready to explore some more examples.
My goal with this blog post series is to provide an end-to-end tour of how RIA Services validation works and how you can leverage its capabilities to build rich, responsive applications. A key factor for making the most of validation is fully understanding when and how RIA Services invokes your validation rules. Awareness of the various validation triggers will help you implement your validators so they are fired as you expect, when you expect. In this post will dig into the RIA Services codebase and identify every place where entity validation is invoked.
We just covered Custom Validation Methods, where we learned how to use CustomValidationAttribute to invoke a static (VB: Shared) method to perform validation. Let’s talk about an alternate approach to custom validation though: creating custom, reusable validators by deriving fromValidationAttribute. While it’s true that the custom validation methods used by [CustomValidation] could certainly be reusable, I tend to think of that approach as a light-weight way to call specific business logic routines for validation. The approach we’re about to see is what I use when I’m creating an inventory of validators to be reused throughout my project(s).