June 2011 - Artículos - Jorge Serrano - MVP Visual Developer - Visual Basic

June 2011 - Artículos

 

Introducción

Programas tanto y vas tan deprisa, que a veces no caes en algunos conceptos, otras veces simplemente te olvidas de ellos, y en otras ocasiones, has hecho las cosas porque sí casi sin pararte a pensar en el porqué.

Funcionar funcionan sí, pero no siempre es así.

El problema

Recientemente en un proyecto con C# me he encontrado (una vez más) con la tesitura de decidir en qué sitio deben ir los using.

¿Dentro o fuera del namespace?.

Normalmente los he puesto siempre dentro, y el caso es que si no lo hago y ejecuto StyleCop, éste me empieza a brear con avisos sobre la idoneidad de poner los using dentro del namespace.

Bien, vale, aceptamos pulpo como animal de compañía y salimos del paso, pasamos el análisis de código y continuamos, pero... ¿qué implicaciones o qué más da ponerlo dentro o fuera?.

Lo mejor es verlo con un sencillísimo ejemplo que nos demuestre que ponerlo dentro o ponerlo fuera NO DA IGUAL.

Y ojo, que cuando digo que NO DA IGUAL, quiero decir literalmente,... CUIDADO, PORQUE LA PODEMOS CAGAR.

La explicación

Partimos de una clase:

 

 

