Develop Reference

How to use Code First Migrations When Domain Models in Separate Project from WebUI?

I have a VS 2017 solution with 2 .Net Core 1.1 projects, 1 is just a class library containing all of my domain models and the other is the actual MVC web application containing the contexts (the ApplicationDbContext & one I created) & all of the EFCore assemblies. I'm trying to enable & use migration on the context I created but having trouble being that the context is in the WebUI project and the models are in the class project. Upon 1st execution of Add-Migration command, I got this error about my target project didn't match my migrations assembly, so I figured out how to get around that by changing the migration assembly in Startup.cs. Add-Migration ended up working but the migration file was created in the class project where the EFCore assemblies are not referenced, thus giving an error on the migration file. I thought maybe I'd try and trick it by moving the file to my WebUI project to update the database, but then figured that may not work & there has to be an easier way of doing this. Does anyone know how to setup code first migrations for EFCore to keep track of modifications and update the database when my domain models are in another project? Any help would be greatly appreciated. Hopefully this isn't too vague. If more info is needed, I'll be all too happy to post. Thanks.

I may not be understanding the question correctly, but have you tried referencing your domain project in your webUI?

Scaffolding in .Net Core with Multiple Projects in Solution

I have created an .Net Core MVC6 application targeting net461. I have used a project structure I am very familiar with in which I place the data, model, and service classes in separate class library projects and the Web project references these.
When I attempt to scaffold a controller I receive an error that multiple matching types exist for the model I am scaffolding.
If I move all code to a single project, scaffolding is successful. If I move the context to Web project and leave the model in a separate project, I receive an error the NO matching types were found.
Has anyone else seen this same issue? Is there a workaround to still use this type of architecture?
Update
I started another project and always get this issue. I get this error when only using 1 extra project for the models. Attached is the error I recieve.
Scaffolding Error
Update 2
When the context and model are in the same project I receive this error.
Error editing dbContext

Cannot post a comment, so I've to write an answer instead. I also had the same issue and opened it on Scaffolding github repository. Here's the response:
currently there is an issue with scaffolding, that it doesn't support
model classes outside of the current project properly.
As a workaround, you can add the model temporarily to your web project
and then move it to the BLL/ DAL projects after scaffolding.
Plus they also opened this issue as a bug, quoting:
Scaffolding fails if model class is in a dependency (project/ library)
of the project on which scaffolding is being run. #251
Project A has a dependeny on Project B. Project B has model class If
you try to run scaffolding on Project A by using model class from
Project B, it fails with the below error: No model type returned for
type:
Hence, as of RC2, this is a bug in scaffolding tooling.

Entity Framework Change Assembly Model not recognised

I have an MVC 5 website with using the entity framework V6.1.1. The entity framework DbContext classes and models were originally all inside the website project. This project had 3 DbContext classes and 3 databases. I had also enabled migrations and applied one one of these databases.
I have now moved all the entity framework classes including the models and the migrations to a separate project and since then I have been getting the following error for the databases where a migration has been applied:
The model backing the 'MyContext' context has changed since the
database was created.
The database has not changed. I have also made sure the Context Key is the same in both the Configuration constructor and the database __MigrationHistory table.
I have also been seeing the following behavior:
I do a Get-Migrations in the package manager console and the correct migrations are returned. Then I am able to build and run the site and no error message is shown until I next make a change and build the solution.
If I change the Context Key in either the database of the Configuration constructor there is no error, but I assume that the migrations are not all being picked up.
I have also been looking through all the migrations files including the designer files and the namespaces all match up. If anyone could shed some light on this problem it would be much appreciated.

You should put this in the constructor of 'MyContext'
> Database.SetInitializer<YourDbContext>(null);

Cannot enable migrations for Entity Framework in class library

