weixin_39587010
weixin_39587010
2021-01-11 09:36

Suggestion: Allow custom ValidationResult in CustomValidationAttribute

I want to create custom ValidationResult class by deriving from it in order to include some additional information about the error. For example ValidationSeverity (Warning, Error), etc.

However, CustomValidationAttribute only allows validation methods that returns System.ComponentModel.DataAnnotation.ValidationResult.

E.g.:

csharp
public class CustomValidator
{
  //this is allowed
  public static ValidationResult Validate(object o) 
    => return new CustomValidationResult(…)

   //this is not allowed, but I think it should be
   public static CustomValidationResult ValidateCustom(object o) ...
}

See: https://github.com/dotnet/corefx/pull/33766

该提问来源于开源项目:dotnet/runtime

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

9条回答

  • weixin_39587246 weixin_39587246 4月前

    Always use master for everything. Of course you can ask someone to help you port PRs to other branches, assuming you want them there - you have to fight for them in shiproom after all. The key point is that each PR has to be first in master before it can be considered to backporting to servicing branches. Normal internal bar for servicing .NET Core applies (even for community contributions to release branches).

    Does it help?

    why is it closed? If it is something we would take, we should keep it open and set milestone to Future + up-for-grabs (if you have guidance what to do). If you are sure you will never ever do it, then closing is fine. If it is just too far out, I'd recommend to keep it opened + milestone:Future (aka no commitment).

    点赞 评论 复制链接分享
  • weixin_39573822 weixin_39573822 4月前

    That would be a misuse of both the milestone and the up-for-grabs label. The up-for-grabs label means that this is a good entry-level issue for somebody to work on. It does not in any way indicate whether or not we will work on it. Also, the lack of this label doesn't mean that we wouldn't take a contribution for it, just that it's not an easy first issue.

    The milestone indicates when something is planned to be worked on. Putting the issue in the Future milestone means we are planning that somebody at some point in the future will get to this issue and work on it. This is not the case here. This issue will never be implemented by us because it's simply not high enough priority. The only chance it will get done is if somebody in the community wants to work on it.

    点赞 评论 复制链接分享
  • weixin_39587010 weixin_39587010 4月前

    : I would like to get this very small change to single line of code to .NET Core 3 release. All tests passed, no breaking change. How do I fight for it? You are the area owner, right? :)

    点赞 评论 复制链接分享
  • weixin_39573822 weixin_39573822 4月前

    No need to fight for it. Thanks for submitting the PR--I'll take a look.

    点赞 评论 复制链接分享
  • weixin_39573822 weixin_39573822 4月前

    Fixed by community PR for .NET Core 3.0. Thanks !

    点赞 评论 复制链接分享
  • weixin_39573822 weixin_39573822 4月前

    This is not something we plan to implement. However, we would consider a community PR. Keep in mind that it must be 100% non-breaking to existing code.

    点赞 评论 复制链接分享
  • weixin_39587010 weixin_39587010 4月前

    I will do PR. To which branch should I request, please?

    点赞 评论 复制链接分享
  • weixin_39573822 weixin_39573822 4月前

    Which branch should be targeted by community PRs?

    点赞 评论 复制链接分享
  • weixin_39556702 weixin_39556702 4月前

    As far as I know everything should be against master and can then be backported to other branches as needed.

    点赞 评论 复制链接分享

相关推荐