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.
I'd love a default suo file that comes down from TFS containing all the user defaults for a solution. That way you can pull a copy of the source code from TFS and have it up and running in a moment. No need to follow through documents to setup your dev environment. Of course you wouldn't check the file in by default.
This is severely needed for build servers.
Niclas Eriksson commented
This badly needs to be fixed somehow! If you are running a project with multiple small services, a bunch of separate web projects and some other utils that all needs to start in the correct order for debug to be meaningful it's a pain to constantly have to set the startups (and the correct order). It's prone to errors and quickly becomes a huge time-waster. Also, the system would be more self documenting if it was possible to save different startup configurations in the solution. The individual developers could then simply select one pre-built config and have the active one stored in their .suo, or, they could set up something themselves and have it stored in their .sou. Best of both worlds!
Alex Merkulov commented
Good idea. Right now the first project gets marked as startup. It would be nice to override that default setting from the sln file somehow. If a user chose another project as the default then that could go into his suo file and override the sln setting.
Carmai Constant commented
This feature should be implemented. I would be useful to store in source control the default project to startup. It is helpful for everyone on the development team. It would be one less thing to document. A new developer could simply pull the solution from source control and run the application.
Mark Hancock commented
What is the solution when using a build server?
Do we have to check in the suo file into Version Control? -- That seems like a bad idea.
Do we manually set the order in the sln and rely on that to work? -- Could a future solution change 'fix' it back?
Do we start the name of the StartUp project 'AAAA'? -- LOL, does not address multiple Startup Apps
There needs documented way to set the StartUp project(s) for a machine built solution.
I find this behavior very strange because the .csproj file can have any "user specific" settings copied into it from the user csproj 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.