I just got on board with EF 5 and am using their code-first migrations tool but I seem to get an error when I try to enable migrations.
I type Enable-Migrations into the package manager console and then it says
No classes deriving from DbContext found in the current project.
Edit the generated Configuration class to specify the context to enable migrations for.
Code First Migrations enabled for project MyApp.MvcUI.
It then creates a Migrations folder and a Configuration class in my MvcUI project. Thing is, my DbContext lives in a class library project called MyApp.Domain. It should be doing all that in that project and should have no problem finding my DbContext.

Oh wow, nevermind. I'm dumb.
In the Nuget package manager console there is a dropdown menu at the top labeled "Default Project:". Make sure you set that to the project you want to run the command against.
Hopefully this helps someone else avoid my embarrassing mistake.

There are actually 3 ways to make Nuget commands run in a specific project:
[Package Manager Console] Set the active project in the dropdown at the top of the console toolwindow
[Package Manager Console] Look for a parameter to specify the project. For some cmdlets I've seen -ProjectName and some use -Project
[Solution Explorer] Right-click the project you want, and use the graphical package manager window (Manage NuGet Packages...).

Entity Framework 4.3 doesn't create database

I created new project and added the newest entity framework to it (version 4.3). I created classes and the context as in previous EF versions. However, during the very first run when the database should be created (in my case it is SQL Server 2005), I'm receiving the following error:
An error occurred while executing the command definition. See the inner exception for details.
With the following inner exception:
Invalid object name 'dbo.__MigrationHistory'.
As I understand, this table is for migrations, but this table does not exist if there is no database. Am I doing something wrong?
More info:
For testing purposes I created only one class:
public class Test
{
[Key]
public int TestId { get; set;}
public string Name {get; set;}
}
public class Context : DbContext
{
public Context() : base("MyConnection")
{
}
public DbSet<Test> Tests { get; set;}
}
UPDATE 1
After some tests I realized that application is throwing unhandled exception from visual studio and break in visual studio. The exception was System.Data.EntityCommandExecutionException. Once I ignored that expection and didn't stop code execution, database was created.
UPDATE 2
After another few hours working with database I found out that playing with Enable-Migrations option and Update-Database from console also is solving that issue. It is creating database before application start and don't break in Visual Studio.

Could you try removing your constructor to make EF use it's default connection string.
public Context() : base("MyConnection")
{
}
Failing that, could you try updating your database from the Package Manager Console to see if you get any further information.
Update-Database -Verbose
Possibly unrelated in your case, but I get the same error when using MvcMiniProfiler 1.9. If you are using it too, make sure EF profiling is turned off by commenting out the line:
//MiniProfilerEF.Initialize();
Within the MiniProfiler App_Start.
For others experiencing a similar issue, I have found that reenabling migrations from the Package Manager Console can help in certain cases. Make sure you have a copy of your Migration configuration before doing this.
Enable-Migrations -Force

...and just to add one more possible answer for all those facing similar problem
(note: this is an open-ended story seems, as there're obviously some bugs still with the migration part)...
This link came closest to what I needed
Error when running Update-Database with EF 4.3
so, you need to do 3 things (in that order - and I'm referring to an existing project):
(all is in PM console)
Make sure that 'default project' in PM Console is set to your desired project (i.e. for larger solutions) - that doesn't necessarily match your startup project! (and closely watch the comments/response in PM as to whether the actions were made on the project you want)
(1) Enable-Migrations -force
(2) Add-Migration Initial
(3) Update-Database -Verbose
...if you still get an exception in PM console
(4) then you might need to 'move' your project into the root
it sounds silly I know, but that was the main problem on my side - I had a bunch of solution folders and any of the above would fail on projects within solution folders. However, once I moved the project to the root, everything worked fine (no more exceptions, with or w/o first-chance exceptions for CLR turned on or off)...
hope this helps somebody
EDIT: if your data model project (EF CF) is a library - then set that project as a 'default project' in PM console - and run all those things above on that project directly (and have migration configuration etc. created in the lib itself). Otherwise it'd fail (and the same no MigrationHistory exception also appears when your model is a lib - and no migration defined for it, within it - and you have migration defined on the 'main project').
EDIT: you'd need to move both the lib (EF model) and the 'startup' project (calling it) into the root.