(Xaml Markup Elements) switch issue level for xaml related methods to warning for first build or after added new element which hasnt be build till then

What would you like to be added

See Edit Note in reasoning, there seem to be a fix for wpf solutions you might could replicate for fixing? Else: Add a "first time" marker to xaml using elements in project file or other codebehind for the compiler, that disables errors/issues coming from unrecognized e.g. InitializeComponent() Methods caused xaml at/after build/compilation or alternativly set them for before first build to just warning if possible
Add a c#-Markup using ContentDialog Template to the chooseable Templatelist which visual studio uses on Add>New Item
If it is possible to influence the generator of the csproj file, please add the capability to it to first look up the named itemgroups & items in it and maybe make it more sorted? If the named path/file is not longer existing, it should not add duplicates of them, else if it is not exsisting (mostly relevant in pre release state), just let it delete the item group thats not longer needed.

Why is this needed

Everytime on creating a uno/xaml involving solution for the first time or after adding the Solution issue list is telling that e.g. InitializeComponent() is not defined, along other xaml related Methods/Propertys, underlined in red (normally indicating that this has to be solved before actual build & debugging, but since its no "real" issue the developer can search for his live and never find the problem that is causing this. With adding the Issue modification the developer would see the issue as a warning, but a warning level issue is known to be there but the solution should build with that and after building it is normally be gone so resolved itself.

[Added Edit Note:] Researching for existing workarounds of other Developers in internet for the curious case of the duplicate Pages Warning, I found this report which is quite matching to the behaviour (including screenshots and comments of many users) I expirienced with point 1 of my list. https://developercommunity.visualstudio.com/t/Second-time-reporting:-WPF:-C-Editor-ca/10532548 In the middle of the quite neverending story there it seems to be fixed, but if you scroll to the end (August 2024!), where the problem in WPF Applications seems to be fixed, they are explicit mentioning UNO and MAUI applications:

It turned out Maui and Uno projects were built completely differently, and they don’t use the same product code in WPF projects, which were being updated to address the original problem reported in this thread. Based on that, the fix made for the original reported issue would not fix the problem in either Maui or Uno project, or on the other word, the WPF project related code or the code generation was not executed, although the experience might have some similarities in those projects.

Please report the problem you saw in Maui projects as a separated issue, which can be looped to the owner.

In case you created a application with c# Markup and decide to need a ContentDialog, you would normally do this in visual studio: Folder/Solution>RightClick>Add>New Item this will prompt you the template manager to choose a template from the list and set its name. Because all uno templates are listed as c# Elements the estimation would be, to get a cs file like e.g. MainPage with its MainModel like the rest of the solution structure. But what it will give you is a ContentDialog.xaml and under this a ContentDialog.xaml.cs so someone who was happy to just have to learn c# to develop a uno application, will have to learn xaml additional and be promted the mentioned issue from 1.
Behaviour of duplication good described here (for WPF) https://developercommunity.visualstudio.com/t/duplicated-xaml-file/119138 But additionally it is telling me on my device, that the ContentDialog file is already existing. I think that is caused by the naming: ContentDialog1.xaml ContentDialog1.xaml.cs seems like it is thinking the one with .cs ending is duplicate of the xaml only...

For which platform

WebAssembly, Android, iOS, Mac Catalyst, Skia (WPF), Skia (Linux X11), Skia (macOS), Skia (Linux Framebuffer), Skia (GTK), Windows (WinAppSDK)

Anything else we need to know?

Additional (I do not know were this would belong correctly): Could you add a kind of automatism for the time inbetween, while we have to add xaml files to a c# markup application, that disables the possibility to add a ContentDialog templated file into the Presentation folder? I already had a few times the issue, that the dublicated page warning throws me a issue because of this, so please take a look into that, so editing the csproj file to clean up not longer existing paths/files manually would not longer needed.

Workarounds?

copy from the mentioned forum above of one of the posts, giving a quite goot summ up of possible (not tryed out) workaround:

The issue is expected to be corrected in a 17.11.xx release. Until then the work arounds are to:

Close the solution, delete the .vs, OBJ and BIN folders, then reopen the solution (this is what I’ve been doing) Toggling between Debug/Release modes and rebuilding Creating a new Class, building and then deleting the class Open VS alone (ie “Continue without code”) then open your solution from File>Open>Project/Solution

Thanks for the report. I'm not too sure what the issues are. Could you provide repro steps that explain the behavior that you think is incorrect or could be improved?

@jeromelaban its kind of a known issue (see link I provided which is showing the same "InitializeComponent() is not known maybe missing reference" Problem. I did speak about that with @mikernet who do have some more experience than me in dev things. I listed this not recognizing as enchanement because it is most of the time no "really" issue, more kind of annoying, thats why I asked if it could be set to warning if it is prompted to the developer. It is most of the time happening in connection with xaml and idk what the compiler actually did miss to set so its happening. At this moment I do not having that issue, because it happens (like mentioned in the link) kind of randomly and most of the time in freshly created solutions, which wasnt build until that point. Yes, you are absolutly right, if you are saying, "hey, thats kind of a reason we are telling in Getting started Guide to build the solution in the first steps". My point on Mentioned Point 1 is: Lets say you are a newbe with that whole xaml and codebehind cs and first thing it is prompting you are a whole bunch of issues. As a newbe you would not be able to differ between all of that issues you dont know and from the point the user did not work with xaml before, a error message in visual studio would tell that this is a critical problem, which will cause the compiler to not be able to build your solution. A Warning would not do that. With a active Warning message the dev user would see it but more likly dont worry much and try to build the solution. Most cases that would solve Point 1 of my list. Is that understandable? Yes, I would say, with generally solved that, like it seems to be happened in wpf, would be the best case so we are not needing this workaround, but since it is not relyable reproduceable on demand because most of the time solved after building the solution or new added component, I am not able to give you the requested solution. Sorry.

Did that answer your question? Other Questions to the other points?

@jeromelaban I think the issues being referred to here are: 1) Add C# markup-based templates for common controls (i.e. Page, ContentDialog, etc) 2) InitializeComponent() often shows as not being recognized when a new control is added until the project is built

Thanks @DevTKSS, it does.

Add C# markup-based templates for common controls (i.e. Page, ContentDialog, etc)

This is a good idea indeed, though I don't think VS will allow to filter templates and both the XAML and markup ones would appear at the same time. Let's track in https://github.com/unoplatform/uno/issues/18690.

InitializeComponent() often shows as not being recognized when a new control is added until the project is built

This is generally a WinUI problem, as uno uses code generators that take effect almost instantly. Do you see it still happening if net8.0-windowsX.XX is not in the TargetFrameworks list?

@jeromelaban Sorry for not answering your last question, actually I did not noticed your replyed information in my inbox. Actually, I had it here in this repo and did a commit and push to my github repo on this app here, I was trying to get familiar with the xaml and mvux: https://github.com/DevTKSS/MyUnoXamlApp.git see the commit history on that. BUT in the time between, we (mikernet worked with me on that to inspect the issue that might be causing that on my project and helped me out when stuck learning a bit. Hard learning curve for me) are thinking, that on that particular repo project the source of the not recognization might be more on the x:Bind he listed as issue to you here: unoplatform/uno#18710

At the moment, I can not provide a example repo where the InitializeComponent() Issue is present, just that it is most of the time happening on not build projects or on files which are newly added to the project, so also not build > Background generators not runned, and I will have a look, if it happens again, if it is also on projects without the windows target like you said. If it would be possible technically, we might could temporarily close this issue or similar until there is any future information to follow to the issue root object?

unoplatform / uno.extensions