doc/articles/migrating-guidance.md
This article explains adjustments that may need to be made to WinUI/UWP-only code for it to run on Uno Platform, be it in an application or a class library.
Certain class definitions will need to have the partial keyword added. This is because Uno generates additional code at compile-time to support them properly.
You'll need to do this for:
FrameworkElement, directly or indirectlyDependencyObjectApart from adding partial, you don't need to worry about the generated code. You may however get misleading errors from Intellisense until the first time you try to compile the project, because the generated partial classes haven't been added yet.
Classes that inherit from FrameworkElement directly or indirectly can't be nested inside another class; it's been observed to cause problems on Xamarin.iOS. If you have any nested FrameworkElement-derived classes, you'll need to refactor them to be top-level classes.
This is relevant if you're targeting Android, iOS, and/or macOS, where Uno views (hence, FrameworkElement) inherit from the native view type. In some cases you may find that a reference to a type from the UWP framework is confused with a native property. The fix in this case is generally to disambiguate by supplying the full namespace of the type.
Some common cases:
Window.Current will be confused with the UIView.Window property. The fix is to fully qualify this as Windows.UI.Xaml.Current.TextAlignment enum will be confused with the View.TextAlignment property. The fix, again, is to fully qualify the reference as Windows.UI.Xaml.TextAlignment.Windows in it?If, for example, your control is defined in the CoolControls namespace, and you've also defined a CoolControls.Windows namespace, then the above will give a compilation error. You'll need to use the global keyword, eg global::Windows.UI.Xaml.Window.Current.
Not all .NET runtime features are supported on every platform. See Migrating - Before You Start for more details.