Visual Studio Save

Hi @Sid Kraft ,

As I mentioned in your previous question, a “dirty” file means there are changes in your code that haven’t been saved yet. In this state, Visual Studio detects modifications, but they only exist in memory and can be lost if the machine restarts or there is a power interruption.

If you have already saved the file (for example, by clicking Save or using Ctrl + S) but still notice that the changes are lost after restarting your computer, I recommend following the steps I shared in your previous message to help identify the root cause.

I would like to sincerely apologize for the frustration and inconvenience this issue has caused you. I completely understand how upsetting it can be to lose work, and I truly regret that your experience has been so disappointing. Please be assured that I am here to support you and will do everything I can to help you get to the bottom of this.

If possible, please share any additional details about your environment or what you are experiencing. This will help me better assist you and move toward a solution.

Thank you again for your patience. I truly appreciate your cooperation, and I’m here to help you through this.

Ok, so the system only saves "dirty" files? What in the world is a "dirty file" and how does one make the current file "dirty"? Sid Kraft

"Save All" in Visual Studio saves all dirty documents, projects, and the solution to disk. It is the correct command for persisting code changes. If changes disappear after closing and reopening Visual Studio, typical causes are:

1. Files or project not actually dirty

• Visual Studio only saves items marked as modified ("dirty").
• The environment determines what to save by checking each open document and project item via the running document table and IsItemDirty/IsDocDataDirty.
• If the editor or project system does not report the item as dirty, it will not be saved even when "Save All" is used.

2. Custom or nonstandard project/item persistence

• Some project types or custom components own their own persistence model and must implement IPersistFileFormat, IVsPersistHierarchyItem, and IVsPersistHierarchyItem2 correctly so that the IDE can save them when "Save All" is invoked.
• If a project or item does not implement these correctly, Visual Studio may build successfully (because it uses the in-memory state) but not persist changes to disk.

3. Confusion between build output and source files

• Building or rebuilding (Build, Rebuild Solution) compiles the current in-memory source into binaries; it does not itself guarantee that source files are written to disk.
• The correct sequence for persisting code is: edit → ensure documents are dirty → use File > Save All → then build/rebuild.

4. Settings and state persistence vs. code persistence

• Visual Studio automatically saves certain environment and window settings (for example, window layout, last document view) into .suo, solution, or project files, but code changes are saved only when the document or project items are persisted as described above.

To diagnose in this scenario:

1. After editing but before closing Visual Studio, verify that the document tab shows the unsaved marker (typically an asterisk) and that File > Save All is enabled.
2. Immediately after Save All, confirm the marker disappears and that the file timestamps on disk change.
3. If timestamps do not change, the project or editor type may not be correctly reporting dirty state or implementing persistence.

If this is a standard C++ project type and the issue persists, it likely indicates a problem with the project’s persistence or environment configuration, and further investigation of the specific project type or extensions involved is required.

References:

• Saving a Custom Document
• Composite Patterns for Visual Studio
• Project Persistence
• Build and clean projects and solutions in Visual Studio
• Compile and build in Visual Studio
• Make code work in Visual Studio