My ASP.NET MVC 2 application uses Entity Framework 4.0 for the data model. Following the instructions on http://blogs.msdn.com/b/aspnetue/archive/2010/09/17/second_2d00_post.aspx I put the .edmx in its own assembly so my solution has two projects:
MyApp.Core (ASP.NET MVC 2 Web Application Project, references MyApp.DataLayer)
Models/
Controllers/
Views/
Web.config
MyApp.DataLayer (Class Library Project)
Entities.edmx
App.Config (<-- generated by edmx when I update model from DB)
When I regenerate Entities.edmx, it creates the App.Config file under MyApp.DataLayer with connection strings to the database. The problem is that when I deploy the solution, the Web.config is the only config also deployed, so I have to manually add these connection strings to it otherwise I get an exception at runtime because they cannot be found.
I'd like to not the same connection string defined in both Web.config and App.Config. How should I organize my projects/config files such that the connection string to the db are found in only one place? Is this possible?
You can either embed the autogenerated app.config in your Model project and reference the connection string when you create your DataContext using GetEmbeddedResource...or (the more normal approach) copy the connection strings manually from the auto-generated app.config to your web.config.
If you want to be really ingenuitive, create a simple T4 template that copies the app.config connection strings in your web.config when you generate the EDMX model.
Related
I've built a .NET Core 2.1 MVC project which containing appsettings.js as config instead of web.config.
I had to add reference to a dll as a requirement of the project, that referenced dll need config values from web.config file. But the problem is .NET Core 2.1 MVC project doesn't contain a web.config file.
Please help me to find a solution. Thank you.
You just need to create web.config at the root of your project.
When the application is published, the compiler always creates a web.config, if it already exists in your project, it will get your changes and add on publish web.config
Using EF6 and Database First, I created custom T4 templates (*.tt files) in my VS2013 class library project. I don't want to migrate the app.config file with my assembly so I delete it. When I Update Model from Database, it presents me with a connection to select (I believe this is stored in the Visual Studio user preferences). If I choose not to store this in the app.config, it continues to show this step in the Wizard. Whenever the connection selection step is presented and the wizard completes, I notice the EDMX generates the two default *.tt files alongside my custom ones. Any way of preventing this? I read an article about EF code-based configuration and I tried DbConfiguration.SetDefaultConnectionFactory but that didn't help. The EF wizard always wants a connection in the app.config. Is there any way around this?
I ended up leaving it in the app.config (on my machine) and do not migrate this file to our development/test/prod environments. It's become a manual task to confirm each app.config file since it has become necessary to migrate some files due to adding project assembly redirects.
Code first migrations have been working very well for me. I have a services project and a wpf project. The model is in the services project which is referenced by the wpf project. Update-database is done on the services project, but uses connection string from the wpf project. I now add a web project which also references the service project. So now that there is a connection string in the app.config and there is one in the web.config, which one will it use?
In my scenario, the app.config in the services project is ignored. Code first migrations will use either the app.config from the WPF project or the web.config on the web project, depending which is selected as the startup project.
When doing update-database you should specify the project that contains the migrations. Make sure that you have an app.config file in that project that contains the correct connection string.
you can do a Update-Database -ConnectionStringName "MyConnectionString" and it should work like a charm.
I'm using entity framework. When an edmx file is generated, the connection string appears in the app.config file.
Is it possible to locate the configuration file in another project? Or, let the edmx file use another project's app.config's connection string?
.NET application uses configuration file of executed assembly. .NET IIS hosted application use web.config. Simply move your connection string to the correct configuration file. That is a correct solution to do that. Otherwise you will have to open another configuration file manually, get the connection string and pass it to context in your code.
I have a .NET 2008 solution with a project that acts as WCF Service host. That project has a web.config file with settings that will be replaced by the installer when the project is complete. Those setting are components that make up the connection string and a few others.
This WCF project references a Business Logic project(class library which implements service code) which in turn references a DAL project which uses the Entity Framework.
What I would like to know is how can I get the values in the web.config in the WCF project to the DAL? Without using any relative paths that I have seen with OpenMappedExeConfiguration. I need to build up the connection string in the DAL based on the setting in the web.config file.
Thanks for your answers.
I`m storing shared things like connection strings in 1 folder, which even is not under folder where source code lives. In DAL tier i just use ConfigurationManager to pick it up.
In project, which starts application (in your case, it`s WCF project), i add "ConnectionStrings.config" file from my external "config" folder AS A LINK (in visual studio, press 'add an existing item' -> choose item -> next to "Add" button is an arrow where this option lives). Then i just set it through that file properties (click on file in solution explorer -> press F4) as a content of project and that it should be copied once again if modified to deploy folder. Then i add a new app.config file to project, which includes "ConnectionString.config".
Source of connectionstrings.config:
<connectionStrings>
<add name="MyConnectionString"
connectionString="Data source=tralala"/>
</connectionStrings>
Source of app.config in WCF project:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<connectionStrings configSource="ConnectionStrings.config"></connectionStrings>
</configuration>
I'm not sure that this is the best approach. But so far so good.
Unfortunately, the answer to your question is "copy and paste". This has always been true.
The closest thing to an exception to this rule is the "new" .NET 2.0 Settings files. Because the structure and default values for these are part of the assembly defining the component, the component can, upon startup, cause the default values to be written to the applications configuration. I imagine one could couple that with a piece of code to work with installutil to cause the defaults to be written out before the containing application is ever started, leaving the defaults in the config file to be edited before the application is used for the first time.