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.
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 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 want to ask about the main considerations we have to put in mind when publishing application using SQLServer database?
I ask this question because I faced a problem when I developed an application using SQL server Database in C# and used it in another machine. The problem is an exception happen in launching the application.
This is the exception message:
<b>"The ConnectionString proberty has not been initialized"</b>. The ConnectionString is in App.config and assing while form loading.
This is the ConnectionString:
<b>"Data Source=.\SQLEXPRESS;Initial Catalog=test;Integrated Security=True;Pooling=False"</b> and it is in this file: appName.exe.config
The application is Desktop application and it's not need for installation just click .exe and it should connect to the existing SQLServer database with the ConncetionString in the appName.exe.config file.
The best way to deploy any type of application will be creating a setup.exe or .msi file.
Since this will ensure the important files which will copy to the target machine. It also provides a well structured file hierarchy along custom action which we can program each and every steps of installation.
It is always good to keep the connection properties in a config file, which helps to change the configuration settings without building the project. The exe will reads data from the config file, so if we changed the values then also it will works fine. While creating the setup project add the configuration settings and deploy or it is also good to have a common setup msi and different config files.
For example the database may be different for servers like DEV,QA,Staging etc. For each sever the msi will be same but the connection string will be different. So there is also a way to create self extracting files which will update the config files . For QA,DEV,Staging etc different self extracting files will be there. by running those files, it is possible to update the server details and authentication details. By providing msi and extracting files, users can install the application very easily
I got a solution that includes 3 different projects, a Class Library, a Web Service and a Windows Service.
MySolution.DataAccessLayer (Class Library)
Using Entity-Framework 3.5 to access the database.
MySolution.WebService (Web Service)
MySolution.WindowsService (Windows Service)
My problem is that a have to include the Connection String in my Web Service/Windows Service configuration files to get it to work.
I have checked and I have the correct Connection String in my DataAccessLayer App.Config.
Why does it not use that?
It will not run that, because the DLL is loaded in the process space. Meaning that the services load the DLL and it is the service config that is used.
In other words - the service starts, loads the config file (that belongs to it), then loads the dataaccess DLL. As it already has its own config, it will not look further for the DLL config.
The config system looks up the app/web.config for the app that's running, regardless of where in the code you look up the configuration.
The class library doesn't care that it's a class library/seperate .dll when it's running, and will just look up configuration in the app.config for the program that's running - which will be the config for your Windows service in one case and the config for your Web service in the other.
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.