Thanks for your feedback. We are routing this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team

Hello Kevin,

Thanks for taking the time to send us feedback on Visual Studio. I agree that saving settings on exit does result in some issues, as you’ve noted in this bug. We won’t be able to consider making changes to this for Visual Studio 2010, because of where we are in the product cycle, but we can consider this for a future release.

A developer on the Shell team passed along a macro to me that will save the current settings on demand:

Sub Export()
        Dim path As String = DTE.Properties("Environment", "Import and Export Settings").Item("AutoSaveFile").Value
        DTE.ExecuteCommand("Tools.ImportAndExportSettings", "/export:""" + path + """")
End Sub

If Visual Studio crashes after the macro is executed, when it’s restarted you will see the “VS is configuring settings for the first time” progress dialog and the saved settings will be restored. (The same will happen if you start up another instance of Visual Studio.) If Visual Studio shuts down normally, you won’t see the progress dialog when it starts again (i.e. executing this macro doesn’t affect anything in the normal scenario). I hope this macro is helpful for you as a workaround.

I’m going to close this bug as “Postponed” so we can revisit this scenario for future release planning.

Thanks,
Suzanne Hansen, Program Manager, Visual Studio Platform Shell Team

Hello Kevin,

As I was pressing the send button on my response I noticed that there were 19 people who had rated this bug, for an overall rating of 4.8. This high level of community feedback prompted me to look into this issue further, and I have a few questions for you (and the rest of the community).

The fix to have Visual Studio save settings when they are changed is actually pretty expensive – it’s going to involve a co-ordinated effort across several groups. Unfortunately, at this point in the Visual Studio 2010 product cycle, I’m not going to be able to make this happen. I do want to revisit this when we start planning the next release of Visual Studio.

We started looking into an auto-save solution, since this will not only pick up changes made though Tools -> Options, but also changes made throughout the IDE: e.g. changing Toolbox settings, what the Error List displays, etc. Of course, we’d only make this sort of change if there’s a minimal impact on performance.

Although the above changes are straightforward for fixing the issue for product crashes, the scenario of multiple instances of Visual Studio is not as simple. Here are my questions for you and the community. I want to know what kind of behavior you expect:

- When settings are changed on one instance of Visual Studio, do you expect the other instance to sync with the changes made? (Do you expect fonts and color setting to sync? Window layout settings? Visual Studio may need to restart – this doesn’t seem ideal to me)
- If you don’t expect the instances to sync, how about the following: If instance 1 changes the fonts, overwrite that section of the settings file. If instance 2 modifies the toolbox, overwrite that section of the settings file. When the instances are closed, there is no save all of the settings. When a new instance (instance 3) is opened, it’ll pick up the changes that were made by instance 1 and 2. If any instance overwrites a change to a specific setting that was made by another instance, then the last one to edit that setting “wins”.

These are just some initial ideas that I have… I look forward to hearing more feedback on this. If I can better understand the exact behavior that you expect, it’ll greatly help.

Thanks,
Suzanne Hansen, Program Manager, Visual Studio Platform Shell Team

Suzanne,

Thanks for following up on this.

Auto-save would be a big plus for all of the reasons already mentioned. I would not necessarily expect settings to immediately propagate to other VS instances; that would be nice in a perfect world, but is probably not worth what I imagine would be a lot of extra work.

I imagine it working basically as you outline in your second point: when a settings change is made in a VS instance, that change (and ONLY that change) is saved immediately. If multiple VS instances make changes to different settings, each one saves its own changes and leaves everything else alone. The next time a VS instance is opened, it will have all of the changes made by all of the other instances.

The only tricky part comes when multiple instances make changes to the same settings. The previous changes will make this far less likely (if I make a change and then open another instance, I don't have to make the change again, it will already be there). However, if it does happen, I think "last one wins" is perfectly acceptable. Again, in a perfect world some kind of conflict detection and resolution might be nice (e.g. "This setting was previously changed, do you want to overwrite?"), but is almost certainly not necessary given the amount of work involved and how rarely it should come up.

This issue is also somewhat related to the problem of what constitutes an application setting. The most obvious example is auto-formatting rules, which can change based on a per-solution or even a per-project basis. If these kinds of settings were pushed to the project level instead of the application level, the lack of auto-save for settings would be slightly less painful (although still important).

I also have no expectation around syncing settings across multiple running instances of Visual Studio. Your proposal - each settings area saves its own settings, and conflicts are resolved with last one wins - is totally reasonable.

The biggest headache for me is scenario 2) - I change a setting, and THEN launch a new instance of Visual Studio. It's not a case of multiple instances of Visual Studio already running then changing settings. I expect some issues with that.

As others have said - don't make a mountain out of a mole hill by making it more complicated than it needs to be. Syncing between active windows isn't necessary, expected, or wanted behavior.

My first instinct was also to say that auto-sync isn't needed, until I realized that it's a bit hard to fix the last-one-to-exit-wins problem without it.

I'd suggest the following as a lower cost solution:
1) Settings are saved as soon as you exit the Tools > Options dialog.
2) A change counter is stored in the Registry and used to display a warning on opening Tools > Options if another instance of Visual Studio has changed settings since that instance was launched.

This wouldn't automagically merge settings, but it least makes it clear when you're about to hit a conflict instead of later discovering that some settings have reverted.

@phaeron,

If you are only saving the settings that have actually changed, why is "last-one-to-exit-wins" still a problem? What scenario is your solution trying to fix?

The solution I proposed solves two problems: losing settings if VS crashes, and any ambiguity about what has been saved. The change counter means you at least know when you're about to cause a conflict and can close all instances of Visual Studio so you know exactly what's getting saved out.

I'm mainly concerned about two issues with the partial save suggestion: that it'd be too much work, and the question of what constitutes an area to save. For instance, if I delete an entry from the source server list, does just that entry get deleted, or does the whole list get overwritten?

I guess what I'm trying to say here is that if the individual setting save solution is deemed unimplementable, I'd still rather have a conflict notification than nothing at all.

Settings changes should of course be saved immediately; that removes the problem of the crash scenario.

If removing a server from the list caused the entire list to be overwritten, I would consider that to be a buggy implementation. If you remove a server from the list, then removing that server is the only thing that should change. As long as that is the case, I think "last one wins" is acceptable, without any kind of conflict detection.

This is something that's bugged me for years - I recall having a lengthy discussion with other C++ MVPs and members of the product team on this a few years back.

I agree that the second option in Suzanne's post - each settings area takes care of itself, and multiple changes in the same area suffer from "last one wins" would be a HUGE improvement. In fact, the difference between that and full live sync between multiple running instances would be virtually zero in a real-world scenario (further, live-sync between instances could actually be undesirable in some circumstances).

I'd love to see this in VS201x - it's been an annoyance for way too long!