We are trying to bind to a model that has a Guid value that is required. A simple example would be:
public class UserModel
{
[Required]
public Guid UserId { get; set; }
}
After updating to RTM we get the following error:
Value-typed properties marked as [Required] must also be marked with [DataMember(IsRequired=true)] to be recognized as required. Consider attributing the declaring type with [DataContract] and the property with [DataMember(IsRequired=true)].","
We've tried adding the [DataMember] and [DataContract] attributes accordingly and still no luck.
I can't find anything online that would speak to why this problem starting appearing and what we need to do about it.
[Required] checks whether the attribute is null, and a value type is not nullable.
If the serialized UserModel does not contain a "UserId" property, then the XML and JSON formatters will both assign a default (all-zero) value.
I just tried adding the [DataMember] and [DataContract] attributes and that worked for me. This will make the UserId property required for the XML formatter.
I'm sorry, I should have clarified. This is the value we are trying to RETURN from a WebAPI call. The call makes it to the ApiController successfuly, and we are populating the model to return. The model does contain a valid UserId value. For some reason,
the Json serializer is now choking with this error when trying to return the data back to the client.
Before RTM, we didn't have to decorate the class with the [DataContract] and [DataMember] attributes. We could simply use the [Required] attribute on the property. Immediately after the upgrade to RTM, we started receiving this error after the ApiController
method finished.
My 2 cents are that Guid is not a nullable object and the constructor creates Guid.Empty if there is no value. So the work-around is to use nullable guid.
[DataContract]
public class UserModel
{
[DataMember(IsRequired=true)]
public Guid? UserId { get; set; }
}
Please "Mark As Answer" if the post helped you.
mitja.gti | www.mitjagti.com
In RTM version the default Json serializer got changed to JSON.net hence the change in behaviour for previously working code.
User DataMemberRequiredAttribute or JsonPropertyAttribute or use existing IsRequired but mark valuetype propeties to nullable (e.g Nullable<Guid> UserId {get; set;} ).
What seems to fix it is to set [DataMember(IsRequired=true)] on [Required] properties, and [DataMember] on all other properties, plus setting [DataContract] on the class.
But why is this now necessary? It makes no sense, it was so pretty to just set [Required] on required properties and then use model validation. But now we have to add DataMember attributes all over.
But why is this now necessary? It makes no sense, it was so pretty to just set [Required] on required properties and then use model validation. But now we have to add DataMember attributes all over.
Totally agree. When i saw that attributes like [Required] moved to the new DataAnnotations assembly, i thought they decided to reuse these attributes. I mean i thought they decided allow librariries to decide, what [Required] or [MaxLength] means in their
context. I thought they decided to allow other libraries to interpret these attributes by their own, instead of reinvention of personal wheel for every library...
I'm afraid that in next versions will demand M+1 attributes for every property, were M is version number.... I don't know, how these attributes will be named, but this does not matter at all. May be i will have to jump away of webapi boat to plain MVC, uisng
some tweaks like custom JSONActionResult and JSONValuesProvider classes.
The similar problem described in this issue http://aspnetwebstack.codeplex.com/workitem/270
Remove the validation logic in config help me to solve the problem:
GlobalConfiguration.Configuration.Services.RemoveAll(
typeof(System.Web.Http.Validation.ModelValidatorProvider),
v => v is InvalidModelValidatorProvider);
landersen
0 Points
3 Posts
MvC 4.0 RTM broke us and we don't know how to fix it
Aug 16, 2012 10:35 PM|LINK
Folks,
We are trying to bind to a model that has a Guid value that is required. A simple example would be:
public class UserModel { [Required] public Guid UserId { get; set; } }After updating to RTM we get the following error:
Value-typed properties marked as [Required] must also be marked with [DataMember(IsRequired=true)] to be recognized as required. Consider attributing the declaring type with [DataContract] and the property with [DataMember(IsRequired=true)].","
We've tried adding the [DataMember] and [DataContract] attributes accordingly and still no luck.
I can't find anything online that would speak to why this problem starting appearing and what we need to do about it.
Any ideas? Any and all help would be appreciated.
Thanks.
Kiran Challa
Participant
1442 Points
281 Posts
Microsoft
Re: MvC 4.0 RTM broke us and we don't know how to fix it
Aug 16, 2012 10:53 PM|LINK
Hi, what is the issue that you are seeing? Isn't your model state Invalid if you are not sending the UserId?
Kiran Challa
MikeWasson
Member
486 Points
78 Posts
Microsoft
Re: MvC 4.0 RTM broke us and we don't know how to fix it
Aug 16, 2012 11:12 PM|LINK
[Required] checks whether the attribute is null, and a value type is not nullable.
If the serialized UserModel does not contain a "UserId" property, then the XML and JSON formatters will both assign a default (all-zero) value.
I just tried adding the [DataMember] and [DataContract] attributes and that worked for me. This will make the UserId property required for the XML formatter.
- Mike
landersen
0 Points
3 Posts
Re: MvC 4.0 RTM broke us and we don't know how to fix it
Aug 16, 2012 11:31 PM|LINK
I'm sorry, I should have clarified. This is the value we are trying to RETURN from a WebAPI call. The call makes it to the ApiController successfuly, and we are populating the model to return. The model does contain a valid UserId value. For some reason, the Json serializer is now choking with this error when trying to return the data back to the client.
Before RTM, we didn't have to decorate the class with the [DataContract] and [DataMember] attributes. We could simply use the [Required] attribute on the property. Immediately after the upgrade to RTM, we started receiving this error after the ApiController method finished.
Thanks.
mitja.GTI
Star
11157 Points
2094 Posts
Re: MvC 4.0 RTM broke us and we don't know how to fix it
Aug 16, 2012 11:37 PM|LINK
My 2 cents are that Guid is not a nullable object and the constructor creates Guid.Empty if there is no value. So the work-around is to use nullable guid.
[DataContract] public class UserModel { [DataMember(IsRequired=true)] public Guid? UserId { get; set; } }mitja.gti | www.mitjagti.com
MikeWasson
Member
486 Points
78 Posts
Microsoft
Re: MvC 4.0 RTM broke us and we don't know how to fix it
Aug 16, 2012 11:39 PM|LINK
Then I don't think you need the [Required] attribute in this scenario?
ARJindal
Member
4 Points
1 Post
Re: MvC 4.0 RTM broke us and we don't know how to fix it
Aug 17, 2012 01:21 AM|LINK
In RTM version the default Json serializer got changed to JSON.net hence the change in behaviour for previously working code.
User DataMemberRequiredAttribute or JsonPropertyAttribute or use existing IsRequired but mark valuetype propeties to nullable (e.g Nullable<Guid> UserId {get; set;} ).
Hope this helps.
steingran
Member
2 Points
1 Post
Re: MvC 4.0 RTM broke us and we don't know how to fix it
Aug 18, 2012 02:42 PM|LINK
Struggling with the exact same error here.
What seems to fix it is to set [DataMember(IsRequired=true)] on [Required] properties, and [DataMember] on all other properties, plus setting [DataContract] on the class.
But why is this now necessary? It makes no sense, it was so pretty to just set [Required] on required properties and then use model validation. But now we have to add DataMember attributes all over.
KonstardiyFr...
Member
2 Points
1 Post
Re: MvC 4.0 RTM broke us and we don't know how to fix it
Aug 19, 2012 02:05 PM|LINK
Totally agree. When i saw that attributes like [Required] moved to the new DataAnnotations assembly, i thought they decided to reuse these attributes. I mean i thought they decided allow librariries to decide, what [Required] or [MaxLength] means in their context. I thought they decided to allow other libraries to interpret these attributes by their own, instead of reinvention of personal wheel for every library...
I'm afraid that in next versions will demand M+1 attributes for every property, were M is version number.... I don't know, how these attributes will be named, but this does not matter at all. May be i will have to jump away of webapi boat to plain MVC, uisng some tweaks like custom JSONActionResult and JSONValuesProvider classes.
ArthurShvets...
Member
2 Points
1 Post
Re: MvC 4.0 RTM broke us and we don't know how to fix it
Aug 19, 2012 03:36 PM|LINK
The similar problem described in this issue http://aspnetwebstack.codeplex.com/workitem/270
Remove the validation logic in config help me to solve the problem: