web-dev-qa-db-fra.com

Fichiers en double dans le dossier DerivedData à l'aide du générateur CoreData

J'essaie de générer NSManagedModels à partir de mon modèle de données. La génération fonctionne mais après j'ai eu beaucoup d'erreurs:

erreur: nom de fichier "Station + CoreDataProperties.Swift" utilisé deux fois: '/Users/Me/MyApp/Models/CoreData/Station+CoreDataProperties.Swift' et '/ Users/Me/Library/Developer/Xcode/DerivedData/MyApp-gwacspwrsnabomertjnqfbuhjvwc/Build/Intermediates/MyApp.build/Debug-iphoneos/MyApp.build/DerivedSources/CoreDataGenerated/Model/Station + CoreDataProperties.Swift ': 0: remarque: les noms de fichiers sont utilisés pour distinguer les déclarations privées portant le même nom

J'essaye le dossier de construction propre et le répertoire de dérivéData supprimer. J'utilise Xcode 8 BETA c'est peut-être un bug?

42
Ludovic

J'obtiens ceci dans Xcode 8.1 Pour moi, les étapes suivantes ont résolu le problème. Veuillez noter que la commande est importante.

1) Créez une entité dans le modèle Core Data.

2) Dans la section des cours, effectuez les réglages comme sur l'image suivante.

Module: Nom du produit actuel

Codegen: manuel/aucun

3) Générez votre sous-classe NSManagedObject.

enter image description here

69
Vladimir Shutyuk

Ce message m'a beaucoup aidé à résoudre ce problème moi-même. Personnellement, je considère cela comme un bug Xcode. Bug ou pas, c'est une énorme situation de poulet et d'oeufs.

Je suis tombé dessus par:

  1. Création d'un nouveau projet à l'aide de Core Data
  2. Généré ma NSManagedObject sous-classe + extension (tandis que codegen: ClassDefinition)
  3. J'ai accidentellement enregistré les classes générées dans le dossier Wrong
  4. J'ai supprimé les fichiers générés
  5. Re-généré dans le dossier que je voulais
  6. ???? - Xcode used twice les erreurs

Comme d'autres l'ont posté, j'ai continué à nettoyer ma version (et clean build folder) mais cela n'a jamais résolu le problème de construction.

J'ai finalement compris si vous aviez initialement créé vos classes générées par NSManagedObject avec codegen: ClassDefinition, comme je l'ai fait sans le savoir, vous êtes enfermé pour le problème du poulet et des œufs.

J'ai ensuite supprimé les classes générées automatiquement en pensant J'ai dû régénérer, alors je l'ai fait. Une fois re-généré, j'obtiendrais le used twice erreur de build à nouveau. Je suis entré manuellement dans le ../DerivedSources/CoreDataGenerated/Model/.. et supprimé les doublons. Encore une fois, j'ai re-généré en pensant que je n'aurais qu'une seule copie (dans mon projet) mais je me trompais. Si codegen: ClassDefinition était initialement défini, alors Xcode continuera à créer le auto-generated classes + extensions et les mettre dans le dossier enterré ../DerivedSources/CoreDataGenerated/Model/... J'ai répété ce poulet et cet œuf plusieurs fois avant de continuer.

J'ai réalisé plus tard que vous devez en effet marquer codegen: Manual/None cependant, pour que les choses soient synchronisées, vous devez supprimer les fichiers générés automatiquement dans ../DerivedSources/CoreDataGenerated/Model/.. et dans votre projet si vous en avez encore.

Soyez prudent de réglage codegen: Manual/None, pour moi c'était un peu délicat parce que codegen: Manual/None ne serait pas coller. J'ai dû cliquer plusieurs fois entre les entités pour vérifier/tripler chaque entité a été définie sur codegen: Manual/None. Ensuite générer automatiquement les fichiers. À ce stade, votre seule copie des fichiers générés automatiquement doit se trouver dans votre projet et non dans ../DerivedSources/CoreDataGenerated/Model/...

Enfin, je pense que c'est un bug car si vous spécifiez codegen: Manual/None Je ne m'attends pas du tout à ce que Xcode génère automatiquement des fichiers, pourtant il le fait et les place dans votre projet. Plus déroutant si votre paramètre est codegen: ClassDefinition, qui diable sait que Xcode mettra les fichiers dans un répertoire enterré mais il est disponible pour une utilisation dans votre projet. Mon bœuf est que les fichiers générés automatiquement ne sont pas contrôlés par la source et si je change d'ordinateur, je dois savoir les générer automatiquement sur la nouvelle station.

