Home > Articles



Configuration Data

This article is excerpted from Chapter 4, "Adding Debugging Support," of Designing for .NET Enterprise Design with Visual Basic .NET and SQL Server 2000 by Jimmy Nilsson, Sams Publishing (ISBN 0672322331).


Techniques for dealing with configuration data are clearly useful in many situations, not only for adding debugging support.

When I refer to configuration data, I'm talking about the kind of configuration data that you need to refresh on-the-fly (such as enabling/disabling tracing), as well as more static configuration data, such as connection strings. Before we look at how to deal with configuration data, I'd like to say a few more words about the data itself.


It's not just possible to enable/disable tracing by changing configuration data. It is also easy, for example, to switch between different tracing implementations to be used by changing the content of the configuration data.

Different Types of Configuration Data

The following are the different types of configuration data:

  • Fetched once, used many times

  • Fetched every now and then, used many times

  • Fetched each time it is used

I just mentioned connection strings, and this kind of configuration data is a typical example of "fetched once, used many times." When your server application is running, it's perfectly fine to say that for the application to refresh the connection string to work with another database server instead of the current one, you have to shut down the server application so that the next request will lead to the connection string being read again (and the new value is then found).

The second category, "Fetched every now and then, used many times," can be exemplified with settings for configuring tracing. You don't usually want to shut down the server application simply to change the filter for tracing or to activate tracing. Instead, reading the configuration data from persistent storage is often good enough, say, once a minute, and all requests for the configuration data are serviced with cached data in this time.

