Problème web service : pertes de données avec Silverlight

JuicyLink Messages postés 1 Date d'inscription vendredi 13 août 2010 Statut Membre Dernière intervention 13 août 2010 - 13 août 2010 à 10:29
leftbehind Messages postés 1 Date d'inscription mercredi 20 juin 2007 Statut Membre Dernière intervention 21 octobre 2010 - 21 oct. 2010 à 21:10
Bonjour,

Je travaille actuellement sur un projet Silverlight 4 consommant un web service que j'ai développé et qui est hébergé sur un serveur IIS 7.

J'ai effectué 2 scénarios de tests :
- le premier en incluant le service comme projet en référence de mon projet de test ;
- le second en développant un petit client qui consomme le service.

Mon problème vient du fait qu'en consommant le service (donc lors du second scénario de test) je perds toutes les données d'un objet qu'on appellera Container, contenant des informations sur une image quelconque (même si pour mes tests j'utilise une image au format JPG).
La structure du Container ne concerne que les types string, int, double, bool, char ainsi que des tableaux de ces derniers types.

Donc en gros, j'ai un objet Container rempli à la sortie de ma méthode en utilisation "directe" (projet de test référençant le service directement), et un objet Container vide à la sortie de ma méthode en consomment le web service hébergé sur IIS.

J'ai même eu un autre problème, à la sortie de ma méthode en consommant le web service, j'ai eu l'exception suivante :
[CommunicationException] "Le serveur n'a pas retourné la réponse attendue."


Le message d'erreur exact est le suivant :
Le serveur n'a pas fourni de réponse pertinente*; ceci peut être causé par des contrats qui ne correspondent pas, un arrêt prématuré de la session ou une erreur interne du serveur.


Et voici la StackTrace fournit :
Server stack trace: 
   à System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   à System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   à System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
 
Exception rethrown at [0]: 
   à System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   à WebServiceModelConsummer.MyService.IService1.GetImage(String objectID, Int32 index)
   à WebServiceModelConsummer.MyService.Service1Client.GetImage(String objectID, Int32 index) dans C:\Documents and Settings\JuicyLink\Mes documents\Visual Studio 2010\Projects\WebServiceModelConsummer\WebServiceModelConsummer\Service References\MyService\Reference.cs:ligne 3713
   à WebServiceModelConsummer.TestsConsoleMyService.GetImage(MyObject object) dans C:\Documents and Settings\JuicyLink\Mes documents\Visual Studio 2010\Projects\WebServiceModelConsummer\WebServiceModelConsummer\Form1.cs:ligne 666
   à WebServiceModelConsummer.TestsConsoleMyService.btnGetImage_Click(Object sender, EventArgs e) dans C:\Documents and Settings\JuicyLink\Mes documents\Visual Studio 2010\Projects\WebServiceModelConsummer\WebServiceModelConsummer\Form1.cs:ligne 855
   à System.Windows.Forms.Control.OnClick(EventArgs e)
   à System.Windows.Forms.Button.OnClick(EventArgs e)
   à System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   à System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   à System.Windows.Forms.Control.WndProc(Message& m)
   à System.Windows.Forms.ButtonBase.WndProc(Message& m)
   à System.Windows.Forms.Button.WndProc(Message& m)
   à System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   à System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   à System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   à System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   à System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
   à System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   à System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   à System.Windows.Forms.Application.Run(Form mainForm)
   à WebServiceModelConsummer.Program.Main() dans C:\Documents and Settings\JuicyLink\Mes documents\Visual Studio 2010\Projects\WebServiceModelConsummer\WebServiceModelConsummer\Program.cs:ligne 18
   à System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
   à System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
   à Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
   à System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   à System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
   à System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   à System.Threading.ThreadHelper.ThreadStart()


J'ai aujourd'hui bien ciblé la cause du problème : dans mon objet Container j'ai des tableaux de type Byte, Short et Ushort, je les ai respectivement appelés ByteBuffer, ShortBuffer et UshortBuffer.
Ce sont ces 3 champs de mon objet qui posent problème puisqu'en leur attribuant la valeur null, tout se déroule correctement.

La question à ce jour est : y aurait-il un problème connu avec les tableaux de type Byte, Short et Ushort stockés dans un objet exposé (ces champs aussi étant exposés) et levant une exception de type CommunicationException ?

En espérant que ça pourra nous aider à résoudre mon problème.

Merci.

1 réponse

leftbehind Messages postés 1 Date d'inscription mercredi 20 juin 2007 Statut Membre Dernière intervention 21 octobre 2010
21 oct. 2010 à 21:10
Salut,

C'est sûrement trop tard, mais pour ceux qui auraient ce genre d'erreur (ou d'autres), un moyen bien pratique de débugger ses services WCF est d'activer les logs en plaçant ce bout de XML dans le Web.config du projet hébergeant les services :

<configuration>
...
  <system.diagnostics>
    <trace autoflush="true" />
    <sources>
      <source name="System.ServiceModel"
              switchValue="Information, ActivityTracing"
              propagateActivity="true">
        <listeners>
          
        </listeners>
      </source>
    </sources>
  </system.diagnostics>
...
</configuration>

SdrConfigExample.e2e correspond au nom du fichier de log qui sera généré.

Et d'ensuite les lire avec l'outil "Service Trace Viewer" livré avec Visual Studio (C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\SvcTraceViewer.exe ou avec v6.0A si Visual Studio < 2010).

L'outil met bien en évidence les exceptions côté serveur et affiche le détail.

Plus d'infos ici : Service Trace Viewer Tool (SvcTraceViewer.exe)
0
Rejoignez-nous