OK I have two web projects WebProject1 & WebProject2. Both require database connectivity so this is all in a C#.NET project called Common.
Now my question is currently the connection string for both is the same and at the moment it's hard coded into the DB class (In the Common project), but I want to move it out to a config file.
I would really like to have a config file in the Common project with the connection string in which both web projects then use. Is this possible, and if so how?
There's a few ways you could do it:
put common configuration settings in machine.config as shown here
put common configuration settings in a central file and link to that in each projects's app.config as shown here
store the configuration settings in the registry
Here's a way to do this.
Seperate your DataLayer that interacts with the database by making it a class library project. The class library project will produce an assembly which you can further refer to any project you want. In this project add 'app.config' in the project-root and store your connection string into the app.config. Your data-access classes in the projects can then refer to the connection string in the app.config. When you compile and deploy your data-access project into an assembly the app.config is embeded into the assembly. Now you can add this assembly as reference to as many as projects you want to share the connection and data-access.
Related
Hope you can help with this one, although so for here does seem to b a resolution.
I have a class library which connects to a SQL Server database using an EF context class with a connection string in the app.config file.
I then reference this dll in an ASP.NET app but have to add the connection sting again in the web.config file
I would have though by referencing the dll and thus the connection string, I would not require to add the connection string again.
Perhaps I am missing something or has anyone else found a resolution to this ?
The connection string is read from the executables app.config (i.e. windows forms/WPF/console applications). For web applications the connection string is taken from the web.config file of the startup project (i.e. where the global.aspx.cs) is located.
You cannot use the app.config from your model DLL directly. You have to put the connection strings in the "main" projects.
What might help is some kind of scripting, but that's up to you.
You could try to use the configSource attribute and configure and external file:
<ConnectionString configSource="shared.config" />
The content of the file replaces the content of the element though. Another thing is that you need to include the file in your web app project and toggle copy to output.
And another warning:
the external connection strings file must be in the same directory as
the root web.config file, so you'll have to take precautions to ensure
you don't check it into your source repository.
More about that and best practices about deploying sensitive data can be found here:
http://www.asp.net/identity/overview/features-api/best-practices-for-deploying-passwords-and-other-sensitive-data-to-aspnet-and-azure#con
I have 2 projects: Console Application and Class Library (dll)
My main project, the console app, references my dll.
In my dll I created an EF (Entity Framework) ADO model.
The EF connection string must be in the dll project .config file.
The problem is when I initialize a DbContext it is looking for the connection string in the Console Application .config file.
How can I tell the DbContext to look for the connection string in the dll .config file ?
Thanks
That's how config files work. The running app always looks in {appname}.exe.config. The config file for the DLL project is just there to give you placeholders that must be copied to the running app's config file. It is not deployed along with the DLL.
You should specify your connection string in your console app. Here is a quick example why you want to do that.
Imagine if you have another app that uses your DLL in your solution. What if it wants to connect to another database instance? Now you have to change your DLL connection string? But that would break your first app.
Very often you have different instances of you app running in different environments (e.g. development, staging, production). Each instance needs to connect to a different database. How would you reconfigure DLL connection string for each instance?
If somebody else uses your DLL, how can you know what database they want to point it to?
And there are a lot more arguments to why you really want to do it. All the tools are built around it too.
I believe Visual Studio doesn't add DLL config files when it compiles sources for apps that use these DLLs.
Hosting environments (e.g. Azure) allows you to easily change your web.config files, but don't know anything about your DLL config files.
I have for example 3 Winforms projects inside the same solution.
Project1
Project2
Project3
When I build the solution, all the projects and his respectives files (.exe) are generated.
The problem is: Each project uses different connectionstring and just the solutions .config file is generated in the Bin folder.
When I deploy the solution to my customer, the project1 and project2 (for example) shows errors regarding to connectionstring problems (diferent Data Source, UserId and Password).
I've tried to put the connectionstring inside the .config file generated but it's not working too.
How can I manage these connectionstrings and works well when I deploy my programs ?
Regards
Jr
Each project needs to have its own connection string if it won't be connecting the same database/schema/or has same permissions on the DB. So you will have to change the name of the connection string for each project and place each of those connection strings in the config file of the built exe.
Then each project will be able to access its own connection string.
Add app.config to each project. You can store the connection strings specific to your project/assembly in this file. Then should be no problems.
I am using more than one projects in a solution, on e of them are real projects, others are helper projects. One of those helper projects, I have settings.settings file for storing database connection string. Now When I build/debug it. I don't see any file where I can change the connection string. Was it gone integrated in the helperproject's dll file? How can i resolve this os that i can change the connection string please?
The Settings class generated by the designer has "internal" access specifier by default.
So the application settings you've added will not be visible in the assembly that is referring the helper assembly.
To make it visible across the referring assemblies, make the class public manually or via the designer. See the snapshot.
After you've made it public, you can access it in other projects where this assembly is referred.
String connectionString = TestAssembly.Settings.Default.ConnectionString;
But it would be better to put the settings in a application configuration file specific to that application. In your case add an app.config to the main project; and add connectionStrings section in the config.
I think that you miss understood something. You should add at any project you want the app.config file (or web.config in case of web app / site).
Then via ConfigurationManager class you should access the data in it.
http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.appsettings.aspx
The app.config is automatically copied once you run/compile your project and it will have a name as youreapp.exe.config or yourelib.dll.config.
For more details read here http://www.codeproject.com/KB/files/SaveConnStringInAppConfig.aspx
Hope this helps
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.