Application Architecture Guide 2.0 - Beta 2

 

A finales del mes pasado os comentaba en otra entrada que Microsoft había liberado la versión Beta 1 de su documentos de buenas prácticas Application Architecture Guide 2.0.

En esta ocasión, os traigo la noticia de la aparición de la versión Beta 2 de ese documento.

El documento, en inglés, tiene un tamaño de 2.7 Mb y está en formato pdf.

Se trata como dije en la entrada anterior a esta, un documento "o libro" de obligada lectura.

Las 365 páginas de este imprescindible libro está dividida en 5 partes y diferentes capítulos dentro de cada parte.

Los 5 bloques o partes principales son:

  • Parte 1: Fundamentals
  • Parte 2: Design
  • Parte 3: Layers
  • Parte 4: Archetypes

No he podido revisarlo aún, pero con respecto a la Beta 1, creo que a simple vista resalta que la Parte 4: Quality Attributes ha sido eliminada y se ha metido dentro de la Parte 2. La Parte 5 es ahora la Parte 4.

Conviene recordar, que el documento está aún en fase Beta y sujeto a cambis ya ajustes.

Podemos acceder al documento desde este enlace.

Más información sobre Application Architecture Guide 2.0 en este otro enlace.

Cross Posted from Jorge Serrano - MVP Visual Developer - VB
Posted por Jorge Serrano con no comments
Archivado en:

20/11/2008 :: Evento(s) de MAD.NUG... ¡2 por el precio de 1!

 

Acceso a la página oficial de MAD.NUG.  

El próximo 20 de noviembre de 2008 MAD.NUG tiene la suerte de contar no con 1,... sino con ¡¡¡2 eventos!!!. Un día para saciar el apetito del más Geek.

Primer evento: 20 de noviembre de 2008 de 9:00 a 12:30

Con el título de VB/VS Spanish Tour, tenemos la suerte de contar en Madrid (concretamente en Getafe), con los equipos de producto de Visual Studio y Visual Basic. Las personas que vienen están directamente implicadas en Visual Studio y Visual Basic, y vienen desde Redmond (USA) aprovechando el reciente Tech·Ed de Europa que se ha celebrado en Barcelona.

Es una fantástica oportunidad para preguntar esas cosas que nunca te atreviste a preguntar, o de simplemente conocer de primera mano algunas de las novedades o aspectos destacables de Visual Studio desde la versión 2005 hasta lo más reciente que se acerca en Visual Studio 2010, así como de Visual Basic y sus características más interesantes.

Este evento es de carácter gratuito y técnico, en inglés, y dividido en dos sesiones de una duración aproximada de tres horas.

Aunque parezca un evento destinado para desarrolladores de VB, los desarrolladores de C# podrán sacar mucho provecho de este evento debido a que las novedades de Visual Basic y C# son muy parejas, por lo que las novedades que afectan a uno, afectan al otro de igual manera.

La dirección para acudir al evento es la siguiente:

Centro de Formación en Tecnologías de la Información y las Comunicaciones.
C/ Arcas del agua s/n, Getafe (Madrid)
Getafe Madrid 28905
España

La agenda del evento es: 

09:15 - Recepción

09:30 - Bienvenida

09:45 - VB 2005, VB 2008 and VB 2010 IDE
            XML Literals

11:00 - Cofee Break
11:15 - VB 2010 Language features
            LINQ to ADO/SQL & Objects
            Interop Toolkit & PowerPacks

12:30 - Q & A

Podrás registrarte para este evento en este enlace.

Segundo evento: 20 de noviembre de 2008 de 19:00 a 21:00

Como no hay dos sin tres, la mejor forma de completar el día es que por la tarde, alguien de Microsoft nos "amenice" con esas "cosas" nuevas o recientes que han llegado del PDC que se celebró en Los Ángeles hace muy pocas fechas. Cosas que todo el mundo ha oído comentar a diestro y siniestro.

David Salgado (Microsoft DPE España) nos hablará (en español) en este evento sobre el PDC Highlights, es decir, de esas cosas que hemos oído contar pero que a lo mejor no terminados de encajar del todo en el puzzle de tecnologías Microsoft... ¿seguro que no?,... ¡pues que no se diga!, porque ahora tenemos la oportunidad de encajar esas piezas de primera mano gracias a David, que estuvo presente en el mismo PDC.

La dirección para acudir al evento es la siguiente:

Microsoft Ibérica, S.R.L.
Sala Marie Curie
Pº del Club deportivo, 1 Centro empresarial La Finca- Edificio 1
Madrid Madrid 28223
España

La información del evento es:

El PDC es un evento internacional de Microsoft donde se presenta el futuro de muchos productos, herramientas y frameworks.
En esta sesión intentaremos dar un repaso a los anuncios más relevantes para el colectivo de desarrolladores.

Ponente: David Salgado
             Development Evangelist. Microsoft Iberica

¿Sigues pensando en no venir?. ;-) 

Podrás registrarte para este evento en este enlace.

Cross Posted from Jorge Serrano - MVP Visual Developer - VB
Posted por Jorge Serrano con no comments
Archivado en:

Porqué es bueno eliminar la refencia al ensamblado Microsoft.VisualBasic.dll en nuestros proyectos (II)

 

Introducción

En mi última entrada, hacía referencia al porqué puede resultar positivo eliminar la referencia al ensamblado Microsoft.VisualBasic.dll en nuestros proyectos de Visual Basic. Lo cierto es que estas cosas no las encuentras en los libros ni te las cuentan prácticamente nadie, porque simplemente, muchas veces no nos cuestionamos algunas cosas. De vez en cuando es bueno preguntarse el porqué y cómo funcionan las cosas, más que dar por hecho una verdad absoluta.

