Using ConfigurationManager With DLL Library

Posted on 2012-09-12
Last Modified: 2012-09-12
We have a solution which contains multiple projects. These projects utilize many shared business objects. Our thought was to create a DLL library of the classes for the business objects and reference it from the various projects.

Each of these projects has an app.settings file. We want to be able to reference settings in the project app.config file when instantiating objects and calling methods within the DLL library (i.e. the app.config for the application contains a database and server name as well as a connection string - we want these values to be used by the classes contained in the DLL library when creating database connections).

We think we should be able to read from the configuration of the calling application from within the DLL, but have been unable to find any documentation on how this is done.

Can anyone point us in the right direction to solve what must be a common issue?

Question by:ellswrth
    LVL 40

    Accepted Solution

    The application uses the dll, not the other way around. It is bad practice for a dll to "use" the application. And the role of app.config is to record information for the assembly itself, not for another assembly. You might share resources, but sharing an app.config file is not a good idea.

    If you want to share information, do it in a conventional way, by passing parameters from the application to the dll.

    You could handle that with a Shared property in one of the classes of the dll. A Public Shared property does not required an object to be accessed, you simply go ClassName.PropertyName = Value. And it is shared between all the instances of the class, meaning that if you set it once, then it stays put and available from anywhere in the dll.

    If declared Public, it can also be set from an application that uses the dll.

    Author Comment

    OK, sort of get it.

    A little perplexed about the Shared property though.

    What we're (obviously) trying to do here is to be able to tell the DLL what db to connect to, and change it from installation to installation.

    This DLL has many classes in it.

    If I follow what you're saying, we can create a Public Shared property ConnectionString on ONE of the DLL classes and set that with the appropriate string.

    Then, at application start, we set that property (without necessarily instantiating the containing class) and reference it from ALL the other classes, and they will ALL use that property?
    LVL 40

    Expert Comment

    by:Jacques Bourgeois (James Burger)
    You got it properly.

    Shared fields, properties and methods is what is generated by the compiler when you create a module in VB. Modules do not exist in .NET. Microsoft kept them in VB to ease the transition from VB Classic. Underneath, the compiler compiles them as static members, that can be used directly on the class, without having to instantiate any object. I could have told you to do that in a module in your dll, but since you seem to want to go with an object oriented approach, I oriented you toward the class equivalent of a module.

    Note that the documentation, they are usually discussed as static members, not as shared members. Because was already used for local variable declarations in VB, Microsoft decided to use Shared in VB instead of the Static declaration used in most other languages.

    Author Comment

    Thanks for the quick lesson - yes, we are trying to move towards an object oriented structure - this library is full of business objects and is built to eliminate the need to write the same code many many times.

    I quickly revised our code as proof of concept, and it proved the concept ;-)

    One question, though can you elaborate on why it's bad practice for for a DLL to “use” the application by obtaining configuration from it?
    LVL 40

    Expert Comment

    by:Jacques Bourgeois (James Burger)
    Did you ever have to use the configuration file of any other application but your own in the time you have been developing? I do not suppose so. Each assembly (an exe is an assembly, a dll is an assembly) has its own configuration file, a tool that was designed by Microsoft to be used by the assembly itself, not by other assemblies that are reference by it.

    Look at the code generated by the compiler to access the data in app.config. It is in the Settings.Designer.vb file that you will find under the My Project directory of your project. It is declared Friend, meaning that it can be used only by code in the same project. Your dll is another project, so it does not have access to that code. Microsoft probably has good reasons to declare it Friend instead of Public.

    If you were developing the dll to be used by only one application, you might lower the meaning of "bad" in bad practice. But since the same dll might be used by many applications, forcing each application to answer to the dll would be too much. It is already quite a job to provide a good one way interface between an application and a dll. Doing it both ways is not as easy.

    When in the dll, you know that it will be used by many different applications, possibly of different types and needs. Your user will be a programmer. You program accordingly. When in an application, you think only of the job at hand. Your user will be a "normal" person. You are not in the same state of mind when you program an application as when you program a dll.

    Your want to program in an object oriented way, think of the real world of objects. The analogies are usually good. Take a drill. This is a tool, same as a dll. If it was designed to work on a specific material, it would not work or work very badly with other materials. But because it is designed without taking into account the materials that it will be working on, you can use it on almost anything.

    Same for a dll. If you design it with the application in mind, it would be a lot more limited than if you designed it so that any application can use it. Requiring the application to pass a parameter is thus a better way than having the dll know how to read many different applications settings.

    And old programmers like me always think of maintenance, specially for dlls. If one of these days Microsoft implements an alternative way of reading configuration files, you will thus be able, without modification, to use the dll with any application, no matter what type of settings it use. If the COM / ActiveX dlls of the 90's had been designed so that they needed to know about the applications that use them, it would probably be impossible to use them with .NET applications.

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    Find Ransomware Secrets With All-Source Analysis

    Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

    I think the Typed DataTable and Typed DataSet are very good options when working with data, but I don't like auto-generated code. First, I create an Abstract Class for my DataTables Common Code.  This class Inherits from DataTable. Also, it can …
    Introduction As chip makers focus on adding processor cores over increasing clock speed, developers need to utilize the features of modern CPUs.  One of the ways we can do this is by implementing parallel algorithms in our software.   One recent…
    Need more eyes on your posted question? Go ahead and follow the quick steps in this video to learn how to Request Attention to your question. *Log into your Experts Exchange account *Find the question you want to Request Attention for *Go to the e…
    Excel styles will make formatting consistent and let you apply and change formatting faster. In this tutorial, you'll learn how to use Excel's built-in styles, how to modify styles, and how to create your own. You'll also learn how to use your custo…

    737 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    22 Experts available now in Live!

    Get 1:1 Help Now