2017-02-14 2 views
4

J'ai un projet de test d'unité de base de données de VS 2015. Je suis en train de tester VS 2017 RC.Résolution de conflit d'assemblage pour l'assembly Microsoft.Data.Tools.Schema.Sql.UnitTesting

Il existe un conflit d'assembly avec l'assembly Microsoft.Data.Tools.Schema.Sql.UnitTesting que je ne suis pas sûr de résoudre. Le GAC a la version 15.0 de cet assembly. Dans le cadre de VS 2017 SSDT, la version 15.1 est disponible, mais pas dans le GAC.

J'ai essayé la redirection d'assembly dans app.config, mais cela n'a pas fait de différence.

J'ai essayé de parcourir spécifiquement le dossier C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB et de sélectionner l'ensemble en tant que référence. Cependant, il est revenu à l'assembly GAC. Il a continué à le faire même si j'ai défini Version spécifique = True dans les propriétés du projet.

J'ai déjà supprimé l'ancien dossier avec SSDT de la propriété de projet Repères de référence et l'ai pointé vers l'emplacement 2017.

J'ai rencontré un problème similaire avec l'assembly Microsoft.Data.Tools.Components, mais il a été résolu en spécifiant Specific Version = False (assez curieusement ...) dans les propriétés du projet.

Si je supprime la référence du projet, le projet génère mais signale que la version 15.0 de l'assembly est introuvable. Dans ce cas, les tests courent et passent même. Cela ne dure que tant que la solution est ouverte. Une fois que je l'ai fermé et rouvert, les références "mauvaises" réapparaissent dans la liste des références.

Screen shot of References list of database project after loading

EDIT: J'ai couru asmspy et il détecte certains conflits entre 2.0 et 4.0 versions d'ensembles de système, y compris mscorlib et System.Data. Les versions 2.0 sont toutes référencées par Microsoft.VisualStudio.QualityTools.UnitTestFramework version 10.0. J'ai mis à jour ces références à 10.1 mais cette version fait toujours référence à la version 2.0 de ces assemblys. Je ne sais pas si cela est lié/pertinent.

Répondre

0

Il s'avère que la cause du problème d'assemblage était liée à la modification de la version du framework .NET Target en version 4.6.1 au lieu de 4.5.2.