namespace UsingInsideOutside
{
    public class Math
    {
        public static double PI = 6.28F;
    } // Math// UsingInsideOutside

 

 

La clase se explica por sí sola... una variable estática y pública con un valor de PI que me he inventado para demostrar las implicaciones del uso de using dentro o fuera del namespace.

Ahora la otra clase con el using fuera del namespace y objeto de la primera prueba demostrativa:

 

 

using System;
namespace UsingInsideOutside.Other
{
    public class Foo
    {
        public static double Calculate(double value)
        {
            return Math.PI * value;
        } // Calculate
    } // Foo// UsingInsideOutside.Other

 

 

Y ahora el código de ejecución de este ejemplo:

 

 

MessageBox.Show(UsingInsideOutside.Other.Foo.Calculate(1).ToString());

 

 

¿Qué resultado obtendremos?

 

6.28...

 

¿Y si ponemos el using dentro?:

 

namespace UsingInsideOutside.Other
{
    using System;
    public class Foo
    {
        public static double Calculate(double value)
        {
            return Math.PI * value;
        } // Calculate
    } // Foo// UsingInsideOutside.Other

Si ejecutamos nuevamente nuestro código de ejemplo, ¿qué resultado obtendré?.

 

3.14...

 

Entonces... está claro que hay implicaciones directas entre poner el using dentro o fuera del namespace,... pero ¿porqué?.

La explicación es muy simple.

Al poner el using dentro del namespace, el compilador busca PI dentro de los using, encontrándolo en using System;.

Si no lo encuentrara, lo buscaría en UsingInsideOutside.

Para demostrar esto último, simplemente debemos renombrar using System; por otro namespace como using System.Collections;, o eliminar o comentar using System; y observar que el valor que devuelve es 6.28...

En el caso de poner el using fuera del namespace, el compilador busca los using, y como no encuentra ninguno, pasa a buscarlo en UsingInsideOutside.

Allí encuentra a PI y es el que utiliza.

Ahora bien, ¿qué ocurre si ponemos los dos namespaces (using System; y using UsingInsideOutside;) dentro del namespace?.

En este caso, el compilador dará un error de ambigüedad, ya que no sabrá si debe hacer referencia a PI de System o a PI de UsingInsideOutside.

Como podemos ver, la cosa se complica poco a poco.

Así que vamos con otro paso... ¿qué pasa entonces si ponemos las dos referencias (using System; y using UsingInsideOutside;) fuera del namespace?.

El compilador no dará errores, es más... la aplicación se ejecutará correctamente.

¿Qué resultado dará entonces?.

6.28...

¿Porqué?.

Simplemente porque estando en UsingInsideOutside.Other, busca los using dentro de su namespace, y como no encuentra ninguno, se pone a buscar los de su propio ensamblado raiz primero (UsingInsideOutside) para buscar posteriormente los de System.

A efectos de simplificar, es exactamente el mismo resultado que utilizar el ejemplo de poner el using System; fuera del namespace sin hacer referencia a UsingInsideOutside.

Así que como podemos observar, el orden de los factores altera el poducto.

NO es lo mismo poner los using dentro del namespace que fuera.

Por eso, decidir un aspecto como este es muy importante y no es para nada trivial.

¿Y cuales son las implicaciones de todo esto en tiempo de ejecución?

Ahora bien... ¿y como se comporta .NET en tiempo de ejecución?

Aquí viene lo bueno... o mejor dicho, la segunda parte que aporta un valor añadido a lo ya he comentado (por si no era interesante por sí solo).

La pregunta sería: ¿qué implicaciones existen en .NET en tiempo de ejecución y por lo tanto en rendimiento en usar los using dentro o fuera de un namespace?.

Según leí un día de acuerdo a una recomendación (creo recordar que del equipo de StyleCop), si ponemos los using dentro del namespace, .NET cargará el ensamblado referenciado sólo cuando éste es llamado. Es decir, cuando la clase que lo utiliza se carga y se lanza.

Por contra, si ponemos los using fuera del namespace, .NET cargará el ensamblado o ensamblados al cargar el ensamblado principal (el ejemplo entero que hemos preparado para ser más concretos).

¿Y esto afectaría al rendimiento?. Si es así, evidentemente sí, y no sólo al rendimiento, sino también al consumo de memoria de un ensamblado.

El problema no obstante es que yo no he logrado realizar ejemplos que demuestren esto, así que lo voy a dejar como conjetura. De hecho, las pruebas que he hecho no desvelan apenas variaciones. Es más, el IL es casi idéntico.

Cierto es que es un ejemplo tan sencillo que no se aprecia diferencias entre una forma y otra.

No obstante, he ejecutado una instrucción para saber qué ensamblados cargaba el ejemplo con using dentro y fuera del namespace y en ambos casos son los mismos, así que casi podríamos decir que la afirmación anterior es un "mito".

Intentaré sacar más conclusiones al respecto de esto último, de hecho lo dejo por aquí por si alguien se ha topado con este asunto o no y quiere compartir sus experiencias, pero creo firmemente que no hay relación entre declarar los using dentro o fuera de un namespace y la carga y rendimiento de la aplicación.

Conclusiones

Después de todo esto y pese a la última parte de la entrada (la del "mito"), es que la recomendación de StyleCop tiene su sentido, y yo por lo menos es la que voy a seguir usando, eso sí, teniendo en cuenta estos detalles que a veces pasan desapercibidos y que a lo mejor nunca te habías cuestionado. Que sirva esta entrada para que no pensemos haber visto fantasmas en nuestro código.

Espero que os haya parecido interesante lo tratado en esta entrada.

Compártelo

¿Qué piensas tú o cómo lo haces en tus proyectos y porqué?.

 

Si por alguna "extraña" razón te ves empujado a instalar (por necesidades del guión) las Windows Phone Developer Tools en un sistema operativo Windows 2008, quizás te hayas encontrado con la desagradable situación de que aparecerá un error en la ventana de instalación, indicándote que sólo se puede instalar las tools en sistemas operativos Windows Vista y Windows 7.

Bien, esto ha sido criticado hasta la saciedad porque a veces, no muy frecuentemente pero sí necesariamente, nos encontramos con alguna extraña situación en la que deseamos instalar estas herramientas en otros sistemas operativos.

La pregunta entonces es... ¿y cómo resolver esto?.

Pues manualmente. ¿Y cómo?. Lo voy a explicar ahora para quién no lo sepa.

Si quieres instalar tanto las Windows Phone Developer Tools 7.0 RTM como las Windows Phone Developer Tools 7.1 Beta, deberás realizar estos sencillos pasos:

1) Para las Windows Phone Developer Tools 7.0 RTM, su archivo es el vm_web.exe, mientras que para las Windows Phone Developer Tools 7.1 Beta, el archivo es el vm_web2.exe.
2) Nos situaremos con una ventana de DOS en la carpeta que contiene las herramientas o tools que queremos instalar.
3) Escribiremos esto: <ejecutable> /x, por ejemplo: vm_web.exe /x.
4) Aparecerá una ventana de Windows dentro de la cuál seleccionaremos la carpeta donde queremos descomprimir los archivos de instalación de las herramientas o tools.
5) Una vez descomprimido, nos situaremos en la carpeta donde se encuentran los archivos de instalación y buscaremos el archivo baseline.dat.
6) Abriremos baseline.dat con un editor de textos como el bloc de notas y buscaremos el texto [gencomp7788], sección dedicada al control y bloqueo de instalación del paquete en los sistemas operativos.
7) Dentro de esta sección localizaremos el texto InstallOnLHS y cambiaremos su valor de 1 a 0.
8) Dentro de esta sección localizaremos también el texto InstallOnWin7Server y cambiaremos su valor de 1 a 0.
9) Guardaremos las modificaciones del archivo baseline.dat y lo cerraremos.
10) Desde la línea de comandos ejecutaremos el comando setup.exe /web.

