Wisej-4 .NET Core Designer removes Name property from NavigationBar Items - Breaking existing code logic

Hello Wisej Team,

I’ve been developing enterprise solutions with Wisej.NET for several years, and I recently migrated from Wisej 3 to Wisej 4. After the migration, I’ve encountered a significant issue with the .NET Core Designer that is breaking our existing application logic.

Environment:

• Wisej 4.0.1-preview.10
• Visual Studio with .NET Core Designer
• Target Frameworks: net9.0-windows / net9.0
• Component: Wisej.Web.Ext.NavigationBar

Issue Description:

While the removal of this keyword is documented and acceptable, the .NET Core Designer is also removing the Name property from NavigationBar Items, which breaks existing code that relies on the Name property for control flow logic.

The Problem:

Our application uses the Name property to identify NavigationBar items in event handlers:

private void navBar_ItemClick(object sender, Wisej.Web.Ext.NavigationBar.NavigationBarItemClickEventArgs e)
{
    navBar.SelectedItem = e.Item;
    Application.Session.SelectedItemName = e.Item.Name;
    
    switch (e.Item.Name) // This no longer works!
    {
        case "niTree":
            Navigation.Navigate(typeof(OrgTreePage));
            break;
        case "niMy":
            Navigation.Navigate(typeof(MyPage));
            break;
        case "niSettings":
            Navigation.Navigate(typeof(SettingsPage));
            break;
        case "niAbout":
            Navigation.Navigate(typeof(AboutPage));
            break;
        case "niData":
            Navigation.Navigate(typeof(SourceDataPage));
            break;
    }
}

Designer Output Comparison:

Traditional Designer generates:

this.niTree.Name = "niTree";
this.niTree.Tag = "{json data}";
this.niTree.Text = "Organizational Tree";

.NET Core Designer generates:

niTree.Tag = "{json data}";
niTree.Text = "Organizational Tree";
// Name property is missing!

Impact:

1. All switch statements based on e.Item.Name will fail
2. Existing code logic must be rewritten to use Tag or other properties
3. This is a breaking change not mentioned in the migration documentation

Why Tag is not a suitable replacement:

• Tag property is meant for storing arbitrary user data
• Name property is the standard way to identify controls in .NET
• Changing all code to use Tag instead of Name is a significant refactoring effort
• Other developers expect Name to work as it always has

Question:

Is this behavior intentional or a bug? If intentional, could you please provide guidance on the recommended approach for control identification in Wisej 4? We’d appreciate any insights on how to handle this transition.

Thank you for addressing this issue.

Best regards,

Bill Kim