Finally, the third category, "Fetched each time it is used," is not actually a common type of configuration data (at least I can't think of an example). If you encounter this situation, it might be a good idea to think twice about whether this is really configuration data or session data, user data, or application data. Such data that must be fetched from persistent storage each time it will be used often enjoys living in the database.

There are several techniques to choose from when dealing with these different types of data. However, I'd like to start with a short discussion about how I solved the problem of dealing with configuration data in the old days of VB6.

Dealing with Configuration Data in VB6

When we wrote COM+ components in VB6, they were Single-Threaded Apartment (STA) components. This meant that in one specific STA, only one method could run at the same time. To get multitasking, several STAs were available at the same time for a process. In the case of the COM+ server application, there were approximately ten STAs multiplied by the number of processors in the machine. Assume that you were using a machine with only one processor; your COM+ server application would then have had approximately ten threads. Each thread would have had its own public data—that is, global variables, module-global variables, and static variables (but not member data). The public data was stored in Win 32's Thread Local Storage (TLS).

This implementation could be a major problem in some situations. Developers who didn't know that global variables were local to threads and shared between users created horrible, hard to find bugs, because several users were sharing the global data. Yet the global data wasn't completely shared; there were several (say, ten) instances of it.

On the other hand, global data per thread could sometimes also be a great benefit. Even though it was an implementation detail that could change "anytime," I actually based some solutions on this very situation. The typical example was purely configuration data. When the first request came in to a newly started COM+ server application, it was possible a connection string was needed. Then a global variable was investigated to see whether it had been initialized. If not, the connection string was read—for example, from the Registry—and the value was put in the global variable. The next time a request for that very thread made the same investigation, the connection string was found and there was no need to read the Registry again. The nice thing with the solution was that it never introduced any wait states, because each thread had its own data and didn't have to wait for any other thread, which was very efficient. (The main drawback was that you had the data loaded in several instances in memory, which could be a problem in a situation where you wanted to refresh the data for all the threads at the same time, or if the data was large. If so, you wasted memory.)

When you write COM+ components in .NET, you get free-threaded components, but there is a technique to get a similar solution to that in VB6. Before I start the discussion about how to deal with this in .NET, I'd quickly like to point out two important design decisions—the design perspective and centralization.

The Design Perspective

First, remember that in this book we are discussing writing serviced components, and it is from this perspective that I need the ability to refresh the values on-the-fly. For an EXE, this is not usually a problem; it's just a matter of restarting the EXE. However, restarting a COM+ server application will often affect many users.

Because I'm talking about serviced components, this also means that I have more options for how to deal with the configuration data.


You probably know by now that I'm very fond of centralizing code. I feel the same when it comes to accessing the configuration data. When a method needs configuration data, the method should just call another method, probably a Shared one, to find the needed data. The mechanism that is used should be completely transparent to the calling method.

Now that we've looked at these two important design decisions, let's get down to the nitty gritty. You'll see that I have divided the solution options I'm about to discuss into two parts. The first part discusses how to store the configuration data persistently, and the second part discusses how to access the configuration data from transient storage. I'll start with the first part—persistent storage.

Persistent Storage

There are many techniques from which to choose. The following is a list of a number of them, although the list is not exhaustive:

  • Using the usual database

  • Using the Registry

  • Using Active Directory

  • Using Object Construction (OC)

  • Using the .config file

Let's discuss each of these techniques a little further. When you read this discussion, please keep in mind that it's not my intention that the persistent storage should be hit each time the configuration data is needed, but rather it should only be hit once or at least infrequently. (The second part of the solution, how to access the configuration data in transient storage, will further explain this.)

Using the Usual Database

The first technique, using the usual database for holding configuration data, might seem a bit strange, but this is often a really good idea. The good thing about it is that you have one centralized place for the stored configuration data, even if you have a cluster of application servers. You also have the protection of transactions if that is a requirement for you in this case.

One drawback could be that you waste some scarce resources when you have to hit the database for fetching configuration data too. This is not usually a problem, because you will rarely hit persistent storage for configuration data, but it's still something to think about.

I know, I know. Storing connection strings in the database is not a good solution, at least not if the connection strings describe how to reach the database.

Using the Registry

I have to confess that I used .ini files long after the Registry was introduced, but after a while I started to like the solution that the Registry represents. (Sure, I see the problems with it, too, but I still like it.) As you know, Microsoft has now more or less put the Registry on the legacy list and you're not supposed to use it anymore, mainly because it creates a more difficult deployment situation compared to using .config files instead, for example.

You will normally use the Registry class in the Microsoft.Win32 namespace as the entry point when working with the Registry in .NET.

Using Active Directory

You can think of Active Directory as the "Registry," but it spans all the machines in your network and all the information found on all machines. For many developers, it has become a popular place for storing connection strings and similar items.

It was hard to work with Active Directory (or rather ADSI) from VB6, but it's now much easier in .NET. You start by using the DirectoryEntry class of the System.DirectoryServices namespace for finding information in the Active Directory.

Using Object Construction (OC)

COM+ 1.0 made it possible to store a string in the COM+ catalog for a specific component and then retrieve that value when an object of the component was activated. This is still a useful and viable solution for serviced components. As you will see in the next section, I see OC both as a solution for the persistent storage and also as an access mechanism. However, you can also use it just as a persistent storage mechanism so that when you find that you need to read the value from persistent storage, you instantiate an object of the component that is using OC, grab the value, and store it in transient storage.

Listing 4.26 shows code that illustrates how OC can be used for serviced components. As you can see there, I override the Construct() method, and the parameter called constructString is the string that can be changed in the Component Services Explorer.

Listing 4.26 Example Showing How to Use OC in a Serviced Component

Imports System.EnterpriseServices
<ConstructionEnabled _ (Default:="Hello world")> _
Public Class OcTest
  Inherits ServicedComponent
  Private m_Data As String

  Public Overrides Sub Construct _   (ByVal constructString As String)
    m_Data = constructString
  End Sub

  'And some more methods...

End Class

Using the .config File

.config files are files in XML format for holding configuration data. They were introduced in .NET as a solution for helping with XCOPY deployment. (With XCOPY deployment, a single XCOPY command deploys an application at another server. There are no Registry settings that have to be written, no registrations of DLLs, and so on.)

.config files can be used for configuring the built-in tracing solution in .NET, as well as your own tracing solution.

Unfortunately, .config files don't work so well with serviced components. .config files are for EXEs, rather than DLLs, and that is pretty natural. Consider a DLL that is shared by several EXEs. It should probably be possible to use different settings for each EXE. So far, so good. The problem is that COM+ server applications are executed by the surrogate EXE called Dllhost, and there is only one EXE for all COM+ applications, so it's problematic to use the settings for, say, built-in tracing in the .config file. It's also the case that Dllhost isn't written in managed code, and it doesn't know that it should load a .config at all. This is why it's also problematic to use the System.Configuration namespace. Finally, you will have to keep the .config file in the same directory as the Dllhost EXE, and it's located in your system32 directory. So much for XCOPY deployment.


Yet another problem with using .config files is that the built-in tracing solution won't refresh the values found in the .config file. Instead, the .config file is read only once for the process. This is not a big problem for a Windows Forms application, but it might be a huge problem for a COM+ application.

Instead, I have decided to use a custom approach for reading .config files from COM+ applications. I use the format of .config files, but I give them the name of the DLL to which they belong (same value as for exeOrDll constant). The .config files will then be stored in one specific directory. I have decided to use c:\complusapps. Then I use custom code for parsing the .config files, so this approach is quite easy after all.


An interesting white paper that is not only related to adding support for debugging but also about configuration data is Amitabh Srivastava and Edward Jezierski's "Monitoring in .NET Distributed Application Design."9 The paper discusses Windows Management Instrumentation (WMI) and how it can be used for updating .config files, which is just another advantage of the technique of .config files.

Access Mechanism (and Transient Storage)

You also need to think about how to access the configuration data. You can, of course, go to the persistent storage each and every time, but this is probably too costly if you need to go there often. Therefore, the following are a few techniques that I'd like to discuss for providing an access mechanism to transient storage. (Note that this list is not exhaustive.)

  • Using the Shared Properties Manager (SPM)

  • Using Object Construction (OC)

  • Using the Shared (static) member

  • Using the ThreadStatic attribute

  • Using Object Pooling (OP)

Once again, let's look at each of these techniques in detail, starting with the SPM.

Using the Shared Properties Manager (SPM)

The Shared Properties Manager (SPM) is an old, faithful component service that is still around. You can use it from your serviced components as a dictionary object to store keys and values, similar to the Application object in ASP.NET. However, the SPM can group the keys in property groups.

The programming model of the SPM is a bit different from other dictionary objects, but it's still quite simple. You can see a sample in Listing 4.27, where a value is read from the SPM (or written if it wasn't found in the SPM).

