[Last Call] Learn how to a build a cloud-first strategyRegister Now


Using ConfigurationManager With DLL Library

Posted on 2012-09-12
Medium Priority
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
  • 3
  • 2
LVL 40

Accepted Solution

Jacques Bourgeois (James Burger) earned 2000 total points
ID: 38391741
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

ID: 38391911
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
ID: 38392212
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

ID: 38392411
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
ID: 38393145
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.

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Introduction When many people think of the WebBrowser (http://msdn.microsoft.com/en-us/library/2te2y1x6%28v=VS.85%29.aspx) control, they immediately think of a control which allows the viewing and navigation of web pages. While this is true, it's a…
1.0 - Introduction Converting Visual Basic 6.0 (VB6) to Visual Basic 2008+ (VB.NET). If ever there was a subject full of murkiness and bad decisions, it is this one!   The first problem seems to be that people considering this task of converting…
Exchange organizations may use the Journaling Agent of the Transport Service to archive messages going through Exchange. However, if the Transport Service is integrated with some email content management application (such as an anti-spam), the admin…
Whether it be Exchange Server Crash Issues, Dirty Shutdown Errors or Failed to mount error, Stellar Phoenix Mailbox Exchange Recovery has always got your back. With the help of its easy to understand user interface and 3 simple steps recovery proced…
Suggested Courses
Course of the Month18 days, 12 hours left to enroll

834 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