Unterschied zwischen generiertem Proxy-Code für Konsole und Windows store app

Question

Wenn ich einen SOAP-Service in einer Standard Konsolen-Applikation aus der wsdl-Datei generieren lasse, kann ich den den ServicePortTypeClient folgendermaßen instanzieren:

ServicePortTypeClient SOAP = new ServicePortTypeClient("Konfigurationsname","http://Adresse")

In der Windows store app wird kein Code für den Konstruktor generiert, der zwei Strings als Parameter akzeptiert.

Wie gebe ich dann den Konfigurationsnamen an?

Ich dachte, ich könnte einfach mit

ServicePortTypeClient.EndpointConfiguration.Service

die Endpoint-Konfiguration als ersten Parameter angeben. Das ergibt bei der Ausführung allerdings einen Protokollfehler.

Answer 1

Hallo Hans-Otto,

Vielleicht kann dieser Link Dir weiterhelfen http://blogs.msdn.com/b/piyushjo/archive/2011/10/10/calling-a-wcf-service-from-a-metro-application.aspx

Gruss,

Ionut

Answer 2

Danke Ionut,

der eigentliche Hinweis ist in einem weiteren Blogeintrag:

http://blogs.msdn.com/b/piyushjo/archive/2011/09/22/wcf-in-win8-metro-styled-apps-absolutely-supported.aspx

D.h. um den Code in der generierten Datei Reference.cs nicht zu überschreiben, definiert man eine partielle Klasse in seinem eigenen Code etwa so:

public partial class ServiceClient
{
	static partial void ConfigureEndpoint
          (System.ServiceModel.Description.ServiceEndpoint serviceEndpoint, 
          System.ServiceModel.Description.ClientCredentials clientCredentials
            )
        {
            serviceEndpoint.Contract.ConfigurationName = "Konfigurationsname";
            
            serviceEndpoint.Address = new System.ServiceModel.EndpointAddress(http://Adresse);
        }
 }

Um Schreibfehler zu vermeiden, habe ich die Definitionen für die Klasse und die Methode direkt aus reference.cs kopiert.

Mein Problem damit ist, dass ich für die partielle Methode ConfigureEndpoint die Fehlermeldung erhalte, das dafür keine definierende Deklaration gefunden würde. D.h. er findet die Deklaration in reference.cs nicht. Bisher habe ich noch nicht herausgefunden warum.

Answer 3

Um den obigen Fehler zu umgehen, habe ich jetzt die geänderte Endpoint-Adresse einfach direkt in die reference.cs geschrieben.

Der Protokollfehler bleibt der selbe:

System.ServiceModel.ProtocolException wurde nicht behandelt.
  HResult=-2146233087
  Message=The header 'sessionID' from the namespace 'http://....xsd' was not understood by the recipient of this message, causing the message to not be processed.  This error typically indicates that the sender of this message has enabled a communication protocol that the receiver cannot process.  Please ensure that the configuration of the client's binding is consistent with the service's binding.
  Source=System.ServiceModel
  StackTrace:
       at System.ServiceModel.Dispatcher.ProxyOperationRuntime.AfterReply(ProxyRpc& rpc)
       at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
       at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
       at System.ServiceModel.Channels.ServiceChannelProxy.TaskCreator.<>c__DisplayClass5`1.<CreateGenericTask>b__4(IAsyncResult asyncResult)
       at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
       at StoreAppSOAP.MainPage.<btnCallService_Click_1>d__0.MoveNext() in c:\Users\hans-otto\Documents\Visual Studio 2012\Projects\StoreAppSOAP\StoreAppSOAP\MainPage.xaml.cs:line 43
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__0(Object state)
       at System.Threading.WinRTSynchronizationContext.Invoker.InvokeCore()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Threading.WinRTSynchronizationContext.Invoker.<InvokeCore>b__0(Object o)
       at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
       at System.Threading.ThreadPoolWorkQueue.Dispatch()
       at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
  InnerException:

Es scheint also irgendein grundsätzlicher Unterschied zwischen den beiden Proxy-Generierungen zu geben.

Könnte mir jemand den erläutern?

Answer 4

Wie an der Fehlermeldung zu sehen ist, stört er sich an der "SessionId". Hier scheint auch das grundsätzliche Problem zu liegen.

Der Windows Store App Proxy unterstützt im Gegensatz zu der Konsolenanwendung die Handhabung einer SessionId über das BasicHTTPBinding nicht.

Jetzt ist also die Frage: Wie muß ich die Windows Store App Applikation erweitern um diese SessionId-Handhabung zu implementieren?