IFileEntryOwner: Prevent ConstructorContainsNullParameterNames when AOT Compiled

[mtbayley]

Description

Closes #6029

How Has This Been Tested?

Tested with Demo App

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality not to work as expected)

Checklist:

• The PR is submitted to the correct branch (master for dev, rel-1.x for maintenance).
• My code follows the code style of this project.
• I've added relevant tests.

[tesar-tech]

To summarize how the bug works (for me and for future reference):

It starts here in js:

Blazorise/Source/Blazorise/wwwroot/fileEdit.js

Line 19 in cd79586

adapter.invokeMethodAsync('NotifyChange', fileList).then(null, function (err) {

which calls a dotnet method, implemented here:

Blazorise/Source/Blazorise/Adapters/FileEditAdapter.cs

Line 30 in cd79586

public Task NotifyChange( FileEntry[] files )

FileEntry contains the property IFileEntryOwner Owner, which has this property:

Blazorise/Source/Blazorise/Utilities/IO/IFileEntryOwner.cs

Line 52 in cd79586

IJSFileModule JSFileModule { get; set; }

This fails to be marked as "unable to be deserialized" due to AOT trimming.

Is that correct?

---

The bug fix works, yes. We can merge it. But I don't like the solution:

• There is [JsonIgnore] appearing out of nowhere within an interface that isn’t supposed to touch JSON at all.
  • Someone will probably (rightfully) question why it’s there.
• How do we know no other properties are causing the same issue? (There’s probably a way, but you really don’t want to have to keep that in mind.)

---

I suggest creating FileEntryDto to clearly define what should and shouldn’t be transferred between js and dotnet.

Similar issues exist on the js side, where some "hacks" are used to avoid serialization:

Blazorise/Source/Blazorise/wwwroot/fileEdit.js

Line 107 in cd79586

Object.defineProperty(fileEntry, 'blob', { value: file });

So we might want to solve it on both sides.

Not part of this PR—we can move this to another ticket.

---

@mtbayley Can you add a simple comment explaining why the attribute is there?

btw thanks for this and for the referenced issue, I had no idea such issues might happen.

[tesar-tech]

just the comment

[mtbayley]

@tesar-tech Yes, you understand the issue correctly. I have run into a similar issue with my AuthenticationStateProvider in my work.

[JsonIgnore] tells System.Text.Json to not bother serializing/deserializing during the NotifyChange invocation.

If you have a better solution, I'm up for testing that as well. I agree, the error only occurs during runtime for a released AOT compiled app. It would be hard to catch during development or testing.

[tesar-tech]

@stsrki what's the strategy?

• merge the fix, create solution for 1.8 (or another pr)
• merge the fix and leave it
• create the solution right here.

[stsrki]

I think we don't even need it. Why can't we remove JSFileModule from IFileEntryOwner? And just call await JSFileModule.RemoveFileEntry( ElementRef, fileEntry.Id ); directly from FileEdit and Markdown?

Or, change RemoveFileEntry as

async Task RemoveFileEntry( IJSFileModule module, IFileEntry fileEntry, CancellationToken cancellationToken = default )
{
    module.RemoveFileEntry( ElementRef, fileEntry.Id );
}

[tesar-tech]

That will just eliminate the purpose of the interface and duplicate the code. The shared functionality is there, because it's the same for both of the classes.

And it wont solve the "might happen for other types that should not be in dto" issue.

[stsrki]

The thing is, we shouldn't have introduced a new API in the 1.7 release. We broke our own rules, basically. At the time, I had wrongly assumed it was not a big change, so it wouldn't hurt. So I would rather to duplicate code then introducing JSON attribute to the interface.

We can optimize it in 1.8.

[tesar-tech]

• It doesn't change the API - the JSFileModule is ignored either way. The attribute just confirm that on AOT.
• I suspect the IFileEntryOwner is more like the "private public" blazorise interface than really an interface for users to utilize.
• I really don't think someone uses the IFileEntryOwner.
• Even if someone does use the IFileEntryOwner, I don't really think someone is eager to serialize the IJSFileModule. Maybe it is even not possible.

The [JsonIngore] attribute won't affect anyone in a negative way.

We can optimize it in 1.8.

sounds like you don't really care. If that's the case, I have no objections against the latest changes.