I am using entity framework core Ver. 2.2.4, and I am maintaining a separate assembly for maintaining ef generated migrations. During the application startup, when I try to perform context.Database.Migrate(), I am getting the following message in the output log
No migrations were found in assembly 'MyProject.Core'.
I have included optionsBuilder.UseSqlite(GetConnectionString(), builder => builder.MigrationsAssembly("MyProject.Core")); to load the appropriate assembly to find the migrations, but no luck. Any Idea what's going on?
After looking into the EF Core source code, I figured out what the issue was. The problem was with my application db context class i.e. AppDbContext:DbContext. I had this class in my core project marked as abstract and later I was deriving from the class in the android project to define connection string. Looks like EF Core will ignore all the migrations marked with [DbContext(typeof(AppDbContext))] attribute containing abstract db context types. Once I made my db context class concrete, my migrations started working.
Reference your migrations assembly from your project.
If you can't because it causes a circular dependency, set the output path of your migrations assembly to your main project's directory: (or otherwise copy it there)
<PropertyGroup>
<BaseOutputPath>..\MyStartupProject\bin\</BaseOutputPath>
</PropertyGroup>
Related
I am trying with the help of Entity Framework to set up this without having to deal with the code-related part of SQL.
I created a model and added a migration via package manager console and it all worked well it updated and created the table.
The thing I want to ask is how does the entity know which migration I want to add.
I used:
add-migration (and put here the name of the migration file)
But the thing I don't understand is how does it know which model I want for my table?
Or put it in other words if I would have 2 models before I did any migrations which model would get chosen?
Would really appreciate it if someone could help me out.
Thanks in advance
Seems you are using entity framework migrations and got confused how it works. Here is the explanations:
Question: But the thing I don't understand how does it know which model I want for my table?
If you look into your project folder there is the directory
Migrations. Inside it all the migrations history logs written
into.When we made any changes on data model, EF Core compares the current model against a snapshot of the old model to determine the
differences, and generates migration source files; the files can be
tracked in your project's source control like any other source file.
Once a new migration has been generated, it can be applied to a database in various ways. EF Core records all applied migrations in a
special history table, allowing it to know which migrations have been
applied and which haven't
Question: If I would have 2 models before I did any migrations which model would get chosen?
As said earlier, as it keep track previous migrations history, so in your old model it compares the differences and overrite latest
changes that were not written on older files. This is how it works.
Hope above explanations guided you accordingly and redeem your confusions. You can also have a look on official documents here
Let's say that I have a simple WPF or Winforms solution. To that solution I add a new project (based on a class library template , which I then reference in the main project) which is intended to be a data layer containing an entity framework data model. When I create the data model in the new project the connection string that it uses gets added to the app.config file of the main project in the solution.
Now let us say that I want to add two more projects to the solution (both of which will again be based on class libraries) to contain details of WCF services that I wish to use. In each case I add the WCF service by using the ADD Service Reference option from the right click context menu of the projects.
Unlike the data model project though the bindings for the service model get added to the local projects app.config file ass opposed to the app.config file of the main start-up project.
Should I simply copy those bindings to the start-up project's app.config file, or should I copy and then delete, or in fact should I be doing something completely different. Thus far trying combination of the first two suggestions I get error messages connected with endpoint configuration, however my knowledge of WCF is not really sufficiently good to fully understand the MSDN articles that the error list points me to.
Note that if the service references are added to the main project I get no errors whatsoever, so I figure this must be a configuration problem of some description.
Would anyone be able to provide the correct procedure for adding projects that essentially contain no more than a WCF service reference to an existing visual studio solution.
Edit
The screenshot below shows my main app.cofig file after having copied over the bindings configurations from the two service contracts. I'm not sure whether I should have commented out the bit that I did or not, I had thought that by doing so I might get rid of the blue squiggly underlines telling me the following (which I must admit to not understanding):
Warning The 'contract' attribute is invalid - The value 'ErsLiveService.IERSAPIService' is invalid according to its datatype 'clientContractType' - The Enumeration constraint failed.
You're likely getting the blue squigglies because the namespace ErsTestService is defined within the project in which you created the service reference. If the root namespace of that project is MyServiceReferenceProject then try changing the namespace to MyServiceReferenceProject.ErsTestService.IERSAPIService.
I have a highly standardized project in DDD (Domain-Driven Design), so it means that each layer has it's responsibilities and no layer knows other than itself and the Domain Layer.
Here's the structure of my project:
My Infra.Data layer is responsible for connecting with the Database, and i'm persisting using EntityFramework.
My problem is: in order to make it work with SQLServer Databases, i need to add a reference to EntityFramework.SqlServer in my WebApplication layer, which breaks my separation of concerns concept, as you can see below.
Even having the same reference in my Infra.Data layer, which is where it only should be, as you can see below.
If i remove the EntityFramework.SqlServer reference from the WebApplication layer, it stops working, and throws exception every time i try to persist data, as you can see below.
I need to know how to remove this reference to keep separation of concerns, because the way it is now, i'll have to change my WebApplication if i want to change my persistence. My Web layer is prohibited to even have anything with the word "EntityFramework" in it. I want FULL separation of concerns to change any layer without affecting no other.
If i register my <entityFramework> provider in my Web.config file, it will only works if i have the EntityFramework.SqlServer in the project, but without the EntityFramework.SqlServer reference on the WebApplication, it miss namespaces and complain about it.
Note: My project also connects to MySql Databases successfully, and i don't need no references to MySql.Data or any other MySql library in my WebApplication layer, as expected.
Please help me, my DDD/Separation of Concerns OCD is cracking on it, thanks.
You can!
Just create this class in your Infra.Data project:
internal static class ForceEFToCopyDllToOutput
{
private static SqlProviderServices instance = SqlProviderServices.Instance;
}
When you do this you let the compiler know that the specific resource is used and should be available in the bin folder.
Some consider this a hack but it's useful if you want to keep your layers free from infrastructure concerns.
You can read more about this here: DLL reference not copying into project bin
EDIT:
All you'll need now is to copy the connection string from your Infra.Data app.config to your WebApplication web.config
<connectionStrings>
<add name="DatabaseConnectionString" providerName="System.Data.SqlClient" connectionString="..." />
</connectionStrings>
You would not be able to get rid of Entity-framework configuration and the required DLL in your Web-application :
Lets say your infrastructure layer and domain layer need to depend on Entity-framework. This means these two libraries need to have physical access to Entity Framework DLLs(Have Entity-framework package installed) and configured.
When you run your web application which has dependency on infrastructure and domain libraries, all Dlls used by underlying libraries (infrastructure and domain) need to be present physically and configured otherwise you will have run time issue(program might be compile-able but you will get run-time errors).
Morale of the story : If application x [Irrespective of the layer it belongs to] has dependency to library y,z and library y,z rely on some dll and require configuration, for application x to work at run-time you need to have all dlls needed by y,z available and provide their configuration (web.config) in your instance.
You can obviously provide some workarounds such as copying the files directly and providing separate config files for each layer but I strongly advise against it because it would get extremely messy and very hard to maintain in the long run.
I have created a sample WPF project, worked fine.
I added a MVVMLight project, made it a default startup project, and ran fine.
Now I added a class library project, and added an ADO.NET data model with "Code First From Database", and selected relevant tables, that gave me a good collection of entity classes.
I thought this way, I can keep my data model seperate from presentation and businesss logic layers, plus add additional target plateforms if needed and take the advantage of SoC.
So far so good.
Now I want to enable Migrations on my data layer only. I fired up Nuget console, selected dataLayer project in the "Default Project" drop down. Issued Enable-Migrations command and very first error I got was
"No connection string named 'dpFinDataModel' could be found in the application config file."
Now I modified Startup project - i.e. Mvvm project's App.Config to add App.Config details from DataLayer project.
Tried to rerun "Enable-Migrations", and following error occured:
PM> Enable-Migrations
The project 'dpFinMvvm' failed to build.
Am I doing something wrong here?
Will this approach work?
Thanks for all your help.
-DP
1) PM> Enable-Migrations would get an error if your project itself contains errors.
Try going through your code such as in debug mode and check if you have any build errors then try.
2) And for your config file error you may have not referenced it properly, try this tutorial to solve your issue.
http://www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/creating-a-more-complex-data-model-for-an-asp-net-mvc-application
When working in Ruby (specifically, in Rails), I can automatically run my tests using a testing database, and also choose easily between a development or production database. Still new to Entity Framework (WPF), but it seems less than simple.
My Entity assembly has an App.Config file that holds a reference to the database, and I need to copy this App.Config file to all runnable projects (e.g. questions 1113361 and 2233897).
If I use Test->Database Test Configuration without explicitly copying App.Config from my EF project, I get
System.ArgumentException: The
specified named connection is either
not found in the configuration, not
intended to be used with the
EntityClient provider, or not valid.
which is the same as if I have a missing or different App.Config file.
Strangely even if I do change all the connection stings in my Entity project and testing project to the same database, I still get that error.
Is there a step I'm missing when telling Visual Studio (2010 Ultimate) that I want my tests to run using a different testing database, or is this just not supported with EF 4?
Also, Is there some way to change database context other than copying App.Config files back and forth? Seems like a serious way to ignore separation of concerns if not, so I think I'm missing something.
Strangely, as I was playing around after doing this, it started working. Somebody might comment on this, but it looks like I was using Test->Database Test Configuration at the wrong time.
To wit:
Clean project, no App.Config, use Test->Database Test Configuration to set the test database. It generates an app.config (lowercase, notably). You get an error. Even if you check all the connection strings (weird)
Clean project, first copy the App.Config from from you Entity project. Now when you use Test->Database Test Configuration, it will populate the App.Config that you copied, and it works.
I imagine it was some issue I was creating when copying the connection strings.
I've also confirmed that this works with my Entity project using a "Main" database while my testing project uses a "Test" database.
Wonder if someone can confirm/clarify this?