Switzerland's Citroen replica watches uk, although very good, but in replica watches popularity and Tissot is rolex replica immeasurably, but in fact it and Tissot belong to the rolex replica uk same Swatch Group, its positioning higher than the Tissot, lower than Hamilton.
[SyncComm] Nueva versión 0.95 en Codeplex « josemiguel.torres

[SyncComm] Nueva versión 0.95 en Codeplex


Con un poco de retraso, pues tenia pensado publicar esta versión a principios de agosto, acabo de publicar la nueva versión (0.95) de SyncComm. Como novedades:

  • Nueva gestión de excepciones
  • Corregidos algunos BUGs
  • Mas flexibilidad en el uso de las propiedades de los enlaces para HttpBinding y CompressedBinding.
  • Modificados los namespace

Nueva gestión de excepciones

SyncComm aporta una forma de propagación de excepciones en el proceso de sincronización mediante Sync Services for ADO.NET y el proveedor remoto de sincronización expuesto en un servicio WCF. Básicamente, el proxy generado por la herramienta de generación netcfsvcutil.exe y que se utilizó, con algunas modificaciones para llevar a cabo las sincronizaciones, en las versiones iniciales, no procesaba las excepciones o mensajes fault propagados por el servicio WCF. Siguiendo la Guia WCF para desarrolladores Mobile, publicada también en codeplex, mi primer acercamiento fue el de utilizar el proyecto Mobile.ServiceModelEx expuesto por los autores, el cual solucionaba en gran medida toda la gestión de excepciones entre el servicio WCF y el terminal móvil. Sin embargo, únicamente era válido para enlaces cuya versón de mensaje fuera MessageVersion.Soap11, o mejor dicho, la implementación para otras versiones de mensaje no está implementada. El problema es que SyncComm utilitza un enlace con compresión, mediante GZip encoder, y cuya versión de mensaje SOAP es MessageVersion.Soap12WSAddressing10. Después de algunos intentos de comunicación con los autores, todos sin éxito, decidí implementar dicha características para ambas versiones de mensajes SOAP y pese a que no está tan avanzada como Mobile.ServiceModelEx, lo cierto es que cubre los requisitos necesario para la propagación eficiente de cualquier tipo de anomalía durante el proceso de sincronización y la posterior captura y proceso desde el cliente.

Ahora seriamos capaces de propagar mensajes de error desde el servicio WCF de la siguiente forma:

   1: catch (SqlException sqlex)
   2: {
   3:     Guid id = Guid.NewGuid();
   4:  
   5:     //display detailed exception information on console
   6:     Notification.Invoke(DateTime.Now, 
   7:         string.Format ("Exception {0}: {1}", id.ToString(), sqlex.Message));
   8:  
   9:     //throw and exception for being catch by client
  10:     throw new FaultException<string>(sqlex.Message, new FaultReason(
  11:                     new FaultReasonText("SQL Server is not available. Please try later.")),
  12:         FaultCode.CreateSenderFaultCode(id.ToString(), "urn:synccomm.com/2009/07/ISyncService"));
  13:  
  14:  
  15: }
  16: catch (Exception e)
  17: {
  18:     Guid id = Guid.NewGuid();
  19:  
  20:     //display detailed exception information on console
  21:     Notification.Invoke(DateTime.Now, 
  22:         string.Format ("Exception {0}: {1}",id.ToString(),e.Message));
  23:  
  24:     throw new FaultException<string>(e.Message, new FaultReason(
  25:                     new FaultReasonText("SyncService unavailable. Contact SyncService support.")),
  26:         FaultCode.CreateSenderFaultCode(id.ToString(), "urn:synccomm.com/2009/07/ISyncService"));
  27:  
  28: }

Capturarlos desde la aplicación .NET Compact Framework como exepción del tipo CFFaultSyncException, dejando los tipos CommunicationException y Exception, para excepciones relativas a la comunicación y otros tipos de excepciones, respectivamente.

   1: catch (CFFaultSyncException faultEx)
   2: {
   3:     Cursor.Current = Cursors.Default;
   4:     
   5:     //
   6:     MessageBox.Show(string.Format("FaultCode: {0}\r\nFaultReason: {1}\r\nHasDetail: {2}", 
   7:         faultEx.FaultCode, faultEx.FaultMessage, faultEx.HasDetail));
   8: }
   9: catch (CommunicationException communicationException )
  10: {
  11:     //is the emulator cradled? does it reach SyncService endpoint?
  12:     MessageBox.Show(communicationException.Message);
  13: }
  14: catch (Exception e)
  15: {
  16:     //something is not configured properly
  17:     MessageBox.Show(e.Message);
  18:     //HResult -2146233087 maybe database must be reinitialize
  19:  
  20: }

De forma que podemos mostrar un mensaje más amigable por pantalla mientras registramos el error técnico (opcional) para su posterior estudio. Además, todas las excepciones (representadas por la clase CFFaulSyncException) tienen un identificador único (System.Guid) lo cual permite registrar dicha excepción tanto en el servidor como en el cliente:

Si deseáis información más detallada aquí.

