Surprised about being surprised?
I have often said that I have stopped being surprised about what happens over in Redmond, WA. Clearly Microsoft continues to build the best tools for developers but every once in a while Microsoft does something that makes me go, Hmmmmmmmm.
Today's hmmmmm moment is sponsored by the SUO file. What is the SUO file you ask? It stands for Solution User Options and if you look in the project folder of one of your projects, you're not going to find one. These particular files are marked as hidden and you will need to go into your Windows Explorer settings to allow your Explorer window to show them.
So what is this file? This file is used by Visual Studio to persist any IDE configuration changes associated with that project. Things like the dimensions of the Visual Studio IDE window, breakpoints, start-up project, etc. The purpose of the file is to store configuration options unique to your instance of Visual Studio. Checking the Blog-o-Sphere, the public opinion is that these files are not intended to be stored in VSS or SourceSafe and should not be copied from PC to PC. Some articles say that copying a project folder with the SUO file from one PC to another could cause unexpected behavior.
Ok, so what's the concern you ask? My concern is regarding the sample projects with ship with our learning courses. Should I include the SUO file or shouldn't I? Public opinion (and common sense) seem to suggest that these files are superfluous and aren't required--arguable they could even pose problems for the recipients. So I remove them... and for many years, everything appears status-quo.
Until recently.
Out of the blue we begin to receive support requests regarding the Silverlight sample files and they aren't loading properly. We go back to our test machines, test the solutions, everything looks fine and we re-post them. Same problems are reported. After further investigation it is discovered that by deleting the SUO file the Silverlight projects stop working. Hmmmmmmmmm.
Well, Visual Studio defaults the startup project to the first project when it doesn't have the SUO file. This, in our Silverlight projects, will generate errors until the user sets the startup project to the Web project. Looks like a Catch-22. Although we are encouraged to remove the SUO when transporting projects, this cannot guarantee that the receiving PC will be able to run it; at least not with an understanding of the possible issues.
Looks like I will be looking into this further to see if there is a way to get our projects to force a different order; hoping to get the first project to be the one I want. Do you have a better solution?
What is your policy regarding the SUO files?