Métodos opcionales en las propiedades

Los métodos opcionales para proveer mayor funcionalidad a las propiedades son ShouldSerialize y Reset.
La principal funcionalidad que obtendremos al implementar el método Reset es que aparecerá una indicación visual en el explorador de propiedades con la posibilidad de restablecer el valor predeterminado para la misma. El mismo resultado se consigue con la utilización del atributo DefaultValue como marcador de la propiedad pero su uso está restringido a tipos de datos simples.
Con el método ShouldSerialize obtendremos una serialización de la propiedad condicionada a la expresión que evaluemos en el cuerpo del mismo. Este método será invocado por el runtime durante la serialización de la clase.
Veamos un ejemplo de estos dos métodos:

.....

private Negocio tiendaMuebles = null;

public Negocio TiendaMuebles
{
get { return this.tiendaMuebles; }
set { this.tiendaMuebles = value; }
}

public bool ShouldSerializeTiendaMuebles()
{
return this.tiendaMuebles != null;
}

public void ResetTiendaMuebles()
{
this.tiendaMuebles = null;
}
....

Un saludo.

Application Architecture Guide 2.0 Beta

Buenas.
Leo en Geeks que han publicado una versión preliminar de Application Architecture Guide 2.0. (por ahora solo versión en Inglés).
Es un pdf que se puede descargar y es muy interesante ya que estamos sumergidos en algo parecido.

A mandar!

VS no me pide credenciales al conectar con TFS :(

Hola a todos los miembros de ésta nuestra comunidad.

Voy a empezar con algo light. Espero que no demasiado...

Como adelantaba en el anterior post, vamos a dar solución a una cosa muy tonta pero que nos puede dar muchos quebraderos de cabeza. Seguro que muchos ya lo sabéis y algunos también lo habéis leido por el anterior método arcaico (correo a todos los que te acuerdas).

A todos nos ha pasado alguna vez que queremos conectar a nuestro TFS con Visual Studio, a traves de Team Explorer, con una cuenta diferente a la habitual, por ejemplo TFSSETUP. Resulta que algún día marcamos el check de recordar contraseña y a partir de ahí no podemos hacer que VS nos la pida otra vez.
La pregunra es: ¿Dónde almacena Visual Studio esas credenciales?
Bien, las credenciales no las cachea Visual Studio sino el sistema operativo. De hecho el problema nos puede aparecer con cualquier otro producto, aunque seguramente el que más nos molesta sea el acceso a TFS.
Para limpiar estas credenciales guardadas debemos seguir los siguientes pasos.
Tenemos dos opciones, dependiendo de cómo esté sonfigurado nuestro sistema operativo:

• Modo XP "molón". Este es el modo que nos muestra las cosas como si supiéramos.

1. En el panel de control seleccionar la vista clásica. Después entramos en Cuentas de usuario.
2. En la ventana de cuentas de usuario vamos a la pestaña de opciones avanzadas.
3. En la ventana que nos sale nos aparece una lista con las credenciales que tenemos para acceder a los distintos servidores. En el ejemplo sólo hay credenciales guardadas para un servidor que se llama mts. Si accedeis por IP en lugar de por nombre , aquí aparecerá la IP del servidor.
4. En esa pantalla eliminamos la entrada que nos interese, reiniciamos VS (o la aplicación que sea) y nos debe pedir las credenciales de nuevo.
   

• Modo XP "nenaza". Sí, ese modo feo con el que suelen venir nuestros equipos corporativos recien plataformados, antes de meterlos en el dominio. Es como todo más fácil pero no hay cristiano que encuentre dónde están las cosas.

1. Igual que en el modo anterior (Panel de control --> Cuentas de usuario)
   
2. Elegimos cambiar una cuenta.
3. Elegimos la cuenta a cambiar
4. Una vez en tenemos la cuenta para cambiar, pinchamos en Administrar mis contraseñas de red.
5. A partir de aquí, todo igual que en el modo anterior.

Y eso es todo.
Sé que este post puede ser interpretado como un insulto a vuestra inteligencia (sobre todo por los pantallazos en plan "es la primera vez que enciendo un ordenador"). Os prometo que los siguientes posts serán más interesantes.

Vamos a ver si entre todos sacamos adelante esta iniciativa que, personalmente, me parece perfecta.

Un abrazo.

Saltar Validación de Certificado en una Conexión SSL

Como mi primera aportación, voy a indicar un pequeño truco para saltarse por código la validación del certificado servidor al establecer una comunicación SSL (válido xej para conexiones a Servicios Web Securizadas)
El problema viene cuando el certificado utilizado en el servidor de desarrollo para establecer SSL está revocado, caducado, con un DN de prueba etc... Al intentar realizar la conexión al equipo remoto por HTTPS notaremos como nos es imposible ya que el mismo framework nos denegará el acceso.
Podemos comprobar que la conexión no es de confianza si lanzamos un IE y obtenemos un warning indicandonos que la conexión es inválida debido a defectos en el certificado. El navegador nos permitirá omitir este error y proseguir pero... Cómo omitimos esta validación desde código??

Bien, solo tenemos que suscribirnos al evento de validación del certificado en local, y generosamente, permitir la conexión para cualquier certificado siguiendo el siguiente ejemplo (Importante: Este ejemplo es válido para FrameWork 2.0 en adelante)

Previo a la llamada:
// Creamos un delegado para aprobar el certificado cuando se realize la peticion
RemoteCertificateValidationCallback remoteCallback = new RemoteCertificateValidationCallback(ValidateServerCertificate);
//Lo asignamos a la llamada de vuelta
ServicePointManager.ServerCertificateValidationCallback += remoteCallback;

Y en el procedimiento de validacion

public static bool ValidateServerCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
//Validamos el certificado
return true;
}

