I have an older asp.net solution consisting of several projects. The data access layer is contained in a separate class library project while the frontend is in another project.
The data access project is using Application Settings (https://msdn.microsoft.com/en-us/library/a65txexh.aspx) for several settings, among others 3 connection strings. I have a /Properties/Settings.settings file which - when changed - results in an updated /app.config file.
My problem is that I haven't found any way to automatically change these settings when building and publishing the solution.
I know about web.config transformations (https://msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx) and that Visual Studio offers the ability to create a so called "Config Transform". But as far as I know a class library doesn't have a web.config file and this menu option is not available for neither the Settings.settings file nor the app.config file.
Is there a way to automatically change the settings.settings file/app.config or is there a completely different best practise to provide connections strings to a class library?
EDIT: I should add to the above that the Data Access class library is using Datasets.
Related
I have developed a lot of class library projects in VS 2012 to be used in Windows Forms and Web forms applications.
The question is simple. Do I need to deploy the DLL file itself together with the XML file that is created?
For example, the class library project is called DataWare. Upon building, I got 5 files in Release folder (this project reference Entity Framework):
DataWare.dll
DataWare.pdb
DataWare.dll.config
EntityFramework.dll
EntityFramework.xml
I know that ".pdb" file contains debugging information, so there is no need to deploy. The ".config" file is not taken into account. Instead the App.config or Web.config are.
Regarding this, I think I have to deploy just DataWare.dll and EntityFramework.dll.
However, the main doubt is if I need to deploy EntityFramework.xml as well.
Regards
Jaime
The XML file contains the doc comments for the public types & members in the assembly.
You only need it if you want Visual Studio to show documentation in IntelliSense.
If you're deploying a consumer-facing app (as opposed to a developer-facing reusable library), you do not need it.
No, in most cases you do not need it. If there is an external DLL that needs to be copied local and referenced using the config, then you might need to, but that is somewhat rare.
I have a Class Library project containing some basic logic.
The DLL created by this project will be used in a few other projects.
I have a app.config file in the Class Library project with a couple of values the DLL uses.
When each consumer project will use the DLL, it has to change the values in the app.config
For example, if my DLL's app.config contains 3 settings: A, B, C, then:
The first consumer of the DLL will have A="a", B="aa", C="aaa" .
The second consumer of the DLL will have A="t", B="tt", C="ttt" .
and so on...
From design point of view, what is the most clean way to achieve this scenario?
(It seems to me that the app.config should reside at the project that uses the DLL)
Thanks for your attention! :)
EDIT:
Most of my code in the DLL is consuming ASMX web service which includes it's .config . Each application that will use the DLL, has it's own WS address (the contract is identical). How can I inject the address of the service from the application into the DLL?
EDIT #2:
Now I have 2 config files:
1. In the class library project - contains the WCF client config.
2. In the application that uses the DLL - contains the config with the values for the DLL.
How can I inject values from the application's config into the DLL's config (for example the address of the endpoint) ?
Only applications have a .config file, so having a .config file in your class library is useless.
That means that the values should come from somewhere else
The options I can think of are:
Use the .config file of the application - disadvantage: The person that write the application need to know about your config values and add them. Most of the time he/she will find out about these setting when they will get exceptions for missing values.
Save values to a DB (or some other web service) if all your applications use the same DB this can be a good idea. Works nicely when you have a very limited number of applications. I use this for different values for production/test environments
Make every class that needs these values to get them in a contractor. advantage: no hints needed, the application programer will be aware to data. This is a clean interface. I would use this option if it's a customer specific project. disadvantage: lots of work for the applications programer
I'm using EntityFramework 4 in my WPF desktop-application (NS: MyCompany.MyProduct).
Now I want to create the same application in ASP.NET (NS: MyCompany.MyProduct2), with the exact same functionality... Hence I need to use the exact same database as the WPF application already does.
Additionally, I want to create a new executable (hence a new wpf project) on top of my primary WPF project, that also uses the same ConnectionString like the WPF / ASP.NET-Application, to display some reports.
So I figured out I'd need to share the .edmx-Model (NS: MyCompany.MyProduct.Models.DBModel.edmx) and the ConnectionString that is already persistent in the app.config of the WPF app or the web.config of the ASP.NET-App.
What is the best or recommended way to do this?
What is the best or recommended way to do this?
Create a class library project and put EF model in there and share it between your WPF/Web projects. The app.config file of a library project isn't picked up by the parent project therefore you will have to manually update your web.config file to add the ConnectionString section.
This approach allows you to share business logic between your WPF app & your web app. If they are essentially the same app but on different platforms, then you should only be re-implementing the UI - this is one of the major advantages of the MVC pattern.
Agree with #James here. Don't be afraid of adding library projects to your solution. So you would have a project called MyCompany.Model that contains your EDMX. (Actually, you might find later that you want to use the T4 generation to split your model off from your DbContext or ObjectContext, but that's another discussion.)
With Visual Studio you can actually add a project--your EDMX project--to more than one solution. Be careful not to make changes to the EDMX project when editing one solution that break the other, though.
Respectfully, you may find that it's not ideal to use the GAC here, especially if your EDMX is still evolving.
As for connection strings, these are one thing that you tend not to share between projects. Typically they are in the app.config (or web.config) for your executable project. This can be a gotcha, because if you use a library project to hold your EDMX, EF will automatically create an app.config in the library project, with the connection string in it. But .NET never uses an app.config for a DLL. The only reason it's there is to give you something you can copy/paste into the real app.config for your executable (WPF) app.config or the web.config.
If your goal is to share the single .edmx dll between all three applications on one machine, the best way to accomplish this is to sign the dll, then add it to the GAC. If the dll will remain on different servers, there is no need to GAC the dll, you can just reference it in your projects, and add the connectionstring entry in the respective .configs.
GAC: http://msdn.microsoft.com/en-us/library/yf1d93sz(v=vs.100).aspx
Install a DLL to the GAC: http://msdn.microsoft.com/en-us/library/dkkx7f79.aspx
I have a website built in asp.net mvc 3 which uses the repository pattern and EF.
I have added another project to my solution and would like to access the repositories from within this project for the database work.
I have added a reference to my web project from my new project but when I try and instance a repository I get the error:
The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.
I'm guessing that EF doesnt like to be called outside of the project that it is configured for.
Am I doing this wrong?
Thanks
.NET will use the Web.Config or App.Config from the startup project for configuration. You need to copy the connection strings (and any other necessary settings) into your new project for your database connections to work.
It is also a best practice to move the Repositories and .edmx file into a separate project so your new application does not depend on the entire Web project being correct before it works. You can create a new Class Library project in your solution, drag the Model folder in there, and then add a reference to this project in both your mvc 3 site and your new application.
I got two project in my solution in Visual Studio 2010.
Project 1 contains an app.config with a ConnectionString.
How can I access that ConnectionString from Project 2?
Since they are both using the same ConnectionString, I would prefer to only have one instance in my solution.
You can add the files as a link to the file to one of your projects.
Use Add an Existing Item to the project you want to add the file to - the Open button has a small down arrow, if you click that you can select Add as Link.
This will add the file as a link from the original location, meaning you only have one physical file.
Another idea is to use an IoC container, like Ninject, injecting the connection-string into the constructor of the class you need it in. This is not unlike the factory pattern.
Note: you don't need to be using Entity Framework to use Ninject.
See this post:
Ninject - binding constructors with arguments / Entity Framework connection string
Beside of the file linking suggested in the answer by Oded, you may consider refactoring your application to use a commom data access assembly that contains a DatabaseConnectionFactory class or the like. This assembly would contain the connection string in its settings
If there is only specific section you'd like to share (connectionStrings in your case) then linking wouldn't work for you. Instead you could do something like this:
The solution is to store the connection strings on the web.config of the parent web app.
Note that the web site root is also an app, so you can store a web.config in there (i.e. c:\inetpub\wwwroot\web.config) which will be inherited by all apps under it.
c:\inetpub\wwwroot\web.config -> common configuration.
c:\inetpub\wwwroot\app1\web.config -> configuration for app1
c:\inetpub\wwwroot\app2\web.config -> configuration for app2.
In the case the default web site root is off limits, you can create a root app to contain all other apps and store the common configuration there.
c:\inetpub\wwwroot\myrootapp\web.config-> common configuration. c:\inetpub\wwwroot\myrootapp\app1\web.config -> configuration for app1 c:\inetpub\wwwroot\myrootapp\app2\web.config -> configuration for app2.
If your Project 2 has a reference of Project 1 then Project1 may have a class with a ConnectionString property exposed.
By the way, the "class" may read the connection string from the app.config