192

It seems like this setting should be stored in the solution file so it's shared across all users and part of source code control. Since we don't check in the suo file, each user has to set this separately which seems strange.

Kara
  • 6,115
  • 16
  • 50
  • 57
leora
  • 188,729
  • 360
  • 878
  • 1,366

5 Answers5

410

It is absolutely necessary that everyone can define their StartUp Project themselves, as Jon has already said. But to have a dedicated default one would be great, and as I can tell, it is possible!

If you don’t have a .suo file in your solution directory, Visual Studio picks the first project in your .sln file as the default startup project.

  1. Close your Visual Studio and open the .sln file in your favorite text editor. Starting in line 4, you see all your projects encapsulated in Project – EndProject lines.

  2. Cut and paste the desired default startup project to the top position.

  3. Delete your .suo file.

  4. Open your solution in Visual Studio. Ta daa!

Oliver
  • 43,366
  • 8
  • 94
  • 151
  • 1
    Finaly! This has been bugging me for a long time but not any more! Tkanks :) – mdonatas Jan 20 '10 at 08:44
  • 4
    It seems to work only if not in a solution folder: I mean this trick works for root projects, from my experience with some solutions I have. – jdehaan Jan 27 '12 at 09:38
  • Great! I couldn't resist myself to login to upvote on this. I agree to other arguments that having a startup project should be a choice at individual developer side. However, the keyword is "default". A person who sets up the solution for a team knows the "pain" (of not having ability to setup "default" startup) ;-) – Arun Feb 17 '12 at 18:16
  • 3
    What if there are two default projects - how can I start them both by default? – Amy B Jan 16 '13 at 18:32
  • 1
    @DavidB: The Highlander principle: There can be only one! By the way, how do you select two startup projects manually? This isn't possible and so automatically making this isn't possible too. – Oliver Jan 17 '13 at 07:16
  • How? Easy... Start with debugging the first one. Then start with debugging the second one. But... I am able to combine these projects into a single startable project, so your advice helped. – Amy B Jan 17 '13 at 07:18
  • @DavidB: This is a quite complex operation, cause you have to manually right click the second project and select *Debug - Start new instance*. There is no information stored within VS within the .sln or .suo file about this second manual task and so it is not possible to make two projects run at one click. The workaround would be your idea to create a third project that simply starts the applications of the other two projects and make this third one the default startup project. – Oliver Jan 17 '13 at 07:42
  • 8
    @Oliver: Right-click Solution -> Set StartUp Projects... -> Multiple startup projects. One-click starts multiple. – Anton Jul 10 '13 at 21:20
  • @Anton: This information is stored within the .suo file and not within the .sln file. – Oliver Jul 11 '13 at 06:58
  • 1
    @Oliver: That's right, just wanted to point out it was possible. – Anton Jul 11 '13 at 15:24
  • I know this is old, but anyone know why my solutions consistently default to the second project? I'm using a new solution with about a dozen csproj's, VS2013 Update 2-RC. I've tried re-ordering it in many different ways, and it's consistently the second project that it defaults to. I haven't tried on another devs machine yet, but I will. – Adam Plocher Apr 11 '14 at 06:51
  • @AdamPlocher: This only works when you make a _fresh_ checkout. When you first open the .sln file VS will automatically create a .suo file that contains the startup project for yourself. So after changing the .sln file you should delete the .suo file to see the _default_ behaviour (that's the bold part of my answer). – Oliver Apr 11 '14 at 10:10
  • @Oliver, thanks for the reply. Yes I do understand that. I delete my .SUO file between each try, then open the SLN in Notepad++ and re-arrange the Project elements in the SLN. I can get my default to change (with NO SUO file), but it's just always the second project in the SLN, instead of the first (as everyone else seems to experience). I've tried switching it around about 5 or 6 times and it was very consistent in behavior, I just don't know why it's the second and not the first. – Adam Plocher Apr 11 '14 at 10:52
  • @AdamPlocher: Unfortunately i don't have VS2013. So maybe open up a new question at SO (and refer to this question) to make your problem more prominent and find someone who can help you. – Oliver Apr 11 '14 at 14:12
  • 5
    @jdehaan I was able to change the startup project to one of the nested projects in VS2013 (I do not have any older versions of Visaul Studio): I have copied the containing folder as the first project in .sln file and the starup project as the second one. – Aleksei Poliakov Aug 02 '14 at 21:06
  • 3
    @AdamPlocher I believe if no .suo file is around, VS more specifically picks the first "completely defined" csproj entry: if it lies in a subfolder, the subfolder must be declared as well, before any other project is "completely defined" like this. (Let me know if that does not make sense to you.) – Efrain Sep 19 '14 at 11:43
  • By "completely defined" I think @Efrain is referring to the solution folders that are listed in the SLN file. If you put those above the first project you want as a startup project then it loads properly in VS2013. – sourcenouveau Nov 20 '14 at 15:01
  • @DarkWalker's technique (as explained by @Efrain) works with vs2010 as well – jswolf19 May 19 '15 at 07:06
  • This was a big help. We use a build server to do regression building and testing and to do release builds. We don't check the suo files into version control since they are user specific. Because the default project list order seems to be alphabetic and the first project was a dll, the build server was only building the dll and not the application. This was not good. I guess I could start all my applications projects with an 'A'; but, I like your solution better. Thanks! – markshancock Sep 30 '15 at 16:34
  • @DavidB You could probably use Project Dependencies to force the fist project in the list to start other projects. This is a bit of a 'hack'; but, it seems like it should work. I think the best solution would be a real feature to handle this so it is explicit rather than depending on an undocumented behavior that could change. – markshancock Sep 30 '15 at 16:42
  • @markshancock making it a dependency doesn't START the other project (it just makes it build -- which already happens for legitimate dependencies) -- as far as I can tell, there is no way from the .sln file to declare multiple start-up projects -- it seems we will just have to check in the .suo file. :-( – BrainSlugs83 Nov 19 '15 at 21:25
  • @Piedone: It does. The .suo file just moved into a hidden subfolder *.vs*. – Oliver Jul 10 '17 at 06:03
  • 1
    I deleted the .vs folder too, and while changing the order of projects does change which one is is a startup project by default it's no the top project any more (at least in my cases). I couldn't find out what the algorithm here is, it seems to depend on the projects themselves somehow too. So in the end I couldn't find a way with VS 2015 to set a default startup project by editing the order of projects in the sln file. – Piedone Jul 10 '17 at 10:37
  • Not every project entry within the solution file is really a startable project (e.g. solution folders are also projects). But if you simply move your desired project to the top of the list it should become the starting one. – Oliver Jul 10 '17 at 11:42
  • @Piedone Yes you are right, I have also tried. This workaround is not working with VS 2015. – prem Dec 01 '17 at 14:08
  • This might help some people: VS kept picking the _second_ project for me (which isn't helpful, as it's a library). Unclear why. Both projects were inside a subfolder in the `sln` hierarchy. I moved the first project to the root instead, and now it picks that as default. – Sören Kuklau Apr 07 '21 at 10:34
52

In most cases, it does make sense to have a default on this.

It would be much better to accommodate a default startup project and store this in the .sln file, but which can be overridden by a developer in their .suo file. If the startup setting isn’t found in the .suo file, the default startup project in the .sln would be used.

Actually, this has been suggested on Visual Studio’s UserVoice.

Palec
  • 12,743
  • 8
  • 69
  • 138
Wim
  • 11,998
  • 1
  • 34
  • 57
  • 1
    The linked UserVoice is "closed for voting" but no comment as to why. – yzorg Feb 13 '19 at 15:55
  • 2
    This is definitely the better stance compared to the accepted answer. I've not once worked within a team that considered it an advantage to set this on a per user basis. It just leads to extra setup on fresh clones, etc. – Trevor Reid May 08 '19 at 13:27
43

Why should it be a non-user-specific preference?

If I've got a solution with 10 files in, and one developer is primarily testing/using one of those tools, why should that affect what I start up?

I think MS made the right choice on this one. The project I want to start is far from necessarily the project that other developers want to start.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 147
    Frequently, you'll have a project which is *very likely* to be most people's desired startup project for debugging (eg. website), and you don't want a class library as a startup project. I don't see why MS couldn't provide a proper mechanism (not what seems like a hack, ie. putting the default one at the top in the .sln file) for setting a global default startup project, and then allowing an .suo to override it if desired. – Jez Feb 24 '12 at 12:28
  • 29
    There is, in a manner of speaking... Move the project you want to set as the default start up project to be the first project in the sln file. Delete your suo file, re-open the solution and woila, that first project should be the startup. There may be other factors that contribute to this, but I found it when I noticed that one particularly project kept defaulting when I checked out a clean project from source control. – misteraidan Aug 28 '12 at 01:55
  • 2
    This is a problem when using a build server because it would require checking the suo into version control to set the correct Startup project and checking the suo into version control is a bad idea. – markshancock Sep 30 '15 at 16:20
  • 2
    @markshancock: Why would a build server care about the startup project? I've never seen that as an issue. – Jon Skeet Sep 30 '15 at 16:27
  • @JonSkeet, you may be correct. Initially the build server only seemed to be building the StartUp project; but, it seems there was something else causing that. It just happened to be the same by coincidence. I know in some case we actually have the Build Server run the application to do functional verification on every build change. In those cases, I do not believe the StartUp project would affect them as we don't run them based on that. – markshancock Sep 30 '15 at 20:13
  • If there is no suo file or by defaulty, IDE use the first project defined in SLN file as the startup project. So, you may delete the suo file and change the order of the projects in sln file to make default setting of the startup project as what you like. – smwikipedia Oct 28 '15 at 07:28
  • For some solutions, like where there's all class libraries and one actual project -- it's a pain in the ass to go and fix it on everyone's machine so that they can run the project -- for other projects -- where it's complicated (i.e. you need **more than one start-up** project and there is literally only one way to run the solution), again, it's a pain in the ass to configure it on every single person's machine. – BrainSlugs83 Nov 19 '15 at 21:19
  • @misteraidan that doesn't work for solutions which need multiple start-up projects (i.e. two websites, etc.). – BrainSlugs83 Nov 19 '15 at 21:20
  • Also, the rationalization @JonSkeet provided is kind of silly IMO -- it's like assuming you have to have everything all one way, or all another way -- why can't the DEFAULTS be specified in the SLN file and allow the users to override them in the SUO? – BrainSlugs83 Nov 19 '15 at 21:28
  • FYI: https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2225956-save-default-project-s-in-the-sln-file – BrainSlugs83 Nov 19 '15 at 21:29
  • @BrainSlugs83: Sounds like extra complexity I've never felt a need for, personally. You set it once, you're done... – Jon Skeet Nov 19 '15 at 21:31
  • 23
    I'm sorry, Jon, but I'm going to give you a -1 here. I am a believer that devs should have the ability to download code and then hit F5, expecting the most usual development setup to build and start. Of course, you should have the ability to tailor your startups for personal circumstances, but we should be able to set a default for most users, as stated above. Oliver's answer seems to go some way to do that, although it seems multiple start-up projects will remain impossible to check into source control, which is a shame. – Stephen Holt Apr 03 '17 at 11:14
  • 1
    One click build and debug after first check out is a requirement. Without this feature, the requirement can't be met. – Rhyous Aug 31 '17 at 16:08
  • @Rhyous: "is a requirement" - where, exactly? By whom? If there are 10 different applications you might want to debug, how do you expect that to work? – Jon Skeet Aug 31 '17 at 16:19
  • Where do you think requirements come from? It is a requirement in my department for dev solutions. We also don't allow 10 different applications that need debugged to be in one solution. Just as decoupling in code is bad, coupling in solutions and build is bad. – Rhyous Aug 31 '17 at 16:34
  • 1
    @Rhyous: Right - "it is a requirement in my department" sounds a lot more reasonable - and less like you're trying to claim a *general* requirement - than "is a requirement". I don't want my tools to be determined by your department's rules - just as I see plenty of cases where it's entirely reasonable to have multiple applications in the same solution. (I'm grateful that Visual Studio doesn't impose your department's rules there...) Given your two rules, it looks like Oliver's answer has you covered - just make sure your app is the first project in the solution. – Jon Skeet Aug 31 '17 at 17:26
  • We have an alteration to the Joel test: After checking out source, can you build and debug with one click. – Rhyous Aug 31 '17 at 20:24
  • As for your comment: "I see plenty of cases ..." That is the first response to any best practice and usually after going through a few cases, every last one of these supposed cases would benefit from changing to the best practice. – Rhyous Aug 31 '17 at 20:34
  • @Rhyous: I think we'll have to agree to disagree on that front, and I'm glad that Visual Studio gives me the flexibility to work on multiple related projects in the same window. If you choose to assume you know every one of my use cases better than I do, that's your decision to make, of course. – Jon Skeet Aug 31 '17 at 21:05
  • 3
    Disagree that it should be a user setting. (Especially given how frequently the .suo file has to be deleted to correct for a VS load issue!) Personally, I'd like to the startup project to be set from the config/solution so that the startup project can change with the selected config. That makes more sense to me in a multi-project solution. – SteveCinq Sep 26 '17 at 00:43
  • Thank you @misteraidan! Your solution solved the problem for me. – Simon Brooke Jan 16 '18 at 12:20
  • Jump forward to 2021 where we have a solution containing 40 microservices and circa 80 projects. Managing startups is a recurring headache. I'd like to see a non Visual Studio specific solution (i.e., also usable from the CLI and Rider) where different startup project configs can be defined, named and source controlled. Perhaps make it opt-in so that individuals can still do their own thing by default. – Damien Sawyer Feb 26 '21 at 00:31
  • 1
    @DamienSawyer 2022 here. [This is a thing](https://github.com/SimonCropp/SetStartupProjects). Really, it's been around for ~3 years, but only just now finding out about it. Not sure if it fits your needs. – Lynn Crumbling Mar 14 '22 at 17:15
  • Thanks @LynnCrumbling. That looks interesting. I'd still rather it was removed from the binary .suo file though. – Damien Sawyer Mar 16 '22 at 19:00
  • @DamienSawyer Yes, 100%. That solution still doesn't work for my use-case, either. – Lynn Crumbling Mar 16 '22 at 21:14
3

I wrote a little command line utility for Windows called slnStartupProject to set the Startup Project automatically:

slnStartupProject slnFilename projectName

I personally use it to set the startup project after generating the solution with cmake that always sets a dummy ALL_BUILD project as the first project in the solution.

The source is on GitHub. Forks and feedback are welcome.

Palec
  • 12,743
  • 8
  • 69
  • 138
michaK
  • 111
  • 1
  • 6
  • Thanks for this! I was having exactly this problem with cmake and your utility works great! – sippa Dec 16 '14 at 20:05
  • 1
    You're welcome! Happy it helps as it's been bugging me for years before I decided to get that resolved for good. Don't really understand why people have philosophical fights about this while it's clearly useful in most cases. – michaK Dec 29 '14 at 10:40
  • You .. wait... what? -- you generate your .sln file manually? ... what sorcery is this? – BrainSlugs83 Nov 19 '15 at 21:32
  • does this command line utility support setting two projects as start-up? – CesarB Nov 10 '22 at 00:56
2

If you are using GIT, you can commit the default SUO file and then mark it as unchanged using

git update-index --assume-unchanged YourSolution.suo

It works also if you want to have more than one project in your default start group. The only disadvantage that I know about is that this command must be run by everyone who don't want to commit the SUO file.

ctrl-alt-delor
  • 7,506
  • 5
  • 40
  • 52
sebetovsky
  • 101
  • 7