De acuerdo al título de la entrada, en realidad eliminar tal y como pongo en la entrada es quizás una palabra demasiado drástica, pero es lo suficientemente drástica como para llamar la atención, que es lo que precisamente busco, pero quizás lo más razonable sería decir por ejemplo, tratar de evitar el uso de Microsoft.VisualBasic.dll siempre que podamos en lugar de eliminar, pero aún y así, lo más interesante es describir lo nocivo que puede ser resultar el uso de Microsoft.VisualBasic.dll en nuestros proyectos. Cuando llegue a las conclusiones de esta entrada, pregúntese si realmente está más de acuerdo con la palabra eliminar o con la frase evitar el uso, y sobre todo, pregúntese porqué.

No obstante, para sostener la afirmación de mi primera entrada realicé unos primeros y pequeños estudios que ahora trato de completar con un giro de tuerca más sobre el uso de buenas prácticas, las clases, las funciones y los métodos que .NET nos ofrece y que muchas veces obviamos en nuestros desarrollos Software. 

Recordando los resultados del estudio anterior...

Para esta entrada, me baso en el estudio diferencial existente entre el ensamblado que usa Microsoft.VisualBasic.dll y el ensamblado al que hemos eliminado el uso de esta librería que vimos en la entrada anterior.

Adicionalmente, me apoyo en otro estudio y buenas prácticas que realicé en una entrada de Diciembre de 2006 y que podeis encontrar aquí esta entrada. En esa entrada, argumentaba un estudio sobre la iteración de cadenas en nuestras aplicaciones .NET. Argumentos y estudios que me sirven ahora para argumentar más aún algunas tesis que según mi modesto punto de vista, no son nada despreciables y que muestran las bondades de .NET vs el uso de instrucciones de Visual Basic 6 utilizadas en .NET.

Para tratar de ser justos, he vuelto a repetir las pruebas con JetBrains dotTrace que hice en la entrada anterior y he obtenido los siguientes datos:

La hebra de la aplicación (DatosCon) que utiliza el ensamblado que posee referencias a Microsoft.VisualBasic.dll tarda en total 21.722 ms, y en el proceso del control Button, 20.037 ms.

La hebra de la aplicación (DatosSin) que utiliza el ensamblado que no posee referencias a Microsoft.VisualBasic.dll tarda en total 17.692 ms, y en el proceso del control Button, 15.561 ms.

Es decir, la diferencia entre la hebra del primer (DatosCon) y segundo proceso (DatosSin) es de 4.030 ms. 4 segundos son muchos segundos. 

Estudiando un poco más a fondo todos estos resultados, lo verdaderamente importante no es la comparación de la ejecución de la hebra completa, ya que el proceso entero está basado en hacer el clic manualmente sobre el control Button, y es posible que esa diferencia de milisegundos esté motivada por mi reacción y pulso más que otra cosa.

Así que donde me quiero parar realmente es en el estudio de la hebra del control Button, que es la que realmente me intesa.

Ahí, la diferencia entre ambos procesos es de 4.476 ms a favor de (DatosSin), es decir, el proceso de ejecución que utiliza el ensamblado que no tiene referencia a Microsoft.VisualBasic.dll es casi 4 segundos y medio más rápido que el mismo proceso de (DatosCon). Si miramos las pruebas que hice de la entrada anterior, la diferencia entre ambos procesos es de 4.465 ms, así que ms arriba ms abajo, estamos más o menos dentro de esos márgenes.

Girando la tuerca un poco más...

Pero claro... aquí no acaba esto, ya que lo más sensato es comparar los dos ensamblados.

Me parece estupendo que uno de ellos "gane", pero ¿estamos seguros de que el ensamblado "ganador" es un ensamblado "perfecto"?.

Yo siempre digo que no hay nada perfecto, y cuando se habla de tecnología muchísimo menos. De hecho, lo voy a demostrar.

Utilizando nuevamente la herramienta JetBrains dotTrace, soy capaz de comparar ambos estudios y ver donde están los "cuellos de botella" o esas diferencias más notables.

En la siguiente imagen, podemos ver esas diferencias de forma gráfica:

Si atendemos a esta información, podremos observar que hay diferentes partes que están en color rojo.

Examinando todas las partes, nos damos cuenta de que hay una parte de la información que nos resulta llamativa. Me refiero a la parte del método TestConversion.

Según ese método, en el caso del uso de la librería WithoutReference.dll, el método que se ejecuta dentro del clic del control Button, consume la friolera cantidad de 15.539 ms de los 15.561 ms que consume todo el código contenido en el control Button.

Para estar utilizando funciones de .NET, el resultado no es que digamos esperanzador, por lo que lo primero que debemos hacer es estudiar el código de ese método.

Estudiando el código y aportando soluciones...

El método TestConversion tiene la funcionalidad de concatenar cadenas.

Concatenar cadenas es mucho más costoso que utilizar por ejemplo la clase StringBuilder que encontraremos en el nombre de espacio System.Text.

De acuerdo a la entrada que escribí en Diciembre del 2006 en el que mostraba la forma eficiente de trabajar con cadenas, deberíamos modificar el código de nuestra aplicación, para mejorar aún más el rendimiento del ensamblado que no utiliza Microsoft.VisualBasic.dll. El objetivo: crear un ensamblado lo más eficiente posible.

De esta forma, el código de nuestro ejemplo de acuerdo al método TestConversion, quedaría de la siguiente forma:

WithoutReference.Class1 (Class1.vb):

... 
Public Sub TestConversion()
    
Dim auxiliarText As New System.Text.StringBuilder
    
For i As Integer = 0 To 10000
        
If i Mod 2 = 0 Then
            ' Convert to String
            auxiliarText.Append(Convert.ToInt32(i).ToString)
        
Else
            ' Convert to Integer (Int32)
            auxiliarText.Append(Convert.ToString(i))
        
End If
    Next
End
 Sub
...

Si prestamos atención al código anterior, veremos que lo que hacemos es apoyarnos en la clase StringBuilder para realizar el mismo proceso.

