[Xamarin] Usando Mapbox en Xamarin.Android

¿Alguna vez has tenido la necesidad de usar un proveedor de mapas diferente al de Google Maps? Pues hoy quiero presentarte una alternativa y no te hablo de mostrar un mapa a través de un webview o algo similar, sino de MapBox y como es que lo puedes usar nativamente en Xamarin.Android.

Mapbox

Lo primero que tenemos que hacer es registrarnos en la página oficial de MapBox (https://www.mapbox.com), es un procedimiento gratuito que no toma mucho tiempo y con una cuenta dada de alta ya tenemos un token que nos permitirá inicializar los servicios de MapBox en nuestros futuros proyectos, si deseas más detalles sobre para qué sirve el token puedes visitar la siguiente página: https://www.mapbox.com/help/how-access-tokens-work/

Map Style

Seguido de ello tenemos que elegir con que estilo de mapa queremos trabajar ingresando a la página de mapas de MapBox https://www.mapbox.com/maps/. Vale mencionar que MapBox también te permite crear tus propios estilos para personalizar los mapas, pero no entraremos en esos detalles, así que simplemente elijamos con qué estilos deseamos trabajar.

Nuget

Lo que viene ahora es crear el proyecto y mediante Nuget descargar los componentes correspondientes a Naxam.Mapbox.Droid 5.3.2

Ya con los componentes listos, podemos proceder a hacer lo siguiente para disfrutar de nuestro nuevo mapa.


[.NET] Entendiendo el Patrón de Repositorio

Implementar el patrón de repositorio es una práctica muy común en aquellos proyectos que necesitan trabajar con datos externos, ya sea esto a través de bases de datos, servicios web, archivos u otros.

Este patrón nos ayuda mejorar la mantenibilidad y la capacidad de prueba. Con la correcta separación de intereses, nuestra lógica de negocio ya se puede concentrar en el negocio en sí y no preocuparse en operaciones de bajo nivel, como abrir una conexión a una base de datos o algún socket.

Este patrón nos habla de una capa intermedia entre la lógica de negocio y la fuente de datos, pero hay muchas formas de entenderlo así que exploremos algunos puntos.

1. Reponsabilidad única

En el siguiente programa estamos accediendo a una base de datos para obtener un listado y también para mostrarlo en pantalla, pero todo se encuentra en una sola clase violando el principio de diseño de responsabilidad única.

Lo ideal sería mover la lógica correspondiente a la conexión a base de datos a una una clase aparte en otro proyecto de librería de clases.

Y terminar con la clase principal de la siguiente forma:

2. Repositorios genéricos

En muchas operaciones con datos, creamos, modificamos, eliminamos o consultamos registros, por ello es usual considerar la creación de una interfaz para un repositorio genérico.

Sin embargo, esta idea nos puede llevar a encontrarnos con situaciones muy parecidas a estas:

No es que se acabe el mundo, pero hay que tomarlo en consideración ya que podría dificultar el diseño de nuestras aplicaciones y viola un principio de diseño.

3. Segregación de interfaces

Implementar las interfaces adecuadamente nos ayuda a tener mejores resultados. Si creamos una interfaz como esta:

Tendremos la capacidad de trabajar con diferentes implementaciones según la ocasión.

Y en nuestro programa principal solo nos preocupariamos de la interface y de como se realizaría la instanciación que necesitamos.

Algunos extienden esto usando inyección de dependencias, otros se organizan usando espacios de nombre y otros hacen cosas diferentes. La resolución o complejidad de esto ya depende de los requisitos del proyecto o elección de cada uno.

[.NET] ¿Cómo trabajar async con Enterprise Library?

Digamos que tienes un web service, sí, un web service. Y este, acaba de recibir una petición, si tu web service desea sobrevivir, lo que tendrá que hacer es hacer uso de algún Thread dentro de su Thread Pool. Mientras el procesamiento de cada petición no le tome demasiado a un Thread, podría no haber problema.

Pero en el caso contrario podriamos no solo dejar varias solicitudes en espera, sino también afectar el rendimiento de las demás tareas.

Antes de continuar, recordemos que la creación de un Thread es costosa en términos de memoria (1MB) y tiempo(500ms). Hay escenarios que lo justifican, pero aquellos dónde un Thread se queda bloqueado por esperar el resultado de alguna operación, simplemente no.

Lo bueno de este asunto es que desde .NET 4.5 y C# 5, la programación asíncrona nos permite fácilmente lidear con esta clase de situaciones, un claro ejemplo sería la forma en que HttpClient trabaja, pero igual nos podemos encontrar con casos que no estan listos para esto, por eso ahora veremos como trabajar asíncronamente con Enterprise Library.

En el siguiente código podemos apreciar un controllador que devuelve una lista de elementos.

Y en este otro, un método que logra establecer una conexión a una base de datos para recuperar algunos resultados.

Si una solicitud llega a nuestro servicio y nuestro Thread queda bloqueado por esperar el resultado de una gran consulta o la ejecución de una operación larga, la inmediata próxima solicitud exigirá que se tenga que usar otro Thread o se tenga que crear uno nuevo. Para este sencillo e hipotético ejemplo tendremos que realizar las siguientes modificaciones.

[.NET] ¡No hagan Dispose() en HttpClient!

Cuando desarrollamos un sistema conectado en .NET es probable que lo terminemos haciendo con HttpClient, esto es por todas las ventajas que nos trae:

  1. Fue diseñado especialmente para la creciente necesidad de las solicitudes bajo una arquitectura REST y Henrik F. Nielson, el autor inicial de HTTP, esta involucrado en su desarrollo y diseño.
  2. Puede ser usado en aplicaciones de escritorio para Windows, Linux o Mac, así como para aplicaciones móviles en Android o iOS y aplicaciones de IoT con Windows 10.
  3. Puede reusar DNS resueltos y te permite configurar facilmente headers y cookies.
  4. Una única instancia de HttpClient puede hacer solicitudes concurrentes.
  5. La API es sencilla y eso es genial para hacer pruebas.
  6. Todas las operaciones de espera son asíncronas.

Y otras ventajas más, pero el punto de este post esta en relación al error en la que solemos caer algunos cuando nos damos cuenta que HttpClient implementa la interfaz IDisposable.

¿Qué es lo que sucede?

En el siguiente ejemplo tenemos un programa que crea una nueva instancia de HttpClient por cada solicitud que se realiza.

Y al ejecutarlo, si bien las operaciones culminan con aparente normalidad, la verdad es que dejan varias conexiones abiertas.

Esto es porque las conexiones sobre TCP/IP no se cierran en su totalidad para permitir que los paquetes lleguen fuera de orden o que se vuelvan a transmitir. TIME_WAIT indica que el punto final de nuestro lado ha cerrado las conexiones, pero las conexiones se mantienen para que los paquetes retrasados puedan manejarse correctamente. Una vez que esto sucede, las conexiones se eliminarán luego de un período de tiempo de espera de 4 minutos.

Nuestro programa pudo haber abierto hasta 10 nuevos sockets hacia el servidor, pero ¿te imaginas qué podría pasar en el backend de algún proyecto? Simplemente nos veremos frente a un error similar este:

Unable to connect to the remote server
System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted

¿Qué podemos hacer?

La mejor solución es reusar una única instancia de nuestro HttpClient en vez de crear una para cada solicitud. Y no hay de qué preocuparse porque casi todas las operaciones son thread-safe: CancelPendingRequests, DeleteAsync, GetAsync, GetByteArrayAsync, GetStreamAsync, GetStringAsync, PostAsync, PutAsync y SendAsync.

Ahora, al reutilizar una instancia de HttpClient significa que se mantiene el socket hasta que se cierre, por lo que si se tiene una actualización de registro DNS en el servidor, el cliente nunca lo sabrá hasta que se cierre ese socket. Y esto puede ser otro gran problema, ¿qué pasaría si para nuestro backend hacemos un switch de IPs para pasar una actualización del proyecto a producción? ¡El cliente todavía estaría conectándose a la instancia anterior, osea a la versión anterior del proyecto!

HttpClient no verifica los registros DNS cuando la conexión está abierta y tiene sentido. Por eso tenemos que ir un poco más allá y establecer el valor por defecto de por cuánto tiempo el socket TCP, para un endpoint determinado, puede permanecer abierto.

Pero eso no es todo, una vez cerrada la conexión, nada te asegura de que al momento de que el HttpClient establezca una nueva conexión usando el mismo DNS, resuelva y se conecte a la nueva IP del servidor y esto ocurre porque la resolución del DNS se guarda en memoria. Por ello es que finalmente, también tenemos que hacer lo siguiente.

[.NET] ¿Cómo crear y publicar un paquete NuGet?

Es un hecho de que en la mayoría de proyectos software los desarrolladores reutilizamos componentes y librerias. Para los que trabajamos con Visual Studio, NuGet es uno de los facilitadores de paquetes, es genial, pero ¿cómo así aquellos paquetes aparecen en esa lista? ¿hay que pagar algo? Estas interrogantes las resolveremos en unos sencillos pasos:

Crear o seleccionar un proyecto de librería de clases

Lo primero que hay que hacer es crear o seleccionar un proyecto de librería de clases, para este ejemplo estoy usando un proyecto .NET Standard.

Configurar las propiedades del paquete

El segundo paso es configurar las propiedades del paquete, para ello vamos a propiedades del proyecto y nos ubicamos en la configuración de paquete. Aquí encontraremos los metadatos de nuestro de librería de clases. No todos los campos son obligatorios, solo asegúrense de tener un Id de paquete único.

Observemos que los campos de la licencia, proyecto y repositorio corresponden a un proyecto en GitHub y es que este proyecto lo he subido ahí. Probablemente se hagan preguntas sobre la licencia, pero no se precoupen por ello, porque si entramos a GitHub nos daremos cuenta que nos ayudan a generar uno.

Volviendo a los metadatos, solo queda mencionar que la imagen correspondiente al icono debes subirla a algun lado.

Ejecutar el comando de empaquetado

Ahora el tercer paso solo involucra hacer click en la opción empaquetar del proyecto, asegurándonos claro que este en Release.

Una vez hecho esto, solo confirmemos que nuestro paquete se generó correctamente.

Publicar el paquete

El cuarto y último paso, consiste en ingresar a nuestra cuenta de nuget.org, para ello solo iniciemos sesión gratuitamente con nuestra cuenta de Microsoft. Una vez hecho eso seleccionemos la opción Subir Paquete y busquemos nuestro archivo.

Luego solo revisemos que los metadatos son los que corresponden y en la parte de documentación podemos hacer referencia a nuestro README.

Simplemente copiando y pegando el enlace que obtenemos al dar click en Raw. Confirmamos que la documentación es la nuestra y damos en publicar.

Ahora para que nuestro paquete este disponible para el mundo deben pasar algunas horas, si queremos actualizar la documentación, podemos darle edit package y hacemos algo muy similar a lo que hicimos hace un momento.

Si ahora desde nuestro perfil seleccionamos la opción ver listado de paquetes, nos daremos cuenta que no estará nuestra última versión ahí, hay que esperar.

Pero si tenemos una anterior, desde ahí podremos darnos cuenta en la parte inferior que nuestra última versión esta pasando por un proceso de validación.

[.NET] Principio de Inversión de Dependencias (D)

Ahora veremos el último de los Principios de Diseño Orientado a Objetos, para el cual les recomiendo antes, revisar y entender el Principio de Responsabilidad Única, el de Abierto/Cerrado y el de Segregación de Interfaces.

Dicho esto, ya podemos empezar con el Principio de Inversión de Dependencias, el cual sostiene dos puntos clave, el primero de ellos es:

“Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones.”

Entendamos los módulos de alto nivel como aquellos elementos de nuestro sistema que están más cerca de nuestro cliente, que bien podría ser una persona u otro sistema, y los de bajo nivel como aquellos que están más cerca al núcleo o centro de nuestro sistema.

El siguiente punto clave es:

“Las abstracciones no deben depender de detalles, son los detalles los que deben depender de abstracciones.”

Por ejemplo, cuando vamos a comprar a un supermercado y debemos recibir algún comprobante, independientemente a que sea una boleta o una factura, existe la operación “Emitir Comprobante”, y del mismo modo cuando falta poco tiempo para que acabe el servicio mensual de luz o agua, hay una suerte de “Enviar Notificación”, que bien puede ser por correo electrónico, un documento físico o una llamada telefónica.

Las abstracciones deben capturar el flujo o comportamiento esencial de nuestro sistema sin caer en especificaciones del detalle de su implementación.

Dejando estos dos puntos claros pasemos al siguiente ejemplo:

Podemos apreciar que hay una serie de operaciones en relación al pago de un carro de compras y se podría decir que no hay problema, pero la verdad es que esta situación esta cometiendo algunas infracciones. Y esto es así porque estamos trabajando con detalles, con implementaciones concretas, además de tener una clase que no solo es responsable de hacer un Checkout, sino también de inicializar los servicios que usaremos en todo el proceso.

Antes de proseguir con esto, debo mencionar que así como existen los principios de diseño orientado a objetos también existen una variedad de patrones de diseño que nos pueden ayudar dependiendo a la situación y en esta ocasión, elegiremos la inyección de dependencias por constructor.

Entonces, para el anterior ejemplo, lo adecuado sería definir las siguientes interfaces según las operaciones que hemos identificado:

Una vez definidas, ya podremos conseguir la siguiente actualización para la clase en cuestión y, como se puede apreciar, en el constructor de la clase se reciben las interfaces que previamente hemos definido.

La pregunta que viene ahora, ya que tenemos varias interfaces que eventualmente deben inicializarse, es: ¿Dónde inicializamos los objetos? Esto se puede realizar a través de un contenedor de inversión de control (IoC Container) o definiendo un constructor por defecto, pero para este ejemplo, las inicializaremos manualmente. Primero asegurémonos de implementar las interfaces:

Y una vez hecho eso, ya podemos continuar de la siguiente forma, definiendo clases concretas según las interfaces y enviando como parámetros de constructor todo lo necesario para hacer nuestro Checkout.

Como pueden ver, resulto un poco más trabajoso entender este principio, pero la verdad es que trae interesantes oportunidades. Por ejemplo, podemos tener diferentes implementaciones de las interfaces y realizar pruebas con mucha facilidad.

Para terminar, os quiero hacer acordar que estos principios de diseño son guías, si sientes que tu proyecto no amerita ser estricto con alguno de ellos, no te hagas problemas, lo importante es que sea eficiente.

[.NET] Principio de Segregación de Interfaces (I)

Antes de ir al meollo del asunto quiero hacerles recordar que estos Principios de Diseño Orientado a Objetos son solo sugerencias para tener un código ordenado y de fácil mantenimiento, no son ninguna suerte de mandato o de obligatoria práctica, listo continuemos.

Estoy seguro que en más de una ocasión han visto algo así:

No se preocupen, ver uno o dos puede ser normal, pero tener muchas clases similares a la siguiente, puede significar que hay algo que podemos mejorar.

Cuando diseñamos aplicaciones debemos tener cuidado en como es que vamos a trabajar con interfaces ya que si bien nos pueden ayudar a abstraer varios módulos, un uso inadecuado puede llevarnos a forzar la implementación de métodos o funciones que realmente no usaremos. Ahora conozcamos el Principio de Segregación de Interfaces, el cual sostiene lo siguiente:

Los clientes de un programa dado sólo deberían conocer de éste aquellos métodos que realmente usan, y no aquellos que no necesitan usar.

Entonces, algo muy práctico que podríamos hacer, para esta ocasión, es segregar estas operaciones de la siguiente manera:

Y de esta forma, volviendo a nuestro ejemplo, tendríamos algo así:

Hemos dado un paso y sé que la ausencia de la interfaz IRepository podría traer algunas dudas, probablemente algunos se hayan dado cuenta que hemos tomado como ejemplo una suerte de implementación del Patrón de Repositorio ó Repository Pattern y he hecho esto intencionalmente porque quiero compartirles que existe una estrecha relación entre la inadecuada implementación de un patrón de diseño con el hecho de infringir un principio de diseño, pero ya será en otra ocasión dónde comparta más sobre este patrón.

Ahora lo que quiero hacer es compartir otro ejemplo, uno que responde al Principio de Segregación de Interfaces, pero desde otro punto de partida. Supongamos una clase que hace una serie de operaciones de utilidad.

Si recordamos, esta clase no esta cumpliendo con el Principio de Responsabilidad Única, pero en vez de crear nuevas clases para este ejemplo, crearemos un par de interfaces del siguiente modo:

De tal manera que podríamos tener, por ejemplo, con la implementación de una de ellas (ILogger.cs) una alternativa para cada ocasión que se requiera ya se que tengamos o no acceso a internet o necesitemos un mayor o menor nivel de confidencialidad o respuesta. En cualquier parte de nuestro sistema.

Y eso es todo amigos, queda pendiente el último principio de diseño orientado a objetos y el patrón de repositorio.

[.NET] Principio de Sustitución de Liskov (L)

Puede ser una pregunta extraña, pero ¿qué tan guitarra es una guitarra eléctrica? A diferencia que en la vida diaria, esta interrogante sí toma cierta relevancia al tratarse del diseño de un sistema informático y es que, al momento de Tocar(), ambas tienen un comportamiento muy distinto.

Mientras que la guitarra común o acústica solo depende de su caja de resonancia para emitir efectivamente un sonido.

La guitarra eléctrica depende del efecto faraday y un amplificador.

Para todas estas situaciones es importante tener en claro el Principio de Sustitución de Liskov, el cual sostiene lo siguiente:

Los subtipos deben ser sustituibles por sus tipos base.

En el anterior ejemplo nos podemos dar con el inconveniente de que al momento de tocar tengamos algunos resultados inesperados, como le hecho de que una sí suene según lo esperado y la otra no se escuche casi nada porque falta amplificar.

Podemos tener un código que tenga la responsabilidad única de validar el tipo y que ejecute el procedimiento correspondiente.

Pero en el ejemplo anterior solo tenemos un subtipo ¿Qué pasaría si hay más? Bajo esta idea podriamos tener una clase padre llamada Instrumento.cs y ocurriría lo siguiente.

Definitivamente esta clase Player.cs no es adecuada ya que es difícil de mantener y agrega una complejidad innecesaria. Por lo tanto, la solución en esta situación es crear una nueva clase abstracta de la cual deriven las demás, de tal manera que cada subtipo tenga su propia implementación.

En ese sentido ya no es necesario alterar ningún comportamiento de la base, ni tampoco es necesario recurrir a un código adicional para conocer la diferencia que hay entre el tipo base y el subtipo.

Lo mejor de esta solución es que extendemos las oportunidades de su implementación así como nos permite tener un código más ordenado.

[.NET] ¿Cómo grabar vídeos en Windows Phone Silverlight?

Hace poco tuve que aprender a progamar para subir vídeos en Windows Phone. Al parecer habían un par de formas de hacerlo, así que a continuación compartiré la que me funcionó y la que creo que fue la mejor alternativa. Se aceptan sugerencias :)!

