I have a WCF Service and Client DLL which has the proxy class for my WCF Service. My client dll is going run by a different exe. I have restrictions in adding my client app.config file to the exe location. I cannot do this myExe.exe.config. I want to load the client app.config file in the client dll itself or the app.config file should be loaded from a different location.
And my exe is C++.
Is there any way to do this?
To explicitly load a particular config, you need to launch the object in a separate AppDomain. Use one of the AppDomain.CreateDomain overloads that takes an AppDomainSetup where you can pass in the path to the config file. Yout need to make sure any return values can be marshalled across AppDomain boundaries. No, there isn't an easier way to do this that I am aware of.
This is actually a standard issue with .NET. In general, when you create a separate project which will build into a dll, you can create settings in an app.config file. These settings are not automatically made part of the web.config of the application which uses the DLL.
The "solution" has always been: copy and paste from your library's app.config and paste into the app.config or web.config of the consuming application.
This actually makes a certain amount of sense: these configuration settings are meant to be changed based on the environment in which the code is executing. One set of configuration for your WCF client, stored in a single location, brings us back to the days of the registry.
Related
I am confused about how the app config file is used. I have a program that connects to a SQL server database , retrieves data from a specific table. I am using LinqToSql classes to do this. When I follow the wizard at the end the connection string gets placed in the app.config file.
I then plan to use that program as a class library so I add a reference to that exe from a different executable which is a wpf application. On that wpf application I have to place an app.config file containing the connection string in order for the program to work.
So far I understand everything. Now the part I am confused is why I do not have to copy also the settings located in the app.config file as well in order for the program to work? which settings are OK to be on the referenced executable and which ones are not. For example I know that the connection string should be on the app.config file of the wpf application. But the user settings :
app.config:
can be on the app.config of the referenced executable.
In summary why did I have to move content from the referenced executable's app.config file to the app.config file of the wpf application and I did not had to move other content from the referenced executable app.config file?
By default, the config file that is used is that of the executing process/program. Since your WPF app runs as its own executable, the config settings need to exist in its config file.
As for the other settings, your WPF app probably doesn't need them.
As a side note, it's usually a better practice to have a WPF/client app hit a service instead of going directly to the database itself. That would mean that the connection string would go in the config file of the service at that point. And the WPF app would just ask the service for the information.
I have a Windows Service that I'm creating and I'm wondering what options are available in order for me let developers configure the service.
The service is part of an over all larger open source project and hence the service is going to be installed on lots of different machines.
Normal I would use a web/app.config for this but I'm not sure if this is possible.
Hence I am looking to so how others handle this case.
you do as you expect. You use the app.config, which will be renamed to <exeName>.configwhen the project is built and then <exeName>.config will be read by the service called <exeName>.
Settings are applied in a layered way and may come from other configuration files on the machine, such as machine.config. You can read about how configuration is handled on MSDN
EDIT
In response to comment: A service will only read the config when it starts (for perf reasons). If you want to reload the config file later, you need to handle that yourself I think.
You could read the last modified date/time of the config file to determine if the file has been changed, or setup a file system watcher and then tell the configuration manager to reload that section again next time it is read, by calling ConfigurationManager.RefreshSection("appSettings") and that section will be reloaded from disk when you next access it. See the ConfigurationManager MSDN docs
You can just use a .config file with the same name as the exe that is the service.
If your service runs as MyService.exe, it's config file would be MyService.exe.config.
In Visual Studio, just add an Application Configuration file. This will add an app.config file to the project.
You can then access things like AppSettings and ConnectionStrings using the ConfigurationManager class, just like you do with ASP.Net applications.
I have a VC2010 C# Solution, with a number of projects in it.
So for example, I have a web project, and I have a class library.
In the web.config file, I have a key in the <appSettings> section, e.g.
<add key="FileDirectory" value="G:\ftproot\sales" />
I have also added a key in the Web.Production.config file to reflect the file directory on the server.
So when I reference it in my web project (It's MVC) - I do so like this:
var FTPPath = ConfigurationManager.AppSettings["FileDirectory"];
this works fine within my web project. However, I also need to reference this in the class library, which gets to my question - Is there a way to reference a key in the web.config file from another project, e.g. a class library, in the same solution??
All help is appreciated.
Thanks
Yes you can use exactly the same code. .Net will look up the configuration key in the config file of the application which started the app domain. A class library used by such an application will have access to it's config file.
class libraries do not have their own configuration. They use the configuration of which ever executable they are being used in.
This means that for you you should be able to use the same code, and it will read the setting from the config (assuming that it is there).
This is not always convenient though (for example if you write a .net based plugin for a MMC snap-in, as this means you have to modify the mmc.exe.config in the system folder.)
You might be better having a method to pass this required configuration setting into you library code. then in apps where you control the config you can just read it from there and pass it in, and in apps where you can't you can use another approach, like reading from the registry or from a manually read config file. Or have the best of both worlds and make it so you can pass it in, and if this is not done it attempts to read it from the default configuration.
This question has some more details on the pitfalls associated with dll configuration, but also has some techniques for doing it if you need to.
I have the following projects:
MVC
Console application
Class library
Windows forms application
COM Library
All these applications need to use a single configuration file. As far as I understand, app.config files are for windows, console applications and class libraries when web.config are for the web projects.
The same configuration need to be accessible in all of these projects. I have read that it's suggested to use machine configuration file, but we won't always have access to that, therefore configuration files must reside within our solution.
I don't fully understand how the configuration files get build. Currently I wrote a simple project where I have the following:
Class library to store for serving configuration files. A have attempted to do this through reflection.
Windows application that should read the app.config from a class library.
When I execute the following code I expect to get a configuration file with test values:
_applicationSettings = ConfigurationManager.OpenExeConfiguration(
System.Reflection.Assembly.GetAssembly(typeof(WCSConfiguration)).Location
).AppSettings;
What I get instead is an empty application settings file.
Class library has the following App.config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="TestTextKey" value="TestTextValue"/>
</appSettings>
</configuration>
I have tried using .GetExecutingAssembly() method which I expect to return an assembly of a code that's currently being executed. This didn't work, instead it has returned the assembly of a Windows application.
GetAssembly(type(WCSConfiguration)) has returned a right assembly, however, the configuration file was missing in the bin/debug directory.
I have a feeling that either I'm doing something fundamentally wrong or Microsoft hasn't made this flexible enough. I have also tried to search MSDN for explanation, but this hasn't been documented well IMO.
I have also left COM in bold because I'm not sure whether any config files would be available to COM library at all. Firstly I would like to get other projects to work.
I understand that this is a lot of information. Any help would be greately appreciated. Previously we have chosen to use registry, but this has turned out to be nasty, mainly because access to registry is not available in some scenarios. Additionally we now have multiple versions of the applications and switching between branches is a half an hour job :(
Thank you
Edit:
If I add the dll's config sections to app.config that means that these settings will be available only from that application. Please correct me if I'm wrong. Example that I have provided is a scaled down version. In total there are about ten windows applications, a single MVC project and range of class libraries all of which need to make a use of that configuration.
Configuration settings are mostly connection strings, lookup values that do not belong in the database and few other minor settings. Main concern at this point are the connection strings. There are few minor releases of the application where each release points to a different database.
What I'd like to get out of this is a good workable solution so that it can be posted online and other people who come across the same problem won't spend days of their time.
Morale of the story IMO:
Use both App.config and Web.config to store location of your own configuration file.
Write simple XML serializer to read/write config and DLL for serving the configuration.
COM objects are a long story and were implemented with a "hack", since neither App.config or Web.config are available in COM DLLs.
Note ConfigurationManager.OpenExeConfiguration needs to be passed the filename of the config file, not the executable.
You'll need to append .config to the path of the executable. To get the exe assembly use Assembly.GetEntryAssembly.
If you have configuration settings you want to share across multiple pieces of code that are not all in the same .NET Process, I would suggest:
Put them in their own myStuff.config.
In .NET code use ConfigurationManager.OpenExeConfiguration to open and access myStuff.config.
Non-.NET code will need to use an XML parser to load and read the settings. Unless you configuration structures are very complex this shouldn't be too hard to encapsulate.
Put the path to myStuff.config in the app.config of each application sharing this configuration for .NET applications. (Not non-.NET applications: depends on what works for that application.)
Another approach, where the configuration structure is the same but the settings are per-application would be a custom configuration section.
A couple of general points -- add the dll's config sections to the app.config file rather than relying on the dll's config file to get picked up; and app.config actually gets renamed to .exe.config on build, so you need to make sure a file of that name's available.
Also -- you're not constrained to using the default config loading mechanism to configure your application. You could create your own configuration classes and just use XML serialization to deserialize and configure at will.
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.