Suffer from Ctrl+S fatigue? We have a feature for you

Dante Gagne

The idea of the “Integrated Development Experience” is a tool that brings all the systems a developer needs to develop their application into a single place. Coding, debugging, publishing, profiling… these are all tools that Visual Studio brings to our developers. Just as a general contractor doesn’t solve every problem with a hammer, however, we’re aware that Visual Studio isn’t the only tool in the developer toolkit.

One pain point we’ve been hearing about more and more is one that comes up when switching from one tool to another. Specifically, when you arrive at your other tool if you’ve been using Visual Studio without saving your code, that code shown in your other tool may be out of date. Then, when you edit the code in the other tool, your code is out of sync and it’s an ordeal trying to put everything back together.

Starting with 17.2 Preview 1, the new autosave feature will help with this. Use Visual Studio Search (Ctrl+Q) and look for “autosave”. That will take you to the Environment\Documents page in Tools\Options.

A screen capture of the Visual Studio Options dialog. It has the Environment\Documents page selected and highlights the "Automatically save files when Visual Studio is in the background" option with a red rectangle. The option is checked.

If “Automatically save files when Visual Studio is in the background” is checked, any time Visual Studio loses focus, usually as you change to another application in Windows, VS will attempt to save every dirty document in the IDE. This will include project files, solution files and even miscellaneous files that aren’t part of the project or solution. If saving a file fails for any reason (for instance, the file is read-only on disc), Visual Studio will keep your changes in the editor and simply leave the file dirty. The intent is that when you switch to another tool, after a moment, all your changes in VS will be committed to disk. While most developers will benefit from this, code files on slower disks or on remote servers will make a lot more save operations, and developers should keep that fact in mind when enabling autosave.

It’s worth mentioning that folks who are taking advantage of the “Code Cleanup on Save” feature from 17.1 will find that autosave does not trigger a Code Cleanup. We felt that it would be somewhat disruptive if it happened too often. Code Cleanup on Save will only trigger when you explicitly save the file, either through a command like Ctrl+S or implicitly as part of a build.

What do you think?

We’ve had suggestions in the past that some developers would like an even more aggressive autosave mechanism. Some developers would like Visual Studio to commit their changes to disk when Visual Studio goes idle after a set amount of time has passed. Another suggestion is to save when switching documents. If you’re the kind of developer who would find that useful, we’d love to hear from you. You can join the conversation here.

Please let us know how this feature works for you. Are you using it? Is it being too aggressive or not aggressive enough? How could we improve it? Please let us know your thoughts. We read all the suggestions provided on Developer Community as well as the comments on this blog post.