Create AssemblyInfo.cs for .NET MAUI Project Template

[LanceMcCarthy]

This PR adds a file names AssemblyInfo.cs to the Properties folder. The AssemblyInfo.cs file has a single, simple responsibility; enable XAML Compile by default.

Description of Change

This brings the .NET MAUI project template up to the same XamlC standard that Xamarin.Forms used. This was/is a known headache for developers who are not aware about the topic.

If you're not familiar with XamlC (XAML Compilation), this assembly attribute allows developers to use externally defined XAML components without requiring them to define an x:Name or create a dummy instance in C#.

Without those precautions, an exception will be thrown at runtime stating that there is an unknown type.

Example

For example, if a developer has a library with a control named "MyButton". The developer references that library and attempts to use MyButton in XAML like this:

<ContentPage xmlns:myControls="MyControlsLibrary">
    <myControls:MyButton Content="Click Me" />
</ContentPage>

You would expect it to work... but it will not. There's a runtime exception stating that MyButton is an unknown type.

The solution is to choose one of the following options

Solutions

Option 1- Enable XamlC (using a class level or assembly level attribute)**

This is the most reliable and dev-friendly option because we can do it in the default template without dev-user intervention. We also provide the developer with some other advantages of XamlC by default!

We could add it to the MauiProgram.cs file like this:

[assembly: XamlCompilation(XamlCompilationOptions.Compile)]
namespace MauiApp._1;

public static class MauiProgram
{
    ...
}

However, that's not best practice. The standard for this is to have an AssemblyInfo.cs file in the Properties folder. This lets the developer know it is an assembly wide attribute.

Option 2 - Give every control in all the XAML places, an x:Name property value**

This is unreasonable and easily forgettable.

Option 3 - Create a dummy instance of that component in somewhere in the project's C#**

This is also clumsy and unreasonable to ask the dev-user to do this.

Conclusion

The most reliable and dev-friendly option is to just enable XamlC at the assembly level so that the custom components will work in every XAML file.

That is why in this Pull Request, I have made the small change to the default project template maui-mobile, which contains Option 1 implemented in an AssemblyInfo.cs file.

[ghost]

Hey there @LanceMcCarthy! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[LanceMcCarthy]

This should also fix #7503

[PureWeen]

I don't think we can do this by default because having full XAMLC enabled slows down the debug dev loop. That's the main reason ValidateOnly was added here xamarin/Xamarin.Forms#7407 .

To fix this we'll most likely need a less aggressive fix like @StephaneDelcroix indicates here
#7503 (comment)

[LanceMcCarthy]

Thanks for the feedback Shane. I'll keep an eye on the other conversation (it was actually started by a colleague of mine, I didn't see it until after I already opened this PR).

In the meantime, I will try to make sure our users know about this situation and handle it ahead of time. We can use it in our project templates, but I'll add a comment about the dev loop cost.