I have a class library, which has an app.config and when built it put the app.config along with the dll in the output directory I have chosen.
I don't want it to be name app.config though, if I have another component that has it's own dll, I can see confusion happening.
I've been looking at another project, that does exactly that, but I can't see why it outputs dllname.dll.config and mine always app.config.
Any ideas?
Thx
You probably have set the Copy to output directory setting of the app.config.
BUT: In a class library, an app.config is useless.
Note, that you can only have one config file per application. The configuration is being read (at execution time) from <executing assembly file name> + ".config".
Related
I have a console application in which website project is added as dll. Inside dll ConfigurationManager.ConnectionStrings["XXX"] is called which is always returning null.
But web.config in dll has connectionstring named 'XXX'. Can any one suggest what is going wrong?
I don't think .config file of the .dll is added to your console project together with the dll. You need to have the .config in your executing project.
Try copying the config file to your console project. Or at least the connection strings section. Probably in an App.config.
I had a slightly different problem that I haven't seen an answer to. I was using.
ConfigurationManager.ConnectionStrings["XXXX"].ConnectionString;
When I opened up web.config I saw that the connection string I had created was prefixed with "WebApplicationAPI.Properties.Settings." - putting the entire string in worked for me:
ConfigurationManager.ConnectionStrings["WebApplicationAPI.Properties.Settings.XXXX"].ConnectionString;
Your config file is not in the .dll. So you're referencing nothing I would suspect! Unless you've manually copied the web.config file to the correct location or references it via an absolute path?
web.config is for web application.
For console application you have to use app.config.
Well, actually that's the default configuration for C#, I won't be surprised some advanced user could make it go the other way arround.
I have an application that gets compiled into an executable. It relies on an app.config file (which gets turned into a MyApp.exe.config file).
I needed to make an update to the application, so made the change, recompiled, and then replaced the application.exe file. But it wouldn't work...until I also copied up the new app.config file with it, even though the app.config hadn't changed.
Can someone explain this? Does the app.config become a dependency that is versioned like any other dll? I thought since it is a config file (essentially a text file), it wouldn't be versioned and depended on in this way.
The app.config file is just an xml configuration file. There's no versioning like with assemblies.
Is it possible some of the changes you made added some config to the app.config that's in the original app.config. For example, adding service references will change the app.config with endpoints and config needed for web services.
what error do you get?
I have looked around and simply cannot find a way to open a linked XML file. My folder structure is like this:
...\projects\ConfigService\
...\projects\Shared\
...\projects\WebTool\
Inside the Shared folder I have a single XML file that will be modified by the WebTool project and read by the ConfigService (many times after each one is built and running). To make things as simple as possible, I simply tried "add as link" at the XML in each project, but then how do I actually get a full path to the linked object so I can open it? I use a link because the file will be changed after my projects are built, but I will not rebuild.
All answers I have found either try to pack the linked file into the project's binary, or the instructions are for adding classes/code instead of just a flat resource.
Or is there a better way to do this?
The solution that worked out best for him was to use the Server.MapPath() method to find his Shared folder regardless of where in the file system his website was rooted. Since it will always be [virtual-directory]\Shared this works out perfectly and he doesn't need to worry about config settings.
I think you want to use an app.config file to resolve this. Here's how you would do it.
In the WebTool service, and in the Config service, add an app.config file with the following text:
<configuration>
<appSettings>
<add key="XmlFileLocation" value="c:\folder\projects\shared\myfile.xml" />
</appSettings>
</configuration>
Then, you can retrieve the file location in each program by using the following:
string filepath = ConfigurationManager.AppSettings["XmlFileLocation"];
You'll have to add a reference to System.Configuration in your projects though.
Good luck!
Two ways to go
One depends on how you are going to deploy. If they are all going to same folder, the Mr Oded's solution is a quick and simple.
If you are deploying to a more complex folder structure e.g
MyApps
Shared
ConfigService
WebTool
The create a folder structure that mirrors that and set the output directory in each project to the relevant one (instead of the default bin\debug bin\release). The you can grab it with a relative path from from each tool e.g. (..\MyXmlFile.xml).
That said, I like neither of the above.
What else in shared? If there's a dll, then may be it should have a method that returns the location of the file, or the content, and let it manage where that location is.
PS don't forget seeing as it is exposed on the file system (somewhere), you need to cope with some well meaning individual deleting or modifying it.
I'm trying to use application settings with a C#.NET project I am working on. But I can't seem to get it to return anything other then the default values. Through the project properties I've added a single setting, DBConnectionString, and set its value to a connection string I want to use. Its scope is set to "application".
Doing this created a number of files including Settings.settings, Settings.Designer.CS, and app.conifg. From what I understand the two Settings.* files define a custom Settings class that derives from ApplicationSettingsBase. The Settings class then has custom, type safe, properties that can be used to set and retrieve each setting. The app.config file is a XML file that stores the actual settings values.
When I build my project it looks like the app.config file is copied to the target directory as MyApplication.dll.config. My program runs fine and is able to use the default connection string.
Next I tried to edit the MyApplicaiton.dll.config file to change the connection string. I ran my program again, but it continued to use the default value. I noticed that in my Settings.Designer file there is a DefaultSettingValueAttribute with the original default string. I tried removing this attribute, but then when I tried to retrieve the connection string setting it just returned null.
This is the code I'm using to read the connection string.
string conn = Properties.Settings.Default.DbConnectionString
What am I doing wrong? How can I get it to return the value in the settings file and not the default value?
Update:
Sorry I should have mentioned this. I'm actually writing a plug-in for another application through a public API. So my project is a DLL not an EXE.
You cannot read settings from *.dll.config files. If you library needs any special settings you need to put them in your app.config or web.config files.
EDIT: You can include the external config files in the main application or web config file. Look here for details.
This question discusses how to manage configuration files for large projects.
Settings files and .config files are different things (I do not know why VS automatically added a .config when you created a Settings file). But, the settings file is compiled into a class and is referenced like you said. If you decompile the dll with .NET reflector the Settings class will be in there. It is used for holding constant values or external resources. For example: error message strings, icons, or images.
The config file is for settings which can change frequently or between environments (dev, test, prod). For a connection string you should use the <connectionStrings> section of the config file. And the property can be referenced using System.Configuration.ConfigurationManager[ "connectionStringName" ].
However, from your original post it looks like your .dll is going to be used in a larger project (either an .exe of web project). One thing to note is that all projects only use one .config file. And that is the config file for the main project. Websites the web.config file, and exe's use XXX.XXX.XXX.exe.config (as you saw, *.exe.config files are renamed copies of the app.config files). dll's do not have usable config files. All dll's will look at the main project's .config file to retrieve information.
If your connection string is never going to change then by all means use the Settings file. Otherwise, use a config file and let the developer of the main project determine what to populate the connection string with.
I have a config file in my C# class library called MyLibrary.config, in vs 2008.
I created another project, say a simple console app, add reference by "Browsing" the MyLibrary.dll in the bin directory of the class library project, and when I compile, the MyLibrary.config is not including in the bin directory of the output in the console app.
How can I set it so I can include it when I reference the dll?
Cheers
You can't. Your console application is expecting to find a config file with prefix the same as the name as the console application (MyConsoleApplication.exe -> MyConsoleApplication.exe.config.).
In some situations you can share a config file by using the file attribute on the appSettings element:
<appSettings
file="path">
</appSettings>
Note that path is relative to the executing assembly.
As a side note, DLLs do not even use the config file that you've defined in the project. Again, configuration information is read from the a config file with prefix the same as the executing assembly. Thus, even when MyLibrary.dll tries to yank configuration information out of a config file, it will be reading the config file for the executing assembly, not MyLibrary.dll.config.
For more on how config files work, see MSDN.
The standard way to use a config file is to have it the same as the executable, adding a reference to a dll will not include its config file and as far as I know dll's don't load config files on their own, rather they rely on the executable that reference them.
Beyond not being able to do this, I would also advise against this approach.
Rather than trying to tighly couple your settings to the DLL library, consider more of a "Dependency Injection" type approach - i.e. where you pass in the value dependencies (i.e. settings) to the code you are calling (i.e. the library).
The advantage in this is you are not tied to a single method of storing settings. You can then use a database, different config file formats... even hard-coding. It also makes unit testing easier by removing the external file dependency.
There are different ways to implement this, however one example is to pass the configuration settings into the constructor of the class(s) that uses them.