.NETpad 2025: File Operations Rewrite (Premium)

Flush with my success in rewriting .NETpad 4.0 from scratch and reimplementing features in reverse, I moved on to file operations--New, Open, Save, Save As, and Close--next.

The goal? To implement file operations as a standalone C# class that's separate from the MainWindow class. I've referenced this need throughout the app a few times, but only in passing. But as .NETpad has grown more sophisticated, my ham-handed design, in which the core app feature have been modularized into separate files (Backend.cs, AppSettings.cs, FileOperations.cs, and so on) but most are just part of the MainWindow class that was originally defined in MainWindow.xaml and MainWindow.xaml.cs, has become problematic. This, AI has complained, is too many lines of code for a single class.

Fair enough. Creating standalone C# classes for specific functions like file operations is architecturally "better." But it also brings some complexities along for the ride. When everything is in the same class, visibility into and access of other parts of the app are simple, as there are no permission boundaries to worry about. That is, a method or variable or whatever in, say, Backend.cs can reference anything in any other file that's part of the same MainWindow class. Which is/was a lot of the app. (Assuming the visibility of those things is public, etc.)

But standalone classes can be challenging (to me) and I've had some successes and some defeats. Before the rewrite, for example, I successfully created an AppState class to handle what I think of as app-level variables. These were global to the app (via App.xaml.cs) or the MainWindow (via MainWindow.xaml.cs), and they handled things like the zoom level, whether spell checking is enabled, and so on. Less successfully, I looked at moving the tabs-related functionality in Tabs.cs into its own class or into DocumentTab.cs. And I couldn't get to a point where doing either made any sense.

But file operations, thankfully, has landed firmly in the win column. As I write this, I've successfully moved the file open, save, and save as functions into the new class. The new operation doesn't need to be part of the class, and described below. And I will get close to work, for sure, but it requires some extra attention as described below and will come next.

So let's turn file operations into a class.
?️ Making file operations more classy
The new version of the app still has a FileOperation.cs file, but this time it defines a standalone class called FileOperations. It started out like so.

I don't believe this class needs a constructor: I will just create an instance of the class when needed, run whatever method--for open, save, save as, and so on--and that's that. File operations are temporary.

Naturally, I would start with New.
? New
For this app, the New operation could be considered "new document," "new tab," and/or new DocumentTab. In Windows Presentation Foundation (WPF), New is one of many built-in commands in...