Investigate non-reflection alternatives to current sample system

[Arlodotexe]

Overview

The current sample system works like this:

1. Sample pages are decorated with a ToolkitSampleAttribute containing metadata about the sample.
2. A reference to a sample project is added to an app head.
3. When the app is loading, it iterates through all loaded assemblies.
4. When it comes across an assembly with "sample" in the name, it searches for Pages, then for the ToolkitSampleAttribute.
5. If the data is found, it pulls the page in and makes it available for viewing.

The problem

The highly dynamic nature of this approach also brings a potential problem: tree shaking. Any system that trims out unused code paths, such as .NET Native or the IL Linker used in WebAssembly, will trim out entire sample projects due to being unreferenced.

This may not be an immediate problem, but I've made systems like this before and it always becomes a problem, especially when dealing with multiple of them like we will be. Since we need to have this nailed down for the templates, preemptively solving this may be a good idea.

The solution

Get rid of reflection entirely. Alternatives have been briefly discussed before. (see source generators and registry system), both of which can be templated pretty easily.

Source generators have the advantage of not changing our API or templates if we implement post-release, but will take much longer to implement, so we should investigate that last.

Keep in mind that no matter what solution we go with (including keeping the current one), the template system will need additional scripting to add project references to the multi-sample app, so we'll have that tool at our disposal.

Other ideas are encouraged! 👇

[michael-hawker]

There's also things like T4 templates, but I believe those require additional config sometimes to get to run which can be frustrating; though I haven't noticed any issues as of late with our use of them in the .NET Community Toolkit. @Sergio0694 what are your thoughts on them?

I mean we don't really need to utilize a source generator's ability to update them in real-time. Main thing would be if we could identity the sample info either pre-or-mid build to compile a static class like structure or something that contains all the metadata and type pointers. Then this can just be loaded directly rather than having to be parsed/introspected at runtime. Right?

Attributes are pretty easy to spot/parse too, so in the simplest form we could just have something walk the files, pull out the attributes (and what they're attached to) and generate the extra C# file to compile, right?

[Arlodotexe]

Did some tests, looks like it's more than possible.

From these attributes

Using this code

I've generated this

This is a PoC, but it should completely solve our issue! I'll begin working on a PR tomorrow 😎