Para mi caso en especial todo gira alrededor de la siguiente clase:


En el proyecto Windows Phone, empezamos actualizando el WMAppManifest.xml para poder usar la cámara y el micrófono.


Luego de ello ya podemos definir nuestra pantalla como mejor creamos.


En mi caso quedo así:

Luego de definir la pantalla, viene el .cs en el cual hay que lidear con el estado de la cámara, no vayamos a usar recursos que ya estan en uso y con la orientación de nuestra aplicación. Para mi fue todo un lío llegar a terminar esta parte, es más, actualmente tiene un bug. Una estrella para quien lo encuentra.


En fin, luego de haber capturado correctamente la información y dando aceptar, nos ayudamos de una variable estática en el App.xaml.cs llamada PendingVideo y navegamos hacia atrás. Ya del otro lado, la usamos y limpiamos referencias innecesarias.

[.NET] C# 6.0 – Visual Studio 2015 CTP 6

C# 6.0 se incluye con Visual Studio 2015 y viene con varias novedades, en este post compartiré un resumen de las nuevas características de este lenguaje.

Sintaxis using static

En versiones previas de C#, cuando queríamos trabajar, por ejemplo, con la clase estática System.Console teníamos que definir using System y de esa manera tener la posibilidad de usar todas las clases que se encuentran en el espacio de nombres System (no había forma de usar solo la clase System.Console).

