2017-02-14 8 views
4

Ich habe ein Datenbank-Unit-Test-Projekt von VS 2015. Ich teste jetzt VS 2017 RC.Assembly Konfliktlösung für Microsoft.Data.Tools.Schema.Sql.UnitTesting Assembly

Es gibt einen Assembly-Konflikt mit der Microsoft.Data.Tools.Schema.Sql.UnitTesting Assembly, von der ich nicht sicher bin, wie sie gelöst werden soll. Der GAC hat die Version 15.0 dieser Baugruppe. Im Rahmen der VS 2017 SSDT ist Version 15.1 verfügbar, nicht jedoch im GAC.

Ich habe Assembly-Umleitung in app.config versucht, aber das hat keinen Unterschied gemacht.

Ich habe versucht, gezielt zum C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB Ordner zu navigieren und die Baugruppe dort als Referenz auszuwählen. Es kehrte jedoch zu der GAC-Assembly zurück. Es machte das auch dann, wenn ich in den Projekteigenschaften die Einstellung Spezifische Version = Wahr anwendete.

Ich habe den alten Ordner mit SSDT bereits aus der Projekteigenschaft "Reference Paths" entfernt und auf 2017 positioniert.

Ich hatte ein ähnliches Problem mit der Microsoft.Data.Tools.Components Assembly, aber es wurde gelöst, indem Spezifische Version = False (seltsam genug ...) in den Projekteigenschaften angegeben.

Wenn ich die Referenz aus dem Projekt entfernen, wird das Projekt erstellt, aber es wird gewarnt, dass Version 15.0 der Assembly nicht gefunden werden kann. In diesem Fall laufen und laufen die Tests sogar. Das dauert nur solange die Lösung offen ist. Sobald ich es schließe und wieder öffne, erscheinen "schlechte" Referenzen wieder in der Liste der Referenzen.

Screen shot of References list of database project after loading

EDIT: Ich habe asmspy laufen und es erkennt einige Konflikte zwischen 2,0 und 4,0 Versionen von Systembaugruppen, einschließlich mscorlib und System.Data. Die 2.0-Versionen sind alle durch Microsoft.VisualStudio.QualityTools.UnitTestFramework Version 10.0 referenziert. Ich habe diese Verweise auf 10.1 aktualisiert, aber diese Version verweist immer noch auf Version 2.0 dieser Assemblys. Ich weiß nicht, ob das relevant/relevant ist.

Antwort

0

Es stellt sich heraus, dass die Ursache des Assembly-Problems damit zusammenhängt, dass die .NET Framework-Zielversion in 4.6.1 statt in Version 4.5.2 geändert wurde.