I just got this email followup on newsgroup post from years ago related to command arguments getting lost and reset in VC with perforce.  May be of use to someone in the future, so posting here...  (name removed for privacy)

Question (from user):

Basically, every time I get my vcproj file out of source control (Perforce), my "local" settings are stomped.  You seem to imply below that the settings are "stored local", but you do not imply that they should therefore continually be reset by changes other users make.  In fact, it should be impossible for other users to disrupt my settings.  Is this what you meant?  Has this bug been fixed?"

Answer (from same user, 2 years later):

"We now know what causes this, and it's not fixed in 2003.  I have no information on whether it's fixed in 2005.

 

If you do a sync of a vcproj from perforce, and you have this vcproj loaded in .NET, a dialog box will pop in .NET.  If and only if you say "Reload", your user-specific settings will be lost.  Saying "Ignore" and manually reloading the project works fine."

 

 

If the same user does the check in, the command arguments are fine.

 

It happens (100%) when another user checks in our Game.vcproj file.  I did a dif before and after, and the only line that was changed, was: PreprocessorDefinitions="..."

 

Thx for your feedback !

 

Initial Newsgroup Post:

 

> > Subject: Command Arguments getting lost/reset (VS.NET)

> > Date: Wed, 4 Jun 2003 14:24:40 -0400

> >

> > Whenever a project is checked in by a different user, the Command Arguments

> > (Project Properties,Debugging) gets resets to empty.  I'm seeing this

> > bug in VS.NET, but never had it in VC6.  Is there a work around? Or am I

> > doing something wrong?

> >

> > Cheers

> 

> Are you saying that this setting is getting obliterated on the same user

> machine each time a checkin happens, or does it just not persist across all

> users?

> 

> Visual Studio .NET now stores these settings on a per-user basis, which

> means each user is going to have to set them up individually. :(  I talked

> with someone in this area yesterday and he said basically that this is a

> known issue, they are aware it is a major pain, and that they have some

> ideas on how to improve the situation for the next version.

> 

> However if this is something where the setting is not persisting even on

> the same user's machine we might need to investigate further...

> 

> --

> Eric Jarvi, Microsoft Visual C++ Team

>  <http://blogs.gotdotnet.com/ejarvi/>

> This posting is provided "AS IS" with no warranties, and confers no

rights.

> Use of included script samples are subject to the terms specified at

>  <http://www.microsoft.com/info/cpyright.htm>

>