NonSerializable/XMLIgnore Attributes with ICommand/ObservableProperty attributes

[Aurumaker72]

Describe the problem

A way/special attribute to be used in conjunction with ICommand or ObservableProperty which signalizes the backing field not to be serialized

Describe the solution

  [ICommand]
  [SpecialXMLIgnore]
  private void DoSomething()
  {
     MessageBox.Show("Hello");
  }

Example which should compile to

[XmlIgnore]
private IRelayCommand? doSomethingCommand;
public IRelayCommand DoSomethingCommand => doSomethingCommand ??= new RelayCommand(DoSomething);

Alternatives

No response

Additional info

No response

Help us help you

No response

Hello, 'Aurumaker72! Thanks for submitting a new feature request. I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future!

[michael-hawker]

FYI @Sergio0694 this was in the WCT repo, @Arlodotexe we may want to touch base on Monday quick and look at our GitHub Issue categories or something and call out MVVM Toolkit better to redirect here, as I've been noticing a few issues still getting filed over for WCT.

Also linking back to this comment here by @skint007 which was the same request:

Would it be possible to have Attributes carried over to the generated public properties?

Example:

[ObservableProperty]
[NotMapped]
private Person? _selectedPerson;

Currently it doesn't look like they are applied.

[timunie]

Forwarded post /idea

#8 (comment)

[michael-hawker]

Bubbling up the solution proposed by @timunie:

I think other Attributes can be added like AlsoNotifyChangeFor.
Would be

[AttributeDecorator(nameof(MyAttribute))]
private string myField;

That wouldn't account for if extra constructor arguments are needed though.

Would we be able to use params or something to take-in any constructor arguments? i.e.

[AttributeDecorator(nameof(SerializeThing), "SomeOption = true", "SomeOtherOption = 3")]
private string _myField

// To Generate:
[SerializeThing(SomeOption = true, SomeOtherOption = 3)]
public string MyField { get; set; }

Not sure if anything better than a raw string could be used...

Then once dotnet/csharplang#3412 is implemented, this could just all go away in a future version? (but at least still be relatively simple to migrate back over?)

[Sergio0694]

As a related work item, I think we should try to get more traction on that proposal and talk to the Roslyn folks.

cc. @333fred you can see not having access to partial properties is causing a significant amount of issues for us here.
I'd be happy to help with a proposal if you'd be willing to champion this, if you think that could be helpful to get this going 😄

[Sergio0694]

So, there is one big elephant in the room here: not all attributes are valid on both fields and properties.

We need to remind ourselves that what we're doing today in the MVVM Toolkit is just a "best effort", but we'll just never be able to actually land on a "perfect" solution until C# actually gets support for partial properties (see dotnet/csharplang#3412). That said, we can try to make this at least a bit better. What we could do is: for all attributes on a field marked with [ObservableProperty] that is not one of ours, check whether the attribute type also supports properties as targets. If it does, forward it. If it does not, just ignore it. This would help with some scenarios (eg. [JsonIgnore] would work), but not all. I could implement this if we all agree it'd be at least better than what we have today.

Thoughts? 🙂

cc. @michael-hawker @Arlodotexe @Insire @timunie @powerdude, @sonnemaf?

[powerdude]

I like the idea above. Also, to complete the picture and for those scenarios where an attribute can't be on a field, but can be on a property, I think consideration should be made for the AttributeDecorator mentioned above. Maybe call it AlsoAddAttribute

[timunie]

So, there is one big elephant in the room here: not all attributes are valid on both fields and properties.

I am happy with whatever you choose. But tbh, I think "forwarding" an attribute may lead to unpredictable situations:

• You want the attribute for the field, but it can also be added for properties ► wrong forwarded
• I want an attribute to be forwarded, but it failed. Will I ever know this?
• The attribute should only apply to the property, but not for the field itself. Will this be possible?

Happy coding
Tim

[Sergio0694]

Yes, that is what made me not do this in the first place. I do have many issues with this.
As I said, I really don't see a "perfect" solution here, the fact remains that this approach is just fundamentally troublesome.
This is why for now I've only special cases the validation attributes and only had them being forwarded to properties.

Honestly I'm kinda leaning towards only doing so (especially since we're close to 8.0 stable), just saying that special atributes need a manual property for now, and then potentially revisit this post 8.0, or just push for getting partial properties in C# 12.