I'm trying to make a WPF desktop application that communicates with a database through EntityFramework. I've separated my solution into several projects: DTO, DAL, Service and WPFApp. I've set up my database context and repositories in the DAL project and I'm using the WPFApp as startup. Because of this, I'm getting an error when trying to add objects to my db: 'Format of the initialization string does not conform to specification starting at index 0.'
Do I have to set up my DbContext and ConnectionString in the Startup Project or is there another way to make this work?
When you add an entity framework database first model in a project there's a checkbox on the connection screen and it says something like add connection string to app.config.
All your stuff the connection depends on then appears in that particular project's own config.
These aren't the configs you're looking for.
Or at least not the config the exe will look in when your dll is loaded and runs in it's context.
Simplest fix:
Copy all the connection stuff out your project config into the main solution's config.
Related
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.
I currently have built an MVC solution which has a web project (controllers/views/scripts), services project (business layer, builds view models), and repositories project (data access layer).
I have used AutoMapper in my projects in the past and am trying to configure AutoMapper in this solution. Normally, I configure all of my maps in MapperConfig.cs which is called in Global.asax.cs.
My Problem is that the web project which is where I normally configure AutoMapper only has reference to the services project and the services project only has reference to the data project. So, when I go to configure my maps as I normally would, I am unable to define maps for the data project due to the web project not having a reference to the data project. I need a way to configure my data access layer maps without adding a reference for the data project to the web project.
The project dependency diagram would look like the following:
Web Proj --> Services Proj --> Data Proj
How can I overcome this?
There is no need to have a single mapping registration file across all projects, especially that you say that you don't have any cross-cutting types.
The simplest way would be to define a configuration file per project, and have those configurations call each other, repeating the layered dependencies of your assemblies, like below:
Global.asax.cs --> WebProjMapRegistrations.Register()-->ServicesMapRegistrations.Register()-->DataMapRegistrations.Register()
Alternatively, you could use the Assembly Scanning for auto configuration
As described by #Jimmy Bogard, when you run your web app, all assemblies of your application will eventually get loaded into your application domain - so you can get all the profiles from all the assemblies and add them to mapper config: How to Initialize AutoMapper Profiles in referenced project DLLs in ASP.Net webapp
Yet another alternative approach, that works for ASP.NET apps can be found here:
Where to place AutoMapper map registration in referenced dll
The way I've handled this in some ASP.Net MVC projects, is by using AutoMapper Profiles.
You create separate mapping Profiles that handle creating the Mappings for objects in that Project/Assembly.
You then add the profiles to the overall configuration manually, or you can use Reflection/Assembly scanning to automatically load the profiles.
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