Ich habe eine Situation, wo ich etwas Code in einer Client-Anwendung, die System.Web.Http.SelfHost.HttpSelfHostServer in einer Assembly, die zielt auf. Net4.0 als Folge die Abhängigkeit ist auf v4.0.0.0 von System.Web.Http.dllBroken Rückwärtskompatibilität in System.Web.Http
Ich habe auch einen anderen Code auf einem Server, der ein WebApi ist, targetting .net4.6.1. Diese Baugruppe hat eine Abhängigkeit von System.Web.Htpp.dll v5.2.3
Alles läuft gut.
Aber dann komme ich, um einen automatisierten Integrationstest (als Komponententest) zu schreiben, in dem der Prozess beide Teile des Systems instanziieren muss (ohne das Gerüst von IIS oder dergleichen). Die Unit-Test-Assembly ist notwendigerweise .net4.6.1 (da sie von den serverseitigen Assemblies abhängig ist). Dies bedeutet, dass der Verweis auf System.Web.Http in der Komponententestbaugruppe v5.2.3 in den Ordner "bin" führt.
Zur Laufzeit führt dies zu einem ReflectionTypeLoadException mit den LoaderException
"{"Inheritance security rules violated by type: 'System.Web.Http.SelfHost.HttpSelfHostConfiguration'. Derived types must either match the security accessibility of the base type or be less accessible.":"System.Web.Http.SelfHost.HttpSelfHostConfiguration"}"
in meinem app.config (für die Einheit Testanordnung) ich eine Laufzeit rediect habe:
<dependentAssembly>
<assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
</dependentAssembly>
die mein bedeutet. Die net4-Abhängigkeit ist gezwungen, die Version 5.2.3 von System.Web.Http zu verwenden.
Ohne diese Laufzeit umleiten der Client-Seite Baugruppen über eine fehlende Abhängigkeit beklagt (System.Web.Http v4.0.0.0), und wenn ich v4.0.0.0 von System.Web.Http im Verzeichnis ist (aber nicht v5.2.3), dann dem Serverseitige Baugruppen beschweren sich über die fehlende Abhängigkeit.
Gibt es eine Möglichkeit, um dieses Problem zu umgehen? Für mich sieht es aus wie System.Web.Http v5.2.3 ist nicht abwärtskompatibel.
Warum trennen Sie die Unit-Testprojekte nicht? –
Es gibt nur ein Einheitstestprojekt. Die Einheit (Integrationstest) instanziiert einen Client und den Server, fährt dann damit fort, einige Funktionen der einen oder anderen von diesen aufzurufen und behauptet, dass alles wie erwartet geschieht. Der Code für den Server und den Client (Produktionscode) befindet sich in zwei separaten Assemblys, die Unit testet in einem dritten, der auf beide verweist. Sorry, wenn das nicht klar war – MikeW
Warum instanziieren Sie den Server in seinem eigenen Prozess? Selbst wenn Sie es schaffen würden, es zu umgehen, wäre Ihr Integrationstest nicht länger repräsentativ für das, was tatsächlich passiert, da der reale Server und der reale Client anderen Code verwenden. Repräsentativ zu sein ist wahrscheinlich der wichtigste Teil eines Integrationstests. Offensichtlich ist das Ausführen von Eingabe-/Ausgabetests komplizierter, wenn Ihr Server in einem eigenen Prozess läuft, da Sie nicht direkt in sein Gehirn schauen können, aber dies ist wiederum ein Integrationstest. –