De esta forma, las Windows Phone Developer Tools se instalarán correctamente en Windows 2008.

Supongo que servirá para otros sistemas operativos, aunque esto no lo he probado.

Espero que sirva. :)

Publicado por Jorge Serrano | 3 comment(s)
Archivado en:

Microsoft ha actualizado el fichero de ayuda de documentación (core) sobre Windows PowerShell 2.0.

Esta actualización es de Mayo de 2011 y contiene las últimas modificaciones y correcciones de algunos de los aspectos relativos a esta documentación.

El archivo descargable es un fichero .exe que una vez descomprimido, nos permite acceder a un fichero de ayuda de Windows (extensión chm) de 1.8 Mb.

Podrás acceder a la descarga de este archivo en esta página Web de Microsoft.

Publicado por Jorge Serrano | con no comments
Archivado en:

Microsoft publicó hace ya algunos meses una guía especialmente enfocada a los desarrolladores de iPhone que quieran pasarse a desarrollar aplicaciones para Windows Phone 7.

La guía que está disponible en inglés y en formato docx y pdf, tiene casi 100 páginas y tiene un peso de aproximadamente 4 Mb por fichero (docx, pdf) aproximadamente.

Incluso me presto a decir que aunque no seas desarrollador de iPhone, esta guía resulta igualmente útil.

Encontrarás esta información en el blog de Windows Phone Interoperability.

Haz clic aquí para acceder al documento en formato Word (docx) directamente (4 Mb).

Haz clic aquí para acceder al documento en formato pdf directamente (3 Mb).

Publicado por Jorge Serrano | 3 comment(s)
Archivado en:

Microsoft ha publicado hace unos días una guía especialmente enfocada a los desarrolladores de Android que quieran pasarse a desarrollar aplicaciones para Windows Phone 7.

La guía que está disponible en inglés y en formato docx y pdf, tiene casi 100 páginas y tiene un peso de 2.5 Mb por fichero (docx, pdf) aproximadamente.

Incluso me presto a decir que aunque no seas desarrollador de Android, esta guía resulta igualmente útil.

Encontrarás esta información en el blog de Windows Phone Interoperability.

Haz clic aquí para acceder al documento en formato Word (docx) directamente (2.5 Mb).

Haz clic aquí para acceder al documento en formato pdf directamente (2.5 Mb).

Publicado por Jorge Serrano | 1 comment(s)
Archivado en:

La siguiente información tiene que ver con un archivo pdf gratuito con un curso muy rápido sobre Microsoft WebMatrix.

Este pdf ocupa aproximadamente 5.2 Mb y tiene 39 páginas.
El documento puede ser accedido directamente en este enlace (5.2 Mb).

Si quieres acceder a la página Web de donde he obtenido esta información, puedes acceder a este otro enlace.

No olvides visitar la sección de recursos del sitio Web de donde he obtenido esta información. Muy interesante también.

