Project Structure in WPF

A default WPF application created from Visual Studio's 'WPF Application' template contains a small, fixed set of files: an App.xaml/App.xaml.cs pair defining the application object, a MainWindow.xaml/MainWindow.xaml.cs pair for the first window, an AssemblyInfo.cs, and an SDK-style .csproj with <UseWPF>true</UseWPF> and a Windows-specific target framework like net8.0-windows. Beyond that starting point, WPF doesn't mandate any particular folder layout, so most real projects adopt an MVVM-oriented structure with Views, ViewModels, Models, and Services folders to keep UI, presentation logic, and business logic cleanly separated.

App.xaml declares the Application class and typically sets StartupUri to MainWindow.xaml, which tells WPF which window to open when the app launches; it's also where app-wide resource dictionaries, themes, and global styles are merged so they're available to every window. App.xaml.cs is the code-behind partial class for Application, and overriding OnStartup(StartupEventArgs e) there is the standard place to run startup logic — reading command-line args, setting up dependency injection containers, or choosing which window to show programmatically instead of relying on StartupUri.

Most non-trivial WPF codebases group files into Views/ (XAML windows and UserControls), ViewModels/ (classes implementing INotifyPropertyChanged that expose bindable properties and ICommands), Models/ (plain data classes), and Services/ (things like data access or navigation abstracted behind interfaces) — mirroring the MVVM pattern rather than WPF enforcing any specific layout. A common naming convention pairs each view with its view-model by suffix, e.g., CustomerListView.xaml with CustomerListViewModel.cs, which makes it easy to navigate the codebase and keeps the binding relationship between the two obvious even without an explicit file-system link.

Shared styles, colors, and control templates typically live in separate ResourceDictionary XAML files under a Resources or Themes folder — for example Colors.xaml and Styles.xaml — and get pulled into scope by merging them into App.xaml's Application.Resources using a MergedDictionaries collection. Because those merged dictionaries are attached at the application level, any window or control anywhere in the app can reference a resource like {StaticResource PrimaryButtonStyle} without re-declaring it, which is how WPF apps implement consistent theming and, with a bit more work, runtime theme switching by swapping which dictionaries are merged.

Adding a new top-level window means adding a new Window item (via Visual Studio's Add > Window template), which generates a paired .xaml/.xaml.cs file just like MainWindow; adding a reusable piece of UI meant to be embedded inside other windows means adding a UserControl instead, which is composed the same way but hosted inside a parent rather than shown with .Show() or .ShowDialog(). Both Window and UserControl files need their XAML's x:Class attribute to exactly match the namespace and class name declared in the code-behind partial class, since the XAML compiler uses that attribute to generate the InitializeComponent() wiring.