Bueno, espero solucione muchas depuraciones ;)

Compartir tipos entre Servicios.

Buenos días a todos los geeks ;)

En este nuevo número vamos a ver un problema muy muy común cuando trabajamos con arquitecturas SOA o intentamos hacerlo (como es mi caso). Seguro que vamos a tener diferentes servicios y seguro que varios de esos servicios van a utilizar tipos comunes. El problema es que cuando importamos estos servicios en el cliente se nos generan dos tipos (no compatibles) para el mismo tipo compartido.
En primer lugar vamos a suponer que los servicios son implementados como Web Services (asmx).
Para solucionarlo hay que hacer dos cosas:

• Conseguir que los WSDL presenten exactamente la misma serialización para el tipo común. Para ello tenemos que especificar el tipo XML de nuestra clase. Debemos poner un namespace a nuestro tipo común. Ésto, unido a que el nombre del tipo y los campos van a serializar siempre igual, hará que ambos WSDLs definan el tipo común de igual forma.
• Decirle a nuestro gran generador de proxies que sea un poco cuidadoso y si detecta dos tipos iguales (namespace, nombre de tipo y esquema) que sólo genere una clase).
  De esta forma generamos un único tipo en el cliente. Nos olvidamos de problemas de castings entre tipos (que eran iguales pero distintos) y de no poder pasar a un servicio los tipos que me devolvía otro. Vale... Pero ¿Cómo se hace? En este link nos explican cómo dar los dos pasos: http://msdn.microsoft.com/en-us/library/aa480505.aspx En este otro nos explican cómo dar el segundo paso más fácil. http://quickstarts.asp.net/QuickStartv20/webservices/doc/TypeSharing.aspx
  Y en WCF??
  Así --> http://geeks.ms/blogs/jlsoria/archive/2008/07/16/wcf-compartici-243-n-de-tipos-entre-referencias-a-servicios.aspx

Ahora os cuento mi vida. Como todos sabéis, estoy currando con Flex y ya van varias veces que me está condicionando en cosas muy importantes. Varios ejemplos son las entregas anteriores:
Aunque Flex (action script) define enumeraciones, los esquemas xsd también, por tanto WSDL también. Resulta que el generador de proxies tiene un bug y no funcionan (documentado por Adobe y sin workarround ni miras de que vayan a solucionarlo). Esto me ha obligado a no usar enumeraciones --> bajoncete
Aunque el protocolo SOAP define soap faults para transportar errores, y es así como se transportan las excepciones. Flex "descarta" la información que tú pasas en el soap fault y siempre manda la misma excepción genérica al proxy que ha generado. Entonces, nunca puedes ver nada de la excepción --> no puedes usar excepciones para comunicar errores (Documentado por Abobe y el WorkArround es "No uses excepciones") --> bajonazo!!
Ahora, cómo no, he encontrado aquí http://bugs.adobe.com/jira/browse/FB-1251 que no es capaz de darse cuenta de que hay un tipo común entre dos servicios. Dice que hay un workarround aunque no asegura que siempre vaya a funcionar. Ya he perdido mucho tiempo en el proyecto por temas como este. Mi problema actual es que tengo que hacer un servicio bastante más grande de lo que me gustaría (unión de dos), aunque la aplicación no es muy grande y el servicio tampoco es exagerado. A estas alturas no estoy a tiempo de cambiarlo y arriesgarme. Si algún alma caritativa tiene alguna idea o amigo de Flex (me consta que miguelín sí lo tiene ;) ) agradecería su ayuda eternamente.En la siguiente entrega hablaremos de dónde se puede limpiar el almacenamiento de contraseñas responsable que, por ejemplo, no se nos pida nunca la contraseña cuando accedemos al TFS. Es un coñazo cuando queremos cambiar la cuenta con que accedemos.

Un saludo a todos.

Mario.