From xCode 8, xCode should update automatically NSManagedObjects after every DataModel modifies but I'm working on an old project which I've already update to Swift 3 but, every time I modify my DataModel, xCode doesn't update the corresponding ManagedObject.
Is it simply a "coming soon" feature or there something to check to enable this innovation?
The release notes state that
Automatic code generation is enabled and disabled on an entity by entity basis, and is enabled for all entities in new models using the Xcode 8 file format. This feature is available for any data model that has been upgraded to the Xcode 8 format.
You need to upgrade the model file to the new file format.
You may not be able to go back, so make sure your current version is committed to whatever VCS you use.
Related
I recently wanted to try out CoreData and its power, so I found a simple tutorial and while following it, I created a .xcdatamodeld file with Entities and relationships.
What I wanted to do now is to turn it into classes (Tried on Xcode Version 8.1 (8B62) and Xcode Version 8.2 beta (8C23))
For this I opened my model file, clicked on Editor --> Create NSManagedObject subclasses.
Doing this and selecting my two entities would generate 4 classes, two NSManagedObject classes and for each of them one extension.
After adding or rather generating those four files, Xcode won't compile the project and puts out the following error:
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc failed with exit code 1
and sometimes it also says: Invalid redeclaration of [Managed Object Name]
Any insight would be awesome, should I create the classes myself without using a model? or does CoreData work in Objc? then I'd switch to that...
Xcode 8 adds support for automatic Core Data subclass generation, which you can read about in the document What's New in Core Data in macOS 10.12, iOS 10.0, tvOS 10.0, and watchOS 3.0. New projects have automatic code generation turned on so when you created NSManagedObject subclasses manually, you created duplicates, which is causing the compiler error.
There are two ways to fix this. First, you could remove the NSManagedObject subclasses you manually created. Second you can turn off automatic code generation for your data model from the Data Model inspector by choosing Manual/None from the Codegen menu. If you're following a tutorial, I recommend the second option because the tutorial was most likely written before Apple added automatic Core Data subclass generation.
You can learn more about Core Data's code generation in the following article:
Core Data Code Generation
I'm trying to generate NSManagedModels from my datamodel. Generation works but after I got many errors :
error: filename "Station+CoreDataProperties.swift" used twice:
'/Users/Me/MyApp/Models/CoreData/Station+CoreDataProperties.swift' and
'/Users/Me/Library/Developer/Xcode/DerivedData/MyApp-gwacspwrsnabomertjnqfbuhjvwc/Build/Intermediates/MyApp.build/Debug-iphoneos/MyApp.build/DerivedSources/CoreDataGenerated/Model/Station+CoreDataProperties.swift'
:0: note: filenames are used to distinguish private
declarations with the same name
I try clean build folder and derivedData directory hard delete. I'm using Xcode 8 BETA maybe it's a bug ?
I get this in Xcode 8.1
For me following steps solved the issue. Please note that order matters.
1) Create entity in Core Data model.
2) Under class section, make settings as on following image.
Module: Current Product Name
Codegen: Manual/None
3) Generate your NSManagedObject subclass.
This post greatly helped me solve this problem myself. Personally I look at this as an Xcode bug. Bug or not this is a huge chicken and egg situation.
I ran into this by:
Created a new Project using Core Data
Generated my NSManagedObject subclass+extension (while codegen: ClassDefinition)
I accidentally saved the generated classes in the Wrong folder
I deleted the generated files
Re-generated in folder I wanted
đź’Ą- Xcode used twice errors
As others have posted I kept cleaning my build (and clean build folder) but that never fixed the build issue.
I finally figured out if you originally created your NSManagedObject generated classes with codegen: ClassDefinition, as I did without knowing then you are locked in for the chicken and egg issue.
I then deleted the auto generated classes thinking I had to re-generate, so I did. Once re-generated I would get the used twice build error again. I manually went into the ../DerivedSources/CoreDataGenerated/Model/.. and deleted the duplicates. Again, I re-generated thinking I'd only have 1 copy (in my project) but I was wrong. If codegen: ClassDefinition was originally set then Xcode will keep creating the auto-generated classes+extensions and put them in the buried folder ../DerivedSources/CoreDataGenerated/Model/... I repeated this chicken and egg a few times before catching on.
I later realized you do indeed need to mark codegen: Manual/None however to get things back in sync you need to delete the auto-generated files in ../DerivedSources/CoreDataGenerated/Model/.. and in your project if you have any there still.
Be careful setting codegen: Manual/None, for me it was bit tricky because codegen: Manual/None wouldn't stick. I had to click back and forth between entities multiple times to double/triple check each entity was set to codegen: Manual/None. Then auto generate the files. At this point your only copy of the auto generated files should be in your project and not in ../DerivedSources/CoreDataGenerated/Model/...
Last, I think this is a bug because if you specify codegen: Manual/None I don't expect Xcode to auto generate files at all, yet it does and puts them in your project. More confusing if your setting is codegen: ClassDefinition, who the heck knows Xcode will put the files in a buried directory yet it is available for use in your project. My beef with this is the auto generated files aren't source controlled and if I change computer I have to know to auto-generate them on the new station.
Hope this helps someone else!
Cheers!
This is indeed not a bug. As #Morrowless suggests both class definition and properties extension are created. If this is not wanted, select Manual/None under Codegen before generating the code. If the code is already generated, just delete them, and try Editor->Create NSManagedObject Subclass... again from the menu (after setting Manual/None).
Note, in the picture below, the Class Name 'Contact' is specific to my project. You will see your entity name instead.
If you generated CoreData subclasses with codegen: ClassDefinition your basically screwed. The only way to fix it is to:
Delete your CoreData subclasses.
Delete your derived data folder.
Clean your project (CMD+K).
Generate new CoreData subclasses, this time select Codegen: Manual/None and Module: Current Product Module
This is not a bug. Codegen generates these files in the DerivedData folder, so you don't need to create them again in your project, hence the compile error.
From Xcode 8.0 Release notes:
Xcode automatically generates classes or class extensions for the entities and properties in a Core Data data model. Automatic code generation is enabled and disabled on an entity by entity basis, and is enabled for all entities in new models that use the Xcode 8 file format. This feature is available for any data model that has been upgraded to the Xcode 8 format. You specify whether Xcode generates Swift or Objective-C code for a data model using the data model’s file inspector.
When automatic code generation is enabled for an entity, Xcode creates
either a class or class extension for the entity as specified in the
entity's inspector: the specified class name is used and the sources
are placed in the project’s Derived Data. For both Swift and
Objective-C, these classes are directly usable from the project’s
code. For Objective-C, an additional header file is created for all
generated entities in your model. The header file name conforms to the
naming convention “DataModelName+CoreDataModel.h”.
However, if you selected Category/Extension under the codegen pulldown menu in the data model inspector (because you want to add logic to your model): codegen will wrongly generate both the class definition and properties extension.
The solution is to simply delete the properties extension (ClassName+CoreDataProperties.swift). Your project should now compile.
After following the guidance from oyalhi and Vladimir Shutyuk, (deleting the NSManagedObject files, changing the entity codegen to Manual/None), I had to restart Xcode to allow it to index again before I could re-generate the NSManagedObject files and get a successful compile.
For the sake of completeness..:
I just ran into the same error, but none of the proposed solutions worked. What puzzled me was that even switching from automated code generation to manual for the one (as I thought) problematic entity didn't do anything.
Finally, I figured out that I had several entities with the same name, but they all shared the same classname. The reason for this was that I copy&pasted one entity several times to save me some work, because they also have a few attributes in common.
Turns out XCode renames the duplicates by adding 1, 2,... to the entity name, but leaves the class name as before. And since now entity name and class name are "unrelated", renaming the entity won't change the class name either.
Hope it helps someone - I have also filed a bug report for this.
I've began to try use Core data with swift 3 and Xcode 8 beta. When I try to generate NSManagedObject subclasses from core data model and Create NSManagedObject subclass… option in Editor menu, Xcode 8 beta generates three files one of them is _COREDATA_DATAMODELNAME_+CoreDataModel.swift with the following content:
import Foundation
import CoreData
___COREDATA_DATAMODEL_MANAGEDOBJECTCLASSES_IMPLEMENTATIONS___
In addition, the content of this file shows two warnings:
Expressions are not allowed at the top level.
Use of unresolved identifier '___COREDATA_DATAMODEL_MANAGEDOBJECTCLASSES_IMPLEMENTATIONS___'
Has anyones faced the same issue? Which is the meaning of this new file?
Thanks
It's probably a (beta) clash with the new automatic subclass generation, which can be controlled in the entity inspector of the data model file.
From the documentation (What's New In Core Data)
Xcode automatic subclass generation
Xcode now supports automatic generation of NSManagedObject subclasses
in the modeling tool. In the entity inspector:
Manual/None is the default, and previous behavior; in this case you
should implement your own subclass or use NSManagedObject.
Category/Extension generates a class extension in a file named like
ClassName+CoreDataGeneratedProperties. You need to declare/implement
the main class (if in Obj-C, via a header the extension can import
named ClassName.h). -
Class Definition generates subclass files named
like ClassName+CoreDataClass as well as the files generated for
Category/Extension.
The generated files are placed in DerivedData and
rebuilt on the first build after the model is saved. They are also
indexed by Xcode, so command-clicking on references and fast-opening
by filename works.
I have similar problems with this developer beta Xcode 8. Some of them resolved Command + S (save changes) before I leave Data Model or before I generate NSManagedObject subclasses. I don't know why but in my case automatic save didn't work sometimes and some errors occur.
I've run into the problem with the .swift file cited above and found that commenting out the ___COREDATA... line got me by the error for now. I'm not sure what it's supposed to accomplish.
I'm also finding that XCODE 8 has a tendency to forget about new fields that are added to CoreData entities and to repeatedly reset the CoreData model code generation target to Objective C, leading to a flurry of .h and .m files instead of swift files when it regenerates files. Most of the issues that I've seen have been CoreData related, but have been workable so far.
Other than that, XCODE 8 has been surprisingly solid working with an app with 25 data entities and over 30 view controllers so I'm not complaining.
Using Xcode 6 beta 4 Core Data, how do you regenerate the subclasses if you want to add/remove an Attribute?
For example, I create a new entity and add a few attributes then go to Editor > CreateNSManagedObjectSubclass.., it works the first time and creates the entity as a .swift file, but then if I go and add a new entity and try to regenerate the subclasses by choosing the same option in the editor menu it doesn't overwrite the .swift file with the new entity. This used to work for me in Xcode 5.
Does anyone know what I'm doing wrong or what is the correct way to do this?
Thanks!
Xcode won't silently overwrite your file. This is a feature, not a bug, because you will not inadvertently lose custom code in those classes.
If you want to replace the file, delete it first. The class generation will then work as expected.
A typical "upgrade table" for InstallShield MSI installation cntains two records: "from any version to current is upgrade" and "from current to any is downgrade". This requires to manually copy-paste "current version" number every time a major, minor or build number has changed, that is not very good.
Currently i'm using a script that parses .ism project file and replace version number in upgrade table before build. But this is a dirty hack. Maybe it is possible to use "ProductVersion" MSI property in upgrade table, so product version is stored only in this property? I have tried to enter this property name multiple ways, like [ProductVersion] or ##ProductVersion##, but nothing helps - it is not being replaced by property value, and resulting MSI contains "##ProductVersion##" text instead of "1.30.1264" property value.
A new project should contain two records intended to behave like you describe. However instead of storing an actual product version, they should have a marker token, something like ***ALL_VERSIONS*** (sorry, I'm not near my copy of InstallShield right now). The name for this token isn't great, because what really happens is the current ProductVersion is substituted for it at build.
If you've already changed the token to an actual version, you can change it back with the "friendly" view by selecting a radio button referencing "my version" instead of the actual version. Or you can create a new project to see it, and copy it in. The token works in either the minimum or maximum field in all recent versions (but just in the maximum field in some older versions) of InstallShield.