Overuse of NotClientImplementable attribute

[AlexeyTliss]

Currently we had three instances where NotClientImplementable was a stumbling stone for us, which caused a lot of extra work where we could avoid it:

1. We needed custom IClassicDesktopStyleApplicationLifetime and ISingleViewApplicationLifetime implementation for Headless tests, since app heavily relies on certain lifetime functions. In the end, we had to use hackish workaround by instancing DesktopLifetime via lambda-compile activator and set Avalonia's builder private _lifeTime field value to this instance every time app is instanced, otherwise Headless tests just won't work

2. When we discovered a memory leak in ContentControl (it won't let go of bindings which refer to static content or singleton viewmodels) we tried to to make it's ancestor or implpement IContentPresenterHost ourselves only to find out we can't do it because of NotClientImplementable (this was in 11.0, things may be different in 11.2), in the end, we had to use hacks

3. Now, we found out that StorageProvider.OpenFilePickerAsync causes either access denied (if use dbus) or segfault (if use gtk) on one of our target platforms - Astra Linux. To our suprise, legacy OpenFileDialog works just fine! So, since we need IStorageItem api for most of other platfroms like Android, IOS and Browser, the solution was simple: call OpenFilePickerAsync through a wrapper which call either StorageProvider.OpenFilePickerAsync on platform where this works, or calls OpenFilePickerAsync.ShowAsync() and then returns our own implementation of IStorageItem which take file path in consturctor and just use basica OS functions like File.Create, easy! Well, except IStorageItem is NotClientImplementable so now we have to use ugly workarounds like these https://pastebin.com/Z85kpU9L

There also people who had issues with NotClientImplementable similar to ours:
#17267
#17275

Please, please reconsider the overuse of this attribute. If user wants to implement an unstable api which may broke on any update - let it be their own problem. Don't be a code police with a baton

[timunie]

I honestly think it's better to try fixing the underlying issue and provide a PR this would also create packages in the all feed for you.

[AlexeyTliss]

The problem is, this will take a huge amount of time being fixed/merged (Avalonia staff oftenly told that reviewing PRs is very high-cost) if this ever happens at all, and I could implement a fix by myself by either creating a custom implementation of IStorageFile or by manually creating BlcStorageFile, neither of which I can do. Instead, I spent a whole day basically creating wrappers for IStorageFile and re-implementing BlcStorageFile under different name,

Basically, you deny us a way to quickly fix things by our own, and wait for a fix which may never come

[stevemonaco]

Can you explain why <AvaloniaAccessUnstablePrivateApis>true</AvaloniaAccessUnstablePrivateApis> is not sufficient? It does cover [NotClientImplementable], too.

[AlexeyTliss]

It is! Thank you!
But how was I supposed to know about it? :)

[stevemonaco]

It's not prominently mentioned because it will inevitably lead to extra maintenance and filed issues when there are breaking changes (which can happen on any release, not just major versions). At least that's how I understand the decision. It works as a filter for dedicated Avalonia app devs and allow Avalonia to be distributed as packages instead of a monolith.

[AlexeyTliss]

I see
Thank you for your replies! Issue solved

[robloo]

@maxkatz6 Why is IStorageItem locked down? Applications should be allowed to implement this I think -- especially if they are running on custom hardware and embedded systems.

https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Base/Platform/Storage/IStorageItem.cs

Edit: Maybe its the API isn't considered final? For things like Delete and Move I would normally expect those to be in a different class rather than the reference to the storage item itself.

[maxkatz6]

Applications should be allowed to implement this I think -- especially if they are running on custom hardware and embedded systems.

I would define two different use cases here:

• Custom backend with its own rules. In this case, PrivateAPI access is required either way.
• Standard unix software, which only needs custom file picker, while keeping standard FileInfo/DirectoryInfo based implementation. For this scenario, we have managed file dialogs, which should be customizable enough (if not enough, can be extended).