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

0
0

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:

csharp
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:

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

.NET Core Designer generates:

csharp
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

  • You must to post comments
0
0

Hi Bill,

thanks for reporting this. It’s already been reported, fixed internally and currently in QA.
Happening for .NET 9.0 only.
Wisej.NET 4.0.1 release is scheduled for tomorrow.

Best regards
Frank

  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.