En este punto, podría preguntarse si podríamos utilizar StringBuilder en el ensamblado que hace referencia a Microsoft.VisualBasic.dll. La respuesta es sí, por supuesto, pero si va a utilizar este objeto propio de .NET, ¿porqué no utiliza desde el principio solo y únicamente los objetos propios de .NET?. Se ahorraría problemas seguramente.

De hecho, el "cuello de botella" del ensamblado que hace uso de Microsoft.VisualBasic.dll está localizado dentro del mismo método, por lo que si utilizáramos StringBuilder, es prácticamente seguro que obtendríamos unos resultados muy óptimos, pero le aseguro, que los resultados más óptimos se encuentran localizados en el ensamblado que no hace uso de Microsoft.VisualBasic.dll. De todos los modos, aquí lo que tratamos de comparar son las funciones y métodos propios de Microsoft.VisualBasic.dll vs las funciones y métodos propios de .NET.

Si una vez modificado el código anterior ejecutamos nuestra aplicación, obtendremos unos resultados sorprendentes. 

Estudiando los resultados...

De acuerdo a los nuevos resultados obtenidos, estos arrojan unos datos demoledores a favor de las instrucciones de .NET.

En la siguiente imagen podemos ver la tabla de resultados:

Ahora y gracias a StringBuilder, podemos indicar que la ejecución total de la hebra es de 1.932 ms, mientras que la ejecución del control Button que contiene todas las instrucciones que nos importan, es de 795,4 ms. Ni siquiera 1 segundo. Dentro de esta parte, seguimos observando que TestConversion sigue consumiendo gran parte del tiempo de proceso de ejecución, pero hemos pasado de 15.539 ms a 772,6 ms.

La diferencia es notable evidentemente.

Sobre ILDASM...

Utilizando la herramienta ILDASM que viene con .NET Framework y que permite estudiar el código intermedio de nuestras aplicaciones, podemos apreciar que las diferencias reales entre los dos ensamblados (el ensamblado que tiene la referencia a Microsoft.VisualBasic.dll y el ensamblado que no tiene referencia a ese ensamblado) son mínimas.

Si se estudia con detenimiento el código intermedio, se pueden ver algunos pequeños detalles en el ensamblado con referencia a Microsoft.VisualBasic.dll que no tiene el otro ensamblado, como algún ajuste de conversión.

De todos los modos, lo mejor es utilizar .NET Reflector y mirar las clases, métodos y funciones de Microsoft.VisualBasic.dll, y comprobar como funciona realmente "por debajo".

Algunas conclusiones...

  • Ante esto tenemos una opción muy clara y evidente con una afirmación mucho más drástica si cabe: el uso exclusivo de Microsoft.VisualBasic.dll no nos favorece. Es decir, si lo que queremos es utilizar únicamente instrucciones de Microsoft.VisualBasic.dll, es prácticamente seguro que penalizaremos en rendimiento a nuestra aplicación. ¿Cuál es la penalización?. En realidad depende de cada proyecto, del código escrito en él, sus iteraciones, etc.
  • El uso híbrido de Microsoft.VisualBasic.dll e instrucciones puras .NET puede resultarnos útil y ventajoso. No es quizás lo más ventajoso, pero es claramente más favorable que el uso único y exclusivo de instrucciones heredadas de Visual Basic 6.
  • Si decidimos por un híbrido entre instrucciones puras .NET e instrucciones extraídas el ensamblado Microsoft.VisualBasic.dll, ¿porqué no utilizar directamente y únicamente las instrucciones de .NET?. Ese sería el escenario más adecuado y positivo. Por esa razón, una forma de habituarnos a trabajar sin el ensamblado Microsoft.VisualBasic.dll en Visual Studio 2008, es acceder a las Propiedades del proyecto y abrir la solapa de Referencias. Dentro de esa solapa, quitar la selección o la referencia al ensamblado Microsoft.VisualBasic.dll. De esta manera, el entorno nos avisará con un mensaje de error si estamos utilizando alguna instrucción de Visual Basic 6 habilitada por medio de Microsoft.VisualBasic.dll.

Así, ¿cuantas veces utiliza (yo lo hago) la instrucción VbCrLf?. Pues quizás no lo sepa, pero VbCrLf pertenece a la clase Contants del nombre de espacio Microsoft.VisualBasic. ¿Sorprendido?. Quizás lo lógico es utilizar \r\n en C#, o Environment.NewLine() en .NET, ¿pero VbCrLf?.

Como podemos ver, los "vicios" adquiridos y arrastrados por los desarrolladores que venimos de Visual Basic 6.0 son muchos, y erradicarlos va a ser un proceso muy largo y tedioso. ¿Porqué no empezar desde ya?.

Cross Posted from Jorge Serrano - MVP Visual Developer - VB

Porqué es bueno eliminar la refencia al ensamblado Microsoft.VisualBasic.dll en nuestros proyectos (I)

 

Introducción

En la última entrada de mi blog, escribí acerca de como eliminar la referencia al ensamblado Microsoft.VisualBasic.dll de nuestros proyectos.

En esa entrada, hubo algunas personas que dieron sus opiniones dentro del apartado de comentarios, algo que agradezco muchísimo, ya que siempre es importante la interactuación de la gente en un blog donde no suele haber un diálogo, sino un intercambio de opiniones o puntos de vista, y los razonamientos y pensamientos se hacen a trompicones.

Las dudas razonables...

Dentro de esos comentarios hubo uno iniciado por delm en el que afirmaba que le daba mucha lástima que se gastara energía en investigar cosas como la que indicaba en mi entrada, y dudaba que esos esfuerzos sirvieran para algo.

Desde luego, que cualquier investigación o análisis sirve, incluso si las conclusiones de esos estudios son nulos. Es positivo que se realicen estudios de todo tipo (con cierto criterio claro está) con el fin de aprender más acerca de las tecnologías y su uso.

Pero no solo es positivo en el campo de la investigación y su uso, sino que a veces es incluso hasta importante u obligatorio.

