I have a MVC project that uses foo.dll, but that foo.dll uses smu.dll so basically I never reference smu.dll within my MVC project. The problem I´m faced with is that within my MVC project I want to be able to store ssettings in web.config so that smu.dll will read.
We have tried to use both applicationsettings and appsettings without effect, when I refernce smu.dll directly from MVC or any other program it picks up the settings without a problem. Do settings for smu.dll have to go into foo.dll app.config?
EDIT
Hello again friends, and thank you for your answers.
I found out what I was doing wrong after I read the comments. In MVC there is a web.config within the Views-folder and one web.config in the root of the project. When I used sectionGroup and applicationSettings in the "Views"-web.config the config was not read by the smu.dll. I then changed the smu.dll to read appsettings instead, whereas I then put the appSettings into to "root"-web.config, then the config file was read by the dll. I hope this makes sense but I am new to this and am still learning.
Anyway, this is finally working now :)
So, you have an MVC project, and two class libraries (foo & smu) ?
MVC -> Foo (via project reference)
Foo -> Smu (via project reference)
within AppSettings of web.config, you have a setting that smu should pick up?
Shouldn't Smu just accept a param, but not care where it comes from e.g.
if Smu was a data-access class, and it needed a connection string - all it needs to allow the user to do is send it a connection string? so, you could then send that from Foo (as this class can access your config settings) ?
Related
Apologies if this has been asked before; after two days of searching I can only find partial answers that don't fully relate to my situation, and are difficult to follow with my lack of experience.
I have a solution that contains four projects:
Class library (containing database connection strings, email server settings, plus lots of other settings)
Web application (web forms)
Web application (MVC)
Web API
Projects 2,3 & 4 all reference the class library, and use the database connection strings, etc, to function. These projects also contain their own additional settings in web.config, bespoke to that project.
Everything works great so far... However, I now need to publish client-specific versions of my solution, e.g. the solution for ClientABC requires different settings for each project than for ClientXYZ. All other aspects remain the same, it is simply the config settings across the four projects that need to change.
From my research, I hit upon something called SlowCheetah which transforms the config files based on the publish profile. That sounded promising, but then I get this problem, where the class library settings aren't pushed into the other projects. I can see bits of useful info in this question, but don't have the experience to apply it to my problem. I'd rather not duplicate the settings into respective project's config file if possible, as that feels messy.
Can anyone please offer me some help as to what's best here? I don't even know if I'm taking the right approach, but am pretty sure I can't be the first ask this?
but then I get this problem, where the class library settings aren't pushed into the other projects
you have to keep in mind that the configuration file is readed by the SturtUp application, your client. Class Library can't run directly, but inside a WebApp or WinApp or ConsoleApp
So, any settings that you put in your ClassLibrary configuration file must be copied in the configuration file of your WebApp.
Generally, I copy some settings from app.config to web.config but, if you search on internet, you can find a method to automate this operation.
I now need to publish client-specific versions of my solution
You can create many configuration profile and use a web.config transformation:
From ToolBar or Build Menu, select Configurazion Manager...
Create all configuration you need for clients
Now you can see different web.configuration files
Now you can specify different configurazion transformation for your ClientABC, ClientXYZ and publish them with specific configuration
EDIT:
So, you can adopt this solution for your Class Library too, or external config file, and include external file in your web.config: External Config
I have two projects in my solution: an ASP.NET MVC web app project with a web.config per environment (production/UAT/dev) and another DAL class library project referenced by the web project that uses EntityFramework Database First to handle persistence. At the moment, the DAL class library project has its own App.Config that specifies the connection string to be used.
I require different connection strings (or rather, different data source) for the different environments.
How would I go about moving the connection strings to the web.config in the the web project and referencing them from the DAL project at runtime?
The auto-generated EF Model.Context.cs code that currently references the connection string name is [name changed for anonymity]:
public EodActivityEntities()
: base("name=DatabaseNameEntities")
{
}
Your application will only ever read a single app.config or web.config at run time which will be the one from your start-up project.
Therefore if you have the following in your DAL:
public EodActivityEntities()
: base("name=DatabaseNameEntities")
{
}
... and you run your web application as your start-up project, it will pick up the connection string with name DatabaseNameEntities from that project's web.config, ignoring what is in your DAL app.config. So it's already doing that for you. Therefore I would say that you shouldn't need to have your connection string in your DAL's app.config file at all.
Now, for the different environments you want different connection strings. Create new Solution Configurations for your environments DEV, UAT & LIVE and you can use web.config transformations (info here and here) and it will build with the correct connections strings.
I would recommend passing the connection string in the constructor of your context. The base constructor created by EF takes a string and can either be a named value from a configuration file or simply the connection string itself.
Then move your connection strings per environment to the MVC project where you can instantiate the context using values in it's web.config
var connectionString = WebConfigurationManager.AppSettings["connection"];
var context = new EodActivityEntities(connectionString);
Coulton is correct in that only one configuration file will be loaded, and a solution could be to name the connection strings the same so that the web.config will load when you run the application. However, this is spreading your configuration around rather than pushing that to the context root of the application.
When you reference your DAL project from your Web project, the built DAL.dll should automatically be copied into the /bin folder of your Web project at the time the Web project is built. First, check that is indeed happening. If not, look at the Web project References, find your DAL project in the list and view the properties. CopyLocal should be set to True.
When your Web project is running, any reference made by your DAL to settings that would have come from your DAL's app.config, will instead come from your Web app's web.config, as the DAL will be running under the context of the Web application.
So you are right, that you need to add settings to your web.config.
The best way to utilise different values for different environments is to use web.config transforms. In a Web application, you may already have a couple of these as child solution files sat under your web.config (web.debug.config & web.release.config). Visual Studio will apply these transformations when publishing. We typically have a publish profile for each environment and a matching transform file for each environment, but only one actual web.config file with all the default (untransformed) settings in.
You didn't mention which version of Visual Studio you are using, but this article may help you along the way:
http://www.asp.net/mvc/overview/deployment/visual-studio-web-deployment/web-config-transformations
This explains further: http://go.microsoft.com/fwlink/?LinkId=125889
I work on a team that works on a project. I change my project web config file to set a specific connection string but when I check-in or get latest version of project it changes to others connection strings. I have same problem in WCF Service references. appconfig and xsd files of service references always corrupted when I check-in or get latest version of program from tfs and I have to delete service references and add it again! How can I get rid of this?
We had the same issue on our project (with connection strings), and found a good solution: http://msdn.microsoft.com/en-us/library/ms254494(v=vs.110).aspx
By adding a connections.config file for each developer with his own connection string, we just needed to say that this file must not be a part of Source Control. Then in the web.config connectionString section, you just refer to the connections.config file.
Just be aware that you need to either transform your web.config or add the connections.config when publishing the site.
I know you can do the same about the appSettings section in the web.config.
How you do it with WCF, I don't know - but it sounds strange to me that your are not using the same WCF refence.
There are many solutions.
The team uses the same configuration (e.g. everyone uses localhost references)
You separate user from application settings (do not apply to all kind of settings nor projects)
Use transforms and solution configuration to map have per-environment setting
Use configSource to move config section in separate files that are not under version control
I do not think there is a perfect solution, but maybe you apply a mix of these. I strongly suggest to apply them in the stated order.
I know similar flavors of this question has been asked before, but I am asking something a little different. I know how to use applicationSettings and such, but what I am trying to do is to make it into a config. i.e., I have a web application which as a reference to a class library. This class library has a reference to a web service. In doing that, it created a .settings file. When I am using this class library in the web application, everything works fine locally. However, in staging and production, I would like to have different URLs for the web service - the only way to do that seems to take the applicationSettings section, and put it in the web.config of the web application project. I'm trying to avoid muddying up the web.config, so is there a way to have this applicationSettings section in another files referenced by the web.config?
<appsSettings configSource="appSettings.config" />
This moves the whole app settings section to a separate file.
I have an app MainApp that references another project MyDLL.dll. Inside the MyDLL project I have made some user settings in a Settings.settings file that may be changed at runtime. So it appears that these settings get saved in the app.config file of MyDLL. But the problem is, the main project is MainApp, and MyDLL.dll.config does not, so far as I can see, get copied to the MainApp output folder. This is reflected in the fact that even though I save the settings in the code of MyDLL, the next time I run MainApp the settings have gone back to the default.
I must be missing something really obvious here. There has to be a way for related assemblies to preserve their settings values. But how?
While you can add an app.config to a library project, it has no effect to do so. Configuration is linked to the application, not the library.
You need to create the settings and configuration in your application itself. You can do something like including the library's app.config if you really wanted to, but that would probably not do what you want, either. It's best to just handle your configuration in the application.
Why is this so? Because what's to say it's valid to have user settings for your library in the first place? A library should not be tied to any particular kind of application. What if you used it in a Windows Service or an ASP.NET application?