I am working on a class library that uses Microsoft enteprise library logging application block. I have some settings in my app.config file.
Now, when a developer uses this library in a web applications, they have to copy entire config sections and appsettings part from the app.config to the web.config.
Is there something which can be done to bypass this step and makes it easier for developers to use my library without manual copy of all those settings.
Could try putting the repeated sections in an external config file, adding that file as a reference to the web.config project, and then referencing it in both the app.config & the web.config.
Enterprise Library has a visual config editor that you can use to load your web.config.
You can choose the settings you want and have them persisted to this file. Personally, I would not use Enterprise Library unless I had no choice. Simply too much glop code and overhead.
Related
I have built a server api that consists aith 3 projects:
Api(an api project) that calles BL(class library) that calls Dal(class library).
Very standard.
It works perfectly locally.
Now when I publish it, the app.config of the BL disappears.
Why is it? Where can I store my configurable parameters?
Thank you very much. Tal
On your main project ASP.NET, use the Web.Config instead of App.Config to make it work.
app.config is only the name during development, once the project is built the app.config is copied to .config and this is what is used by the application when running
An asp.net application reads config from web.config so if you have an app.config it implies that your project is not a web project but a standard library or executable.
if it is a library (.dll) then you should place your config in the web.config (if the library is used by asp.net) or in the .config if its a standard executable.
Ideally your libraries should not read settings as this creates a hidden coupling between the library and config files, and it would be better to provide those configuration parameters to the classes that need them in the library externally, this then leaves the application using the library free to store them where ever is most appropriate.
How is the consumer of your library going to know that they need to add SettingX to the appsettings of their configuration file? Better for the library to require the setting value directly. So if your DAL needs a connection string then the class which wants a connection string should ask for it in their constructor. Then the application using it can get it from settings (or whereever) and pass it to the library., and the consumers have visibility of the dependency on the connection string. If the library reads it from config the consumer has no way to know that this is something they need add to the settings
So in a web app the startup would read the settings from web.config and pass them to your library but some other app using the same library could store them in a database if they wanted.
I have an ASP.NET solution in which there are two separate projects. One is normal UI and the other one is a class library which is being referred in the former.
In my class library project I am trying to read from App.Config file but it is reading from Web.Config file. I am using:
string url = Convert.ToString(ConfigurationManager.AppSettings["UpdateURL"]);
Initially, this key was written in Web.Config but now I have removed it from there and added this into the App.Config file. However, the compiler is still trying to fetch it from Web.Config. There may be something wrong I am doing. Please tell me what changes I need to make to get this done.
A web application will use web.config.
Keep your app settings inside that. A dll specic config file is not required.
A windows application will use App.config while a web application will use web.config.
If you use your dll in a windows or console application put the setting in app.config.
Dlls will always use the config file of the application they are loaded into.
If you want to have a dll specific config file, you will have to load it yourself.
This is normal behavior. Any referenced project will run under the parent's rules.
So if your class library had his own appConfig file, this one is no longer "valid". The Web.Config file has preference.
You need to copy the appSettings section of the class library into the Web.Config file.
You also have the option to "chain" the reading of the settings, it's like, the appSettings section of the web.Config might point to another .config file, but that's just a matter of taste and it's up to you.
Is it there (I'm sure there is) a way to separate the local Config file and the online ? I don't want to write and rewrite each time i upload my web.config files! talking about an asp.net mvc3 application!
If you're using .NET 4.0, take a look at Web.config Transformations
It basically keeps a base web.config file, and then you can specify different values depending on whether you're in Release or Debug mode.
Another simple solution is to have sections of your web.config reference external files. You can then change the external file without a need to restart the web application.
You can then overwrite the external file with one that contains data required for your local environment.
When you come to publish your app. you can include the online config files.
when building a desktop app in wpf can you read documentation of problems and safely subsititute 'app.config' when people's answer's refer to 'web.config'?
if so are there any glaring GOTCHAS you have to look out for?
tnx
Read the Documentation:
Web.config and App.config
The choice of the
configuration file name is determined by the hosting environment you
choose for the service. If you are using IIS to host your service, use
a Web.config file. If you are using any other hosting environment, use
an App.config file.
In Visual Studio, the file named App.config is used to create the
final configuration file. The final name actually used for the
configuration depends on the assembly name. For example, an assembly
named "Cohowinery.exe" has a final configuration file name of
"Cohowinery.exe.config". However, you only need to modify the
App.config file. Changes made to that file are automatically made to
the final application configuration file at compile time.
In using an App.config, file the configuration system merges the
App.config file with content of the Machine.config file when the
application starts and the configuration is applied. This mechanism
allows machine-wide settings to be defined in the Machine.config file.
The App.config file can be used to override the settings of the
Machine.config file; you can also lock in the settings in
Machine.config file so that they get used. In the Web.config case, the
configuration system merges the Web.config files in all directories
leading up to the application directory into the configuration that
gets applied.
Web.Config is used for asp.net web projects / web services.
App.Config is used for Windows Forms, Windows Services, Console Apps and WPF applications
Your question isn't providing all the information as to where the gotcha's may lie for you.
Can you give us more info on what you are trying to do in terms of these config files?
Here's a link...
Problems with Web.config and App.config
I have an solution in VS 2008 which contains two class library projects and an ASP.NET web site. The ASP.NET site references the class libraries and one of the libraries contains a LINQ To SQL item.
My question is with regards to the app.config in the class library which contains the connection string for the database. When I build the project, this app.config isn't within the build directory and this means I can't dynamically change the connection string for the deployed project.
What am I doing wrong here, how can I have these settings deployed too so I can make changes to the connection string?
Thanks in advance,
Martin.
This caused me a bit of confusion at first as well.
You might think that the class library uses the app.config file that's contained in it's own project but it doesn't. It uses the config file of the project that is referencing it.
So what you need to do is look for the <appSettings/> tag inside the web.config file of your ASP.Net project and change it to <appSettings></appSettings> And add the <add ... /> tags that are contained in the app.config file of the library project. You don't need to change anything in your code for the ConfigurationManager class to figure this out. It knows where to look automagically.
Hope that makes sense.
You can edit the Web.config file in the final product. Configuration APIs normally will get configuration data from the primary configuration file of the application which, in case of ASP.NET apps is the Web.config and for client applications is Myfile.exe.config. It's important to know that class libraries in the project usually will not have their separate configuration file like MyClassLib.dll.config (unless you manually refer to the specific file).
To overcome the problem of connection string, here is the trick
Inside ur class library declare module that has got two properties, one is a setter and the other is a getter, and make them public.
Inside ur website project, go to the global file, and under both session start and application start call the setter property that u declared previously, and assign it the connection string that is located in ur web.config, now the connection string will be available in the website general scope and the value exists as long as ur session credential not expired.
Copy the connectionString section from your library's app.config file to your web.config file. Change the actual connection string from your development to your production server as necessary. The ConfigurationManager class that LINQ2SQL uses to obtain the connection string will look in the web.config file for the appropriately named connection string and use it if it exists.
If you want to have different settings for development vs production, use the Web Deployment Project. Download here. From Microsoft's description:
Visual Studio 2008 Web Deployment
Projects provide additional
functionality to build and deploy Web
sites and Web applications in Visual
Studio 2008. This add-in provides a
comprehensive UI to manage build
configurations, merging, and using
pre-build and post-build tasks with
MSBuild.