I'm using Entity Framework Migrations & Code First and recently encountered a very weird problem.
The problem was reproduced with versions 4.3.1 and 4.4.
EF thinks that the context was changed while actually it didn't.
It happens when I change the path of the solution. for example:
If my solution is located in C:\integration\something.sln the migration may work but if now I will change the path to C:\development\something.sln and re-build the solution the migration will throw an exception saying there are pending changes in the database. (Of course without any changes in the source code.
I used IL Disassembler to create a dump of the output assemblies and with BeyondCompare I saw that there are differences. I assume the data is the same but its written in different order...
How EF determines if there were changes in the context? Is it possible that the assembly check-sum comes out different and will cause EF to think that there were changes?
Any ideas are most welcome...
First, this is not a migration issue - its probably a bug in the Entity Framework's algorithm to check if there are changes in the database.
I had a class hierarchy that contained an abstract class with no properties, making that class not abstract solved the problem.
After gaining some precious debugging experience, I found several ways to solve this issue and each one raised more eyebrows than the one before which makes me very convinced that I fell on a very rare corner case. As I mentioned, I decided to solve by making a class not abstract.
I tried to reproduce the bug in a clean solution so I can send it to Microsoft but until now it didn't really work.
So... to sum things up, if you find yourself with such a problem (very frustrating one), a good tip is to look for abstract classes!
Related
I'm starting a project and already check how useful is gobuffalo/pop.
I have never previously used a framework for my GO projects. I just used the stdlib and I'm used to working with Django too.
In Django it is pretty straight forward to create/update a model and generate its migrations. It gets the current DjangoModel and generates a migration with the changes. What a surprise to me when I can't find how to do it with pop.
I already checked the documentation but I couldn't find any examples.
How do you do that?
Right now, you can only generate empty migrations and write them yourself: https://gobuffalo.io/en/docs/db/migrations#writing-migrations
There's an issue asking to implement a Django-like migrations generator (https://github.com/gobuffalo/pop/issues/184), but it's not done yet and requires a lot of work.
Does anyone here has experience with IBM.EntityFrameworkCore package? I've created a .NET Standard 2.0 library project in VS2017, added mentioned package, and tried to make it work by following this and this tutorial from IBM website, with no luck. I get the project compiled, but at the runtime I'm getting a System.TypeLoadException with the following message:
Method 'ApplyServices' in type 'IBM.EntityFrameworkCore.Infrastructure.Internal.Db2OptionsExtension' from assembly 'IBM.EntityFrameworkCore, Version=1.1.1.101, Culture=neutral, PublicKeyToken=7c307b91aa13d208' does not have an implementation.
Any help will be appreciated!
Thanks!
Update: The exception happens as soon as I try to use the context. It means after the context is successfully created, but before DbContext.OnConfiguring call happens.
I've solved it. It turned out that this exception happens if actual entity types (i.e. MyType) aren't defined in the same assembly (project) as the context. In my solution I had entity types defined in one project, and DbContextdefined in a different project, that references the first one, of course.
The reason for me to have such design was in the fact that there are two different packages (depending on the actual OS): IBM.EntityFrameworkCore and IBM.EntityFrameworkCore-lnx. So I've created two different projects, each referencing one of these packages. Still, I wanted to have all the entity types defined once... But obviously it cannot work like that.
Update: Sadly, it turned out that this isn't the only issue. I've ran into another one, described here. Thumbs down for DB2 .NET team! It's always frustrating to work with...
I just started using EF 6 and I noticed that the first execution takes more time because it needs to be compiled, so I researched and found that you can pre-generate the view.
I used EF Power Tool to generate the view: http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d/
It's a dll, and I'm building using the option Embed in Output Assembly.
The problem is that even though I have the view.cs when I execute the first query I have the same delay, so it seems that my library is not using the pre-generated view.
What could be wrong? I'm passing the connection to the entity using an EntityConnectionStringBuilder returning a EntityConnection object.
Also I tried changing the view.cs to Embedded Resource, since with Compile I did not have any changes, in both ways I still have the first time delay.
I'm sure I'm missing something, but not sure what.
Thanks in advance,
Lucas.
EF5 views will not work with EF6 (in addition to that there are some issues with EF6 Beta 1 and EF6 RC1 which prevent using views with EF6 - these issues should be fixed for EF6 RTM). I created a T4 template for generating views for EF6 - you can find more details here - again due to the problems above the views generated by the template will not work for EF6 RC1. If you absolutely think you need it you can try the version from my github - it was updated to work with EF6 RTM and also works with nightly builds.
Anyways, I am pretty sure that this is actually not view generation that are causing the issues (actually the performance of view generation in EF6 has been greatly improved). We recently found a few performance issues (see 1674 and 1662) that are affecting start up time and we are looking at these.
EDIT
The version of the template that works with EF6 RTM (6.0.0.0, 6.0.1.0) has been published to the VS Gallery
I've been using EF 4.1 and the POCO template generator.
I love and hate EF. I love the time I save. I hate maintaining the EDMX file.
But while keeping the EDMX in sync with the database has been a challenge, I'm now overwhelmed by the POCO generator. Up until now, the POCO generator has created POCO's for me and kept the ClassObjects.Context.cs empty and non-conflicting.
After my most recent refresh I have had constant problems with "Amiguity between 'perseus.DataLayer.accounts' and 'perseus.DataLayer.accounts'.
I get this error for every POCO.
I'm on the edge of panicking as I recommended and owned the maintenance of EF. I've spent a couple days on trying everything from database refreshes to deleting all items from the EDMX file and reloading them from the database.
Nothing has made a difference. I have no clue what has suddenly changed from the last few months of relative stability. I'm seriously lost as to what I can do from here.
It looks to me like you have not disabled the code generation strategy. click on the designer background and check the properties tab, the first item is Code Generation Strategy. This should say None, and not Default.
Editing the edmx manually is difficult and error prone. I would suggest copying what you have off to another location then letting the tool regenerate the edmx for you. Compare the two.
I worked with some DB2 entities that I had to manually sync and had constant issues. The tool would clobber my changes and I would have to manually replace that with working code.
If at all possible, don't modify the edmx code yourself. If you must, make the changes, copy those off to a text file in the project for tracking/safe keeping.
I have gone through this post and the links, and still can't solve my issue.
I have changed my config to name the assembly, but it makes no odds.
We recently moved the projects and think that might be an issue - but how to solve it if so. I don't quite understand how EF when running finds the cdsl etc. files I thought they were embedded in the dll [it is set to do so]?
The service having the issue doesn't directly use EF itself, it uses another DLL which DOES. I also added a direct ref to the DLL but no joy.
Also, the same code (the dll that contains the functionality, not the wrapper service) using the same connections strings works fine in my system test project via the IDE.
Turned out to be down to incorrect initialisation of StructureMap and not really to do with EF itself.