Laden Sie die vorherige Version von Specflow herunter .vsix

Question

Unser Team unterstützt die Automatisierungsbemühungen von Benutzern, die auf der neuesten Version von Specflow sind, sowie von Benutzern, die dies nicht tun. Es besteht also die Notwendigkeit, zwischen dem aktuellen .vsix für Specflow auf VS2017 und dem .vsix, der Specflow 2.1 erwartet, zu bouncen (momentan stehe ich fest, weil jede feature.cs-Wiederherstellung fehlschlägt, weil 2.2 nicht gefunden wird). Ich habe versucht, von https://github.com/techtalk/SpecFlow.VisualStudio/tree/release/v2017.1 ziehen, aber bekomme mehrere nicht aufgelöste Verweise auf Microsoft.VisualStudio.

Jeder Weg, einfach die .vsix zu ziehen, die mit SpecFlow 2.1 funktioniert?

Edit: Danke Andreas, die schnelle Antwort wird sehr geschätzt. Ich werde weitermachen und ein Problem auf GitHub öffnen, wenn Sie möchten, aber ich wollte nicht andeuten, dass es ein Problem mit der Erweiterung gibt. Es kann durchaus ein Missverständnis meinerseits sein - ich erwarte, dass die aktuelle Specflow VS Extension "SpecFlow 2.2" erwartet.

Wie Sie wissen, SpecFlow 2.2 verwendet NUnit 3.x, während SpecFlow 2.1 NUnit 2.x verwendet, die für Lösungen im Wesentlichen eine Bruch Änderung ist, dass obsolete Funktionen von NUnit 2.x. verwendet

Wenn ich also von einer Verzweigung, die SpecFlow 2.2 verwendet, zu einer anderen Verzweigung wechselt, die 2.1 verwendet (sogar versucht, AppData/Local/Temp zu löschen), wird der SpecFlowGenerator fehlschlagen, weil er nach SpecFlow 2.2 sucht, was wir nicht wollen wegen des NUnit-Problems im Zweig "Vorkonvertierung" verwenden.

Ich würde lieben, die Erweiterung nicht austauschen zu müssen, solange ich fortsetzen kann, Zweige zwischen einer zu wechseln, die SpecFlow 2.1 verwendet, und einer, die 2.2 verwendet. Die app.config für das Projekt hat eine Bindung Umleitung enthalten -

<dependentAssembly> <assemblyIdentity name="TechTalk.SpecFlow" publicKeyToken="0778194805d6db41" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-2.2.1.0" newVersion="2.1.0.0" /> </dependentAssembly>

Die Frage ist also, wie die up-to-date verwenden Erweiterung, auch wenn zwischen den Zweigen Prellen, die 2.1 und 2.2 verwenden. Danke noch einmal!

Answer 1

Die Visual Studio-Erweiterung unterstützt alle SpecFlow-Versionen von 1.9 bis 2.2.

Wenn Sie Probleme damit haben, öffnen Sie bitte ein Problem auf GitHub, damit wir den Grund zusammen finden können.

Aktualisierung:
SpecFlow hat keine direkte Referenz zu NUnit. Nicht mit 2.2 oder irgendetwas vorher. Es gibt ein NuGet-Paket SpecFlow.NUnit, das eine Paketabhängigkeit zu NUnit besitzt, aber dieses Paket hilft nur bei der Konfiguration von SpecFlow für NUnit. Sie benötigen dies jedoch nicht, wenn Sie die Konfiguration manuell durchführen (indem Sie den Komponententestanbieter in der app.config auf NUnit setzen).

Es könnte sein, dass, wenn Sie Zweige wechseln und Visual Studio nicht neu starten, dass wir immer noch einen Verweis auf die vorherigen SpecFlow-Assemblys haben und so ein Version-Hickup erstellt wird.

---

Volle Offenbarung: Ich bin einer der Betreuer von SpecFlow.

Answer 2

Falls jemand anderes mit diesem ringt, ist hier das Update, das für mich mit dieser bestimmten Sequenz von Ereignissen arbeitete

1) Sie einen Zweig haben, die SpecFlow 2,1

2) auf die neueste Upgrade verwendet VS SpecFlowExtension

3) Sie wechseln zu einem anderen Zweig, der SpecFlow 2.2 verwendet und die Funktion erfolgreich verwendet.cs erzeugt

4) Sie eine Anfrage von einem Benutzer erhalten Unterstützung benötigen auf 2,1, wechseln Sie in diesen Zweig, um eine Änderung zu einer Feature-Datei machen, und mit SpecFlow 2.2 nicht

5) auch nach dem Schließen gefunden knallte bekommen alle Instanzen von VS, Löschen von LocalAppData/Temp/VisualStudioTestExplorerExtensions, Starten von VS und Öffnen der Lösung, die die SpecFlow 2.1-Treiber verwendet und dann versucht, noch Ergebnisse in SpecFlow 2.2 nicht gefunden zu speichern, selbst mit einer verbindlichen Umleitung zu 2.1 Anscheinend etwas ist auf Festplatte zwischengespeichert (Neustarts haben nicht geholfen), die nicht sofort offensichtlich ist. Die Lösung sollte separate Klone haben - einen für den Zweig, der SpecFlow 2.1 referenzierte, und einen völlig separaten Klon für den Zweig, der SpecFlow 2.2 referenzierte.

Jetzt bekomme ich nicht mehr SpecFlow Generator Fehler - der Trick ist nicht getrennte Zweige zu verwenden, sondern separate Klone.