I've recently downloaded iOS 8 to make sure that my existing app works properly with it, but I'm getting a warning in the debugger on launch:
"CoreData: warning: Unable to load class named 'CDAccount' for entity 'CDAccount'.
Class not found, using default NSManagedObject instead."
After some research, it seems like people have had similar issues when using Core Data in Swift, but all my code is in Objective-C (and the data model hasn't changed for at least 6 months).
Any advice is much appreciated, I'm really nervous that my app isn't going to function properly once people start upgrading to iOS 8!
I had the exact same problem in Objective-C and Xcode 6. For some reason, Xcode had removed my 'CustomNSManagedObject'.m classes from my Compile Sources.
Go to your project target -> Build Phases -> Compile Sources and use the + button to add CDAccount.m
If you are using Mogenerator to create a _CDAccount.m file, add that to your Compile Sources as well.
Remove the "dot" in Configurations "Default" on .xcdatamodeld:
to:
Rebuild the application.
My issue was also similar, but the reason was that module of entity was not set.
It seems to be an Xcode bug/issue. I'm using Xcode 6.3.1
click on your core data entity (xxx.xcdatamodeld), then select the entity, and in the attributes inspector you'll see that the entity's class name is set to:
PRODUCT_MODULE_NAME.xxx, where 'xxx' is your entity's name.
solution : You have to replace PRODUCT_MODULE_NAME with your app's name.
If in doubt about your app's name, check under 'build settings', filter on 'product_module_name', and you'll find your app name under 'packaging'
in some cases (my case) the data model file (swift or objective-c) is also removed by Xcode from the project - it's still on in disk though, but you need to add it again. So in this case take the 'CDAccount.m' file & drop it in your project again (or use another of the several ways to do this)
My issue was similar, but the listed solutions didn't work because my CD Classes were stored in a framework. The solution was to change the Class Name Representation to "frameworkName.className". However, the xcdatamodeld didn't allow me to change it to that, so I had to "Show Contents" on the file, open the "contents" file in XCode, and make the changes myself.
Related
I just upgraded to Xcode 10, and I suddenly face this error when I try to build, any ideas how to fix it? I tried cleaning derived data, but without any luck.
If you use CocoaPods, click Xcode menu file -> Workspace Settings , And click Build system choice Legacy Build System
If you not use CocoaPods, same of top , select Project Settings
If your app is generating the error related to the multiple .app files just like mentioned above in question then removing the .plist files from "Copy bundle Resources" WILL NOT WORK.
If the error is related to .app file then follow the following steps.
Select the Target.
Go to Build Phases tab.
Remove the items listed in Output Files
Compile the code if it compiles successfully then not follow the next steps.
If code does not compile successfully and Xcode may give you an error related to "Library not found". Then add the missing library in General Tab in Linked Frameworks and Libraries that Xcode mentioned in the error.
Keep adding these libraries (that Xcode ask through compile errors) in Linked Frameworks and Libraries until the code compiles successfully.
Hope this helps.
You can try to change the build system to Legacy,
File > Workspace Settings > Build System > Legacy Build System.
I also faced this issue in xcode 10 but it was because of adding the same framework in main project + other extensions (watchkit or siri extension etc).
I added ObjectMapper in podfile for my main project + for my extensions. When I compiled it gave me an error that multiple command produce and also shows me which framework is causing this issue. Now its working fine for me as I've removed it from my extensions I wasn't using it in my extensions.
Don't know about your issue may be you can check your podfile.
If this is CoreData related. The issue is that you are trying to generate the NSManagedObject subclass but you need to set the 'CodeGen' option to Manual/None. This option is defaulted to Class definition and this would regenerate the code thus creating this issue.
i encountered this issue as well while working with CoreData.
in my .xcdatamodeld file, it came down to the fact that, during the creation of my various Entities, i had copy and pasted one multiple times (thinking i was saving time because various properties were similar enough that i thought this was a good idea).
the resulting Build error Xcode 10 - 'Multiple commands produce' occurred because i forgot to check and make sure the new Entities were set to their own unique corresponding class to match the new Entity in the Data Model Inspector pane.
unfortunately, it took me two days to figure out the original Entity's Class Name was still in place.
so lesson: careful when you copy/paste/duplicate Entities in CoreData.
(... i guess :0} )
some time saver. oops! hope this helps someone.
I had this same issue with Core Data entity class. I had forgotten to select Codegen Manual / None because I do not allow mine to be autogenerated. So I had a class in place and also it was trying to generate one.
I use Core Data's automatically generated classes. My project has 3 targets in addition to the test target. For each target, the Core Data classes are properly generated which I verified by inspecting the Derived Data folder. However, classes are not generated for the Test Target despite it being ticked in the Core Data model file. This causes an "undeclared identifier" and "Use of undeclared type" errors when I try to reference one of the Core Data classes in the test target. How can I fix this please?
You do not need extra classes generated for each test target - your import process should import everything, and no files should need to be added to other targets.
Declaring #testable import MyProject should take care of everything.
In Objective C
#import MyProject;
In Xcode 9.1 try adding your .xcdatamodel to a test target too. All auto-generated class will be imported too.
This was due to a bug currently in Xcode (8.3.1) where auto-generated NSManagedObject classes (codegen set to "Class Definition") cannot be found on the global path despite the project compiling successfully. The only way around it is to which to manual generation of the NSManagedObject classes by setting codegen for each entity to "Manual/None".
Select the test target, navigate to Build Settings and search for the setting "Header Search Paths"
Then add the following entry:
$CONFIGURATION_TEMP_DIR/{Project Target Name}.build/DerivedSources/CoreDataGenerated/{Project Name}
Replace the curly brackets with your main target name (not the test target), and your project name, respectively.
Xcode should now be able to find the generated source files when building the test target.
I noticed in Xcode 9.1 that the Data Model Inspector has a drop down for the Module to use. Selecting 'Current Product Module' with the Class Definition Codegen, and including the model in your Test target, compiles without errors. From what I can tell, the problem pieSquared noticed doesn't appear to be an issue, but my tests aren't exhaustive yet. It may be something to try, nonetheless.
I have wrestled with this issue ever since Xcode 9.4 or thereabouts. The error was always the same:
Testing cancelled because build failed.
'MyEntity+CoreDataProperties.h' file not found
I've filed a bug report (45802900), but I got Apple Support involved as well and together we finally found the solution. . Actually, there are two solutions.
Solution 1: Set the Header Search Paths build setting of the Test Target
The most elegant solution, to my mind, is to set the Header Search Paths build setting of the test target. Ziqiao Chen of Technical Support figured out the correct path, while I provided the build variables. For projects with only one data model, the name of which is the same as the project (which is the default), the Header Search Path may be:
$(TARGET_TEMP_DIR)/../$(PROJECT_NAME).build/DerivedSources/CoreDataGenerated/$(PROJECT_NAME)
Make sure the path is set to 'non-recursive'.
For projects with multiple data models, a non-recursive path should be added to Header Search Paths for each data model:
$(TARGET_TEMP_DIR)/../$(PROJECT_NAME).build/DerivedSources/CoreDataGenerated/dataModel1
$(TARGET_TEMP_DIR)/../$(PROJECT_NAME).build/DerivedSources/CoreDataGenerated/data_model_B
Solution 2: Add the data model to the Test Target
Another solution, which Ziqiao Chen came up with and which I've also read on here on SO, is to add the data model to the test target. In my experience, however, this only works with a single data model. As Ziqiao Chen pointed out, Xcode should generated the exact same files for the test target as for the main target.
My experience is that in more complicated projects (multiple targets, multiple data models) all kind of linker errors may occur, from complaints about duplicates to the "testing cancelled" error described above. For simple projects, however, it's a quick and simple solution.
For Xcode 11.5:
if Codegen property is class Definition, and if you are not getting a suggestion for the entity you created in xcdatamodel. Try to quit Xcode and reopen your project again. It works for me. This answer is only if you are not getting suggestion but if your file doesn't get generated try any above answer.
I have been working on a project for a while, and recently upgraded to Xcode 8 and Swift 3.0 and iOS 10. But since I did that I have not been able to compile.
I am getting an error for each of my entities:
:0: error: no such file or directory: ''/Users/mark/Library/Developer/Xcode/DerivedData/.../.Account+CoreDataProperties.swift'
Each case has a . (dot) prefix before the entity name: .Account+CoreDataProperties.swift.
I changed the Code Gen from "Category / Extension" to Manual / None, I do a clean and clean directory, an delete the DerivedData directory. Interestingly, when I look in the appropriate directory there is an actual file there, just without the dot prefix.
This is very confusing. Can anyone explain it? I need to solve this to be able to continue with core data.
TIA
Mark
The dot files are generated by Xcode8. See WWDC2016. I ran into the same issue after having to delete derived data due to another issue.
Two possible fixes:
1) The recommended, modern approach
Delete all generated NSManagedObject subclasses from your project, if exists.
Set Codegento Class Definition in your .xcdatamodel for all entities
Make sure Module is empty ("Global Namespace" in light gray) (workaround an Apple bug, see #Chris Hansons answer)
Clean project
Clean DerivedData folder
Note: Even you do not see the generated files in your project, Xcode has a reference to it, so you are able to write extensions and such. For instance:
extension MyEntity {
func doSomething() {
//
}
}
Also, you can command+click to the generated file within Xcode.
2) A rather paranoid but bullet-prove approach, ignoring the new Xcode features
Delete all generated NSManagedObject subclasses from your project, if exists.
Set Codegento Manual/None in your .xcdatamodel for all entities
Clean project
Clean DerivedData folder
Restart Xcode
Manually generate NSManagedObject subclasses (in "Editor" menu)
Make sure those files are added to your project
build
If your problem persists, repeat:
Clean project
Clean DerivedData folder
Restart Xcode
This occurs when the module of an entity is set to "Current Product Module" (e.g. to be within the Swift namespace, rather than the global Objective-C namespace).
The workaround for this is to remove the customization of the "Module" field of the entity, so it has the default value of "Global namespace" (in light gray text).
I changed the Code Gen from "Category / Extension"
Change Codegen to Class Definition.
Now get rid of whatever you were doing in code to turn your entities into pseudo-classes. Your entities are now real classes!
You will now be able to pare your code down considerably. You no longer have to cast down to specify an entity type as a class. When you fetch Person objects, your fetch results is a generic parameterized on Person, and so each fetched object is a Person. Similarly, to make a new Person, just call Person(context:) and configure, and save the store. The word "entity" will probably cease to exist anywhere in your code.
I have solved it. I was about to recontruct the whole app from scratch to avoid whatever the issue was, and I noticed that the entity class files were in the directory, even though they weren't visible in Xcode. So I deleted those files and that cleared that hurdle.
I'm very happy now.
From the beginning of my project, I use a custom framework, let's call it "custom.framework". But there was a bug in this framework and now I want to use another version of the "custom.framework".
At first, I simply removed the "custom.framework" file from my project and added the new one. But nothing changed, the bug was still there.
After multiple tries and hours, I understood that Xcode add the old version in memory and used this one instead of the new version. I know it because in the new version I added a method and when I cmd+click the class I've add the method into, it's not there and the file's path is unavailable.
Searching through the web, I tried to change some version parameters to my framework projects: Compatibility version, Curent Library version, Framework version. But this didn't change anything to Xcode which keeps using the old version.
I also tried to make the framework's project as a sub-project and add resulting framework as a dependency to my target. It worked well, but as the framework's project is on a separated remote git repository, I don't think this is an acceptable solution.
So my last try was to build a "custom2.framework", to force Xcode to use the real file and not some cached version. But again, it doesn't work and when building I get errors telling me that all my classes in custom2.framework are duplicated symbols of its cached version of "custom.framework".
So my question is simple: how can I finally tell Xcode to deleted its cached old version and let me use the file I gave him? I already tried to delete my project's derivedData but it seems cached frameworks aren't there.... I'm so desperate :(
Edit: Here are 2 screenshots to illustrate the issue
First screenshot is the path as shown by Xcode when I opened the file from the .framework object in the project navigator.
Second screenshot is the path as shown by Xcode when I opened the file from a cmd+click to a "DCEquipmentManager" in code.
As you can see, the framework linked with the code is not the framework in the project.
it seems problem with binding in new framework, your project still linked with old framework files.
try to remove all files and folder related to your "custom.framework and also remove path for that framework from project setting--> build setting --> search Path
Then after Drag and Drop Your "custom.framework" files in project.
it works for me.hope it resolve your problem.
Please try to clear derrived data:
Window -> Organizer
at the right side you will see projects list. Find your project and tap on it. I the top part of window you will see button delete in front of Derrived data, tap on it.
I guess it will solve your problem.
It might sound silly, but sometimes restarting XCode or the whole machine fix things.
Did you remove the old framework from Build Phases --> Link Binary With Libraries?
Use Clean Build Folder: option-shift-command-K, or select it from the Product menu when holding down the alt/option key.
First lets say something upfront. The build stage is a(are) command line tool(s) that is managed by Xcode according to your Build Settings.
So when Xcode doesn't find your Framework - the Build System will usually also not find it. This forces you to act but may end up in confused Xcode to catch an older reference.
Yes it may happen that the Header Xcode is pointing to is correct but the build system still uses an old copy somewhere. An outdated copy can dangle around literally anywhere depending on the steps you took before.
It (Xcode) assumes where it is located but the Build System still uses another version or the Search Paths just pointing in the wrong Locations even if they are visible to you and even your Framework icons are visible in the lists. So when you erase the last build you actually only force Xcode to rebuild from the known arguments, the settings stay the same, the lists stay the same. Even restarting Xcode does not change anything, the problem persists.
Ergo: Compiler Instructions, Xcode settings and Build System settings don't match what the code tells with #import <NAME/Name.h>
So you will check at least those 6 stages again:
Is your Framework Header File published in your Framework project?
are Build Settings really pointing to the right Framework Search Paths or System Framework Search Paths?
Is your Framework in linking list?
Is your Framework in Embed Framework list?
Does your framework appear in the Framework Group Folder in Workspace/Project Browser? (usually the very last Group Folder in the Browser below all your other files)
Is my Folder Structure correct?
At least 1 to 4 must be right otherwise it will fail.
Here a random list of common causes
Framework is located outside your Source Paths structure
Structure got changed after you added it to the project
You use Workspace's where Framework development and Final Application can appear side by side but you assume Xcode uses this to change its Search Paths
The contained build settings are misleading from former drag and drop operations, ending up tricking Xcode in the "wrong" corner. In this case recreating a project is just one of the possible ways to fix it but not the solution.
Also dragging a Framework into your Project > General or separated in Build Phases > Link Binary list or Embed Framework lists does not make Xcode aware of the wrong Build Settings.
The Linking works, embedding works, but compiling does not. The Header information is still missing.
The solution must be to correct your Build Settings.
As mentioned above Build System and Xcode are two different things. In particular only setting the right Framework Search Paths will solve those issues, even if you managed to kick your derived data manually.
Erasing Derived data?
Derived data is the place where precompiler collects data to compile. So it can be seen as expression of what all the settings are told to do. Erasing it does of course not change the settings but may fix inconsistencies related to former Build Settings. It would erase the derived data and rebuild from the Build System Settings you gave.
Correcting Linking?
Also Linking is not the same as making Xcode aware of the desired Headers. Linking is for your final Product to know where Symbols are to call on them at runtime, it does not change Framework Search Paths and System Framework Search Paths, they stay the same as given.
But it is not wrong to start fixing first with
Product > Clean Build Folder, it forces your build to parse all and compile all again on the next Build.
When the troubles come up because of folder structure in parallel or Frameworks are simply placed outside the Source Directory then you must point to them directly or relative.
Most likely you should place one extra entry in your Framework Search Paths like $(SRCROOT)/../Yourframeworksource/build/Debug. expression to point to relative higher folder structure.
Needless to say that a Release Build likely needs another entry ending in "/Release".Hint: Well you can have different Search Paths for different Compile Schemes..
This works particular good after you cleaned Linking List, Embed Frameworks List and then also check the very last Group Folder "Frameworks" for double entries to drag and drop a fresh Framework reference in there.
How to know if leading /../ will fix it?
Click on the dropped Framework Icon inside the workspace Framework Group Folder (lower most) while your Project is the active selected to work on, now watch for the relative Path information on the very upper right side of Xcode, if there is some /../ you know you need it as well.
Sorting of Framework Search Paths
play a role of course, just the same as #import/#include rule sorting matters.
Remember the first found, first wins rule because often we use #import that works different then #include but ignores second attempts to declare. This leads to once wrongfully declared headers to hide corrected declarations later on in parsing that share the same filename or define rules
#ifndef xyz
#define xyz
// all your code here.
// a second read attempt would be ignored
// a second read is hidden also when you use #include then.
#endif
So you can sort those entries either by code and/or in the build settings if needed because of course it matters what is declared before other declarations depend on it.
I have previously built a Keyboard extension project that has components of both Swift and Objective C. I'd like to built a new Keyboard app based on my previous app, with the simple goal of changing the name, keyboard UI and some keyboard mechanics.
I followed the guidelines here on duplicating and renaming an XCode Project. I even managed to get the project to compile after changing the Bundle IDs (for both the container app and the underlying keyboard). However, because of the name of the Targets have now changed, I am get the error that the following files:
#import "NewNameContainerApp-Swift.h"
#import "NewNameContainerApp-Bridging-Header.h"
cannot be found (these errors persist despite me manually changing OldNameContainerApp-Bridging-Header.h to NewNameContainerApp-Bridging-Header.h. It seems that the project has not regenerated a new set of bridging header and -Swift.h files matching the names of my new target.
My question is - is there a way to force XCode to regenerate a new set of these files? And if not, where do I find OldNameContainerApp-Swift.h so I can manually change it to NewNameContainerApp-Swift.h?
Thanks!
Check in your applications Define-Module in the build section. Update it to your latest project name. To find it easily just search for Defines-Module and see if it needs updating. If it is updated try cleaning your project or deleting your Derived Data
I have found no way to force Xcode to regenerate these files. Removing them just causes builds to fail. The only reliable method is to do a clean build, or removed DerivedData and rebuild (effectively the same solution).
When renaming an Objective-C/Swift mixed app, the following additional changes have to be performed for a successful build.
The Swift to Objective-C header file depends on the module name:
<ModuleName>-Swift.h
So if the Module name changes, you need to change the import in your code. In build settings search for Product Module Name to find the module name that is being used.
The Objective-C to Swift bridging header name depends on the build setting Objective-C Bridging Header. Check the Xcode target build settings and modify to match your new name.