Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
We should ensure that when MD shuts down we only write tabs to the userprefs if those tabs represent files within the solution. A common issue is that debugging can cause mono files to be opened in the editor and then those are reopened the next time the solution is opened.
We also open the same file multiple times if it is written multiple times. This was introduced by the recent optimisations to increase the speed of reopening the previous tabs on startup.
Are we sure we really want this "feature"?
trivial to implement if we decide we want it... I'm just thinking that it might be nice to be able to restore non-project files.
IMO this is a useful feature.
If we're opening the same files multiple times, that's a problem, but it doesn't mean we should throw away the feature.
One oddity I've noticed is that the files that are not part of the solution are persisted into the userprefs, but are not closed. This is inconsistent. It means that if you open and close another solution afterwards, the files will become "attached" to that solution too, which can be annoying.
See also bug 2762.
It's driving me crazy that non-solution files (I'll call them orphan files in
the following) are BOTH remembered together with the prefs for a solution AND
kept open after closing that solution. As mentioned, this means that those
files can easily get "attached" to a whole bunch of different solutions if you
switch between different solutions frequently (like I do).
I can see a number of different ways things can work:
A) SAVE OPEN ORPHAN FILES IN SOLUTION PREFS, KEEP OPEN WHEN CLOSING SOLUTION.
This is how it currently works, and it means orphan files can easily spread
from solution to solution "like a virus". Being passive about the files is a
destructive behaviour that will eventually clutter up all your solutions with
these files. In order to NOT clutter up all your solutions you have to be VERY
careful to close all the right files at the right times (before closing the
projects, that is).
B) SAVE OPEN ORPHAN FILES IN SOLUTION PREFS, CLOSE THEM WHEN CLOSING SOLUTION.
This consistently treats open files as being attached to one project.
C) DON'T SAVE OPEN ORPHAN FILES IN SOLUTION PREFS, KEEP OPEN WHEN CLOSING
SOLUTION. This consistently treats open files as NOT being attached to
D) SAVE ORPHAN FILES IN PREFS ONLY WHEN OPENING THEM, KEEP OPEN WHEN CLOSING
SOLUTION. I don't know how the prefs work and if this solution is compatible
with it, but this solution means orphan files are only saved to the prefs of a
solution when they are OPENED EXPLICITLY; not if they were already open when
the solution was opened. This way they will both stick with the project that
was open when the orphan file was opened, and also stick after that solution is
closed, but the orphan files will not spread to other solutions at least.
Currently MonoDeveloper does A) which is the worst possible solution. I'd be
more happy with either of B), C), or D), though I think B) and C) are most
consistent and easy to understand while D) is kind of a messy concept, only
less destructive than the current A).
As far as I understand, the pleasantness of having certain non-solution files
open together with a solution can also be achieved by the user by simply
including them to the solution. So I think my favorite solution would be C)
since the behavior similar to B) would still be available as a workaround when
you'd want it.
In either case, any of B), C), and D) would be a big improvement over the
It's not correct that including non-solution files in the solution is a viable workaround. If they're not logically part of the solution, then all that does is to pollute the solution, which is far worse than polluting the userprefs.
I fear that D would be nontrivial to implement due to implementation details. Not sure about the behavior, maybe it would be intuitive, maybe not.
B seem simple but the corner case where you have multiple solutions open is messy.
C is simple but we lose a fairly convenient feature. I often open files from outside the solution for reference, and it's useful to have them open again when closing and reopening the solution.
Maybe we should check what VS does.
We just tested this and Visual Studio does B. Visual Studio does not support having multiple solutions open simultaneously it seems so they don't have the problematic corner case.
B has been implemented.