Save default project(s) in the .sln file
As per http://stackoverflow.com/questions/694730/why-is-set-as-startup-option-stored-in-the-sou-file-and-not-the-sln-file/1808264#1808264 , store the Startup Project(s) selected in the IDE in the .sln file, but allow them to be overridden by Startup Project(s) stored in the .suo file.
Michel Courtine commented
I just wrote a little command line utility for windows called slnStartupProject to solve this. It sets the Startup Project automatically like this:
slnStartupProject slnFilename projectName
I personally use it to set the project after generating the solution with [cmake](http://cmake.org) that always sets a dummy ALL_BUILD project as the first project in the solution.
The source is on github:
Forks and feedbacks are welcome.
Hope this helps!
Praveen Yaramada commented
+1. Totally agree.
This would be quite useful where a solution uses multiple start up files in a specific order. Having this in sln will allow it to checked in to the source control system.
Dawid Ciecierski commented
Definitely agree that this should be seriously considered. While in simple cases (one-two projects) I agree that this may sound as overkill as others have pointed out, but in more complex solutions this would be a huge time-saver.
In our case we have a solution comprising of ~20 projects, five of which have to be started to do any sort of debugging. Selecting them once-twice a day when checking out new dev branches is annoying, and error-prone.
Laurence Evans commented
This is an issue primarily if you require multiple startup projects, there's no way to have this information saved and has to be set everytime you get a clean solution without a suo file.
It is not a big problem in development machine. However, on a build machine, the command line build failed due to different startup project until we loaded the project in VS and set the startup project to set that in the .suo local file.
Antoine Bervoet commented
+1 for this request.
I am currently working on a full solution generation project and can not set my web project as startup... i always must set it by reopening the solution in VS and right clicking.
Not that big issue i agree, but it would help to be able to set this in the .sln file
Trout Man commented
I think you missed the point completely. It's not that a given developer can't figure out how to set a start up project, its that having the ability to set a sane default and have it stick is a *good* thing. Do you disagree that a large percentage of projects usually have a project that serves as the entry point for the solution? Web applications come to mind...
To your second issue, that would work just like it does now. If you really needed a different start up project, it can get stored in the .suo file.
Honestly, I can't fathom why people don't see the usefulness of a default. Likely they work in isolation, or at Microsoft, because on every single team I've been on we *all* used the same start up 99% of the time. ;-)
I see absolutely no benefit to this. If a developer can't figure out which project to start, why does that need to be defaulted for him/her? Sounds more like a training issue.
Also, how would the IDE even know when a user really wanted to change from the default or when to go back to the default? Seems like a mess waiting to happen.
No it wouldn't, the request is to be able to set a default start project in the .sln file which can be overridden in the .suo file. Under normal circumstances if the user chooses their own startup project it will only change the .suo file and not the .sln file.
Doing this would create too much versioning on the .sln files. If developers change the startup project settings, they will check it in all the time.
The idea is good but I think the .sln may contain "default startup projet values" but the actual values should stay in the .suo file.
I'd really like to see this as I want all of my developers to have (by default) a set of startup projects including a single unit test project (without debugging) so that the results are continuously shown at build time.