CSLAs WCF Verwendung beim Ausführen von XUnit Tests in vs Test Explorer verursacht eine Identitätswechsel Ausnahme

Question

Wir verwenden XUnit 2.1.0 von NuGet mit den zugehörigen Läufern, Konsole und Visual Studio wie dokumentiert here unter der Überschrift "Tests mit Visual Studio laufen" und Bezug auf Inhalte.

Ich bin auch mit Visual Studio 2015 Enterprise Update 2. Das einzige, was veraltet vernünftig ist, ist CSLA, sind wir auf 4.0.1 (glaube ich 5 Jahre alt?)

Wenn wir laufen Bei Tests, bei denen ein DataPortal-Abruf erforderlich ist, wird der Test abgebrochen, sobald der DataPortal-Abrufversuch an den Server gesendet wird. WCF löst eine "System.ServiceModel.FaultException" mit der Meldung "Ungültiges Token für Identitätswechsel aus - es kann nicht dupliziert werden." Es ist wichtig zu beachten, dass keiner der Tests versucht, sich als ein anderer Benutzer auszugeben. Das Umfallen geschieht in jedem Test, der versucht, CSLA für einen DataPortal-Aufruf zu verwenden. Wir sind vor kurzem von xunit 1.x auf 2.x über nugget umgestiegen. Früher haben wir xunit vom xunit-Runner ausgeführt, als wir unsere Tests lokal getestet haben, aber das ist nun veraltet. Die Tests liefen absolut gut sowohl mit dem Gui als auch mit dem Console Runner für xunit 1.x. Jetzt müssen wir den Visual Studio Runner mit xunit 2.x verwenden, wir bekommen diese verrückte Ausnahme.

bearbeiten: Wenn Sie Xunit 2.x Konsole Runner von außerhalb des Visual Studio ausführen, sind die Tests auch gut auf 2.x, es ist die visuelle Studio-Seite der Dinge, die nicht funktioniert.

-Stack-Trace:

Server stack trace: 
    at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter) 
    at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) 
    at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) 
    at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) 
    at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) 

Exception rethrown at [0]: 
    at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) 
    at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) 
    at Csla.Server.Hosts.IWcfPortal.Fetch(FetchRequest request) 
    at Csla.DataPortalClient.WcfProxy.Fetch(Type objectType, Object criteria, DataPortalContext context) in D:\Dev\Insight\Trunk\Source\Lib\CSLA .NET\4.0\Source\Csla\DataPortalClient\WcfProxy.cs:line 162 
    at Csla.DataPortal.Fetch(Type objectType, Object criteria) in D:\Dev\Insight\Trunk\Source\Lib\CSLA .NET\4.0\Source\Csla\DataPortal.cs:line 245 
    at Csla.DataPortal.Fetch[T](Object criteria) in D:\Dev\Insight\Trunk\Source\Lib\CSLA .NET\4.0\Source\Csla\DataPortal.cs:line 170 

Auch das funktioniert gut, wenn wir die Tests von einem anderen Test-Runner, entweder die alte xunit Testläufer oder CruiseControl.Net zum Beispiel (Wir verwenden CC.Net für kontinuierliche Integration laufen und das führt die Tests in Ordnung)

Answer 1

Ich denke, das ist eher ein Problem mit der Art, wie Visual Studio Test Runner den aktuellen Benutzerprinzipal einrichtet. Die meisten anderen Test-Runner scheinen ein leeres GenericPrincipal zu verwenden, während das VS-System den aktuellen Principal auf eine imitierte Version der aktuellen Windows-Identität zu setzen scheint. Dies bedeutet, dass Sie den Fehler erhalten, den Sie sehen, wenn CSLA.NET versucht, sie erneut zu imitieren.

Das Thema wird ausführlich in dieser Blog-Post in Zusammenhang mit NUnit diskutiert: http://www.ienumerable.it/2015/03/21/Setting-up-good-fixture.html

Eine relativ einfache Möglichkeit, dies mit xUnit (aus dem Blog oben angepasst) zu lösen, ist eine BeforeAfterTestAttribute einzurichten es ein zu setzen GenericPrincipal vor dem Test und anschließend den ursprünglichen Principal wiederherstellen. Dies garantiert, dass es unabhängig vom verwendeten Test Runner mit dem gleichen Prinzip läuft.

public class RequiresGenericPrincipalAttribute : BeforeAfterTestAttribute 
{ 
    private IPrincipal _originalPrincipal; 
    public override void Before(MethodInfo methodUnderTest) 
    { 
     _originalPrincipal = System.Threading.Thread.CurrentPrincipal; 
     System.Threading.Thread.CurrentPrincipal = new GenericPrincipal(new GenericIdentity(""), new String[] { }); 
     base.Before(methodUnderTest);       
    } 

    public override void After(MethodInfo methodUnderTest) 
    { 
     base.After(methodUnderTest); 
     System.Threading.Thread.CurrentPrincipal = _originalPrincipal; 
    } 

}