using System;

namespace CSharp6.CTP6
{
internal class Program
{
private static void Main(string[] args)
{
Console.ForegroundColor = ConsoleColor.Cyan;
Console.WriteLine("¡Hola XAML Development!");
Console.ForegroundColor = ConsoleColor.Green;
Console.WriteLine("¡Viva C# 6.0!");
}
}
}

Ahora con C# 6.0, tu puedes agregar using static para poder utilizar los métodos y propiedades de la única clase estática o el enumerado a la cual haces referencia:

using static System.Console;
using static System.ConsoleColor;

namespace CSharp6.CTP6
{
internal class Program
{
private static void Main(string[] args)
{
ForegroundColor = Cyan;
WriteLine("¡Hola XAML Development!");
ForegroundColor = Green;
WriteLine("¡Viva C# 6.0!");
}
}
}

nameof

Muchas veces hemos usado literales de cadena para hacer referencia el nombre de una variable.

public static void Foo(string code)
{
if (code== null) throw new Exception("code");
//...
}

En C # 6.0, hay un nuevo operador llamado nameof que nos permitirá refactorizar nuestro código y deshacernos de muchos de esos literales de cadena. Ahora podremos tener un código más limpio y seguro cuando se trate de obtener el nombre de nuestras variables.

public static void Foo(string code)
{
if (code== null) throw new Exception(nameof(code));
//...
}

