John Saunders

This a pair of dumb questions, but they're dumb questions I should have asked back in the .NET 1.0 days.

  1. Which settings in the Project Designer are kept on a per-user basis as opposed to being kept in the solution
  2. Which settings in the Project Designer are kept on a per-configuration basis, as opposed to staying the same as the configuration changes

I haven't been able to find documentation on these questions, which probably means that the answers are too obvious to require documentation! Please help me find the documentation, or tell me why it's too obvious.

Thanks!




Re: Visual C# IDE Project Designer - Which Settings Per-User? Which Per-Configuration?

Figo Fei - MSFT

Hi John,

Do you mean Client Settings of a project

Setting values could either user-scope or application-scope, VS provide such a choice.

For more information, see: Client Settings FAQ

If I misunderstand, please let me know.

Thanks






Re: Visual C# IDE Project Designer - Which Settings Per-User? Which Per-Configuration?

John Saunders

Figo Fei - MSFT wrote:

Hi John,

Do you mean Client Settings of a project

Thanks for responding, but no, what I meant is what you get when you right-click a project in Solution Explorer and then choose "Properties".






Re: Visual C# IDE Project Designer - Which Settings Per-User? Which Per-Configuration?

Figo Fei - MSFT

John Saunders wrote:
Figo Fei - MSFT wrote:

Hi John,

Do you mean Client Settings of a project

Thanks for responding, but no, what I meant is what you get when you right-click a project in Solution Explorer and then choose "Properties".

Hi John,

If I comprehand you right, we are talking about the same thing.

It is about application settings, besides the FAQ link I mentioned, msdn documentation is right here: http://msdn2.microsoft.com/en-us/library/k4s6c3a0.aspx, it gives a inside look and mechanism into the settings.

Thanks






Re: Visual C# IDE Project Designer - Which Settings Per-User? Which Per-Configuration?

John Saunders

See this image to see what I mean. I mean all of the pages shown by all of the tabs on the left of the image.






Re: Visual C# IDE Project Designer - Which Settings Per-User? Which Per-Configuration?

Figo Fei - MSFT

Oh I see. You mean *ALL* the settings of the project.

The application settings I mentioned above is a subset of these settings, and that "user-scoped" refer to the user who use the application, while the user in your word "per-user" seems to refer to the developer, so I think there is no "per-user" settings in project properties. (if any misunderstanding is there, please figure it out)

Since they are all project settings, saved in project information, that is to say they are project specific.

The document is located here: Project Properties (Visual Studio)

Thanks






Re: Visual C# IDE Project Designer - Which Settings Per-User? Which Per-Configuration?

John Saunders

On my use of the term "Project Designer", see "Managing C# and J# Project Properties".

But my questions still stand: which of these properties on all of these pages are per-configuration Which (if any) are stored per-user (in the .csproj.user files, for instance) and which are stored as part of the project or solution






Re: Visual C# IDE Project Designer - Which Settings Per-User? Which Per-Configuration?

Stephen Weatherford MS

No, they¡¯re not dumb questions, although I hope that most of the time you don't need to think about it much.

Question 1: Which properties are per-user (kept in the .csproj.user instead of the .csproj):

Debug page: all properties

Advanced Security page: ¡°Debug this application with the selected permission set¡± and ¡°Debug this application as if it were downloaded from the following URL¡±

Reference Paths: all properties

Database page (SQL Server projects): Connection properties

I believe all other properties are per-project (most are stored in the project file, but some of the properties in the Signing page are stored in the app.manifest file, Resources/Settings are stored in separate files, etc.).

Question 2: Which properties are per-configuration-dependent

This one is easier to answer. In general, if the Configuration and Platform comboboxes at the top of the project designer are enabled, then the properties on that page are configuration-dependent (i.e., each configuration in a project can have different values, as opposed to there being only a single value that applies to all configurations in the project). There are a few exceptions in the VB pages (particularly on the Compile page) but I don¡¯t think there are any in the C# pages.

If you don¡¯t see the Configuration and Platform comboboxes at the top of the project designer, then you have ¡°simplified configurations¡± turned on (the default for C# Express and all VB SKUs). In this mode, the settings that you see usually refer to all configurations in the project and will affect all configurations if you change them. (There are some exceptions where it makes sense, such as ¡°Define DEBUG constant¡± on the build page.) If you¡¯d prefer to be specific about which property values apply to which configurations, you can turn off this mode by going to Tools.Options -> Projects and Solutions and checking ¡°Show advanced build configurations.¡±

So, the following pages are stored per-configuration:

Build (for VB, Compile)

Advanced Build (for VB, Advanced Compile)

Debug

Code Analysis

Hope that helps,

Stephen Weatherford






Re: Visual C# IDE Project Designer - Which Settings Per-User? Which Per-Configuration?

John Saunders

Thanks, Stephen, that was helpful.

I presume that it's dangerous to directly manipulate the project file to change things that the UI can't do For instance, I was able to create configuration-specific post-build tasks by editing the project file.






Re: Visual C# IDE Project Designer - Which Settings Per-User? Which Per-Configuration?

Stephen Weatherford MS

I'm not sure that it's "dangerous", but there are disadvantages, depending on the situation. Most properties that you want to change are exposed through automation/extensibility as project or configuration properties, and that's the preferred way to change them (the UI uses them, too). If you're talking about an add-in or extensibility feature that changes the project file directly, then you've got to deal with the project getting reloaded, etc. That certainly wouldn't be the preferred method for a tool.

In the case you mention, I'm assuming you're talking about manually modifying the file. That's not necessarily a problem, but depending on what you do, VS might decide the project has custom changes and give a security warning whenever you load it up. Changing the build events to be per-config doesn't seem to trigger this, but the UI may not be able to edit it properly. MSBuild is pretty powerful, and there are lots of customizations you can make. VS may not understand all of them, but generally it leaves things alone if it doesn't know about it, so if it works and suits your needs, it's probably fine.