Replace existing Resource.designer.cs System by using Reference assemblies.

[dellis1972]

Android Resource Assemblies

This idea is a replacement for the current Resource.designer.cs system
that exists in Xamarin.Android.

Problems with the current system.

The current implementation relies on us generating code which is then
updated via reflection on application startup. Reflection is generally
slow so it is best avoided, especially on mobile platforms.

We have another issue, the code which updates the Resouce ids must be
done for each assembly that has a Resource.desinger.cs. This means that
as you add more assemblies, your startup time will increase.

Lets use Reference Assemblies

So the new idea is going to make use of Reference assemblies. These
are assemblies which are designed be replaced at runtime.

So for class libraries what we do is instead of compiling the designer
code into the class library , we instead generate a refernce assembly
which has the Resource.designer code in it. This Resource class will
be in a KNOWN namespace. So the namespace is common across ALL assmblies.
Rather than the individually namespaced classes we have today.

For the main app we generate a normal assembly which contains ALL the resources
for the app in the Resource.designer code. This will not be a reference
assembly, it will be a standard (maybe even netstadard) assembly. This is
the only one which will be packaged in the applicaiton.

Because the class libraries are using reference assemblies, they should intheory
pick up this normal assembly at runtime.

How it will work

We will use our existing code to generate the Resource.designer.cs file, this will
then be compiled into the new assembly. For class libraries we include the
[assembly:ReferenceAssembly] attribute. The new genearted code will NOT include
the current UpdateIdValues method as it will not be required.

For apps, we do the same as above except we exclude the new attribute producing an
actual assembly. This assembly will also NOT require the UpdateIdValues method as
all the ID's in it will be the FINAL id's. Because the class exists in a specific namespace
(say Xamarin.Android.Resource.Designer) all the class libraries should be able to
resolve it.

We can then remove all the reflection code which calls UpdateIdValues.

Example

Create a netstandard2.0 class library with the following code.

using System;
using System.Runtime.CompilerServices;

[assembly:ReferenceAssembly]

namespace Xamarin.Android.Resource.Designer
{
    public class Resources
    {
        public partial class Id
		{
			public static int actions = -1;
        }
    }
}

This will generate a Reference assembly.

Next create a class library which has the following code

using System;

namespace Class1
{
    public class Class1
    {
        public int Foo () {
            return Xamarin.Android.Resource.Designer.Resources.Id.actions;
        }
    }
}

Then reference the first Reference assembly project.

Next create a netstandard2.0 library with a class with the actual desginer values.

using System;
using System.Runtime.CompilerServices;

namespace Xamarin.Android.Resource.Designer
{
    public class Resources
    {
        public partial class Id
		{
			public static int actions = 2131165207;
        }
    }
}

Next create the app program which references the class library and the FINAL designer assembly.

using System;

namespace App
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
            Console.WriteLine($"{Xamarin.Android.Resource.Designer.Resources.Id.actions}");
            Console.WriteLine($"{new Class1.Class1 ().Foo ()}");
        }
    }
}

This will output the following when run

Hello World!
2131165207
2131165207

As you can see the refernce assembly gets replaced by the final one. And the class library
reads the actual values.

We would need to write our own MSBuild task to generate this new assemby rather than making
a user create them, but this does prove the concept will work.

How do we migrate?

One of the issues we will have is how to deal with legacy code which exists in nuget files.

We could introduce a linker step for both relase and debug which will migrate to the new
system. This could be done by altering the existing class to derive from the new Resource
designer class, and clear out ALL of the fields. This in theory should still expose the
fields to the existing namespace.

public class Resources : Xamarin.Android.Resource.Designer.Resources {

}

[dellis1972]

One other issue is how do we support people using Nuget packages built with the new system on older Xamarin.Android versions... do we even bother?

[grendello]

I think it's a great idea. The only question that pops in my mind is about the size of the final assembly, but it probably doesn't matter much since it would be the same size as it is now. For runtime performance it would be beneficial if all the classes in the assembly were both static and sealed, the JIT can generate a bit more efficient code for accessing them then.

