You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Could you please put CommandLineArguments into user-specific configuration file. #7025
For a foo.pyproj project created in VS2015~VS2022(up until today, 2022.06.05), if user sets script argument, the argument is saved in foo.pyproj itself .
I have to say, that is very unfriendly for a team. Team member Tom and team member Bob probably run/test the python program with different arguments, and their settings should not stomp on each other. Therefore, <CommandLineArguments> should be placed into another file called foo.pyproj.user . The team will have foo.pyproj checked into git, but not for foo.pyproj.user.
Microsoft Visual Studio projects for C++ and C# has a very long history of putting program startup parameters in foo.vcxproj.user and foo.csproj.user, and I appreciate that decision. I've been so surprised that PTVS developers have not realized this better(or best) practice yet.
Suggestion: Two-tier configuration of CommandLineArguments is welcome and is the most flexible design in my opinion. It means, PTVS still recognize team-wide CommandLineArguments in foo.pyproj(as suggested running arguments for all/most team members), and a team member can override this setting in his own foo.pyproj.user.
This requires configuration UI to be updated as well. The UI should tell the user, whether the currently displayed "Script Argument" is from foo.pyproj or from foo.pyproj.user, and make it clear that the changes here will be saved to foo.pyproj.user .
Activity
chjfth commentedon Jun 7, 2022
Suggestion: Two-tier configuration of CommandLineArguments is welcome and is the most flexible design in my opinion. It means, PTVS still recognize team-wide CommandLineArguments in foo.pyproj(as suggested running arguments for all/most team members), and a team member can override this setting in his own foo.pyproj.user.
This requires configuration UI to be updated as well. The UI should tell the user, whether the currently displayed "Script Argument" is from foo.pyproj or from foo.pyproj.user, and make it clear that the changes here will be saved to foo.pyproj.user .