I have a Class Library project containing some basic logic.
The DLL created by this project will be used in a few other projects.
I have a app.config file in the Class Library project with a couple of values the DLL uses.
When each consumer project will use the DLL, it has to change the values in the app.config
For example, if my DLL's app.config contains 3 settings: A, B, C, then:
The first consumer of the DLL will have A="a", B="aa", C="aaa" .
The second consumer of the DLL will have A="t", B="tt", C="ttt" .
and so on...
From design point of view, what is the most clean way to achieve this scenario?
(It seems to me that the app.config should reside at the project that uses the DLL)
Thanks for your attention! :)
EDIT:
Most of my code in the DLL is consuming ASMX web service which includes it's .config . Each application that will use the DLL, has it's own WS address (the contract is identical). How can I inject the address of the service from the application into the DLL?
EDIT #2:
Now I have 2 config files:
1. In the class library project - contains the WCF client config.
2. In the application that uses the DLL - contains the config with the values for the DLL.
How can I inject values from the application's config into the DLL's config (for example the address of the endpoint) ?
Only applications have a .config file, so having a .config file in your class library is useless.
That means that the values should come from somewhere else
The options I can think of are:
Use the .config file of the application - disadvantage: The person that write the application need to know about your config values and add them. Most of the time he/she will find out about these setting when they will get exceptions for missing values.
Save values to a DB (or some other web service) if all your applications use the same DB this can be a good idea. Works nicely when you have a very limited number of applications. I use this for different values for production/test environments
Make every class that needs these values to get them in a contractor. advantage: no hints needed, the application programer will be aware to data. This is a clean interface. I would use this option if it's a customer specific project. disadvantage: lots of work for the applications programer
Related
I have an older asp.net solution consisting of several projects. The data access layer is contained in a separate class library project while the frontend is in another project.
The data access project is using Application Settings (https://msdn.microsoft.com/en-us/library/a65txexh.aspx) for several settings, among others 3 connection strings. I have a /Properties/Settings.settings file which - when changed - results in an updated /app.config file.
My problem is that I haven't found any way to automatically change these settings when building and publishing the solution.
I know about web.config transformations (https://msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx) and that Visual Studio offers the ability to create a so called "Config Transform". But as far as I know a class library doesn't have a web.config file and this menu option is not available for neither the Settings.settings file nor the app.config file.
Is there a way to automatically change the settings.settings file/app.config or is there a completely different best practise to provide connections strings to a class library?
EDIT: I should add to the above that the Data Access class library is using Datasets.
I'm using EntityFramework 4 in my WPF desktop-application (NS: MyCompany.MyProduct).
Now I want to create the same application in ASP.NET (NS: MyCompany.MyProduct2), with the exact same functionality... Hence I need to use the exact same database as the WPF application already does.
Additionally, I want to create a new executable (hence a new wpf project) on top of my primary WPF project, that also uses the same ConnectionString like the WPF / ASP.NET-Application, to display some reports.
So I figured out I'd need to share the .edmx-Model (NS: MyCompany.MyProduct.Models.DBModel.edmx) and the ConnectionString that is already persistent in the app.config of the WPF app or the web.config of the ASP.NET-App.
What is the best or recommended way to do this?
What is the best or recommended way to do this?
Create a class library project and put EF model in there and share it between your WPF/Web projects. The app.config file of a library project isn't picked up by the parent project therefore you will have to manually update your web.config file to add the ConnectionString section.
This approach allows you to share business logic between your WPF app & your web app. If they are essentially the same app but on different platforms, then you should only be re-implementing the UI - this is one of the major advantages of the MVC pattern.
Agree with #James here. Don't be afraid of adding library projects to your solution. So you would have a project called MyCompany.Model that contains your EDMX. (Actually, you might find later that you want to use the T4 generation to split your model off from your DbContext or ObjectContext, but that's another discussion.)
With Visual Studio you can actually add a project--your EDMX project--to more than one solution. Be careful not to make changes to the EDMX project when editing one solution that break the other, though.
Respectfully, you may find that it's not ideal to use the GAC here, especially if your EDMX is still evolving.
As for connection strings, these are one thing that you tend not to share between projects. Typically they are in the app.config (or web.config) for your executable project. This can be a gotcha, because if you use a library project to hold your EDMX, EF will automatically create an app.config in the library project, with the connection string in it. But .NET never uses an app.config for a DLL. The only reason it's there is to give you something you can copy/paste into the real app.config for your executable (WPF) app.config or the web.config.
If your goal is to share the single .edmx dll between all three applications on one machine, the best way to accomplish this is to sign the dll, then add it to the GAC. If the dll will remain on different servers, there is no need to GAC the dll, you can just reference it in your projects, and add the connectionstring entry in the respective .configs.
GAC: http://msdn.microsoft.com/en-us/library/yf1d93sz(v=vs.100).aspx
Install a DLL to the GAC: http://msdn.microsoft.com/en-us/library/dkkx7f79.aspx
I have a windows service. The idea is to execute as many different tasks as possible. Lets say we have this IServicePart interface with Start() and Stop() methods. When the service starts it will search all assemblies in some directory and find all classes which implements IServicePart. Done, no problem.
The problem:
Assembly1.dll is a good candidate for IServicePart. But it needs a configuration. For example Assembly1.dll.config. Now I can copy/paste/rename the dll to task2.dll and task2.dll.config and create a second task for the service. Each of those plugins comes with 10-20 dll dependencies
1) The most obvious problem is how to load the configuration, because the service host's appDomain is different than assembly1 and task2.
2) I expect issues when I try to load the two IServiceParts when they depend on the same 3rd party assemblies
Solution 1 is to make a custom configuration and not use the app.config.
Solution 2 is to run each plugin in its own appDomain.
What are your suggestions.
Hope I explained this correctly
===================
reference: similar question here: Plugin to use its own app.config
The way I've done this, involves having each plugin in its own app domain. However, the codebase property of those appdomains continue to point to the root directory where my service exe is located. This achieves two things:
The many tertiary dependencies that the plugins have now don't need to be duplicated. For example, I can put my logger assembly in the root folder (with the service exe) and all the plugins can see it. This is great, because I neither wish to put my logger assembly into each plugin subdirectory, nor do I wish to use the GAC.
All plugins now share the same app config (the same one used by the service exe). This is a good or bad thing, depending on your needs. But don't forget the configSource attribute, which can allow you to put specific config sections into seperate config files within your plugin subdirectories.
Incidentally, I've been using MAF for my plugins.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Reading dll.config (not app.config!) from a plugin module.
I have two different projects, say A and B. I need to use some classes of A in B. So I added a reference to A in B. When I tried to run the application, I stated getting Object reference set to null exception. On investigation, I found that when I access classes of A from B, control goes to project A, but C# still uses config file of project B instead of using project A's config file. How do I get around this? How can I "include" A's config file in the dll?
I have gone through this blog but I feel it is a very dirty way of doing it. There ought to be an easier way!
Let me know if the question is unclear..
I believe .NET will always load the app.config file associated with the application rather than any libraries. There are complicated ways of specifying your own locations for config files - or just using your own configuration framework instead of the built-in one - but I don't think you can just ask .NET to load a config file per DLL.
Why don't you just all the necessary settings into the config file from project B? If you use some tools and libraries from an external vendor you just do the same stuff to configure it.
If you abstracted the configuration good enough you should be fine. Using another configuration file than the default one - well i would consider this as bad practice.
As I understand this you want integrate a app.config into your dll. Check this out:
How do you load the app.config file into a DLL
You can copy the relevant sections of A's config into the B config file and it'll work properly, but it's a bit tedious to say the least. I suppose you could automate it with a custom tool though.
I've used these two configuration files many times before, but I've never taken the time to fully understand how they really work. As most people do, I understand the basics in how to call WebConfigurationManager.AppSettings["key"] to get config values.
Here are some questions I came up with:
What happens when you reference a configuration value within a class library, and the library is part of a bigger solution? Does the app.config need to be copied to the output directory in order for the variables to be found? (I assume yes)
Can you directly use a configuration value from an app.config in another class library?
Assuming question 3 is "yes", what happens if there are multiple app.config files from different libraries containing configuration values with the same key?
What happens when you reference the web.config, but in a class library?
What happens when you reference the app.config, but in a website or web application project?
The underlying answer to all of your questions is the same: Unless you set up something unusual, all assemblies in your project will read from the same configuration file. In a web app, they will all read from "web.config". In any other project type, they will read from the starting assembly's config file.
The app/ web.config that is used is the one that starts the process. Easier if I give an example:
Assume all projects in a solution have an app or web.config.
A test in project A calls code in project B that calls a web service in project C which calls code in project D.
In this case code in project A and B will use the app.config in project A. Code in project C and D will use the web.config in project C.