[dellis1972]

The RemoveResourceDesignerStep should still be able to function (with some tweaks). So we can still optimise the release builds to remove this new assembly completely.

[jonathanpeppers]

This idea does seem like it would be better, because:

1. ResourceIdManager and it's use of System.Reflection could go away.
2. We don't copy lots of fields at startup.

The issues are around: "how do we create these extra assemblies?"

1. These assemblies have to be available during design-time builds for Intellisense. So it has to be fast & work the same as before.
2. It doesn't seem like we should call <Csc/> independently? Does that mean we should use Mono.Cecil or System.Reflection.Metadata to generate these new assemblies with fields inside?

[dellis1972]

We could call <Csc/> for this. I don't think it would be that much slower.
The design-time build will still need to work and be quick, so that is something we need to be mindful of.

[dellis1972]

I can prototype a Cecil generator and test that against a Cs call, see which is quicker.

[grendello]

Could the design time assembly be in memory only? Generated using System.Reflection.Emit for instance?

[jonathanpeppers]

It might also be worth checking if type forwarding would work better for this idea than reference assemblies.

[jonpryor]

Had a chat w/ @grendello recently, and I had a modification for this idea: instead of Xamarin.Android.Resource.Designer.Resources containing static fields, instead have static properties:

namespace Xamarin.Android.Resource.Designer
{
    public class Resources
    {
        public partial class Id
        {
            public static int actions => 2131165207;
        }
    }
}

The reason for this is JIT-time overheads: with static fields, every field is set in the static constructor. If you have 30k fields, the static constructor sets 30k fields, and needs to JIT a method that sets (and references!) 30k fields, and -- when unlucky -- the interpreter blows up because the method is too big. ;-)

With static methods, as above, every method is small -- no static constructor with 30k fields -- and the JIT can potentially inline them. Methods also provide possible flexibility in the future, should we think of different implementation approaches.

[grendello]

And static methods will be JIT-ed only when called

[AmrAlSayed0]

Would it be possible to make these static properties just return the original properties?

namespace Xamarin.Android.Resource.Designer
{
    public class Resources
    {
        public partial class Id
        {
            public static int actions => Xamarin.Google.Android.Material.Resources.Id.actions;
        }
    }
}

This will also work whether Xamarin.Google.Android.Material.Resources.Id.actions is a property or a field.

[dellis1972]

@AmrAlSayed0 I'm afraid that won't work in this context. Since the value for Xamarin.Google.Android.Material.Resources.Id.actions which would be in the Android.Google.Android.Material.dll is just a place holder. The actual final ID is not known until we build and link the final application.
If we used the items directly we would have to go though every assembly and update the values with the final values. Which is something we are trying to avoid.

[bddckr]

As an F# user I wonder what this change means for my projects? As a note: The F# type provider that provides access to the IDs at compile time hasn't been working for several years now.

Would this allow F# projects to consume the IDs in a way that they are available at compile time, preventing the need for a C# helper project just for this (or use Resources.getIdentifier at runtime)?

[dellis1972]

@bddckr I'm not entirely sure ,it should make things better for F# users in theory. We won't know until we try.

[dellis1972]

So I hacked together a basic version of this, and in principal it seems to work at runtime at least.

Problems I have found so far are mostly related to release mode. We get a linker error

error XALNK7000: Mono.Linker.MarkException: Error processing method: 'System.Void MyLibrary.MainActivity::OnCreate(Android.OS.Bundle)' in assembly: 'MyLibrary.dll' ---> Mono.Cecil.ResolutionException: Failed to resolve System.Int32 Xamarin.Android.Resource.Designer.Resource/Layout::main_get()

This is despite the Xamarin.Android.Resource.Designer assembly being loaded already. I'll need to dig into this to see what is causing it.

[jonathanpeppers]

Failed to resolve System.Int32

What is the TargetFramework of the assembly you generate? Seems like System.Int32 might be type-forwarded, like it is netstandard?