Publicado por Jorge Serrano | con no comments
Archivado en:

De vez en cuando, y cuando el tiempo me lo permita, pondré pequeños recortes de código a modo de trucos y tips sobre codificación de aplicaciones Windows Phone 7.

Espero que a más de uno le resulte de utilidad.

Tip 001 - Marcar un número de teléfono

Desde Windows Phone 7 no podemos marcar un número de teléfono de forma directa, pero sí podemos hacerlo esperando a que el usuario de permiso para que se marque ese número telefónico.

Para ello, deberemos utilizar el namespace Microsoft.Phone.Tasks (using Microsoft.Phone.Tasks).

El código de esta utilidad podría ser por ejemplo el siguiente:

 

PhoneCallTask phoneCallTask = new PhoneCallTask();
phoneCallTask.PhoneNumber = "600111222";
phoneCallTask.DisplayName = "Primo Enrique";
phoneCallTask.Show();

 

De esta manera, aparecerá en pantalla un pequeño mensaje preguntándonos si permitimos la llamada de teléfono al número indicado.

A la izquierda del número de teléfono aparecerá una pequeña etiqueta con el texto que hemos indicado en DisplayName.

Publicado por Jorge Serrano | 1 comment(s)
Archivado en:

Llevo con este terminal Windows Phone 7 apenas tres días y sigo exprimiéndolo buscando códigos y opciones ocultas (me encantan estas cosas, que queréis que os diga).

El caso es que he sabido de un menú secreto que quiero compartir, eso sí, antes quiero decir que no me hago responsable de su uso, y si alguien estropea su terminal... luego no quiero responsabilidades.

Dicho esto, paso a comentaros como funciona.

 

  • Básicamente hay que posicionarse en el terminal como si fuéramos a realizar una llamada y allí pondremos el siguiente código: ##634#.
  • Marcaremos la llamada y esperaremos a que el terminal responda.
  • La respuesta del terminal será preguntando por un código. Ahí indicaremos el código 277634#*#.
  • Una vez introducido el código, accederemos al menú oculto del sistema donde consultaremos diferentes parámetros de configuración, de versiones de sistema, reseteo a la configuración de fábrica, posibilidades de leer y escribir en el registro del terminal, o el cambio de acceso al puerto USB.

 

A partir de aquí, es cuestión de echar imaginación, porque de momento no he encontrado información de todas sus opciones. Algunas son obvias y otras no tanto. He jugueteado con alguna y bueno, las hay más y menos curiosas.

Repito, cada uno que haga lo que quiera con esto, pero no me pidáis responsabilidades si algo va mal. Avisados quedáis que cuando se tocan estas cosas, el diablo está en medio y puedes dejar a tu terminal como un fantástico pisapapeles.

Publicado por Jorge Serrano | 1 comment(s)
Archivado en:

 

Ayer se presentaba una preview de lo que será la nueva UI (interfaz de usuario) de Windows 8.

Casi un cuarto de siglo después de los primeros sistemas operativos presentados por Microsoft, Windows 8 tiene una interfaz de usuario realmente renovada, obviamente multitarea, y basada en las tiles o losetas de Windows Phone 7 y que tanto ha gustado.

En un primer video, Microsoft por medio de Jensen Harris (Director of PM de Windows User Experience) nos da unas pinceladas iniciales sobre las novedades visuales y de navegación más atractivas del nuevo Windows 8.

Queda aún bastante por hacer, pero este video al que le seguirán muchos más, me da que pensar que Microsoft tiene muy avanzado su nuevo sistema operativo, y que no están haciendo otra cosa que darnos el caramelo para que todos estemos deseando tenerlo entre nuestra manos.

En mi caso y después de ver el video sólo he pensado en adquirir una tableta con este sistema operativo. Merece la pena esperar, pero no sé si podré aguantar.

El video de Jensen Harris en Youtube se puede encontrar en este enlace.

Sobre el soporte de aplicaciones en Windows 8, prácticamente lo de siempre en cuanto a productos Microsoft, y posiblemente incluso Internet Explorer 10 con el presumible adelanto de más características de HTML5, sobre el que Microsoft está haciendo especial hincapié.

