none
Can't Set/Version Startup Project

    Question

  • Assume the following, pretty simple, setup:

    A single Solution, with two projects:
    - MyClassLibrary
    - MyExecutable

    When I checked this solution in to TFS, the "MyClassLibrary" was accidentally set as the startup project in Visual Studio.

    I can change that until I'm blue in the face (either by right-clicking on the other project and selecting "Set as Startup Project", or by editing the Solution's properties directly).

    The problem, of course, is that the 'choice' of which project in a Solution is a startup project ends up getting tracked in the .suo file - which TFS (somewhat logically) doesn't track/version.

    The net result:
    1) I can't even debug my project when it's under TFS - as the 'change' to set my executable project to be the startup project simply won't 'take'... and I'm left every time I try to debug with an infuriating message reminding me that only an idiot would try to 'run' a project with the output type of 'Class Library' (despite the fact that the Solution Explorer 'shows' that my executable project is set as the startup project).
    2) There's simply no way for me to 'correct' this from a versioning standpoint.

    Hopefully this is something stupid I'm missing. Anyone know how to fix this?

    Wednesday, April 11, 2007 3:42 PM

Answers

  • So if I understand correctly, the problem with the startup project setting not "sticking" was resolved by cleaning up the *.suo file.  The only remaining bug is that the debugger thinks your startup project [the correctly remembered one] is not executable when it's bound to source control.

    I'll have someone look at it.  Assuming CodePlex comes back up, which solution should I point them to?
    Friday, April 13, 2007 6:07 AM

All replies

  • Have you isolated what event causes the setting to flip back to MyClassLibrary?  Like you say, it should be stored in the .suo and thus not related to TFS at all.
    Wednesday, April 11, 2007 7:59 PM
  • From what I can tell, Visual Studio isn't completely getting/seeing the change. And for some reason it doesn't look like it's actually creating a .suo file.

    Hmmmm. In a previous attempt to get my change to 'stick' I did something RASH: I 'added' the .suo file to my 'repo' in the hopes that it would somehow get picked up. (Of course, all that did was 'add' the file as another versioned resource - not as something that was available when VS started up (I typically use SVN - so adding the .suo file didn't seem quite as dumb as it really was at the time).

    Any chance that because there's a 'removed' .suo file hiding out in my workspace/change set that VS is somehow causing it to not be created/read?


    Wednesday, April 11, 2007 8:06 PM
  • When you add a file to TFS, it gets marked as read-only on disk.  I'll bet that's the problem.
    Wednesday, April 11, 2007 8:08 PM
  • Good idea. I checked, and it wasn't set to Read Only. For kicks and giggles I deleted the .suo file, re-opened the project, set the change, and closed/re-opened.

    Interestingly enough, this time it DID 'stick' and the "MyExecutable" project is set as the startup project. (I wasn't able to get it to do that before.)

    That said, I'm still not able to debug, because I get the warning about a Class Library not being a viable option for a startup project. Only, I just realized something: My "MyExecutable" project actually is a Class Library - it's a VSPackage implementation that I'm working on. When the solution is NOT under TFS Source Control, this Solution obviously fires up without a problem, and my VSPackage is routed into Experimental Build as an 'executable'. Under TFS Source that just doesn't seem to be the case.

    I'm starting to think I might have bumped in to a bug...

    In other words, I CAN now set the 'startup project' as I needed, but the 'underlying' bug is still there - which is that I can't launch a Class Library for debugging. If the exact same code is removed from TFS source, it compiles/F5's perfectly. Undert TFS Source it barfs.

    Any thoughts?
    Wednesday, April 11, 2007 8:20 PM
  • FYI, my code is actually out on CodePlex if anyone is interested. (Although it looks like the TFS server is currently down this exact second... )

    Wednesday, April 11, 2007 8:23 PM
  • When you talk about being under / not being under source control, are you actually adding & removing the bindings?  Using the "temporarily work offline" feature?  Something else?

    Have you deleted the .suo file from the repository?  Just to rule that out.
    Wednesday, April 11, 2007 9:06 PM
  • Richard,

    Yeah, I've removed the .suo from the repository.

    And yeah, when I refer to working 'without' source control, I mean copying the contents of my workspace to another location/machine, avoiding login to the TFS, and then 'permanently' removing the bindings. Once I do that, the solution debugs as intended. (And I've run a diff against the files just to make sure that nothing is out of whack - the only differences are the 'hooks' for source control).

    Wednesday, April 11, 2007 9:12 PM
  • So if I understand correctly, the problem with the startup project setting not "sticking" was resolved by cleaning up the *.suo file.  The only remaining bug is that the debugger thinks your startup project [the correctly remembered one] is not executable when it's bound to source control.

    I'll have someone look at it.  Assuming CodePlex comes back up, which solution should I point them to?
    Friday, April 13, 2007 6:07 AM
  • Hi Richard and friends,

     Richard Berg MSFT wrote:
    Have you isolated what event causes the setting to flip back to MyClassLibrary?  Like you say, it should be stored in the .suo and thus not related to TFS at all.

    (TFS 2005) When I add a VB 2005 solutions to TFS that has several projects, the startup project is not correctly set. I need to set it manually in VS Solutions Explorer and can see that that change is saved to my .suo file when I close the solution. Since I am not saving .suo files in TFS ( as recommended http://msdn2.microsoft.com/en-us/library/ms171339.aspx ), how can I set the startup project on the shared code. Or worded another way, why should I not save the .suo in TFS?

     

    TIA,

    Dave

    Monday, February 18, 2008 5:16 PM