Introduction to Dynamic Properties (Visual Studio)

Article
01/21/2013

Note

The user interface for dynamic properties has been removed as of Visual Studio 2005. However, dynamic properties are still supported. If you import a project from an earlier version of Visual Studio, the dynamic properties settings will be preserved in code and will work at run time. We recommend that you instead use the Project Designer to specify application settings. For more information, see Managing Application Settings.

Dynamic properties allow you to configure your application so that some or all of its property values are stored in an external configuration file rather than in the application's compiled code. By providing administrators with the means to update property values that may need to change over time, this can reduce the total cost of maintaining an application after the application has been deployed. For example, suppose you are building an application that uses a test database during the development process, and you need to switch it to a production database when you deploy it. If you store the property values inside the application, you have to manually change all of the database settings before you deploy, and then recompile the source code. If you store these values externally, you can make a single change in the external file and the application will pick up the new values the next time it runs.

Security Note
Property values stored in a configuration file are not secure. Sensitive data such as passwords and credit-card information should not be stored as dynamic properties.

You can use dynamic properties in any application that compiles to an .exe file. Projects that compile a DLL cannot use dynamic properties directly; however DLL properties can be set dynamically by the .exe referencing the .dll. Although the properties of any component, form, or control in these applications can be handled dynamically, some properties make better dynamic property candidates than others. Most often, you will store and retrieve properties that connect to external resources that might change, including databases, event logs, or performance counters. Many of these properties are identified as default candidates for dynamic properties.

Note

The example code in this topic relies on the existence of a SqlConnection object and a configuration file; it will cause compilation errors without them.

Dynamic Properties and Configuration Files

When you set a property as configurable, its value is written to a configuration file and code is inserted in the class to indicate that the property value should be retrieved from this external resource. The configuration file varies based on the type of application; Web-based applications use the Web.config file, and Windows-based applications use a similar file with the extension .config. All of the forms and components in an application use a single configuration file. You cannot switch to a different configuration file or use multiple files within a single application.

Within the configuration file, properties are persisted using XML. For example, suppose you indicated that the ConnectionString property for a data connection should be stored in the configuration file. You would see this code in the Code Editor indicating that the value is stored externally:

Me.SqlConnection1.ConnectionString =
  System.Configuration.ConfigurationManager.
  AppSettings.Get("SqlConnection1.ConnectionString")

        this.sqlConnection1.ConnectionString = 
          System.Configuration.ConfigurationManager.
          AppSettings.Get("SqlConnection1.ConnectionString");

Security Note
For more information about creating secure data connections, see Protecting Connection Information (ADO.NET).

In the configuration file, the value for this property would be stored via XML, using the key indicated in the form's code:

</appSettings>

</configuration>

Each value in the configuration file is assigned a key that is used to store and retrieve the value. The initial portion of the key indicates the component from which the value originated. For example, these two keys indicate a ConnectionString property on two different data connections within a single application:

</appSettings>

</configuration>

You can modify the configuration file directly in order to dynamically update the property values in your application. The next time the application starts, it will update the values.

In a sense, configuration files are similar to resource files; both are used to store values outside the compiled application and both use XML to store their information. However, resource files serve a much different purpose than configuration files. Resource files are used to store strings and other localizable resources for translation purposes, while configuration files (in the case of dynamic properties) are used to update property values. The values in a resource file are meant to be translated but typically not changed, while the dynamic property values in a configuration file can be changed as needed. Also, you can associate multiple resource files with a project, but you can only have a single configuration file for your application. For more information on resource files, see Hierarchical Organization of Resources for Localization.

Setting Multiple Properties to the Same Key

Multiple properties can reference the same key-value pair in a configuration file. For example, if you have three components in your class that all access the same database, you can store the ConnectionString property for each in the same key-value pair. This means that if the database changes, you can update a single value in the settings file to apply the change to all three components. You would do this by setting each of the properties to the same key, like this:

Me.SqlConnection1.ConnectionString =
  System.Configuration.ConfigurationManager.
  AppSettings.Get("SqlConnection1.ConnectionString")

Me.SqlConnection2.ConnectionString =
  System.Configuration.ConfigurationManager.
  AppSettings.Get("SqlConnection1.ConnectionString")

Me.SqlConnection3.ConnectionString =
  System.Configuration.ConfigurationManager.
  AppSettings.Get("SqlConnection1.ConnectionString")

        this.sqlConnection1.ConnectionString = 
          System.Configuration.ConfigurationManager.
          AppSettings.Get("SqlConnection1.ConnectionString");

        this.sqlConnection2.ConnectionString = 
          System.Configuration.ConfigurationManager.
          AppSettings.Get("SqlConnection1.ConnectionString"); 

        this.sqlConnection3.ConnectionString = 
          System.Configuration.ConfigurationManager.
          AppSettings.Get("SqlConnection1.ConnectionString");

Note that while the components in use differ, they all refer to the key for sqlConnection1.ConnectionString.

When you choose the same key for multiple properties, only one entry is made in the configuration file. The initial value stored is that from the first property that was given that key.

Data Types and Dynamic Properties

XML stores everything as a string. If the property value you are storing is not a string, you will see additional information in the Code Editor to indicate the data type for the property value. For example, suppose you are dynamically storing the value for a Timer component's Interval and Enabled properties. In the configuration file, this property would be stored like this:

</appSettings>

In the Code Editor, you would see this code to indicate that the retrieved value needs to be changed to a Double Data Type (Visual Basic):

Me.Timer1.Enabled = (New System.Configuration.
AppSettingsReader()).GetValue("timer1.Enabled", GetType(Boolean))

Me.Timer1.Interval = (New System.Configuration.
AppSettingsReader()).GetValue("Timer1.Interval", GetType(Double))

        this.timer1.Enabled = (bool)(new System.Configuration.
          AppSettingsReader().GetValue("timer1.Enabled", typeof(bool)));

        this.timer1.Interval = (System.Double)(new System.Configuration.
          AppSettingsReader().GetValue("timer1.Interval", typeof(System.Double)));

Note

There are two timers, one for Windows Forms and one for server-based applications, with slight differences in programming models. This example uses the server-based timer.

Performance and Security Concerns with Dynamic Properties

There are two items that may be of concern when you use dynamic properties. First, dynamic property storage and retrieval may affect your application's performance somewhat. Retrieving property values from within the compiled application is slightly faster than retrieving property values from the configuration file. The first time a configuration file value is accessed by the application, there will be a slight performance impact as the application reads the file. This impact is very minor, however, and should not be noticeable. Any subsequent retrieval of that or other properties has a much smaller performance impact — similar to reading a value from a hash table.

Second, if you are storing property values such as user IDs and passwords to an external file, you will want to control whom has access to the file and the values it contains. One way to accomplish this is to secure your file with a Windows access control list (ACL). An access control list specifies what operations different users can perform on specific files and directories. In addition, if you are working with a Web-based application, you can take advantage of the integrated security option provided by Windows, Internet Information Services (IIS), and SQL Server. In that model, a user's authentication credentials for the local network are also used to access database resources, and no explicit user name or password are used in the connection string.

For more information about security, see your Windows documentation or the following pages:

Share via

Introduction to Dynamic Properties (Visual Studio)

Dynamic Properties and Configuration Files

Setting Multiple Properties to the Same Key

Data Types and Dynamic Properties

Performance and Security Concerns with Dynamic Properties

See Also

Other Resources

Additional resources