28

We're creating an application that understands some command-line parameters. There are some default's we would like to supply on the command-line when debugging, and these are easily set in the project settings as explained here.

The thing is visual studio stores these settings in a *.csproj.user file, and the default settings for integrated source control do not check-in *.user files. We would like to just have these default command-line parameters in everyone's IDE when debugging this project.

Often (but not always) when visual studio guides you into doing things a certain way it is for good reason. We probably don't want to just check-in someone's .csproj.user file... right?

This question is has a few parts:

  • Why does Visual Studio store this particular setting per user?
  • Is there a way to alter this behavior? - Would doing so bring bad juju?
  • Under these circumstances is it OK to check-in and share a .user file?
  • Is there a better way to accomplish what we are trying to do here?

Thank you -

Community
  • 1
  • 1
DanO
  • 2,526
  • 2
  • 32
  • 38
  • 1
    Seven years later, it still works the same way. While most project properties are stored in the `*.vcxproj` file, local debugger command arguments are stored in `*.vcxproj.user`. Give Microsoft points for consistency. – Jonathan Lidbeck Jan 13 '17 at 00:41

2 Answers2

13

Maybe you could alter the program to optionally read its parameters from a configuration file as well as from the command-line (and then check-in a copy of that configuration file).

ChrisW
  • 54,973
  • 13
  • 116
  • 224
  • Good point. This meets the same need and bypasses the issue. – DanO Sep 02 '09 at 15:46
  • 3
    Putting the default debugging command-line options into a .config file bypasses the issue but also forces in new behavior that may not have been wanted (we can live with it in this case.) In general I now see that relying on default debugging command-line parameters across the team and in source control is a bad thing. It adds wrinkles to the CI (auto) builds and unit tests. We are effectively making "debug" parameters into a source artifact... not good. So in general, the best answer is: "Don't do that - find another way" and in this case a .config file is fine. Thanks. – DanO Sep 02 '09 at 16:10
6

I would not recommend checking in the user file because, as you said, this is per user. If someone checks out your "default" user file and then makes any personalized configuration changes, those will be reflected back in the user file and (most likely) will be reflected in the source control.

If you want someone to set command-line parameters for debugging, I would adjust the project file to include these - don't include them in the user file. (It is okay to check in the .proj file, and I typically do for my team projects.)

JasCav
  • 34,458
  • 20
  • 113
  • 170
  • I have seen some very confused developers that did not realize that the .user file was in source control (or didn't know what it was for). – Eric J. Sep 01 '09 at 16:59
  • So if manually "merge" the xml that supplies the command-line parameters in the .user settings file with the main project file... will that do what I am hoping... or just mangle things? – DanO Sep 01 '09 at 17:00
  • 3
    @Jason: How would you adjust the project file to contain command line parameters? – sbi Sep 01 '09 at 17:16
  • I think I misread part of your post. I still stick to not checking in the .user file. I have to agree with your first bulleted point...no clue why Visual Studio does this. I just assumed that it went into the project file since that is how it is for a project I am working on. A better alternative may be to document the settings and let each user specify where those settings are located. Or, provide an initial config file that the users can just copy into their workspace. – JasCav Sep 01 '09 at 18:57
  • 1
    "adjust the project file to include these" - how? By manual editing? – thomthom Jan 03 '14 at 10:23
  • @thomthom and sbi - See this article: http://msdn.microsoft.com/en-us/library/vstudio/1ktzfy9w(v=vs.100).aspx and this SO answer: http://stackoverflow.com/a/298713/132528 – JasCav Jan 03 '14 at 17:28
  • 2
    @JasCav - did those link describe how to set the debugger properties per project instead of per user? From what I gathered they described where the settings where - but not how to avoid them ending up in the per-user setting. – thomthom Jan 04 '14 at 11:30
  • @thomthom - I have always gone through the project settings and (I am looking at the raw .proj file right now) - all those settings are in the project file. (I'm using VS2013.) So...maybe something changed between 2010 and 2013 in how those settings were stored... – JasCav Jan 04 '14 at 17:45
  • 2
    Hmm.. I'm using VS2013 as well and I found the debugger settings to be put in the .user file. Which I found to be very odd. I manually copied and pasted the settings and that worked though. – thomthom Jan 04 '14 at 18:37