x:Uid can not be set from code-behind

[Balkoth]

Describe the bug

You can not create controls in code-behind cs-files and attach x:Uid and get automatic language string support.

Steps to reproduce the bug

Try creating any Xaml-Control in a code-behind file and set x:Uid on it.

NuGet package version

1.7.250513003

Windows version

Windows 11 23H2

[Jay-o-Way]

Where does it say that this should be possible?

[Balkoth]

I don't know but having the same language support available from code-behind as from xaml seems like a no-brainer to me. Why shouldn't this be possible?

[AndrewKeepCoding]

@Balkoth The WinUI3Localizer might fit your requirements. It uses its own Uid allowing you to get/set it programmatically. For instance:

var awesomeButton = new Button();
Uids.SetUid(awesomeButton,  "AwesomeButton");

(Disclaimer: I'm the author.)

[hiteshkrmsft]

@Balkoth does this help with your ask, or you need further support.

[Jay-o-Way]

I don't know but having the same language support available from code-behind as from xaml seems like a no-brainer to me

xUid is a xaml property. This is not actually a bug, but an expectation.

[Balkoth]

WPF exposes the Uid property on its controls descending from UIElement:

The bug label here is defined:

It's not working to set Uid from code-behind to get localization support, so i consider this a bug.

[Jay-o-Way]

(What I should have asked earlier) Could you please provide some examples of your code? It helps a lot to see what you're doing exactly. The first example is "are you using Uid or x:Uid"?

Also, are you building with .NET WASK or WPF? Note that those are different frameworks.

[Balkoth]

This issue happens when building apps with .NET C# WindowsAppSDK WinUI3. Coming from a WPF app where some controls are created in code-behind and Uid is used for localization. This is currently basically a show-stopper for porting the app.

[hiteshkrmsft]

I have converted this to a discussion for now, as this is not something that WinUI promises to support. We will move it to a feature proposal if it turns out to be a commonly needed scenario or receives significant community interest.

@Balkoth also could you please provide a minimal repro to help us understand your scenario.

[Balkoth]

No because if you don't care to support this either way i am not putting any more work into this. Everything needed to understand the scenario is visible in this thread. As i said this is a show stopper for porting a WPF app to WinAppSDK.