I am using MVC5 and EF6 CodeFirst migrations. My model is in a separate project from my MVC web app and I keep getting this error when trying to access the model classes. I have automatic migrations already enabled. I can drop the entire database and then using update-database to regenerate everything I still get this error. The error is wrong because the context has not changed since I created the database. Also, through a Unit Test project, using the same calling code as I have in my MVC app, I can reference the same Model project, access the model classes and data. I have the Model separate from the MVC project because I need to be able to reuse the Model outside of the web.
The model backing the "xx" context has changed since the database was created. Consider using Code First Migrations to update the database
Database.SetInitializer<DbContext>(null);
http://patrickdesjardins.com/blog/the-model-backing-the-context-has-changed-since-the-database-was-created-ef4-3
I got a similar problem :
The model backing the 'ApplicationDbContext' context has changed since
the database was created. Consider using Code First Migrations to
update the database
I have one project for MVC and another project for the model, context and repositories. I've been working on it for weeks but today it said stop.
I have tried to delete database, enable-migration, add-migration and update-database so many times that I've lost count. I've added initializers to MigrateDatabaseToLatestVersion as well as DropCreateDatabaseIfModelChanges.
What finally made it work was to move model, context and repositories into the MVC project (not something I was keen on)...then it worked right out of the box without any code changes at all (besides namespaces)! Very strange...
I've read so many blog posts during the day trying to solve this problem. One of them (I don't know which one) mentioned a bug in Visual Studio 2013 where reference to DLL files weren't always updated as they should, suggesting that my MVC project missed out something when I was running add-migration and update-database in my separate project. But it's just a guess.
I'm using EF 6.1 and .Net 4.5.1 in my solution.
Just to elaborate on RouR's answer:
I had an MVC web project that had a model attached.
I then created a console app that consumes this model.
My console app, only is aware of the connection string and has EF reference, just doesn't know how to let each one communicate.
Hence, the model backing database changed error appears
The engine is just confused how to proceed it sees and expects an entity, as was reference, just losses it when it fails to find the proper context, and assumes context wan't migrated properly.
So here we are,
Database.SetInitializer<MyProject.Models.MyModel>(null);
We are having the same issue. What solved it for me was not necessarily to move the Model, Context into the MVC project, but move my seperate project to the same solution as the MVC project and reference it by project folder.
This worked, but referencing a DLL instead of a project did not work.
Funnily enough, when creating a new Console Application and referencing the DLL assembly, we did not get this issue... only from an MVC project
We use EF code migrations to keep databases schemas up to date. The other day I had the same problem, in my case I was working with 2 database instances (QA and DEV databases of the same client with exact same data however QA environment was throwing this error. I've fixed the problem by deleting the _MigrationHistory folder and problem solved.
Related
For doing authorization in asp.net mvc 5 I have searched lot on internet but not getting correct answer. Actually I am using Visual studio community edition with .net framework 4.5.2 and mvc5. I want to do the Authorization in my project. My project is created with no authentication mode while creating a project.
Firstly I have tried these things:
I typed a command "Enable Migrations" on Package manager console.
Then I got one error like: Creating a DbModelBuilder or writing the EDMX from a DbContext created using Database First or Model First is not supported. EDMX can only be obtained from a Code First DbContext created without using an existing DbCompiledModel.
I dont know how to resolve this error. please help me to get out of it.
Which approach did you chooses to build our database model? Code First, Model First or Database First?
I'm asking because you can't use migrations with Model First or Database First approach. EF Migrations is a product targeted for Code First approach. CodeFirst assumes that you will never make any changes manually to the database. All the changes to the database will go through the code first migrations.
But there is solution for that - you can use Code First approach with an existing database. Take a look here: Using EF “Code First” with an Existing Database.
Is it possible using EF6 Code First and MVC5 to put all the models, views, and controllers that involve ASP.Identity into its own class library project. So that over multiple web applications you could use that same DLL and already have all the views / controllers / models and be using the same security database for multiple applications?
We have several web applications with separate databases and one security database that handles all of them, and we weren't sure how to keep this model now that we're moving to EF6 Code First and MVC5.
If it is possible could someone point me to a tutorial of something similar or give me a basic outline of steps to go through?
Or if there is a better way to achieve my goal, of having one set of code to handle ASP.NET-Identity security that I can plug that dll into multiple web applications and get the same logic and databases?
Or is this not a good idea in general?
Very open to suggestion and advice. I appreciate it.
Yes it is. We do this with every project that we have. The structure is very simple. Just create a class library project to your solution, add EF to the project, then reference the class library from your main project.
If using Code First Migrations be sure to select the class library project as the default project in the Package Manager console when running migrations or adding migrations.
Here is a pseudo solution structure for your solution
MySolution
- MyWebApp
reference: MyDAL
-MyDAL
reference: EF6
The advantage that I find to this is that you can then reference the "DAL" class library from say a companion console application or windows form application, or a companion website, even in a different solution, and they will use the same code base.
For example:
MySolution
- MyWebApp
reference: MyDAL
- MyDAL
reference: EF6
- MyOtherWebApp
reference: MyDAL
NOTE: Your data context will look for its connection string in the Web.config or App.config in the startup project. NOT the class library. This can be confusing at first... But once you think about how .NET compiles the application together into the final package, it makes sense.
If you're talking about creating one class library for an entire data layer shared between multiple projects, then that's easy enough. You can move all your models, your context, etc. into a class library and run migrations using the class library project. The other projects will just reference that class library and not have migrations of their own.
However, if you're talking about multiple databases and associated data layers, where project Foo has its own models, context and migrations and project Bar has its own models, context and migrations, while the class library has just the IdentityUser and IdentityDbContext, things get a little more complicated. You won't be able to combine any of these contexts. So in your Foo project you'd have to instantiate your context for Foo and your Identity context if you need to work with both. It's not a problem, per se, but it's something to be aware of.
I have a database project in Visual Studio 2012 with SSDT (latest as of this writing). In the database project, I have a schema called "UNITTEST" which contains tons of stored procedures that create, destroy, and provide other helper functionality for the unit tests. We do this because it gives us the ability to control our test data centrally rather than inside each unit test. Now that's fine and all however, I don't want to publish this schema or any of the objects inside of this schema to production.
So my question.. Is there a way to stop SSDT/VS2012 from including the UNITTEST schema in the production build deployment script?
I'm thinking there should be a way to do it depending on the solution configuration settings and publish profiles. If my configuration is set to "Release" then I want the build to perform a bit differently.
Builds are very new to me. I found this question: build-different-scripts-depending-on-build-configuration but I can't seem to get the answer to fulfill my problem. This question also doesn't help although it's very similar: bind-the-deploy-and-publish-destination.
Is anyone else managing something like this? The other developers in my team are just modifying the published script to remove these objects but I HATE manual work, there HAS to be a solution! :)
Thanks all!
One of my schemas references a lot of sys.* objects which created a lot of errors in the build. I created another project in the solution and moved that schema to the new project.
Luckily you can build and publish at the project level.
This allows me to keep the other schema in change control at least.
(It may also help to set the Properties on the SQL files to Build Action: None)
Partial/Composite projects might be useful here. Main project contains all of your necessary DB objects for your apps to run. The partial project references the main project, but then contains all of the "Test" code.
Here are a couple of options from Jamie Thomson:
http://sqlblog.com/blogs/jamie_thomson/archive/2013/03/10/deployment-of-client-specific-database-code-using-ssdt.aspx --This may be the simplest way to handle this
http://sqlblog.com/blogs/jamie_thomson/archive/2012/01/01/implementing-sql-server-solutions-using-visual-studio-2010-database-projects-a-compendium-of-project-experiences.aspx --Lots of good information in this post and most of it also applies to SSDT SQL Projects.
http://msdn.microsoft.com/en-us/library/dd193415.aspx - Composite projects for larger DBs. This could potentially work for you as well.
I have an XPages application that has been running quite happily for the last couple of years.
The application uses some Java classes as converters that are used to convert data entry on certain fields to upper case, proper case, etc. This functionality has been present and working since the app was first deployed.
Today I was asked to make a change to one of the pages, adding a new field. The change was made in a test copy of the database, the app rebuilt and tested and all was fine.
The same change was then promoted into the live database, but after being rebuilt the error
Can't instantiate class: 'Cannot find class uk.co.xxx.beans.UpperCase in NSF'.
is being returned.
I have tried rebuilding the app and cleaning the project numerous times without success. I have also tried amending the code in the Java class and rebuilding.
If I remove all references to the UpperCase class it then complains about the ProperCase class. It appears as if the app has lost its reference to the Java classes and rebuilding isn't fixing the problem.
As an interim solution I have removed all uses of these classes so that users can at least display the page - but this is obviously not a long term solution. As soon as I reinstate one instance and rebuild, the error returns.
The only change in the app has been the addition of the new field. Removing it makes no difference.
Can you suggest anything else I can try and what may be causing the problem?
Open production db in designer and using Navigator view open WebContent/WEB-INF and delete classes folder. Then rebuild the app or refresh it from template again.
Sometimes classes are not updated correctly. I've seen it few times.
I have seen this too (domino 8.5.3). I recompile until it eventually works. With a restart of the http task thrown in for good measure. How are you deploying the classes within the db or as jar files in lib/ext?
I ran into similar issues with 8.53 FP2 with the same "can't instantiate errors" if accessed by a designer client. I even put a PRD in at IBM for it.
In order to fix this problem we had to update to the server and clients to FP5. We had a work around before we could update the FP5. We had to modify how the application was rolled out. Once the database was updated from a template we had to do a clean then a build while use our Application ID used for signing applications.
http://www-01.ibm.com/support/docview.wss?uid=swg21639571
JDAE8ZV2CX
XPage With Java Design Element Breaks When Domino Designer opens after applying 8.5.3 Fix Pack 2 interim fix of any 853 Fix Pack 2/Fix Pack 3 hotfix
I have an existing project using RIAServices with Entity Framework. The project builds correctly and generates the AmsiWeb.g.cs file with all the context classes for my services.
I am converting my designer based entities and ObjectContext with Code First entities and DbContext. I installed the RIAServices.EntityFramework NuGet package to the web application that contains my services. However, now when I build the AmsiWeb.g.cs file only contains the WebContext class. It doesn't contain any generated services.
I have only at this point converted a single EDMX model to Code First and DbContext and made the requisite changes to the services that use that model to inherit from DbDomainService.
I am using EF 5.0... not sure if that matters cause I'm not sure how adding a DLL to the AmsiWeb application project would break code generation.
What would cause this to no longer work and how can I fix it?
Maybe it's a problem within the msbuild task that generates the proxy code (I mean the *.g.cs file). Probably it's looking for the wrong version of a entity framework. Have a look at this blog post http://mcasamento.blogspot.it/2012/10/entity-framework-5-code-first-and-wcf.html in the final part I wrote an assembly redirect statement that did the trick
It turns out that their needs to be a redirect for Entity Framework 5.0 (4.4.0.0 since I was using .Net 4.0) in the web.config. But, since my RIA Services were in a web application project that was not my root project the code wasn't generating.
Once I added the redirect to the web.config of the web application with the RIA services in it, the context code was correctly generated.