Listing 4.27 Reading a Value That Is Stored in the SPM

Imports System.EnterpriseServices
Public Class SpmTest
  Inherits ServicedComponent

  Public Function Test() As String
    Dim theExist As Boolean
    Dim aManager As New SharedPropertyGroupManager()

    Dim aGroup As SharedPropertyGroup = _
    aManager.CreatePropertyGroup("MyGroup", _
    PropertyLockMode.SetGet, _
    PropertyReleaseMode.Process, theExist)

    Dim aProperty As SharedProperty = _
    aGroup.CreateProperty("MyProperty", theExist)

    If Not theExist Then
      aProperty.Value = Now.ToString()
    End If
    Return aProperty.Value.ToString()

  End Function
End Class

Using Object Construction (OC)

In the previous section, I talked about OC as a mechanism for persistent storage, but it is also a mechanism for accessing transient storage. Refer toListing 4.26 for a code sample.

Using a Shared (Static) Member

Using a Shared member variable is by no means specific to serviced components, of course. It's a simple and efficient mechanism. Its main problem is that you only have one single instance that is shared by all users and their components, which can lead to concurrency conflicts when the value isn't read-only. Because of this, you have to protect the value by writing thread-safe code. This will result in wait states in a highly stressed environment when the Shared member is to be used all the time. Most often, it won't cause you any problems, but in some situations—as I said, under extreme load—it might be a show-stopper.

To get a cheaper locking solution, you can implement a ReaderWriter lock instead. That means that there might be several readers at the same time, but only one writer. Do you get a déjà vu from the database area? You can find more information about how to implement a ReaderWriter lock in the .NET online help.


I must warn you against trying to write thread-safe code manually. If you do so, you might create a debugging nightmare for yourself, either now or in the future. Be careful and make sure you know what you're doing.

Using the ThreadStatic Attribute

It's possible to use TLS in .NET too, so that each thread will have it's own local data. It's easily achievable by just marking a Shared variable with the ThreadStatic attribute.

This will mean that you will have as many instances of the data as you have threads. There will be no blocking, because each thread will the data it needs. This might also mean a problem for you because you waste memory, but that is most often not the case for configuration data.

Using Object Pooling (OP)

The final technique that I'd like to discuss for providing an access mechanism to transient storage is using Object Pooling (OP) in serviced components. If you still remember the technique of thread-specific global variables from the days of VB6 (and which I discussed earlier in this section about configuration data), OP is the technique that comes closest to that solution. Not that pooled objects are tied to a specific thread, but you will have a pool of n number of objects with OP, so that you can avoid the situation of several simultaneous requests of the same value leading to wait states. On the other hand, the larger the pool, the larger the amount of used memory, of course.

However, while it is an advantage that several instances minimize contention, it's a disadvantage if it's necessary for all instances to have the same values all the time. If it is necessary, you'd better use one single value instead (unless it's not a "fetch once, use many times" type of data).


Both Object Construction and Object Pooling can be used, even when the object is located in the context of the caller, because neither of these services are built with interception.

Summary of Persistent Storage and Access Mechanisms

Not all access mechanisms can be used with all persistent storage mechanisms. Table 4.3 presents the possible combinations.

Table 4.3 Possible Combinations of Access Mechanisms and Persistent Storage Mechanisms




Shared Member

Thread Static


Database server












Active Directory












.config file






As you see in Table 4.3, only OC is a bit inflexible as an access mechanism because it is so closely related to its storage. You can let the users affect OC as an access mechanism by using the Admin API for COM+ to change the stored value, but it is sort of a hack. At least, I don't think this was the way OC was supposed to be used.

How and When to Refresh the Cached Configuration Data

Finally, it might be a problem deciding when to refresh the cached configuration data. A simple approach is to encapsulate the data so that each time there is a request for the data, you can investigate whether a certain amount of time has elapsed since the last time the date was refreshed. If so, you go to persistent storage to read the data and remember when this happened.

If you use Object Pooling for caching the data, it might be a good idea to introduce a two-phase technique so that not every object in the object pool has to go to persistent storage. Instead, you have one single pooled object (of, say, class A) that is responsible for this, and every pooled object (of, say, class B) will only go to the object of class A when they find out that it's time to refresh their data. Class A uses a similar algorithm so that it doesn't go to persistent storage each time it is called by a B instance. If you use a schema like this, you have to remember that the maximum time for different instances to be out of sync is the sum of the refresh delay of the A object and the refresh delay of B objects.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020