Filtros de Excepciones

Los filtros de excepciones no son nuevos en Visual Basic, pero sí en C#. La keyword when te permite especificar una condición para un bloque catch.

            try
{
throw new System.Exception("Error");
}
catch (System.Exception ex) when (ex.Message == "ReallyBadError")
{
// :(
}
catch (System.Exception ex) when (ex.Message == "Error")
{
WriteLine("Boom!");
}

await desde un bloque catch y finally

Esta nueva característica no requiere mucha explicación. Que bueno que por fin este con nosotros ya que es muy útil.

        public static async void BoomAsync()
{
try
{
throw new Exception("Boom!");
}
catch
{
await Task.Delay(5000);
WriteLine("Esperaste 5 segundos");
}
finally
{
await Task.Delay(3000);
WriteLine("Esperaste 3 segundos");
}
}

Interpolación de cadenas

Ahora podemos poner expresiones directamente en la cadena literal para mostrar los valores de una manera sencilla. En C # 6.0 podemos especificar fácilmente varios formatos en nuestros valores.

            //C# < 6.0                
string txt1 = "Hola" + "Mundo";
string txt2 = string.Format("{0} {1}", "Hola", "Mundo");

//C# >= 6.0
string txt3 = "Mundo";
int habitantes = 8000;
Console.WriteLine($"En el {txt3}. Hay aproximadamente {habitantes + 1} millones de habitantes. {DateTime.Now:dd-MM-yyyy}");

