[NotifyPropertyChanging] Question & Issue

[RealDotNetDave]

I'm looking at this package and have two questions about [NotifyPropertyChanging].

1. As the class author, how do I implement validation of the properties? I don't see how that can be done. I have the same question about another source generator I found.

2. When I do use [NotifyPropertyChanging], the build fails with errors like this: Missing XML comment for publicly visible type or member 'TestClass.SetFieldAndRaisePropertyChanging<T>(out T, T, string)' This happens for the properties too. If I document the field, that documentation is not carried over to the generated property.

Please advise. Thanks!

[CollinAlpert]

Hi and thanks for the issue!

1. Do you mean validation using the attributes from the System.ComponentModel.DataAnnotations namespace? If so, that is not possible right now, but I can see if it is possible to add the validation attribute to the field and have it carried over to the property.
2. What error code is that? Is it a CS or a CA error? I assume the compiler or analyzer is not correctly picking up the file as auto-generated and thus is not ignoring it. Documentation not being carried over to the properties is a known issue. XML comments are represented as trivia by the compiler and I currently have no trivia support in the library.

Thanks for raising this issue, I will work on a fix on the weekend!

[CollinAlpert]

Regarding your compilation error, you need to configure CS1591 to ignore generated files. You can do this by adding the following snippet to your .editorconfig file.

[*.g.cs]
dotnet_diagnostic.CS1591.severity = none

[CollinAlpert]

As of version 2.1.1, comments are now carried over to the generated properties. Also, properties from the System.ComponentModel.DataAnnotations namespace are carried over to the generated properties. Let me know if this helps!

[RealDotNetDave]

Let me explain better. No, not talking about DataAnnotations, but custom code to verify strings, numbers, etc. For example, I usually code this in the property setter. You can see what I mean by going here: https://github.com/RealDotNetDave/dotNetTips.Spargine/blob/main/source/6/dotNetTips.Spargine.6.Tester/Models/RefTypes/PersonProper.cs

Yes, the analyzer is picking up the generated file. When I write code or write or speak about it, I always document public and protected members. Source generators should too, just like the RegEx source generator from Microsoft.

I hope this is more clear.

[CollinAlpert]

Thanks for the explanation. If you have a lot of custom code, you're going to be better off manually creating your properties. There's no real benefit Source Generators can give you in this case.

While I agree that public and protected members should be documented (I follow this practice in Lombok.NET itself), I don't think builds should fail due to generated code. Nonetheless, I will add some documentation to the generated code in the next release.