Why are a visual studio project's command-line settings stored per user? Is it OK to check-in (and share) a .user setting file?

Question

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 -

Answer 1

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.)

Answer 2

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).

Answer 3

As detailed here simply moving the debug startup options from the .user file into the csproj file works just fine.