Operador de condicional nulo

¿Quien no se ha topado con un NullReferenceException?. Esta excepción que nos salta cuando olvidamos validar si es que un valor no es nulo antes de usarlo. Ahora gracias a C# 6.0 el trabajo con algunas de las validaciones será menos complicado. En el siguiente código, si nuestra variable es null la función devolverá null en vez de caerse.

        public static string NullConditional(object obj)
{
return obj?.ToString();
}

Inicializadores de Diccionarios

No podemos negar que el siguiente formato para la creación de diccionarios es confuso :

            Dictionary<string, string> data = new Dictionary<string, string>()
{
{ "Fruta", "Mandarina" },
{ "Disciplina", "Parkour" },
{ "Profesion", "Developer" }
};

En C# 6.0 esto se extendió y ahora también se puede hacer de la siguiente manera, la cual es más fácil de entender:

            Dictionary<string, string> data = new Dictionary<string, string>()
{
["Fruta"] = "Mandarina",
["Disciplina"] = "Parkour",
["Profesion"] = "Developer"
};

Inicializadores Auto-Property

En el pasado teníamos que hacer lo siguiente para inicializar nuestras propiedades:

    public class Usuario
{
public Usuario()
{
this.Id = Guid.NewGuid();
}

public Guid Id { get; set; }

public readonly int code = 3;

public int Code
{
get { return code; }
}
}
Ahora es suficiente hacer lo siguiente:
    public class Usuario
{
public Guid Id { get; set; } = Guid.NewGuid();

public int Code { get; } = 3;
}

Conclusión

Desde que empezó su desarrollo, C# 6.0 ha ido tomando una mejor forma. Me agradan bastante las nuevas características, pero ahora debemos ser conscientes que cualquier cosa aquí esta sujeto a cambios, esto se puede deducir tomando en cuenta que tanto Visual Studio 2015 como C# 6.0 siguen en preview. Aconsejo mantenerse enganchado a los siguientes sitios:

http://msdn.microsoft.com/
http://channel9.msdn.com/