Talkin’ ‘bout my generation: How the Uno Platform generates code, part 2 — Under the hood

We’re inheriting from DependencyObject and defining a DependencyPropertyusing the standard syntax, which uses the DependencyObject.GetValue and DependencyObject.SetValue methods. On UWP these are defined in the base class, but if DependencyObject is an interface then there is no base class. In fact if it’s just an interface then the code won’t compile, because the interface hasn’t been implemented.

Luckily DependencyObject isn’t just an interface in Uno, and the code above will compile as-is on Android and iOS, just as it does on UWP. Code generation makes it happen. Here’s some programmer art to illustrate the point. The detailed explanation is below.

On UWP, UIElement inherits from the DependencyObject class.

Multiple inheritance — not an option.

In Uno, DependencyObject is an interface, with the implementation automagically supplied by code generation.

We face a weaker form of this problem — wanting to have two base types — in other cases as well. In a few places in the framework, we inherit from a more derived native view type. For example, ScrollContentPresenter inherits from the native scroll view on Android and iOS. But we also want ScrollContentPresenter to expose the methods and properties of FrameworkElement.

We successfully addressed both of these problems by using code generation to implement mixins in C#.

Mixing things up

Most statically-typed languages don’t permit multiple base classes on account of the added complexity it brings, a.k.a. the ‘diamond problem’. (C++ is a notable exception.) In dynamically-typed languages, however, it’s quite common to bolt on extra functionality to a class in a reusable way with mixins.

C#, as a statically-typed language, doesn’t support mixins as a first-class language feature. Code generation allows us to simulate it, though. Uno uses code generation to add mixins in (at least) two different ways.

I’ll start with the simpler approach: using ‘T4’ templates. To quote Microsoft’s documentation:

In Visual Studio, a T4 text template is a mixture of text blocks and control logic that can generate a text file. The control logic is written as fragments of program code in Visual C# or Visual Basic. In Visual Studio 2015 Update 2 and later, you can use C# version 6.0 features in T4 templates directives. The generated file can be text of any kind, such as a web page, or a resource file, or program source code in any language.

Source: https://docs.microsoft.com/en-us/visualstudio/modeling/code-generation-and-t4-text-templates?view=vs-2017

T4 templates (‘.tt files’) have been around for quite a while. They’re essentially a mix of static text (which is C# code, in our case) and conditional logic. Here’s a snippet:

namespace <#= mixin.NamespaceName #> 
{ 
    public partial class <#= mixin.ClassName #> : IFrameworkElement 
    {  
    #if !<#= mixin.IsFrameworkElement #> 
        /// <summary> 
        /// Gets the parent of this FrameworkElement in the object tree. 
        /// </summary> 
        public DependencyObject Parent => ((IDependencyObjectStoreProvider)this).Store.Parent as DependencyObject; 
#endif 
 
#if <#= mixin.HasAttachedToWindow #> 
    partial void OnAttachedToWindowPartial() 
    { 
        OnLoading(); 
        OnLoaded(); 
    } 
�

That’s from the template which adds IFrameworkElement functionality in Uno. It implements properties like Width/Height, Opacity, Style, etc. At compile time, the template runs and creates a partial class with those members for ScrollContentPresenter and several other classes (including FrameworkElement itself).

The T4 approach is well-tested and works well in this scenario. It has a couple of limitations though:

1. It requires manual set-up: each class that wants to use the mixin has to be explicitly registered.
2. It requires manual flags to make sure that the generated code doesn’t ‘step on’ the authored code, eg by generating a Foo() method when the authored code already defines Foo().
3. It doesn’t support external code. You can’t use the mixin above in your app (short of copy-pasting the templates into the app).

For that reason, in order to have a mixin to implement DependencyObject‘s features, we went with something a little more complex and a little more magical.

DependencyObjectGenerator — Making the magic happen

The release of Roslyn, aka the ‘.NET Compiler Platform’, was a boon to code generation. With Roslyn, Microsoft open-sourced the C# compiler, but they also exposed a powerful API for code analysis. With Roslyn it’s easy to access all the syntactic and semantic information that the compiler possesses.

To leverage this power for code generation, we created the Uno.SourceGeneration package. Like the Uno Platform, it’s free and open source. It creates a build task and allows you to easily add generated code based on Roslyn’s analysis of your solution. This might be partial class definitions which augment existing types, or it might be entirely new classes.

In Uno, this used by the DependencyObjectGenerator class. This generator looks for every class in the solution that implements the DependencyObjectinterface, like our MyBindableObject example above. For each such class, it automatically generates the methods and properties of DependencyObject.

Since the generator has a full set of semantic information from Roslyn, it can do this in a smart way. For instance, if it detects that the class is a view type, it adds methods to update binding information when the view is loaded or unloaded.

Here’s a small snippet of code from DependencyObjectGenerator:

private void WriteAndroidAttachedToWindow(INamedTypeSymbol typeSymbol, IndentedStringBuilder builder)
			{
				var isAndroidView = typeSymbol.Is(_androidViewSymbol);
				var isAndroidActivity = typeSymbol.Is(_androidActivitySymbol);
				var isAndroidFragment = typeSymbol.Is(_androidFragmentSymbol);
				var isUnoViewGroup = typeSymbol.Is(_unoViewgroupSymbol);
				var implementsIFrameworkElement = typeSymbol.Interfaces.Any(t => t == _iFrameworkElementSymbol);
				var hasOverridesAttachedToWindowAndroid = isAndroidView &&
					typeSymbol
					.GetMethods()
					.Where(m => IsNotDependencyObjectGeneratorSourceFile(m))
					.None(m => m.Name == "OnAttachedToWindow");
				if (isAndroidView || isAndroidActivity || isAndroidFragment)
				{
					if (!isAndroidActivity && !isAndroidFragment)
					{
						WriteRegisterLoadActions(typeSymbol, builder);
					}
					builder.AppendLine($@"
#if {hasOverridesAttachedToWindowAndroid} //Is Android view (that doesn't already override OnAttachedToWindow)
#if {isUnoViewGroup} //Is UnoViewGroup
					// Both methods below are implementation of abstract methods
					// which are called from onAttachedToWindow in Java.
					protected override void OnNativeLoaded()
					{{
						_loadActions.ForEach(a => a.Item1());
						BinderAttachedToWindow();
					}}