Fehler beim Konfigurieren des WCF-Clients für Komponententest-Ausführungsfehler mit basicHttpsBinding konnte nicht gefunden werden

Question

Versuch, einen Komponententest einzurichten, der einen WCF-Dienst aufruft. Wird unter NET4.6 ausgeführt. Der Client verwendet die basicHttpsBinding.

Haben die system.serviceModel Config-Abschnitt über (die includs die basicHttpsBinding Tags der Komponententest der app.config kopiert.

Wenn ich den Test (xUnit) laufen bekomme ich folgende Fehlermeldung, wenn der Client-Konstruktor ausgeführt wird.

Exception thrown: 'System.Configuration.ConfigurationErrorsException' in System.Configuration.dll 

Additional information: Configuration binding extension 'system.serviceModel/bindings/basicHttpsBinding' could not be found. 
Verify that this binding extension is properly registered in system.serviceModel/extensions/bindingExtensions and that it is spelled correctly. 

Eine andere Antwort vorgeschlagen Zugabe der folgenden (um sicherzustellen, mindestens NET4.5 ist in executd für den Test.

<startup> 
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6"/> 
</startup> 

Ein y Hinweise?

Edit: Dies ist nur unter Resharper 10 Test Runer fehlgeschlagen. Wenn ich CTRL-R, T verwende und gegen den InBuild-Runner laufe, funktioniert es gut.

Ich habe ein paar Optionen in ReSharper versucht,

• Kraft CLR bis 4,5,
• deaktivieren/Schattenkopie aktivieren, und
• läuft in eigener Appdomain.

keiner änderte das Ergebnis.

Answer 1

Ich sehe keine offensichtlichen Gründe dafür zu scheitern - das Xunit-Plugin (jetzt ein Teil von ReSharper selbst ab Version 2016.1) funktioniert mit app.config-Dateien. Wenn Sie könnten log an issue, und idealerweise fügen Sie die Lösung (Sie können dies privat, so nur JetBrains Mitarbeiter können sehen, oder wir können NDA tun, wenn erforderlich) Ich kann einen Blick für Sie.

Answer 2

Ich vermute, es ist ähnlich, warum meine ähnliche WCF bestellt Tests fehlschlagen unter den Microsoft-Tools ... Ausführen eines einzelnen Tests funktioniert, weil es direkt von \ bin \ Debug ausgeführt wird ... aber mehrere Einheiten als eine Reihenfolge laufen Der Test schlägt fehl, da Microsoft eine ausführbare Sandbox mit dem Namen QTAgentXXXXX.exe verwendet.

Um herauszufinden, welche ausführbare Ihre Tests ausgeführt wird, einfach Punkt früh brechen und werfen den AppDomain.CurrentDomain.SetupInformation heraus (man beachte die TargetFrameworkName und Application Eigenschaften speziell) und auch einen Aufruf an System.Diagnostics.Process auskippen .GetCurrentProcess(). MainModule.FileVersionInfo, um den ausführbaren Pfad abzurufen. Laden Sie diese ausführbare Datei in ILSpy, und Sie können das Framework auschecken, für das es kompiliert wurde.

Die Microsoft QTAgent-Anwendungen befinden sich unter C: \ Programme (x86) \ Microsoft Visual Studio \ 2017 \ Professional \ Common7 \ IDE \ und es scheint verschiedene Varianten zu geben, je nachdem, welches .NET Framework verwendet wird oder welche seltsame Erkennung Schema, das sie verwenden, um eins zu wählen .... UNERLÄSSLICH, beobachte ich, dass die neueste QTAgent32_40.exe unter dem alten Framework 4.0 kompiliert wird und bevor Sie fragen, ja gibt es eine QTAgent32_40.exe.config und nein, Hinzufügen der unterstütztenRuntime-Einstellung mit sku = 4.6 ermutigt es nicht, anders zu arbeiten (Vielleicht würden Sie verschiedene Ergebnisse sehen, die Ihre Resharper 10 Test Runner config aber tweeten). Und ich habe versucht, die AssemblyBindingApps zu Attribut-Trick in mehreren Threads erwähnt auch vergebens. Ich habe versucht, ILSpy verwenden, um meine eigene Version von QTAgent gegen 4.6.2 neu zu kompilieren, aber eine Menge der Microsoft.VisualStudio.blah.blah Assemblys, auf die verwiesen wird, haben viele interne Klassen, gegen die Sie nicht erstellen können.Diese Assemblys haben dieses beschissene Assembly-Attribut namens InternalsVisibleTo, das auflistet, welche externen Bibliotheken und ausführbaren Dateien Zugriff auf diese internen Klassen haben dürfen. Die ausführbaren Dateien von QTAgent gehören zu diesen Attributen, weshalb sie sie aus diesen Assemblys verwenden können. Es wäre also ein sehr langes und tiefes Kaninchenloch, um zu sehen, ob man ALLE diese zusammenhängenden Assemblies im Wesentlichen dekompilieren und das Unit-Testing-Framework neu kompilieren könnte. Das ist viel Forschung für solch einen kleinen Gewinn. Ich sage Schrauben Microsoft Unit Testing Framework. Es ist auch mit anderen Themen behaftet. Mein Kollege schlägt vor, NUnit zu verwenden. Ich denke, ich kann es versuchen.