Cierto es que hay preguntas acerca de tanto soporte y apoyo de Microsoft hacia HTML5 teniendo Silverlight ahí, pero es indudable que Silverlight es una posibilidad, HTML5 otra, y la combinación de varios "mundos" otra más.

A mí me mucho miedo las macedonias de fruta tecnológicas, pero a veces para un proyecto es muy interesante abordar y mezclar no todas ellas, pero sí un par o tres de ellas.

Volviendo al tema de Windows 8, debemos recordar el guiño de Windows 8 y los procesadores ARM para dispositivos de bajo consumo. Es indudable (no lo sé pero me juego lo que sea) a que Microsoft ha optimizado sus esfuerzos en compatibilizarlo con estos procesadores, y que el resto de aplicaciones Microsoft se están optimizando o rehaciendo para que se ejecute con estos procesadores, consuman menos energía y tengan un rendimiento muy alto.

Lo que está claro es que pese al nuevo sistema operativo Windows 8, con respecto a las tabletas, hay una interesante guerra con Apple iOS, Android, WebOS de HP y por supuesto Windows 8.

Sobre la UX comentar que me ha parecido espectacular... está claro que Microsoft se ha puesto las pilas y que está trabajando muy bien.

Si Microsoft quería que se hablara de Windows 8, lo ha conseguido. :)

Información oficial de prensa de Microsoft acerca de la noticia.

 

 

Publicado por Jorge Serrano | con no comments
Archivado en:

 

Actualmente me encuentro en un apasionante proyecto de .NET y por razones forzosas de guión y otras que no vienen al caso comentar ahora, hemos tenido que trabajar para el mismo proyecto con diferentes servidores TFS, lo que significa montar un TFS en varios servidores y mover el repositorio completo del proyecto del servidor 1 al servidor 2, etc, desmantelando el servidor 1, pasando a trabajar con el servidor 2, y así unas cuantas cosas más que darían para una entrada más larga que nos desviaría del problema y solución que quiero compartir.

Lo importante es que cuando hemos intentado recuperar en el segundo servidor los proyectos con el TFS Explorer, éste nos ha dado la bienvenida con un fantástico error TF31001.

Lo curioso es que aunque la máquina la hemos llamado igual para evitar conflictos, lo que sí hemos variado ha sido el Team Project o proyecto de equipo creando uno nuevo recolocando determinados directorios, etc.

Cuando hemos arrancado Visual Studio nos ha pedido las credenciales (bien), las hemos añadido y han aparecido los Team Projects (bien), sin embargo algo no iba bien.

De hecho, los proyectos que aparecían no eran los nuevos, sino los antiguos, y al acceder a él nos da un error muy simpático que acorto: "TF31001 - Value cannot be null".

Es como si tuviéramos enganchada la información de un servidor en el otro... vamos,... en cristiano... está leyendo la caché y no refrescando la información real.

¿Cómo resolver este error?.

Tan fácil como irse a la caché de Team Foundation de cada máquina local desde donde estamos abriendo el repositorio de TFS y eliminar el contenido de esa carpeta caché.

Para Windows Vista y Windows 7, esta carpeta se encuentra en los sistemas cliente en un lugar físico similar a (dependiendo de idioma, versión, etc):

C:\Users\<user>\AppData\Local\Microsoft\Team Foundation\3.0\Cache

En sistemas operativos anteriores a Windows Vista y Windows 7, la carpeta se puede localizar en (dependiendo de idioma, versión, etc):

C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Team Foundation\3.0\Cache

Bastará con cerrar Visual Studio, borrar toda la información de ese directorio, abrir Visual Studio y voilá.

Espero que sirva. Si conoces otra forma diferente de esta hazlo saber, o si no estás de acuerdo con esta forma, indica porqué.

Es la única que he visto que funcione y sirva sin comprometer el funcionamiento ni el sistema.

 

Un saludo.

 

 

 

Publicado por Jorge Serrano | 1 comment(s)
Archivado en: