Entity Framework 6 - Error: 1109 Property is not mapped - entity-framework

We have been using EF6 on a project and have been encountering numerous issues with it.
The latest issue is that we have started getting a compilation error: Error 1109: Property 'Procedure8' is not mapped.
There is no such entity/property as procedure8. Examining the edmx file on the line indicated shows a completely different entity. There will be around 10 or 20 of these errors created from procedure1 through to procedure20, then it will repeat the 11007 error for every class in that was generated.
If we create the .ednx file from scratch and generate the model from the database, it imports all of the tables and stored procedures (about 250 odd of the latter). We then need to generate entities() class from the context.tt file to get all of the classes. Doing this successfully creates the entities and we get the .cs files in the project folder but results in the above error.
We have tried doing a 'generate database from model' to get the SQL file, as some people have suggested that this is required to generate additional files. However, this removes all of the stored procedures from the model store and we have to delete the .edmx file and start again.
Does anyone have any ideas on what actually causes this error and how to get the EF work?

The issue we think is that the edmx file had become corrupted. This was deleted from the project along with all of the generated files.
A new edmx file was added to the project with the same name and re-generated, this created what looked like all of the correct files, but still failed to compile.
The solution was to remove the connection string from the app.config file, then generate a new edmx (visual studio add new item). It will prompt to create a new connection string, then ask to import all of the tables, views and stored procedures.
Once it is done importing everything it is necessary to then wait a very long time while some post processing is done - the visual progress indicator does not always appear.
No other actions are required from there other than building the project.
Not sure why the product is so sensitive around connection strings.

Related

Entity name conflicts in Visual Studio

I'm new to the Entity Framework. I've created a model-first schema in Visual Studio 2012 with EF5, but I'm having trouble getting the generated code to build. One of my entities ("Test") has the same name as the model (edmx) and the project (csproj) files, so it conflicts with the namespace (Test is a namespace but is used like a type). So I decided to change the namespace by setting a "Custom Tool Namespace" for the .tt files. This worked, but then I found that the "Test" entity's generated .cs file was entirely empty (other entities were generating properly), so I had build errors where other entities reference "Test". Renaming the entity results in a properly generated class, and therefore a building project, but I really want to use the original name.
I will probably end up scratching the project and starting over, ensuring to choose unique names for the project, the model, and the entity. But I'd rather know how to fix this if possible in case I run into something similar when the project is further along and it's not so easy to start over.
you can use use an alias on the Using Directive, e.g. using Project = PC.MyCompany.Project; to differentiate between namespaces. see MSDN

Odd failure to create SQL Server CE .sdf file in LINQPad query

I'm using LINQPad with a custom assembly, behind which there is an SQL Server CE database which may or may not exist at the time. The custom assembly uses Entity Framework code-first with automatic migrations, and includes a simple initialiser inheriting from MigrateDatabaseToLatestVersion which will create the database if it doesn't exist. I've been working with it for a couple of weeks and it's been working quite nicely.
This morning, after a small glitch proved frustratingly difficult to diagnose until I realised that a migration had happened between two events in the log, I decided it'd be nice if the database's own log table noted when a migration had been applied. To that end, I added a couple of lines to the Seed() method in the initialiser to instantiate the generic repository/unit-of-work container I've been using, add a record to the logs table, and commit the changes back to the database. The repo has a flag to indicate that it does not own the underlying context, so I can be sure that it doesn't dispose the context I'm then going to try to use.
Now, if I change the model (I'm testing by repeatedly commenting and un-commenting one of the DbSet properties on the context class) then a record is inserted to note that a migration took place. Exactly what I wanted. However, if the .sdf file doesn't exist, LINQPad gives me the following error:
The underlying provider failed on Open
InnerException: The database file cannot be found. Check the path to the database.
While the error message is perfectly self-explanatory (the file can't be found because it isn't there) what isn't clear is why it doesn't just create the file like it did before. What's really odd about this is that if I re-compile the custom assembly and then run the LINQPad query again, then LINQPad will create the .sdf and continue happily. This happens even when the changes to the assembly are irrelevant. In testing, I have run the query, watched it fail, then added a single blank space to the end of a comment in the repository class, re-compiled it, and then run the query again... and it worked. I am completely at a loss to explain how that should have made a difference.
At this point it may be worth mentioning that the "custom assembly" I'm dealing with here is LINQPad's own "My Extensions" file. Yes, I wrote a data context with code-first automatic migrations initialisation and a generic specification-pattern transactional repository in my extensions file. Yes, I realise that's probably not what it's meant for. I was bored, and wanted to test something. Anyways, this may be causing something strange somewhere. It may not, but I thought I'd mention it just in case.

CoreData Automatic Lightweight Migration Error

I am trying to use automatic lightweight migration in my app. I did the following steps:
Create new model version.
Edit new model version.
Set the options NSMigratePersistentStoresAutomaticallyOption and NSInferMappingModelAutomaticallyOption to YES upon creation of the persistentStoreCoordinator.
Setting the current version to the new version.
and got an error: reason = "Can't find model for source store"
I've tried Product->Clean to no avail. Ideas?
Edit: I forgot to put in the model details.
I have two .xcdatamodel files. The first has two Entities, Event and Venue. The second has one Entity, EventDate. I no longer use the second .xcdatamodel in code but I did leave the file in the project. I am trying to add a new entity Update to the first model file.
The error ""Can't find model for source store" means that the .xcdatamodel file originally used to create the existing persistent store cannot be found.
Supposed you started with these two model files (the version number is the version of the app not the data model):
oneEntityModelv1.xcdatamodel
twoEntityModelv1.xcdatamodel
… and you want to migrate to this data model:
threeEntityModelv2.xcdatamodel
The v2 version of your app would have to include all three files for the migration to take place.
The problem was that we were using the mergedModelFromBundles to instantiate our model. Apparently that doesn't play well with automatic lightweight migration. The fix was to
delete the unused xcdatamodel.
delete the database file.
version the remaining model.

Entity framework - create the csdl, ssdl and msl files

I work with EF 4 (not with Self-tracking entities currently). I've added some columns (non of them is a key and all of the are nullable) to one of my entities, and got the Number of members in conceptual type does not match with number of members on object side type exception.
I've followed the accepted answer here but all I got from that was that this entity does not appear in my edmx anymore. I've re-added it from DB, but I keep getting the same exception.
I think the problem is that I've copied the csdl/ssdl/msl files to my executing assembly directory. I'd like to copy the updated files, but they're not created again (they were once created in the obj\Debug\edmxResourcesToEmbed folder of my EF project), not even after removing them.
Any way to get those files created again?
Thanks.
P.S: As I don't want to publish excess amounts of code, I don't add anything yet but I'll be happy to add needed information, I'm just not sure what exactly is needed.
So if you want to create the csdl, ssdl amd msl files, do the following:
Go to your edmx file.
Click on the GuI screen that shows the model.
Switch to the property window (I didn't know that it needs to be accessed from the GUI area and not by right clicking the file in the Solution Explorer.
In the Metadata Artifact Process select Embed in Output Assembly.
Done and done, the files will appear in Debug\edmxResourcesToEmbed under obj or obj\x86, depends on your build definitions.
I'm sorry if this seems to simple to explain, but I was in need for those instructions (msdn was not a great help) and I hope it might help others.

Number of members in conceptual type does not match with number of members on object side type

I'm using .net framework 3.5 SP1.
After adding a column to one table in Sql Server (as well as changing an existing column from allowing nulls to not nullable), I can no longer run my project without getting this error:
The number of members in the
conceptual type
'XBRLDimensionalModel.axis_t' does not
match with the number of members on
the object side type
'EOL.Xbrl.Persistence.Data.axis_t'.
Make sure the number of members are
the same.
I gave up trying to find and fix the generated code. I now have deleted all my local entity-related files and re-generated them by starting over from scratch and adding a new item (ADO.NET Entity Data Model). I still get this error.
The only way I can run the project now is to undo all my pending changes and use the last version from source control, and of course change the two modified database columns to nullable.
From all I've read so far it seems like I simply should have been able to "update" my model from the database. That resulted in this exception (above). But now I'm totally confused that even with a complete regeneration of the entity model and supporting classes I'm still getting that error.
I changed the property on my edmx model: "Metadata Artifact Processing" to "Copy to Output Directory". The Designer.cs, csdl, msl, ssdl files all seem to be consistent with the latest DB changes.
The exception is being thrown the first time my entityModel instance is referenced. So it is prior to any loading or saving of the data from the changed table.
any ideas where I'm going wrong?
Thanks,
TG
This error can also happen if the EDMX file was changed outside Visual Studio. Right click on the EDMX file and click "Run Custom Tool"
Open your model as XML. Remove all references to that type from the CSDL. Save and close, then reopen in the GUI. Now you should be able to update model as usual. If that doesn't work, do the same thing, but remove from MSL as well.
This seems a little verbose for a comment so I'm adding this as another answer:
In response Craig's suggestion I opened the edmx file in an XML viewer and removed all references to Axis_t (including the associations due to Foreign Keys). From the entire file.
I then "updated" the model by opening the edmx file as the GUI interface, right-click | refresh from database | Add (tab) which now only lists the Axis_t table. I added the table which seemed to work fine and included my new column and the column was mapped correctly.
I then ran the project to the same result. Same error as posted above.
I have now reverted back to what was in source control as well as changing the database columns (new one and modified one) as nullable. The project runs fine. I still have not successfully been able to implement the new DB column in EF. It behaves as if there is some stored/compiled version of the model which is not being updated via the "update" process.
When changing a foreign key from nullable to non-nullable (or vice-versa), be sure to change the association multiplicity from 0..1 to 1 (or vice-versa). The designer sometimes misses this in an update from the database.
Right click on your edmx file and open with XML.
Find the incorrect data types and change them.
Save file.
This worked for me.
I was facing the same issue, when I added one column to db and added respective property to entity(edmx).
I was also using source control for my solution. As I noticed, while saving changes to any file, save action prompts with overwrite option.
So, I overwritten the designer.cs as well config file and problem gets resolved.
regards,
bhushan
This has happened to me when I am working on two versions of the same application (with Model differences) that compile into the same folders.
It appears that Visual Studio doesn't "clean out" the "obj" temp folder properly and some fragments of the old model are still in there.
If I simply delete all files from the "obj" folder and re-compile this error goes away.
The Model in each version is perfect which was driving me crazy.
Not saying this is the answer to the OP's question but it is definately another reason for this error.
Steve
I had this same issue for hours. Found that in my Designer.cs file one of the properties of my entity was missing its attributes. (Don't know how this happened?)
[EdmScalarPropertyAttribute(EntityKeyProperty = false, IsNullable = false)]
[DataMemberAttribute()]
public global::System.Int32 ContractCapacity
Now the error message makes sense, this was the missing DataMember. Once the attribute was added IT WORKED!!!
Here's a nightmare scenario that I just experienced: I have an MVC2 website and a WCF service that are built separately, but share a configuration. Within both projects, I used the same Entity Container Name; therefore I picked up the same connection string for both projects. Eventually the metadata got out of sync between the two and caused this error. The obvious solution was to not use the same Entity Container Name in the two projects; changing to a different name allowed me to specify unique connection strings, and therefore metadata, for each component which avoided the problem.
Now that I figured it out, it's obvious, but I had a tense hour or two!