Can Uno.Extensions.Markup.Generators be disabled for selected types ??

[ToddGlodek]

According to this article Generating Extensions the markup generator will "scan that project and automatically generate extensions for the types that are found".

I am encountering compile-time errors with the markup code being generated when it encounters any of my generic abstract controls. Suppose I have a generic abstract widget control called MyWidgetAbstract. I will see hundreds of compile time errors related to a file called MyProject.Controls.MyWidgetAbstractMarkup.g.cs.

Is there a way to turn off or disable markup generation for just MyWidgetAbstract ?? Perhaps some kind of attribute ?? I have about a dozen of these generic abstract classes that essentially do Strongly Typed DataContext

public partial class MyPage : Page
{
	public MyPage()
	{
		this.DataContext<MyPageViewModel>((page, vm) => page
			.Content(new Grid()));
	}
}

but that were written LONG BEFORE strongly typed bindings extensions ever existed.

I would eventually love to refactor the code to use strongly typed bindings extensions - but I cannot presently undertake that task. Currently, I just want to get rid of the compile time conflicts.

I like the idea of 'automatically generat[ing] extensions for [all] the types that are found". Ideally, I would prefer to keep automatic generation for all types, rather than turning it off universally, and then re-enabling it for every single class (except for the dozen abstracts).

Is there a way ??

[francoistanguay]

Are the classes actually marked as abstract? Can you give an example of the class declaration?

If that's the case, the generator should ignore those abstract classes @dansiegel

[dansiegel]

The problem isn't the abstract it's the generic... if you have a class like:

public class MyControl<T> : ContentControl

I could see how the generator would struggle with this particularly as we already have a number of generics in the extensions. It isn't really a use case we had accounted for.

[ToddGlodek]

Yes, we would see the following exceptions when trying to compile the code below:

The type or namespace name 'V' could not be found (are you missing a using directive or an assembly reference?)

The type or namespace name 'L' could not be found (are you missing a using directive or an assembly reference?)

/********************  Vendor Provided Classes ************************************/
public class LegacyBase
{
}

/// <summary>
///   This is a legacy business class from a vendor's assembly that we cannot modify.  
///   Has NO UI interaction
/// </summary>
public class LegacySprocket : LegacyBase
{ }

/// <summary>
///   This is a legacy business class from a vendor's assembly that we cannot modify. 
///   Has NO UI interaction
/// </summary>
public class LegacyCog : LegacyBase
{
}

/****************************  Our ViewModels    ************************************/
/// <summary>
/// This is a ViewModel which every consultant points out "is completely the wrong way to use a
/// ViewModel" - but then is not able to come up with a better way to solve the problem of 
/// accessing the various flavors of LegacyBase
/// </summary>
/// <typeparam name="L">A concrete implmentation of the LegacyBase class </typeparam>
public abstract partial class ViewModelAbstract<L> : ObservableObject, IDisposable where L : LegacyBase
{
    public abstract void Dispose();
}

/// <summary>
/// This is a concrete implementation of the ViewModel for sprockets
/// </summary>
public class SprocketVM : ViewModelAbstract<LegacySprocket>
{
    public void DoSprocketStuff()
    {
    }

    public void DoMoreSprocketStuff()
    {
    }

    public override void Dispose()
    {
        // Must call Dispose() on LegacySprocket
    }
}

/// <summary>
/// This is a concrete implementation of the ViewModel for cogs
/// </summary>
public class CogVM : ViewModelAbstract<LegacyCog>
{
    public void DoCogStuff()
    {
    }

    public void DoMoreCogStuff()
    {
    }


    public override void Dispose()
    {
        // Must call Dispose() on LegacyCog
    }
}

/****************************  Our UI Controls    ************************************/

/// <summary>
/// This is where we encounter the compile-time errors.  Do not need 
/// Uno.Extensions.Markup.Generators to be generated for this class.
/// Ideally there would be an attribute to disable markup generation for just 
/// this class
/// </summary>
public abstract class MyWidgetAbstract<V, L> : Panel 
    where V : ViewModelAbstract<L>
    where L : LegacyBase
{
}

/// <summary>
/// Would desire Uno.Extensions.Markup.Generators to be generated for this class
/// </summary>
public class SprocketPanel : MyWidgetAbstract<SprocketVM, LegacySprocket>
{
}

/// <summary>
/// Would desire Uno.Extensions.Markup.Generators to be generated for this class
/// </summary>
public class CogPanel : MyWidgetAbstract<CogVM, LegacyCog>
{
}

In a best case scenario, we would place everything that interacts with LegacyBase in a whole separate cross platform library so we could have isolated test cases and a DevOps pipelines.

[ToddGlodek]

Well, at least in my case @francoistanguay is correct. Historically XAML code behind generators have never worked with generic classes, but they have always worked with concrete classes based on the generic. Thats exactly why we have the pattern we currently have - because of the way XAML code behind generators work.

From the compiler errors I observe, it appears that the Uno.Extensions.Markup.Generators are actually working on the derived classes. The compiler errors are in the markup code being generated when it encounters any of my generic abstract controls. I don't need or want the markup code generated for the abstract classes - but there is no way to turn it off. Consequently, the entire project fails to compile.

Ideally, there would be an attribute to disable markup generation for generic abstract classes. As long as it allowed the code generators to operate on any derived class, a C# code attribute like this should eliminate the compile errors:

[UnoExtensionsMarkupGenerators_SkipThisClass]    /*  Don't generate Markup for this class  */
public abstract class MyWidgetAbstract<V, L> : Panel 
    where V : ViewModelAbstract<L>
    where L : LegacyBase
{
}

Can you please take a second look at this issue and share your thoughts.

[francoistanguay]

Have you tried with latest Uno updates? I thought the latest Markup generators were skipping classes with generic arguments now so you wouldn't need to put any attributes.

[ToddGlodek]

I upgraded all the packages related to Markup as follows:

    <PackageVersion Include="Uno.WinUI.Markup" Version="5.2.14" />
    <PackageVersion Include="Uno.Extensions.Markup.Generators" Version="5.2.14" />
    <PackageVersion Include="Uno.Toolkit.WinUI.Markup" Version="5.2.14" />
    <PackageVersion Include="Uno.Extensions.Navigation.WinUI.Markup" Version="4.1.23" />
    <PackageVersion Include="Uno.Material.WinUI.Markup" Version="5.0.13" />
    <PackageVersion Include="Uno.Themes.WinUI.Markup" Version="5.0.13" />

That eliminated all the compile time errors related to a generic

The type or namespace name 'V' could not be found (are you missing a using directive or an assembly reference?)
The type or namespace name 'L' could not be found (are you missing a using directive or an assembly reference?)

However, now there is a new issue that I am documenting in a separate discussion : "Compile-time error in markup generated code related to abstract property (Type 'SprocketPanelMarkup' already defines a member called 'WidgetSize' with the same parameter types)" #16879