uno
uno copied to clipboard
unoplatform
Unable to use binding on XAML files with code-behind missing a base type
Current behavior
<views:StatusView DataContext="{Binding StatusViewModel}" />
WASM(maybe other) show this error:
error CS1061: 'DependencyObject' does not contain a definition for 'SetBinding' and no accessible extension method 'SetBinding' accepting a first argument of type 'DependencyObject' could be found (are you missing a using directive or an assembly reference?)
Expected behavior
No response
How to reproduce it (as minimally and precisely as possible)
No response
Workaround
No response
Works on UWP/WinUI
Yes
Environment
Uno.UI / Uno.UI.WebAssembly / Uno.UI.Skia
NuGet package version(s)
3.12.0-dev.2
Affected platforms
WebAssembly
IDE
Visual Studio 2022
IDE version
preview 7.0
Relevant plugins
No response
Anything else we need to know?
No response
Thanks for the report. Can you provide a sample repro for this issue? DataContext binding is supported, but you may have hit an edge case.
Sure. Sorry, I was not able to repeat this in a clean Uno project, but remove all unnecessary from this. ratbuddyssey-datacontextbug (1).zip
Thanks for the repro.
This is not a behavior we'll be able to fix in Uno, as the type in question is not known during the XAML generation (it is generated by another generator). This will be the case until there's a way in Source Generators to define dependencies or multiple passes.
The only way to work around this is to make the base type known explicitly (e.g. in FileView, specifiy an actual base type).
I think it's not about the generator. I was able to reproduce this in another project where I am not using other generators: H.ReactiveUI.CommonInteractions-master.zip
The issue is this time caused by the fact that there's no explicit base class defined on the class PreviewDropView. Uno does not support this yet.
The first reproduction, by the way, defines the ViewBase classes inside the .Net Standard library, so this shouldn't be a problem either. This should work even if the code behind files are empty.
It should indeed. The workaround is to add the base type explicitly in the code-behind file.