WPF main window not showing for Debug build - wpf

Question

I'm working on a C# project with WPF in Visual Studio. My application was building and running perfectly yesterday. As far as I know, I haven't made any changes to the build process.
Today, when I try to run a Debug build, it builds and deploys correctly, and a process starts, but the application startup window never displays (not even in the Windows Taskbar). I tried to attach the Visual Studio Debugger to the process as recommended in this (external) link, but the process is grayed out in the Visual Studio > Debug > Attach to Process... popup. It does not display even if I browse to the Debug folder and double-click the *.exe file.
The unusual thing about this is that if I run in Release rather than Debug, everything works fine. I've checked the Project > Properties > Debug configurations; Debug and Release are identical (I just used the defaults when I created the project). Other projects also work fine in both Debug and Release build. I tried comparing the *.csproj and *.sln files, but I couldn't find any significant differences.
I've tried searching for this, but it's really difficult to find anything useful. This question is unrelated, since the window does not even appear in the taskbar in my case. If I try to include the word "debug," I get a flood of questions about redirecting output to the console, which is not my problem.
I'm not sure what code/configurations are relevant to this question, so please let me know if you need more info about the setup.
Edit 1:
I tried putting a break in the InitializeComponent() method in the auto-generated part of my App class:
public partial class App : System.Windows.Application {
private bool _contentLoaded;
/// <summary>
/// InitializeComponent
/// </summary>
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("PresentationBuildTasks", "4.0.0.0")]
public void InitializeComponent() {
if (_contentLoaded) {
return;
}
_contentLoaded = true;
#line 5 "..\..\App.xaml"
this.StartupUri = new System.Uri("Views\\MainWindow.xaml", System.UriKind.Relative);
#line default
#line hidden
System.Uri resourceLocater = new System.Uri("/MyProject;component/app.xaml", System.UriKind.Relative);
#line 1 "..\..\App.xaml"
System.Windows.Application.LoadComponent(this, resourceLocater);
#line default
#line hidden
}
/// <summary>
/// Application Entry Point.
/// </summary>
[System.STAThreadAttribute()]
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("PresentationBuildTasks", "4.0.0.0")]
public static void Main() {
MyProject.App app = new MyProject.App();
app.InitializeComponent();
app.Run();
}
}
This will break for either Debug or Release if the code is between if(_contentLoaded) { and _contentLoaded = true; but everywhere else in the method, I get "The breakpoint will not currently be hit. No executable code of the debugger's target code type is associated with this line." I get the same message if I try to put a breakpoint anywhere in the Main() method.
Even though Debug breaks at the certain interval mentioned above, it still does not display if I continue.
Edit 2:
Things are starting to get weird. Since the project is backed up in Git, I rolled all the way back to the first commit and to several others along the way. I still couldn't get anything to display for Debug, but Release still worked fine. I even tried deleting the local repo and recloning it, but no success. The stranger part about this is that everything runs fine from the backup folder. Why does the folder name make a difference?

Answer 1

I never found out what caused the issue to occur in the first place, but I was eventually able to come up with two workable solutions.
As described in the edit: Copying the solution directory to another directory and running it from there works for some reason.
For some reason, running Debug|Any CPU didn't work, but running either Debug|x86 or Debug|x64 did.
It's unlikely that someone else will run into my exact situation, but I'm leaving my solutions here for posterity. Maybe someone else can benefit from this.