Corregidos algunos Bug

Como toda nueva versión, se han corregido varios Bugs, tanto registrados desde el site del proyecto como encontrados durante el proceso de desarrollo. El más significativo es el encontrado en los scripts.sql de generación del esquema de seguimiento de modificaciones para bases de datos que utilizan mecanismos de seguimiento personalizados.

Mas flexibilidad en el uso de las propiedades de los enlaces para HttpBinding y CompressedBinding.

Una de las peticiones de algunos desarrolladores fue la posiblidad de incrementar el tamaño máximo del mensaje, el cual se realiza a través de una de las propiedades del enlace. Como tal, se han creado dos métodos en  ClientBase.cs los cuales gestionan todas las propiedades relativas los enlaces de la comunicación con WCF. En el siguiente ejemplo podemos ver uno de ellos. Básicamente se agrupa en un mismo método la forma en la que se va crear el enlace al canal de comunicación expuesto por WCF, de forma que la simple modificación de las propiedades como MaxReceiveMessageSize para el enlace de compresión se concentran en un único método. Lo mismo sucede para el enalce básico mediante HttpBinding.

   1: //NOTE:
   2: //set compressed endpoint binding custom properties here
   3: public static System.ServiceModel.Channels.Binding CreateCompressionBinding()
   4: {
   5:     // Create a CustomBinding
   6:     var customBinding = new CustomBinding();
   7:     // Create a compression binding element
   8:     var compressionBindingElmnt = new CompressionMessageEncodingBindingElement();
   9:     // ..and add to the custom binding
  10:     customBinding.Elements.Add(compressionBindingElmnt);
  11:     
  12:     // Create an HttpTransportBindingElement and add that as well
  13:     var httpBindingElement = new HttpTransportBindingElement();
  14:  
  15:  
  16:     //TODO
  17:     //Set here desired values. Take care to match such values 
  18:     //in app.config in SyncComm host project
  19:     //max buffer size
  20:     //httpBindingElement.MaxBufferSize = int.MaxValue;
  21:     //max received message size
  22:     //httpBindingElement.MaxReceivedMessageSize = long.MaxValue;
  23:     //max buffer pool size
  24:     //httpBindingElement.MaxBufferPoolSize = long.MaxValue;
  25:  
  26:     customBinding.Elements.Add(httpBindingElement);
  27:             
  28:     return customBinding;
  29:             
  30: }

Por consiguiente y debido a que en versiones anteriores estos objetos se instanciaban desde la aplicación .NET CF Windows Form(AppMobileSync) y ahora han pasado al la librería (también .NET CF) SyncComm.Proxy.dll se ha aprovechado para que la instanacia del objecto SyncComm.Proxy.ServiceClient sea mas sencilla desde AppMobileSync. Ahora únicamente debemos indicar la dirección del EndPoint y su respectivo “tipo de enlace”. Dicho “tipo de enlace” se representa mediante el enumerador:

   1: namespace SyncComm.Proxy
   2: {
   3:     /// <summary>
   4:     /// Specify constants defining which endpoint binding to use
   5:     /// </summary>
   6:     public enum BindingType
   7:     {
   8:         /// <summary>
   9:         /// Use basic endpoint binding
  10:         /// </summary>
  11:         Basic,
  12:         /// <summary>
  13:         /// Use compressed endpoint binding
  14:         /// </summary>
  15:         Compressed
  16:     }
  17: }

 

Y por lo tanto la instancia de un objeto SyncComm.Proxy.ServiceClient será tan sencillo como:

   1: //NOTE: For compressed endpoint binding use this
   2: var endPoint = new EndpointAddress("http://10.0.2.15:9999/SyncService/GZip");
   3: var s = new ServiceClient(endPoint, BindingType.Compressed);
   4:  
   5: //NOTE: For basic endpoint use this
   6: var endPoint = new EndpointAddress("http://10.0.2.15:9999/SyncService/Basic");
   7: var s = new ServiceClient(endPoint, BindingType.Basic);

 

 

En lugar de como se hacía en versiones anteriore:

   1: // Create a CustomBinding
   2: var customBinding = new CustomBinding();
   3: // Create a compression binding element
   4: var compressionBindingElmnt = new CompressionMessageEncodingBindingElement();
   5: // ..and add to the custom binding
   6: customBinding.Elements.Add(compressionBindingElmnt);
   7:  
   8: // Create an HttpTransportBindingElement and add that as well
   9: var httpBindingElement =
  10:                     new HttpTransportBindingElement();
  11: customBinding.Elements.Add(httpBindingElement);
  12: // Set endpoint
  13: var endPoint = new EndpointAddress("http://10.0.2.15:9999/SyncService/GZip");
://10.0.2.15:9999/SyncService/GZip");
  14: #endregion
  15:  
  16: // Create the WCF proxy using the custom binding
  17: var s = new ServiceClient(customBinding,endPoint);

Modificados los namespace

Por último, se han modificado todos los namespace de los contratos WCF que antes eran inexistente. Ahora todos pasan a ser urn:synccomm/07/2009.

, ,

Comments are closed.