Refactoring the base namespace after creation of a MVVM project for WinUI3 breaks the code

[gmgallo]

Describe the bug

I ran into this problem while doing tests to find the cause of another nasty problem (see) where at some point the project stops loading and crashes.
To reproduce create a new MVVM WinUI3 project with the TemplateStudio wizard (I have v5.5 installed in VS 2022, preview latest).
Compile and run, works as expected. Then use Edit->Refactor->Rename the base name space (i.e. TSApp to TSApp1 in TSApp.Views, etc.). The refactor apprantly works as expeced in all .cs files. However the generated code is no longer in sync even after deleting bin and obj folders from the project, unloading renaming the projects and project folders as the root namespace. None of this solves the isue. Then refactor again the base namespace to the original namespace all goes back to normal. So, I don't know if this is a TemplateStudio problem or a VS problem because some of the generated code gets the new namespace and some are still generated with the old namespace after deleting the obj folder.
In larger projects even without renaming the base namespace, at some point the problem linked above happens and there is no way back. The only solution I have found so far is to start from scratch, and I suspects tha both problems are related to unresolved namespaces at compile or run time.

To Reproduce

1. Create a new MVVM with Template Studio
2. Compile and run to ensure that the App runs fine.
3. open any .CS file from the project. I use App.xaml.cs.
4. Select the base namespace wiich is the same as the project file.
5. in VS menu go to Edit->Refactor->Rename and change the base namespace.
6. Compile and see the error log.
7. If compiles without errors try to run the program.

Additional context

No response

Applies to the following platforms:

• WinUI
• WPF
• UWP

About your setup

• Visual Studio Version: 17.9.0 Preview 2.0
• Template Studio Wizard Version: 5.5
• Windows Build: 22H2 OS Build 19045.3803

[gmgallo]

Forgot to mention, once you see the error, revert the namespace back to the original, recompile and run. It should run as expected.

[mrlacey]

Without seeing the error messages you're getting, I'd assume it's because you're only renaming the namespaces in the 'cs' files and not the ones in the .xaml` files also.

Can you confirm if Visual Studio's built-in functionality to rename namespaces also makes changes in .xaml files also?

[mrlacey]

A quick check of your repro steps and I see that although the refactor preview doesn't show any XAML fies, it does actually updated the namespaces in them.

However, from the error message that I get:

  HResult=0x80070057
  Message=Page not found: TSApp.ViewModels.MainViewModel. Did you forget to call PageService.Configure?
  Source=TSApp

I can see that the problem is with trying to find the MainViewModel when the app launches.

Searching for instances of that class name I found this:

<NavigationViewItem
     x:Uid="Shell_Main"
     helpers:NavigationHelper.NavigateTo="TSApp.ViewModels.MainViewModel">

It looks like this isn't updated by the refactor.
I think that's acceptable and almost to be expected.
How would the refactor tool (probably based on or using the compiler) know that this string (that just happens to match a namespace and class name) is an assembly that it needs to change?

Anyway, change the "magic" string and it all works again.

I'd argue, it's not a bug in either TemplaeStudio or Visual Studio, just something to be aware of and a reminder not to use magic strings.

[gmgallo]

Hi Matt, thanks for the quick return.

Yes refactor updates namespaces in .CS the XAML files, but it's not smart enough to go after template generated code as you pointed out. What I also noticed is an inconsistency in the compiler generated code, those g.i.cs files where InitializecComponent() is defined. Some, but not all of them still refer to the original namespace.

You are right, it may not be fair to categorize this as a bug, but rather something in the "don't touch" list. What I was up to is to find a way to narrow on the nasty problem that I refer to at the beginning. Nobody has come up with an answer to why that happens or a sure way to fix it, and to me it sounds very similar to this as unresolved namespaces at run time. The exception indicates a supposedly missing Windows dll which is right there with the rest of the app files.
Unlike this case, that problem is impossible to reproduce consistently or revert.