Best Practices: Resources vs. Settings

[Michael]

Can anyone provide some direction as to what types of information
should be put in the project's resources vs. the project's Settings.

(ie. Properties.Resources and Properties.Settings)

As I see, Settings can store both User and Application specific
settings of virtually any object type. Resources is limited to
Strings, Images, Icons, Audio, and Files and its scope is
assembly-wide.

Clearly, user options should be stored as User settings in the Settings
files. On the other end, the Application icon should be stored in the
Resources file.

But what do you do with configuration information such as
"DatabaseConnectionTimeout?"
It could go as a Application scoped Setting, or it could be a assembly
resource.

I seem to be leaning to using Settings for most configuration
information.

Does anyone have an opinion?

 

[Dmytro Lapshyn [MVP]]

Michael,

"DatabaseConnectionTimeout" is definitely a Setting - the user might want to
adjust it. As a rule of thumb, anything possibly adjustable by the user
(even though you might have no UI to adjust it so far) should go into
Settings. Resources are just a convenient way to store program data within a
single executable file and they facilitate localization. UI strings, images,
icons, sounds are all good examples of Resources - you generally do not
expect the user to change any of these, and practically any of these types
of data might need localization.

 

[Michael]

Great, pretty much what I was thinking. Thank you for answering.