J'espère que ceci aide quelqu'un d'autre!

À votre santé!

11
kev

Ce n'est en effet pas un bug. Comme @Morrowless le suggère, la définition de classe et l'extension des propriétés sont créées. Si cela n'est pas souhaité, sélectionnez Manuel/Aucun sous Codegen avant de générer le code. Si le code est déjà généré, supprimez-les simplement et essayez Editor->Create NSManagedObject Subclass... à nouveau dans le menu (après avoir réglé Manuel/Aucun).

Remarque, dans l'image ci-dessous, le nom de classe "Contact" est spécifique à mon projet. Vous verrez à la place le nom de votre entité.

enter image description here

8
oyalhi

Si vous avez généré des sous-classes CoreData avec codegen: ClassDefinition votre essentiellement foutu. La seule façon de le corriger est de:

  1. Supprimez vos sous-classes CoreData.
  2. Supprimez votre dossier de données dérivé.
  3. Nettoyez votre projet (CMD + K).
  4. Générez de nouvelles sous-classes CoreData, cette fois sélectionnez Codegen: Manual/None et Module: Current Product Module
5
100grams

Ce n'est pas un bug. Codegen génère ces fichiers dans le dossier DerivedData, vous n'avez donc pas besoin de les recréer dans votre projet, d'où l'erreur de compilation.

À partir des notes de version de Xcode 8.0:

Xcode génère automatiquement des classes ou des extensions de classe pour les entités et les propriétés dans un modèle de données Core Data. La génération automatique de code est activée et désactivée entité par entité, et est activée pour toutes les entités dans les nouveaux modèles qui utilisent le format de fichier Xcode 8. Cette fonctionnalité est disponible pour tout modèle de données qui a été mis à niveau au format Xcode 8. Vous spécifiez si Xcode génère Swift ou code Objective-C pour un modèle de données à l'aide de l'inspecteur de fichiers du modèle de données.

Lorsque la génération automatique de code est activée pour une entité, Xcode crée une classe ou une extension de classe pour l'entité comme spécifié dans l'inspecteur de l'entité: le nom de classe spécifié est utilisé et les sources sont placées dans les données dérivées du projet. Pour les deux Swift et Objective-C, ces classes sont directement utilisables à partir du code du projet. Pour Objective-C, un fichier d'en-tête supplémentaire est créé pour toutes les entités générées dans votre modèle. Le nom du fichier d'en-tête est conforme à la convention de dénomination "DataModelName + CoreDataModel.h".

Cependant, si vous avez sélectionné Catégorie/Extension dans le menu déroulant codegen dans l'inspecteur de modèle de données (parce que vous voulez ajouter de la logique à votre modèle): codegen générera à tort à la fois la définition de classe et extension des propriétés.

La solution consiste à supprimer simplement l'extension des propriétés (ClassName + CoreDataProperties.Swift). Votre projet devrait maintenant être compilé.

3
Morrowless

Après avoir suivi les conseils de oyalhi et Vladimir Shutyuk, (suppression des fichiers NSManagedObject, modification de l'entité codegen en Manual/None), J'ai dû redémarrer Xcode pour lui permettre de réindexer avant de pouvoir recréer les fichiers NSManagedObject et obtenir une compilation réussie.

0
Jacob Davis

Par souci d'exhaustivité ..:

Je viens de rencontrer la même erreur, mais aucune des solutions proposées n'a fonctionné. Ce qui m'a intrigué, c'est que même le passage de la génération automatisée de code au manuel pour l'entité problématique (comme je le pensais) n'a rien fait.

Enfin, j'ai compris que j'avais plusieurs entités avec le même nom, mais ils partageaient tous le même nom de classe. La raison en est que j'ai copié et collé plusieurs fois une entité pour me faire économiser du travail, car elles ont également quelques attributs en commun.

Il s'avère que XCode renomme les doublons en ajoutant 1, 2, ... au nom de l'entité, mais laisse le nom de la classe comme auparavant. Et puisque maintenant le nom d'entité et le nom de classe ne sont "pas liés", renommer l'entité ne changera pas non plus le nom de classe.

J'espère que cela aide quelqu'un - j'ai également déposé un rapport de bogue pour cela.

0
Toastor