none
Conflit de références ? RRS feed

  • Question

  • Bonjour tout le monde,

    Je travaille sur quelques projets MVC sur une base MySql, le tout partagé via un contrôle de code source SVN dans une équipe de 3 développeurs.

    Jusque là les choses se passaient bien. Dernièrement une table a été ajoutée dans la base, et les choses se gâtent lorsque j'essaie de récupérer la table dans le modèle.

    Dans la liste d'erreurs je vois qu'un certain nombre d'entités ne sont pas mappées. Il paraît pourtant qu'il n'y a rien de neuf à part la table que je dois récupérer, historique d'une autre table qui commençait à prendre trop de volume. ça, c'est après avoir sélectionné dans le menu contextuel du modèle, "Mettre à jour le modèle à partir de la base de données".

    Une fois que je demande à générer l'application, on me dit que System.Data.Objects n'est pas reconnu, ce qui représente une soixantaine d'erreurs, autant que d'appels à des objets de ce module.

    Curieusement, il n'y a pas System.Data.Entity dans les références de l'application, et pourtant il n'y a que sur ma machine que ça pose problème, chez les collègues ça marche. Si j'ajoute cette référence, j'ai de plus nombreuses erreurs -ce qui me fait penser à un conflit avec une autre référence.

    J'avoue que je ne sais pas très bien par où prendre le problème, et apparemment les collègues non plus.

    Pour le moment, je les laisse faire les mises à jour de modèle, et je récupère le résultat via le contrôle de code source, mais ... ce n'est pas un compte.

    Le système est Windows 10, l'environnement de développement Visual Studio Community 2013 version 12.0.31101.00 Update 4, la base de données MySql (il faut que je vérifie la version).

    Hier, j'ai mis à jour le répertoire packages depuis le contrôle de code source, ce qui a solutionné une autre erreur, mais pas ce que je viens de décrire.

    jeudi 27 avril 2017 08:34

Réponses

  • Bon, ça marche.

    Alors après avoir pas mal tourné en rond, on a fini par remplacer la référence System.Data.Objects par System.Data.Entity.Core.Objects,

    et System.Data.DataClasses par System.Data.Entity.Core.Objects.DataClasses.

    Voilà qui rappelle le changement de chemin de SqlFunctions au passage à la version 6 d'EntityFramework.

    On en est à Entity Framework 6.1.3.

    C'est du sport, enfin quand dans l'équipe il y a quelqu'un qui sait se réceptionner à l'arrivée de la figure, on est sauvés.

    Il est vrai que quand on vient d'arriver et qu'on a comme instruction de ne pas faire de mises à jour de peur que ça génère des conflits, c'est un handicap.

    • Marqué comme réponse Gloops jeudi 27 avril 2017 15:39
    jeudi 27 avril 2017 15:39