Por esa razón supongo, delm nos comentaba igualmente que se fundamentara las afirmaciones que se realizan en mi entrada con estudios o profiling en una o varias aplicaciones de un tamaño decente para ver si realmente vale la pena.

A mí me gustaría por otro lado, que delm también realizara esos estudios para fundamentar sus opiniones contrarias. Así nos enriqueceríamos todos.

No obstante, yo ya hice algunos estudios sobre esto hace tiempo, pero ni los tenía a mano, ni sinceramente, me encontraba con ganas de repetirlos debido al poco tiempo libre que tenía para hacer unos estudios concienzudos. Sin embargo, he sacado algo de tiempo para escribir esta segunda entrada y comentar un pequeño y espero que simbólico estudio que he hecho con el fin u objetivo de demostrar el porqué puede ser interesante eliminar al referencia de Microsoft.VisualBasic.dll y usar en su lugar las librerías de .NET.

Lo más sensato es hacer un estudio muchísimo más riguroso, pero espero que este pequeño estudio ofrezca algo de luz a quienes dudan de si es positivo o no eliminar la referencia a Microsoft.VisualBasic.dll.

Recordando...

Recordad, que cuando se llama a un método o función de Microsoft.VisualBasic.dll, ésta se convierte a su método o función equivalente dentro de .NET, lo cuál genera de alguna manera ciertas penalizaciones en el rendimiento de nuestras aplicaciones.

Demostrando...

La pequeña demostración (siento mucho no haber podido hacer una demostración mucho más completa como me hubiera gustado) es la siguiente:

He creado dos clases exactamente iguales en funcionalidad, aunque distintas en cuanto al código escrito, ya que una de ellas se basa en las funciones de VB 6 de Microsoft.VisualBasic.dll y el otro código, se basa en las funciones propias de .NET.

Para estudiar el profiling, me he apoyado en la herramienta JetBrains dotTrace.

Y así, empezamos a codificar la primera clase que he llamado WithReference.

El código de esta primera clase con funciones típicas de VB 6 para .NET es el siguiente:

WithReference.Class1 (Class1.vb):

