When re-targeting a project from .NET 4.0 to .NET 4.5 in VS2012 any EDMX in the project is automatically converted to EF 5, i.e., the namespaces are updated to match the target framework.
Is there a way, maybe via an extension to the EDM Tools, to "listen" for this conversion? We use custom annotations in the EDMX, and when the upgrade is performed also need to convert/update our annotations.
We currently implement IModelTransformExtension to perform custom logic when the model is loaded and saved, and in theory we can use the OnAfterModelLoaded to do the conversion of the annotations too, but since the conversion is needed one time only, and always specifically when the .NET framework is retargeted, it would be great if there's another option.
Any ideas?
Related
Converting an ASP.NET core 2.1 web app to 3.1 and found out a few endpoints broken because the new Json serializer works differently than Json.NET which is default in core 2.1.
I don't want to fix all my model class and want to set Json.NET as the default serializer..how do I do that?
refined my google search and it has been answered here:
https://stackoverflow.com/a/57652537/192727
I followed exactly what #Tao Zhou suggested and it did the trick.
everyone.
I'm trying to create new Scaffolded item for simple ASP.NET Wep API application which should be based on domain object class and DbContext derivative in separate assembly. The assembly is in the solution, target app has a reference to it (and manually created code which invokes the classes from my lib is build up without any errors) and, obviously, the classes I've mentioned have access modifier public.
The problem is wizard for creating new scaffolded item cannot see my model classes. (By the way, when the model classes were in another ASP.NET MVC5 app the wizard worked well.) I'm using Visual Studio 2013 Update5.
How to fix this? Any workaround would be helpful too!
Sorry for disturbing.
the origin of the problem seems to be that I've move my data model classes from ASP.NET MVC app into my class library in wrong way.
I've not just cut/paste them, but copy-paste, cut-paste (confirmed replacement).
this is the only thing which could cause the problem (although I still don't know the details).
Never the less I've started from the beginning again and cut/past the data model files initially - everything seems to work fine now.
How to disable code-first feature in EF (Visual Studio 2012)
I am using Visual Studio 2012, MVC4 (Internet application template).
I want to use EF, but not with its code-first feature. I would want the application to error out, rather than create or modify my database based on my code. (i just can not live with this feeling of my database being changed behind the scenes ... i want the application to use the exact db i have created ... and if there is any thing that has to be changed, i'll do it my self)
is this possible with the new Ef (VS2012)?
i have seen many people asking this, but so far i am unable to find the answer.
You can use Code First and ensure that your database never gets updated or overwritten when you change your model by setting the database initializer to null:
Database.SetInitializer<MyDbContext>(null);
It's a static method of the Database class and should be called at the beginning of your application, for example in global.asax or in a static constructor of your context class. Doing this you have to change model class and database schema manually so that they match.
You can also use the Reverse Engineer feature to create a Code First model from an existing database. It is explained here: http://msdn.microsoft.com/en-us/data/jj200620
Or if you don't want to use Code First at all and work with a model designer you can use the Database First approach, explained here: http://msdn.microsoft.com/en-us/data/jj206878
An overview about all the possible options is here: http://msdn.microsoft.com/en-us/data/ee712907.aspx
I am looking or an ObjectContext generator for Entity Framework 5.0, not a DbContext generator. WCF Data Services requires an ObjectContext and won't work with a DbContext. If I want to use EF5 with a DataService I must provide an ObjectContext. The ObjectContext generators in Visual Studio 2010, and online are for "ADO" and for "EF 4.x". The generators for "EF 5.x" all product DbContext objects.
Right click the white space in the designer and select Properties, then change the Code Generation Strategy to "Default". You'll have to delete the code-first TT files, too.
Although too late - you will have to first delete everything under your edmx file (all the tt templates). After that you will have to download the code generator that creates ObjectContext. To do so right click in your edmx and select Add Code Generation Item. After that select Online (on the left) and select EF 5.x EntityObject Generator for C# - this is the generator that creates ObjectContext, you will see it in the description (this is also valid for EF 4.x, just find the same generator, but with 4.x in the name). Install it and you will have your model under the edmx that inherits ObjectContext.
using System.Data.Entity.Infrastructure;
ObjectContext context = ((IObjectContextAdapter)DbContextObject).ObjectContext;
You would probably want to update the version of WCF Data Services to 5.x. Then it will work with DBContext.
Can I use "Automatic Lightweight Migration" if my already release v1 didn't have a versioned Core Data model?
If yes, are there any key changed to the documented steps I need to apply?
Not only can you do this, in one sense it is the only way you can do this. From the Apple Documentation, "To create a versioned model, you start with a normal model..."
Your v1 had a normal model. As long as you have that model, and you follow the steps linked in that tutorial to create a versioned model, lightweight migration will work—if your migration meets the usual lightweight migration requirements. The lightweight migration happens in your v2 app (or in v1.1 or whatever). The data model that was in your v1 app essentially has no relevance. What Core Data needs is to find that the new v2 app has a copy of the data model that matches what is found in the Core Data store on the local device, and has a new data model that describes how you want the data to be stored from this point forward. If the changes required meet the requirements for lightweight migration, it then does it.
What are those requirements? From the Apple documentation on Lightweight Migration:
To perform a lightweight migration, Core Data needs to be able to find
the source and destination managed object models itself at runtime.
(Core Data searches the bundles returned by NSBundle’s allBundles and
allFrameworks methods.) It must then analyze the schema changes to
persistent entities and properties and generate an inferred mapping
model. For Core Data to be able to do this, the changes must fit an
obvious migration pattern, for example:
• Simple addition of a new attribute
• A non-optional attribute becoming optional
• An optional attribute becoming non-optional, and defining a
default value.
If you rename an entity or property, you can set the
renaming identifier in the destination model to the name of the
corresponding property or entity in the source model. You typically
set the renaming identifier using the Xcode Data Modeling tool, (for
either an NSEntityDescription or an NSPropertyDescription object). In
Xcode, the renaming identifier is in the User Info pane of the Detail
Pane, below the version hash modifier (see The Browser View in Xcode
Tools for Core Data). You can also set the identifier at runtime using
setRenamingIdentifier:. For example, to handle
• Renaming of an entity Car to Automobile,
• and Renaming the Car’s color
attribute to paintColor
you would include the following code after
loading the destination data model, and before attempting to open a
store file:
NSEntityDescription *automobile = [[destinationModel entitiesByName] objectForKey:#"Automobile"];
[automobile setRenamingIdentifier:#"Car"];
NSPropertyDescription *paintColor = [[automobile attributesByName] objectForKey:#"paintColor"];
[paintColor setRenamingIdentifier:#"color"];
In summary, you didn't miss the boat, and it's not too late to make use of these features of Core Data. :) And to answer your specific question, there is nothing you need to change from the standard steps outlined in the documentation.
Later update
Further thoughts based on your comment to another answer, where you said:
so just to confirm, I don't have to in XCode back track my core data
model to what it looked like a v1 and then version it then? So I can
just create the first core data model version at the point where my
application is at v2?
From what you are saying here, the issue would appear to be different to the initial question. Your initial question says that you have already released v1 of your app, without explicitly adding a versioned model. However, this statement implies that you have made changes to your core data model for v2 of your app, without first creating a versioned data model. This is quite a different thing.
If this is the case, then your job is more difficult. However, you can retrieve what you need presuming you keep backups of your source code or manage your code in a repository like git (and I would recommend all developers do both). If you've already changed your core data model for v2, what you need to do is turn the current data model into a versioned model, then restore/checkout a copy of v1 of your app, copy the core data model (the *.xcdatamodel file) from there into your current project, so that you then have both the v1 data model and your newer one. Then you will potentially be able to use lightweight migration, as discussed above.
Note that the key issue here is when you changed your data model. Whether your app is called v1 or v2 is essentially irrelevant to the question, other than obviously that it may be that you introduced changes to the data model at the same time you changed the version number to v2 of the app.
Save off your current non-versioned model file (the .xcdatamodel package).
Now, create a new model version. You will have instead of a single .xcdatamodel package, a .xcdatamodeld file. Right click on it in Finder, select "show package contents". That opens it as a directory - drag your old .xcdatamodel file into that directory alongside the new versioned .xcdatamodel package.
Now an automatic migration should work if it's possible, you may not need a mapping model. Test to be sure though!!!
I have used this approach in a production application and it did work. As long as CoreData can find both the current model the app is using, and the model the new version of the model the application relies on it can attempt the automatic migration.
yes it is possible because by creating the new version you can also create a version mapping file. This file tells the application which keys will be changed to which keys in the new version (and of course which one are deleted and created)
the apple documentation: http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmMappingOverview.html