Namespace WithReference

    
Public Class Class1

        
Public Function DeleteSpaces(ByVal data As StringAs String
            Return Trim(data)
        
End Function

        Public Function TakeLeftRightText(ByVal data As StringAs String
            Return Left(data, 1) & Right(data, 1)
        
End Function

        Public Function TransformTextMid(ByVal data As StringAs String
            Dim auxiliarText As String = ""
            For I As Byte = 1 To Len(data)
                auxiliarText &= Mid(data, I, 1)
            
Next
            Return auxiliarText
        
End Function

        Public Function TransformTextReplace(ByVal data As String, _
            ByVal findCharacter As StringByVal replaceCharacter As StringAs String
            Return Replace(data, findCharacter, replaceCharacter)
        
End Function

        Public Function TransformTextReverse(ByVal data As StringAs String
            Return StrReverse(data)
        
End Function

        Public Function TransformTextUpper(ByVal data As StringAs String
            Return UCase(data)
        
End Function

        Public Function TransformTextLower(ByVal data As StringAs String
            Return LCase(data)
        
End Function

        Public Function GetCharacterPosition(ByVal data As StringByVal searchText As StringAs Byte
            Return InStr(data, searchText)
        
End Function

        Public Sub TestConversion()
            
Dim auxiliarText As String = ""
            For i As Integer = 0 To 10000
                
If i Mod 2 = 0 Then
                    ' Convert to String
                    auxiliarText &= Conversion.Int(i).ToString
                
Else
                    ' Convert to Integer (Int32)
                    auxiliarText &= Conversion.Str(i)
                
End If
            Next
        End Sub

    End Class ' Class1

End Namespace ' WithReference

A la segunda clase la he llamado WithoutReference.
El código de la segunda clase con funciones propias de .NET equivalentes a las usadas en la clase anterior es el siguiente:

WithoutReference.Class1 (Class1.vb):

Namespace WithoutReference

    
Public Class Class1

        
Public Function DeleteSpaces(ByVal data As StringAs String
            Return data.Trim
        
End Function

        Public Function TakeLeftRightText(ByVal data As StringAs String
            Return data.Substring(1, 1) & data.Substring(data.Length - 1, 1)
        
End Function

        Public Function TransformTextMid(ByVal data As StringAs String
            Dim auxiliarText As String = ""
            For I As Byte = 0 To data.Length - 1
                auxiliarText &= data.Substring(I, 1)
            
Next
            Return auxiliarText
        
End Function

        Public Function TransformTextReplace(ByVal data As String, _
            ByVal findCharacter As StringByVal replaceCharacter As StringAs String
            Return data.Replace(findCharacter, replaceCharacter)
        
End Function

        Public Function TransformTextReverse(ByVal data As StringAs String
            Dim charArray(data.Length) As Char
            For i As Byte = 0 To data.Length - 1
                charArray(i) = data(data.Length - (i + 1))
            
Next
            Return New String(charArray)
        
End Function

        Public Function TransformTextUpper(ByVal data As StringAs String
            Return data.ToUpper
        
End Function

        Public Function TransformTextLower(ByVal data As StringAs String
            Return data.ToLower
        
End Function

        Public Function GetCharacterPosition(ByVal data As StringByVal searchText As StringAs Byte
            Return data.IndexOf(searchText, 1)
        
End Function

        Public Sub TestConversion()
            
Dim auxiliarText As String = ""
            For i As Integer = 0 To 10000
                
If i Mod 2 = 0 Then
                    ' Convert to String
                    auxiliarText &= Convert.ToInt32(i).ToString
                
Else
                    ' Convert to Integer (Int32)
                    auxiliarText &= Convert.ToString(i)
                
End If
            Next
        End Sub

    End Class ' Class1

End Namespace ' WithoutReference

Finalmente he compilado las clases. WithReference con Visual Studio 2008, y WithoutReference siguiendo el patrón de la entrada anterior donde mostraba como compilar una clase con .NET eliminando las referencias a Microsoft.VisualBasic.dll.

La diferencia de tamaños entre las clases son:

  • WithReference.dll (11,5 Kb)
  • WithoutReference.dll (4,5 Kb)

Además de los tamaños de las clases, existen más diferencias en tiempo de ejecución tal y como veremos a continuación.

Para este experimento, he iniciado una aplicación Windows con C# y con un control Button, al que he agregado una referencia con el ensamblado WithReference.dll.
Dentro del código del formulario windows he escrito el siguiente código:

Aplicación Windows (MainForm.cs):

private void btnTestProfiler_Click(object sender, EventArgs e)
{
    
this.Text = "Proceso iniciado...";
    
this.Enabled = false;
    WithReference.
Class1 classTest = new WithReference.Class1();
    
for (int i = 0; i < 100; i++)
    {
        
string result;
        result = classTest.DeleteSpaces(
" Testing ");
        
byte position;
        position = classTest.GetCharacterPosition(
"Testing""i");
        result = classTest.TakeLeftRightText(
"Testing");
        classTest.TestConversion();
        result = classTest.TransformTextLower(
"ReSuLtS");
        result = classTest.TransformTextUpper(
"ReSuLtS");
        result = classTest.TransformTextMid(
"Text to extract letter by letter");
        result = classTest.TransformTextReplace(
"This is a sample text, to replace it by other different text.""a""n");
        result = classTest.TransformTextReverse(
"This is a sample text, to do the reverse of this text.");
    }
    
this.Text = "Proceso finalizado.";
    
this.Enabled = true;
}

He generado el fichero ejecutable y he copiado el ejecutable y la librería en un directorio aparte.

Una vez hecho esto, he repetido el proceso quitando la referencia a WithReference.dll y agregando una referencia al ensamblado WithoutReference.dll.

El código de la aplicación para este segundo caso es el siguiente:

Aplicación Windows (MainForm.cs):

private void btnTestProfiler_Click(object sender, EventArgs e)
{
    
this.Text = "Proceso iniciado...";
    
this.Enabled = false;
    WithoutReference.
Class1 classTest = new WithoutReference.Class1();
    
for (int i = 0; i < 100; i++)
    {
        
string result;
        result = classTest.DeleteSpaces(
" Testing ");
        
byte position;
        position = classTest.GetCharacterPosition(
"Testing""i");
        result = classTest.TakeLeftRightText(
"Testing");
        classTest.TestConversion();
        result = classTest.TransformTextLower(
"ReSuLtS");
        result = classTest.TransformTextUpper(
"ReSuLtS");
        result = classTest.TransformTextMid(
"Text to extract letter by letter");
        result = classTest.TransformTextReplace(
"This is a sample text, to replace it by other different text.""a""n");
        result = classTest.TransformTextReverse(
"This is a sample text, to do the reverse of this text.");
    }
    
this.Text = "Proceso finalizado.";
    
this.Enabled = true;
}

He vuelto a compilar el proyecto y lo he apartado en otro directorio junto a la librería del ensamblado WithoutReference.dll.

De esta manera, tengo los dos programas listos para ser procesados con la herramienta de rendimiento y profiling.

Estudiando comportamientos...

He arrancado la herramienta JetBrains dotTrace y he ejecutado el primer ejecutable (con el ensamblado WithReference.dll) y he obtenido unos datos muy diferentes a los que muestra el segundo ejecutable (con el ensamblado WithoutReference.dll).

Los datos obtenidos del uso de WithReference.dll los he denominado DatosCon.

Los datos obtenidos del uso de WithoutReference.dll los he denominado DatosSin.

 

En este punto, lo que tenemos que hacer es estudiar los comportamientos de los dos ensamblados.

En el caso del uso del ensamblado con referencias a Microsoft.VisualBasic.dll, vemos que el proceso de ejecución nos ha durado 24.445 ms, y el proceso principal del control Button, 20.292 ms.

Por su parte, el ensamblado sin referencia a Microsoft.VisualBasic.dll, ha tardado en el proceso general 17.877 ms, mientras que en el proceso principal del control Button, el tiempo que ha tomado es de 15.827 ms.

Algunas conclusiones...

Las conclusiones a simple vista son bastante claras.

El ensamblado que no tiene referencia a Microsoft.VisualBasic.dll, tiene un menor tamaño en su ensamblado y es más rápido en su ejecución.

De todos los modos, tengo pensado agregar alguna entrada más que tendrá por objetivo estudiar algunos de los resultados obtenidos en estas pruebas, y mirar un poco el código intermedio de ambos ensamblados.

Espero que esto, ayude a clarificar aún más mis afirmaciones, las cuales no son verdades absolutas, pero sí pueden ser consideradas por algunos con un poco más de fundamento.

Cross Posted from Jorge Serrano - MVP Visual Developer - VB

Cómo eliminar la refencia al ensamblado Microsoft.VisualBasic.dll en nuestros proyectos

 

Introducción

Tuve la oportunidad a principios de Octubre, de asistir a través del Grupo de Usuarios de Madrid (MADNUG) al evento que el Guille (Guille Community Tour) realizó con motivo del tour que ha realizado por diferentes ciudades de España.

En aquella sesión, el Guille comentaba que en un proyecto de Visual Basic con .NET, era imposible eliminar la referencia al ensamblado Microsoft.VisualBasic.dll (Visual Basic Runtime Library) que el compilador agrega por compatibilidad hacia atrás. El Guille comentó que aunque lo quitaras de las referencias del proyecto, el compilador agregaba el "famoso" ensamblado porque sí, y por lo tanto aparecía siempre ahí. Y que aunque lo tratáramos de eliminar, era imposible y había que esperar a ver si con la próxima versión de Visual Studio .NET (Visual Studio .NET 2010) era por fín posible eliminar esa referencia.

Esto es una verdad a medias, y en aquel momento, no quise levantar la voz indicando mi discrepancia, ya que aunque recordaba que sí se podía eliminar esa referencia, no recordaba con exactitud como, y no hay peor cosa que decir las cosas a medias y confundir aún más al personal. Por eso, no quise comentar nada, pero después de mirar algunas cosas, recordar otras y pelearme con el compilador de Visual Basic, la respuesta es clara y contundente... recordaba bien y sí se puede eliminar la referencia al ensamblado Microsoft.VisualBasic de nuestro proyecto, aunque no de forma directa desde Visual Studio 2008.

¿Cómo?. Eso es justamente lo que voy a tratar en esta entrada, como eliminar la refencia del ensamblado Microsoft.VisualBasic.dll en un proyecto, por ejemplo, en una librería de clases.

¿Qué es Microsoft.VisualBasic.dll?

Este ensamblado es el culpable de incluir compatibilidad hacia atrás con Visual Basic antes de la llegada de .NET. De hecho, este ensamblado contiene métodos y funciones como Left, Right, Trim,... etc., funciones y métodos que no son propios de .NET y que son utilizados por Microsoft.VisualBasic.dll para actuar de wrapper o envoltorio con las funciones propias de .NET que hacen la misma acción. A mí me recuerda esto a una especie de boxing y unboxing (que se entienda lo que digo por favor, que ya sé que no es lo mismo y si se entiende literalmente mi afirmación, es una burrada).

En realidad, el proceso es realmente simple, y consiste en que al llamar a una función de Microsoft.VisualBasic.dll, ésta llama internamente a su equivalente en .NET. De esta manera, un programador que viene de Visual Basic en versiones previas a .NET, no sufre un choque drástico de cambios respecto a .NET y programa casi de la misma forma en la que lo hacía antes.

El problema, es que el programador de Visual Basic continuará "trabajando" con esos vicios adquiridos.

¿Mi opinión al respecto?. Que me parece una mala práctica que desde siempre critiqué, pero que está ahí incluida para dar esa cobertura que algunos programadores de Visual Basic ¿necesitan? para dar ese paso a .NET. El caso es que llevamos ya cerca de siete años utilizando esta librería, y a mí por lo menos, me parece un paso atrás... pero es lo que hay... de momento.

¿Mi recomendación?. ¡No usarla!. En lo posible, tratar de obviarla. Una ventaja de los desarrolladores de C# respecto a esto, es que para ellos, eso de Microsoft.VisualBasic.dll no saben lo que es y ni siquiera saben de su existencia (aquí les envidio y mucho).

De hecho, es probable (y lo lógico) que en un futuro próximo, Microsoft decida eliminarla, por lo que nuestras aplicaciones de .NET que utilicen esta librería tendrían algunos problemas a la hora de migrarla a una versión más nueva de .NET que ya no usara esta librería. No os durmais, porque nunca se sabe si van a hacer el cambio o cuando lo harán... yo desde luego, lo haría para la próxima versión de .NET.

De no arreglar esto, el problema de todo esto como ya os he adelantado, seguirá realizándose arrastrando esos vicios adquiridos de Visual Basic a .NET.

Y si queremos analizar otro motivo del porqué no debemos usar esa librería, es porque lo queráis o no, "engorda" de alguna manera nuestro ensamblado, consume más recursos en el sistema (muchas veces innecesarios), agrega muchísimas funciones de tipo compartido o Shared, y porque el rendimiento de la aplicación se ve afectado.

Una instrucción declarada o utilizada a través de Microsoft.VisualBasic.dll, es reconvertida por lo tanto a su correspondiente instrucción en .NET, por lo que al final, estamos haciendo de alguna manera dos cosas para hacer una sola. Es como abrir un boquete en la pared al lado de la puerta para entrar en la casa, cuando en realidad ya tenemos esa puerta hecha.

My y Microsoft.VisualBasic.dll

También entiendo que el uso de My es muy útil para diferentes proyectos, pero si podemos evitar su uso, mejor que mejor... y ¿cómo podemos eliminar My en nuestro proyecto?,... quitando Microsoft.VisualBasic.dll... ya que mucha de la funcionalidad contenida en My, está implementada por tipos definidos dentro de Microsoft.VisualBasic.dll, así que por todo lo comentado anteriormente y por el "famoso" My, lo ideal es poder prescindir de la referencia a este ensamblado y eliminar de un plumazo a My y al poco deseado Microsoft.VisualBasic, algo que veremos como hacerlo a continuación.

Quitando la referencia a Microsoft.VisualBasic.dll

Lo primero y más importante, es que para llevar a cabo esta tarea, desgraciamente no podemos utilizar el entorno de desarrollo de Visual Studio (por lo que he podido ver), por lo que para hacer esto, deberemos ir a la tediosa línea de comandos del compilador de Visual Basic (vbc :: Visual Basic Compiler).

En mi caso, estoy utilizando Visual Studio 2008.

Otra "mala" noticia es que la línea de comandos requiere que escribamos más comandos de los estrictamente necesarios, y que agregemos toda y cada una de la información necesaria al ensamblado indicándoselo así a vbc.exe, que al fin y al cabo, es el programa al que llama Visual Studio 2008.

En resumidas cuentas, que el ejemplo que voy a describir aquí funciona, pero que dependiendo de la complejidad del proyecto, es posible que tengamos que modificar algunos de los parámetros de la línea de comandos que indico en el siguiente ejemplo.

Una vez dicho esto, nos ponemos manos a la obra.

Lo primero de todo es crear nuestro proyecto de Biblioteca de Clases con Visual Basic como lenguaje (obviamente).

El código de nuestro ejemplo es el siguiente:

NombreEspacio.ClaseEjemplo (ClaseEjemplo.vb):

Namespace NombreEspacio

 

Public Class ClaseEjemplo

Public Function Cuadrado(ByVal valor As Long) As Long

Return valor ^ 2

End Function

End Class ' ClaseEjemplo

 

End Namespace ' NombreEspacio

Como podemos observar, dentro del código le he indicado el nombre de espacio y la clase con una función pública.

Una vez hecho esto, accederemos a las propiedades del proyecto y en concreto a la solapa Aplicación, y eliminaremos el contenido del Espacio de nombres de la raíz. Nuestro proyecto quedará como se indica a continuación:

 

Con esta modificación, lo que hacemos es que la clase tenga en consideración el nombre de espacio que le hemos indicado a Namespace y omita el espacio de nombres de la raiz con el fin de que no nos duplique el nombre de espacio. Esto nos resultará además muy útil para la línea de comandos, ya que el compilador de Visual Studio 2008 también lee el archivo vbproj que contiene información para crear nuesto ensamblado, y que en nuestro caso omitiremos para dejar todo más claro.

Una vez finalizada esta acción, vamos a eliminar las referencias de nuestro proyecto que no queremos utilizar, y entre ellas Microsoft.VisualBasic.

Para eliminar las referencias de nuestro proyecto, seleccionaremos la opción Propiedades de nuestro proyecto y elegiremos la solapa Referencias. Allí eliminaremos las referencias que deseamos quitar al proyecto.

En nuestro caso, hemos dejado únicamente la referencia a System.

En las referencias del proyecto, observamos y verificamos que tenemos únicamente una referencia al ensamblado System.

 

Cuando hayamos modificado la configuración y las referencias del proyecto como se indicaban en las imágenes anteriores, pasaremos a compilar el ensamblado en Visual Studio 2008.

Nuestro ensamblado quedará tal y como se indica en la siguiente imagen (utilizando Reflector):

 

Como podemos observar, nuestro ensamblado contiene tres referencias, a la librería Microsoft.VisualBasic, a mscorlib, y a System.

Los namespaces de nuestro ensamblado, son My, My.Resources y NombreEspacio.

Dentro de NombreEspacio encontramos la función pública Cuadrado.

Nuestro ensamblado en este caso, tendrá un tamaño de 10.752 bytes.

Ahora bien, ¿cómo eliminar la referencia a Microsoft.VisualBasic?. Porque aunque la hayamos eliminado en las referencias del proyecto, el compilador nos la sigue incluyendo..., justo como indicaba el Guille en las ponencias... a ver si no va a ser verdad eso de que se puede eliminar... veamos...

Para hacer esto, salvo que se me escape algo, debemos acudir a la línea de comandos.

Hay una salvadora instrucción que es /vbruntime-. Esta instrucción tiene por cometido compilar sin el motor de tiempo de ejecución predeterminado de Visual Basic.

Sin embargo, al indicar este comando, debemos indicar el ensamblado o ensamblados que sí queremos agregar, y que en nuestro caso es System.

Además de esto, en este ejemplo no hemos incluido ningún recurso. El compilador en Visual Studio 2008 lo añade siempre por defecto, aunque no tengamos nada incluido, y es algo que podríamos evitar incluir para crear ensamblados más livianos aún.

También deberíamos tener en cuenta otros aspectos, pero esta es una demostración básica que espero que aporte algo de luz de como eliminar la referencia del ensamblado de compatibilidad con Visual Basic. Si quieres ponerte una manta en la cabeza y probar cosas nuevas, genial.

El caso es que desde la línea de comandos, preferiblemente la línea de comandos de Visual Studio 2008, o bien agregando en las variables del entorno de Windows (PATH) la ruta del compilador, deberemos escribir la instrucción general en la raiz del proyecto (donde se encuentra el código fuente):

vbc *.vb /r:System.dll /t:library /vbruntime- /vbruntime:System.dll /doc+ /recurse:AssemblyInfo.vb /out:ReferenceLibrary2.dll

Esta instrucción hace lo siguiente:
vbc es el compilador de Visual Basic.
*.vb lee los ficheros de extensión vb del directorio en el que estamos.
/r:System.dll hace referencia a System.dll como metadato del archivo ensamblado para compilarlo correctamente.
/t:library lo utilizamos para indicar al compilador que estamos creando una librería de clases.
/vbruntime- lo utilizamos para eliminar las refencias de Visual Basic al proyecto.
/vbruntime:System.dll lo usamos para agregar la referencia a System.dll en el ensamblado.
/doc+ es utilizado para generar el archivo XML de documentación XML asociado al código.
/recurse:AssemblyInfo.vb lo utilizamos para buscar en los directorios o subdirectorios, y allí seleccionamos el archivo AssemblyInfo.vb para que lo compile en el ensamblado (versionado, nombre fuerte o strong name, etc).
/out:ReferenceLibrary2.dll es el nombre de salida de nuestro ensamblado.

Ejecutamos esta instrucción con el compilador y miramos los resultados en Reflector.

 

Observando este segundo ensamblado, lo primero que llama la atención es que su tamaño es ahora de 4.096 bytes, bastante menor que el ensamblado anterior.

Analizando el ensamblado en Reflector, vemos que la referencia a Microsoft.VisualBasic ha desaparecido (BIEN). También han desaparecido los recursos, ya que en este ejemplo no era necesario incluirlos.

De esta forma, se demuestra que sí es posible eliminar la referencia a Microsoft.VisualBasic dentro de nuestros proyectos Visual Basic, aunque para hacer esto tengamos que bucear un poco dentro de la línea de comandos del compilador de Visual Basic.

Ahora bien, ¿como automatizar de alguna manera esta tarea?. Pues construyendo una pequeña utilidad que nos ahorre tiempo y evite errores.

Si alguien se atreve, se agradecerá mucho.

Espero que esto aporte algo de luz sobre el famoso ensamblado Microsoft.VisualBasic.dll y el cómo eliminarlo de nuestros proyectos.

Referencias

Cross Posted from Jorge Serrano - MVP Visual Developer - VB

Microsoft Silverlight Tools for Visual Studio 2008 SP1 - RTM

 

Hace muy muy poco os hablé de la versión Silverlight 2.0 RTM, y entre otras cosas, Microsoft había hecho pública la versión Microsoft Silverlight Tools for Visual Studio 2008 SP1 - RC1.

Ahora sin embargo, apenas 15 días después, Microsoft hace pública Microsoft Silverlight Tools for Visual Studio 2008 SP1 - RTM.

La descarga está disponible en diferentes idiomas, entre ellos el inglés y el español, y podrá ser descargado desde este enlace (72 Mb).

Espero que la noticia sea de vuestro interés.

Nota: no he visto a nadie anunciar aún esto, pero presumiblemente es la versión RTM, ya que la versión RC1 ha desaparecido como tal.

Cross Posted from Jorge Serrano - MVP Visual Developer - VB

06/11/2008 :: Evento de MAD.NUG - Novedades de SQL Server 2008

 

Acceso a la página oficial de MAD.NUG.  

El próximo 6 de noviembre de 2008 de 19:00 a 21:00 horas, tenemos una cita en MAD.NUG (Grupo de Usuarios de .NET de Madrid).

En esa cita, tendremos la posibilidad de conocer las novedades de SQL Server 2008 de la mano de Pablo Álvarez Doval.

A continuación os indico el texto descriptivo del evento.

A pesar de que el lanzamiento de SQL Server 2008 se ha producido ya hace algunos meses, aún son muchas las áreas oscuras del producto, el desconocimiento de sus nuevas características, mejoras, etc. Como ya sucediera con SQL Server 2005, y como con cualquier producto o tecnología nueva, pasará bastante tiempo hasta que asimilemos y empleemos con naturalidad las novedades, y pasen a formar parte de nuestro arsenal del día a día.

En esta sesión vamos a dar un repaso a las novedades de SQL Server 2008: desde el desarrollo a la administración, desde el motor de almacenamiento a Business Intelligence. Recorreremos algunas de las características más conocidas y, cómo no, haremos hincapié en las menos conocidas. Las aburridas PPTs de rigor irán acompañadas de demostraciones prácticas sobre los nuevos tipos de datos, la MERGE, tablas como parámetros, optimización, y un poquito de administración también.


Por supuesto, la sesión contará con su apartado de preguntas y respuestas, por lo que os animamos a que vengáis con vuestra batería de cuestiones preparadas desde casa para hacer tiro al blanco con el ponente.


Agenda:

 

1.- Introducción a SQL Server 2008
2.- Novedades para Desarrolladores
    - Nuevos Tipos de Datos
       - Datos espaciales
       - Fechas y Horas
       - Estructuras Jerárquicas
    - Operación MERGE
    - Mejoras al XML
    - Mejoras a los tipos de CLR
    - Otras mejoras: TVP, iFTS, Sync Framework
3.- Novedades de Administración
    - Policy-Based Administration
    - Resource Governor
4.- Novedades del Motor de Almacenamiento
    - Compresión de Datos
    - Transparent Data Encryption
    - Vardecimal
5.- Business Intelligence en SQL Server 2008-10-29
    - Integration Services
    - Reporting Services
    - Analysis Services

Como podéis ver en la agenda, el evento promete mucho, así que no dudeis en venir.

Recordad que el evento se realizará en Madrid (España) en las oficinas de Microsoft.

Nota: Seguimos persiguiendo la idea de grabar el evento. Por problemas técnicos no hemos podido hasta la fecha, pero esperamos subsanar todos esos inconvenientes y poder liberar las ponencias para todas las personas en todo el mundo.

Podréis registraros al evento (Nivel 200) en este enlace.

Cross Posted from Jorge Serrano - MVP Visual Developer - VB
Posted por Jorge Serrano con no comments
Archivado en:

Póster preliminar de Microsoft .NET Framework 4.0

 

Después del empacho y borrachera inicial de lo que se nos viene encima (aka PDC 2008), ahora le toca el turno a la resaca de tan magno evento.

Todavía andamos aturdidos por la cantidad de cosas que se nos vienen encima... todos esos cambios muy emocionantes,... pero ya iremos asimilándonos poco a poco. Tiempo al tiempo.

No obstante, entre los efectos de la resaca me encuentro con el blog de Brad Adams, y dentro de ese blog, con una entrada en la que podemos acceder al póster en formato pdf del Universo de Microsoft .NET Framework 4.0.

En realidad es parte del Universo, pero no viene mal tener un mapa en la mano de algo de lo que nos encontraremos "ahí fuera".

Se trata de una versión muy preliminar de Microsoft .NET Framework 4.0 junto a .NET Framework 3.5 SP1. Recordad que .NET Framework 4.0 está en fase de desarrollo y que muchas de estas cosas podrán cambiar (seguro que lo harán), pero menos es nada, así que aquí van las referencias de este póster.

Ref.: blog de Brad Adams.

Cross Posted from Jorge Serrano - MVP Visual Developer - VB

Application Architecture Guide 2.0 - Beta 1

 

A finales del mes pasado os comentaba en otra entrada el anuncio de la eminente versión preliminar de Application architecture Guide 2.0.

En esta ocasión, os comento que la versión Beta 1 de ese documento, ya ha visto la luz en formato pdf de casi 3 Mb.

Un documento "o libro" de obligada lectura desde mi modesto punto de vista.

Las casi 380 páginas de información está dividida en 5 partes y diferentes capítulos dentro de cada parte.

Los 5 bloques o partes principales son:

  • Parte 1: Fundamentals
  • Parte 2: Design
  • Parte 3: Layers
  • Parte 4: Quality Attributes
  • Parte 5: Archetypes - Design and Patterns

Ni que decir, que toda la información está en inglés y que podremos acceder a ella desde este enlace.

Más información en este otro enlace.

Cross Posted from Jorge Serrano - MVP Visual Developer - VB
Posted por Jorge Serrano con no comments
Archivado en: