El blog de Lluis Franco : VB

El CodeCamp 2009 se acerca…

lfranco — Mon, 21 Sep 2009 12:36:00 GMT

Hola a todos,

Ya queda menos de un mes para uno de los eventos más esperados de este año: el CodeCamp 2009. Este evento ha sido organizado por varios grupos de usuarios de España y del extranjero (Andorra también existe!), y se realizará en Salou (Tarragona), durante el fin de semana del 17 y 18 de Octubre.

El CodeCamp Tarragona 2009 es un evento gratuito organizado por y para la comunidad de .NET, cuyo objetivo es reunir a profesionales, usuarios y entusiastas interesados en la plataforma .NET y Mono para intercambiar experiencias y asistir a un conjunto de ponencias realizadas por especialistas de reconocido prestigio.

El Code Camp estará compuesto por una serie de sesiones divididas en varios tracks. Las sesiones abarcarán presentaciones, charlas informales y sesiones prácticas. Estáis todos invitados a asistir, hablar y participar.

Tendremos una mezcla de ponentes, desde MVPs, directores, autores y, los más importante, desarrolladores como tú, ya que nos interesa tratar temas y problemas reales a los que los profesionales se enfrentan en el trabajo diario.

En esta ocasión, voy a participar como ponente en uno de los tracks, conjuntamente con mis buenos amigos Jorge Serrano y Pep Lluís Bano. De modo que si te quieres divertir y estar al loro de las últimas novedades de VB2010 pásate por allí y hablamos un rato.

Más información en:

http://www.codecamp.es/

PD – El día anterior celebraremos el TTT (Train the trainers), de modo que si vas a ir nos vemos allí :-)

** crossposting desde el blog de Lluís Franco en geeks.ms **

10 cosas que me gustan de C# respecto a VB

lfranco — Tue, 23 Dec 2008 17:44:53 GMT

Antes de empezar a leer este post, un aviso: En ningún modo pretendo crear polémica o abrir el viejo debate otra vez, si no más bien enumerar algunas cosillas que hacen que *yo* me sienta más cómodo trabajando con C# que con VB, tanto a nivel de lenguaje como del propio editor. Lo remarco porque quiero que quede bien claro que es una opinión personal, ok? No se trata de comerle el coco a nadie…

Algunas de estas cosillas ya las he compartido con algunos de vosotros en algún evento de los grupos de usuarios, o simplemente delante de unas cervezas (aquí la conversación suele tornarse más pasional y tiende a alargarse un poco), jejeje…, y a decir verdad pocas veces nos ponemos de acuerdo ¿eh agüelo?. Parece ser que antes de empezar a hablar cada cual ya se ha posicionado y de aquí no nos movemos… lo cual es hasta cierto punto normal. Uno sabe con qué herramienta se encuentra más cómodo, aunque pueda usar ambas de forma indistinta.

De hecho he tirado más líneas de código con VB que con cualquier otro lenguaje, y eso que empecé en este mundillo con C y posteriormente con C++, para luego pasar a los lenguajes ‘más productivos’ como Delphi o finalmente VB en sus primeras versiones. No fue hasta 2002 y las primeras versiones de .NET que volví a usar la vieja sintaxis del punto y coma. De modo que VB en-todas-sus-variedades me es muy querido, y debo reconocerle sus ventajas… Sin embargo, codificar, al igual que leer o hablar, es algo que siempre haces mejor o te sientes más cómodo en uno de los lenguajes que dominas, y aquí reconozco que C# (como antes de conocerlo lo fue Java) es mi predilecto. Siempre que YO decido el lenguaje a utilizar en un nuevo proyecto, lo escojo, y en caso contrario intento convencer a la otra persona (ya sea compañero, cliente, etc.).

Os enumero a continuación una lista de cosas que me gustan de C#, o más bien que no me gustan cuando al cabo de un tiempo de trabajar con C#, me pongo a codificar con VB. No siguen ningún orden ni patrón y las voy a ir enumerando conforme se me vayan ocurriendo:

1) Escribo menos código && código más limpio:

En este punto, un desarrollador de VB acostumbra a decirme que esto no es cierto. Que si bien la sintaxis de VB es en alguno puntos ‘rocambolesca’ es para aclarar, y además el propio editor de código se encarga de escribirlo. Sin embargo tengo comprobado que con el editor de C# en la gran mayoría de las situaciones tecleo menos para decir lo mismo, y queda más claro (al menos para mí). Ojo! Es importante destacar que en ningún momento me mueve el afán de teclear menos, sino que el código resultante sea más legible. Comparemos los siguientes ejemplos:

Declarar una variable:

C#:

int x = 5;

VB:

Dim x As Int = 5

Bloques de código (ends por todas partes :-P).

C#:

if(Nombre == "Pepe" && Sueldo <= 500)

...

VB:

If Nombre = "Pepe" AndAlso Sueldo <= 500 Then

...

End If

Operador AddressOf

C#:

Thread t = new Thread(CountSheep);

VB:

Dim t As New Thread(AddressOf CountSheep)

Expresiones lambda:

C#:

Func<int, Func<int, int>> mult = (int x) => (int y) => x * y;

VB:

Dim mult As Func(Of Integer, Func(Of Integer, Integer)) = _

Function(x As Integer) Function(y As Integer) x * y

Implementar una interfaz (no es preciso Implements):

C#:

interface ITest

    string getValue();

class Test : ITest {

    string getValue()

        Random r = new Random();

        return r.Next().ToString();

VB:

Interface ITest

    Function getValue() As String

End Interface

Class Test

    Implements ITest

    Public Function getValue() As String Implements ITest.getValue

        Dim r As New Random

        Return r.Next().ToString()

    End Function

End Class

Podriamos seguir con Overridable, Overrides y unos cuantos más... Pero mejor vamos al siguiente punto que si no, no acabo el post hoy… :-)

2) No más underscores!

Cuantas veces he tenido que escuchar “no tengo porque terminar cada línea de código con un punto y coma!”. Pues precisamente, el delimitador de línea es lo que permite que en los lenguajes derivados del viejo y bueno ‘C’ no tengamos que hacer algo tan antinatural como partir las líneas de código con underscores (_). Además suele pasar que es una de las cosas que olvido con mayor rapidez, y cada vez que escribo en VB una query con LINQ acabo por soltar un “AAAAARGH!!! OTRA VEZ!!!”.

C#

List<int> nums = new List<int>(new int[] { 1, 2, 3, 4 });

var mynums = from n in nums

             where n < 5

             orderby n

             select n;

VB:

Dim nums As New List(Of Integer)(New Integer() {1, 2, 3, 4})

Dim mynums = From n In nums _

    Where n < 5 _

    Order By n _

    Select n

3) Matrices y Listas: [] en lugar de ():

Cuando estoy picando o leyendo código me gusta saber con exactitud si estoy llamando a una función, a una propiedad u obteniendo el valor de una matriz o colección. Precisamente por eso prefiero usar corchetes en lugar de paréntesis para acceder a los miembros de una matriz o lista. En el ejemplo siguiente en la llamada a nums(i) en VB, podría ser tanto un método como una matriz, como una propiedad que devuelve una matriz o lista:

C#

List<int> nums = new List<int>(new int[] { 1, 2, 3, 4 });

Console.WriteLine(nums[2].ToString());

VB:

Dim nums As New List(Of Integer)(New Integer() {1, 2, 3, 4})

Console.WriteLine(nums(2).ToString())

4) Parámetros de salida (out):

Tipos de parámetro de salida. Estos son muy parecidos a los parámetros por referencia (ref), pero no necesitan ser inicializados. Resultan particularmente útiles en algoritmos recursivos. Visual Basic no dispone de nada equivalente, aunque si permite el paso de valores por referencia.

C#:

static void Method(out int i)

    i = 44;

static void Main()

    int value;

    Method(out value);

5) Los códigos de escape y las cadenas verbatim:

Otra cosa que me molesta es que VB no reconoce los carácteres de escape contenidos en un string. Esto es particularmente útil cuando deseamos mostrar un retorno de línea ‘\n’ o una tabulación ‘\t’ dentro de una cadena. En Visual Basic hay que recorrer a la concatenación de Environment.NewLine o artimañas parecidas como concatenar directamente el carácter. Por ejemplo el código siguiente se muestra así:

MessageBox.Show("hola\nque\ntal");

C#:

VB:

En este punto más de uno se preguntará ¿y que pasa si no quiero tratar estos caracteres de escape como especiales?, ¿o si quiero mostrar una ruta de acceso que contiene varios caracteres ‘\’? Bien, para ello tenemos varias alternativas: Podemos anteponer un carácter ‘\’ a todo símbolo que deseemos mostrar literalmente o podemos usar cadenas verbatim (también llamado ‘literal de cadena textual’):

MessageBox.Show("C:\\Windows\\system32\\Calc.exe");

MessageBox.Show(@"hola\nque\ntal");

Las cadenas verbatim van incluso un poco más allá y permiten incluso poder partir una cadena en varias líneas, lo que clarifica en mucho el código:

MessageBox.Show(@"SELECT O.OrderID, O.CustomerID, O.EmployeeID,

                O.OrderDate, O.RequiredDate, O.ShippedDate,

                O.ShipVia, O.Freight, O.ShipName, O.ShipAddress,

                O.ShipCity, O.ShipRegion, O.ShipPostalCode,

                O.ShipCountry, C.CompanyName, C.Address,

                C.City, C.Region, C.PostalCode, C.Country

                FROM dbo.Customers AS C

                INNER JOIN dbo.Orders AS O

                ON C.CustomerID = O.CustomerID");

6) Propiedades autogeneradas:

Algo tan sencillo como crear una propiedad para una clase, lo es todavía más en C#, ya que permite el uso de propiedades autogeneradas. Esto hace que el compilador maneje internamente una variable privada a nivel de clase para almacenar el valor, quedando esta parte oculta al desarrollador. Esta característica estará disponible en la próxima versión de Visual Basic, pero de momento todavía tenemos que conformarnos con representarlo así:

C#:

class Foo

    public int id { get; set; }

    public string name { get; set; }

VB:

Class Foo

    Private _id As Integer

    Public Property id() As Integer

Get

            Return _id

        End Get

        Set(ByVal value As Integer)

            _id = value

        End Set

    End Property

    Private _name As String

    Public Property name() As String

Get

            Return _name

        End Get

        Set(ByVal value As String)

            _name = value

        End Set

    End Property

End Class

7) Refactoring:

Hoy en día, al igual que el uso de pruebas unitarias, empieza a ser impensable no refactorizar el código para una mejor comprensión, que repercute en un mejor índice de mantenibilidad (o Maintainability index, vaya usted a saber cómo se traduce) del código. Bien, pues el menú ‘Refactor’ del editor de C# no aparece en VB. Y la única información acerca de refactorizar el código VB nos enlaza con un Add-In de terceros, la cual a decir verdad es una gran utilidad. Lo sé, porque he usado la versión PRO de este producto durante bastante tiempo. Pero el hecho es que Visual Studio no incorpora ninguna utilidad ‘de fábrica’ para refactorizar el código, lo que no deja de ser sorprendente…

8) Posibilidad de desactivar ‘Strict on’:

Al ser VB la evolución de un lenguaje no tan ‘estricto’ como C#, nos ofrece la posibilidad de desactivar la opción Strict On, y de este modo dejar que el compilador se encargue de realizar muchas conversiones implícitas. Pero lo más peligroso de todo es que la opción viene desactivada ‘de fábrica’ y en cambio no conozco ningún buen programador de VB (que los hay, y muchos) que no sea lo primero que active. Muchos errores en tiempo de ejecución podrían ser evitados si el propio compilador nos obligase a codificar correctamente, en lugar de actual de este modo más ‘relajado’:

VB (con Option Strict Off):

Dim s As String

s = DateTime.Today

VB (con Option Strict On):

Dim s As String

s = DateTime.Today.ToString()

Observar que con Option Strict activado, el compilador no permite asignar una fecha a una variable de tipo cadena (con razón!), de modo que para poder compilar debemos realizar una conversión explícita.

Recomiendo dar un vistazo a este artículo de coding horror:
http://www.codinghorror.com/blog/archives/000355.html

9) Microsoft.VisualBasic:

Son legión los programadores que provienen de versiones anteriores de .NET (6 o anteriores), de modo que para facilitarles el camino los proyectos de VB incorporan el espacio de nombres Microsoft.VisualBasic, el cual a su vez incorpora muchas de las funciones de estas versiones anteriores. El hecho de incorporarlas no es un error en sí, lo malo es que estas funciones tienen su equivalente en el modelo de objetos del framework, y si seguimos usando estas funciones ‘antiguas’ no aprenderemos las nuevas, y el día en que debamos trabajar con otro lenguaje del Framework (que no tiene porque ser C#, hay unos cuantos más :-P) nos encontraremos con que estamos usando funciones propias de VB y no conoceremos su equivalente.

Por ejemplo, en lugar de llamar a la función Len para averiguar el número de caracteres de una cadena, es mejor usar el método Lenght de la clase String, lo mismo para Trim(), y todavía es más flagrante con Mid(), que equivale al método SubString del objeto String:

Dim n As Integer = Len(DateTime.Now.ToLongDateString)    'NO

Dim n As Integer = DateTime.Now.ToLongDateString.Lenght  'SI

No son pocos los esfuerzos de muchos compañeros, fantásticos programadores como Jorge Serrano o Harvey Triana para eliminar esta librería de nuestras aplicaciones, de modo que la recomendación siempre acaba siendo “no la uses, no la mires, haz como si no estuviera…”. Por cierto, os recomiendo una lectura de ambos artículos.

10) Hay más, y no se por cual decidirme…

Hay muchas otras cosas que se quedan en el tintero, porque algunas de ellas son demasiado largas (como el manejo de eventos), y otras no son precisamente de uso diario, como la ejecución de código no seguro (unsafe). Pero estaremos de acuerdo en que la mayoría de las novedades aparecen primero para C# (inicializadores de colecciones, propiedades autogeneradas, soporte para expresiones lambda ‘de verdad’, etc.) e incluso los compiladores de C# del proyecto MoNo van siempre por delante de los de VB. Aunque este último punto reconozco que no es demasiado importante… o sí?

En fin, vaya chapa me ha salido! Pero por lo menos ahora tengo una lista de cosas para cuando me pregunten “¿porque te gusta más C# que VB?”.

Un saludo desde Andorra,

** crossposting desde el blog de Lluís Franco en geeks.ms **

ADO.NET Data Services – Entrevista en Channel 9

lfranco — Wed, 22 Oct 2008 07:40:27 GMT

En este vídeo, Beth Massi entrevista a Saaid Kahn (Program Manager de Visual Studio Pro Tools team) y nos muestra cómo crear aplicaciones de n capas usando ADO.NET Data Services (Astoria) y el Entity Data Model.

ADO.NET Data Services (Astoria) in Visual Studio 2008 SP1

Absolutamente recomendable darle una ojeada. Dura poco más de un cuarto de hora y vale la pena.

** crossposting desde el blog de Lluís Franco en geeks.ms **

El Guille community Tour 2008 pasó por Andorra…

lfranco — Fri, 17 Oct 2008 09:24:45 GMT

…y no he podido escribir nada hasta ahora… aisssss!

La verdad es que he estado missing durante unos dias debido a que tengo una punta de trabajo terrible. Espero volver a dar un poco más la vara tanto aquí como el los foros online, de los que también he estado un poco desconectado.

Pero a lo que iba: El pasado lunes 13 en AndorraDotNet tuvimos la suerte de poder contar con dos ponentes de lujo: El Guille y David Salgado de Microsoft. Guille nos habló de las novedades de VB 9.0 como no podía ser de otra manera, y hubieron muchos ‘piques’ entre los defensores de VB y de C#, con lo que nos reímos mucho.. David nos regaló una fantástica demo de cómo construir una aplicación Web mediante ASP.NET, en la que empezamos con una solución en blanco y fue creando poco a poco los diversos elementos del proyecto. Por cierto, que sepas que ya me la han pedido!!!

Al final de la sesión tuvimos el típico sorteo de regalos, en el que algunos afortunados se fueron con un regalo entre las manos.

La audiencia estuvo sobre las casi 60 personas con perfiles muy diferentes, y aunque me hubiese gustado ver más gente de empresa (ya os tiraré de las orejas a los que no pudísteis asistir) no estuvo nada mal. Por nuestra parte seguiremos trabajando intentando cambiar la situación del país, ya que sigue siendo muy difícil hacer ver a los empresarios que la formación es un recurso vital para la buena marcha de un negocio (si, parece mentira pero hay mucha gente que todavía no lo tiene claro). Si queremos avanzar no hay que escatimar en formación y en I+D. Es por el bien del país!

Un agradecimiento especial al colega Jan Arbona de TSCP por su colaboración en el evento, y por habernos tirado un cable en los momentos de estrés.
Gracias a todos y os espero en el próximo evento que ya estamos preparando!

** crossposting desde el blog de Lluís Franco en geeks.ms **

Quieres ver las caras del VBTeam?

lfranco — Thu, 24 Jul 2008 08:04:16 GMT

Beth Massi publica un par de fotos en el blog del VBTeam, y nos cuenta la anécdota de porque todos visten de gris.

Saludos,

** crossposting desde el blog de Lluís Franco en geeks.ms **

VBTeam - How Do I Videos (WPF Forms over Data)

lfranco — Fri, 18 Jul 2008 08:00:48 GMT

Beth Massi del equipo de VB, ha publicado nuevos videos en el sitio “How Do I” Videos — Visual Basic. En este caso se trata de dos videos que muestran cómo crear formularios basados en datos en Windows Presentation Foundation usando Visual Studio 2008.

How Do I: Create a Simple Data Entry Form in WPF?

#1 | How Do I: Create a Simple Data Entry Form in WPF?
(24 minutes, 32 seconds)

#2 | How Do I: Display Data in a List in WPF?
(11 minutes, 47 seconds)

El link en: http://msdn.microsoft.com/en-us/vbasic/bb466226.aspx#wpfdata

Si no conoceis el sitio “How Do I” Videos darle un vistazo, que merece la pena y mucho... :-)

** crossposting desde el blog de Lluís Franco en geeks.ms **

How to: Utilizar en modelo de proveedores de datos de ADO.NET 2.0

lfranco — Sat, 12 Jul 2008 10:03:31 GMT

(*) Este post es bastante antiguo y lo tenía publicado en otro blog que ya no existe, pero como veo que es un tema recurrente en los foros de MSDN he decidido publicarlo de nuevo.

A petición del inefable Juansa, vamos a ver cómo funciona el modelo de proveedores de ADO.NET 2.0.

Estre modelo es ideal para todas aquellas aplicaciones que deben utilizar distintos proveedores de datos (Access, SQL Server, Oracle), ya que disponen de unas factorías de objetos que proporcionan un nivel de abstracción. Por ejemplo, si deseamos usar el proveedor de SQL Server ya no es necesario usar las clases conexión, comando, etc. que hay dentro del namespace System.Data.SqlClient, ahora podemos crear una factoría basada en SQL Server y pedirle que nos cree una clase de tipo connection, comando, etc.

De este modo, si deseamos cambiar el proveedor de datos basta con cambiar el string del nombre del proveedor y la cadena de conexión. Para muestra un botón:

Private Sub TestFactoryProviders()

    Dim ProviderName As String = "System.Data.SqlClient"

    Dim CnnStr As String = "Data Source=TU_SERVIDOR_SQL;" + _

        "Initial Catalog=TU_BD;" + _

        "Integrated Security=True"

    Dim SQLStr As String = "SELECT * FROM TU_TABLA"

    'Crea la factoria en base al proveedor especificado

    Dim Factory As DbProviderFactory = DbProviderFactories.GetFactory(ProviderName)

    'Crea la conexión del tipo apropiado (según proveedor)

    Dim Con As DbConnection = Factory.CreateConnection()

    Using Con

        'Asigna la cadena de conexión

        Con.ConnectionString = CnnStr

        Con.Open()

        'Crea un command del tipo apropiado (según proveedor)

        Dim Cmd As DbCommand = Con.CreateCommand()

        Using Cmd

            Cmd.CommandType = CommandType.Text

            Cmd.CommandText = SQLStr

            'Crea un DataTable y lo llena a partir del

            'DataReader que devuelve el comando

            Dim dt As DataTable = New DataTable("dt1")

            dt.Load(Cmd.ExecuteReader())

            For Each row As DataRow In dt.Rows

                'Haz lo que quieras con los datos... :-P

            Next

        End Using

        Con.Close()

    End Using

End Sub

Según el ejemplo, cambiando los valores de las dos primeras variables podemos utilizar cualquier origen de datos de forma indistinta.
Happy coding!

** crossposting desde el blog de Lluís Franco en geeks.ms **

How to: Cómo insertar un WinForm dentro de un control TabPanel

lfranco — Tue, 01 Jul 2008 12:10:32 GMT

:-)
Hoy he visto en el foro de VB una duda que planteaba Tito, acerca de la posibilidad de usar un entorno de formularios hijos dentro de un TabPanel (al estilo del editor de Visual Studio). No es la primera vez que veo esta duda, así que le he dedicado un ratillo y aquí publico una posible solución.

De este modo podemos tener un formulario que actúa como contenedor de otros, pero sin utilizar MDI (que por otra parte me parece ya bastante pasado de moda :-P). La técnica a usar muy sencilla y lo único que hacemos es cada vez que creamos un form, creamos también un objeto TabPage e insertamos el formulario dentro de la nueva pestaña. La única cosa que tenemos que tener en cuenta es establecer la propiedad TopLevel del nuevo formulario 'hijo' a False, ya que de otro modo recibiremos un error.

Una muestra:

Private Sub ShowForm()

    Dim r As New Random()

    Static i As Integer

    i += 1

    Dim key As String = "f" + i.ToString()

    'Crea el nuevo form (copia de form2)

    Dim f As New Form2

    f.BackColor = Color.FromArgb(r.Next(0, 255), r.Next(0, 255), r.Next(0, 255))

    f.Text = String.Format("Nuevo form {0}", i)

    'Crea el tab que lo contiene

    Me.Tabs.TabPages.Add(key, f.Text)

    f.TopLevel = False

    f.FormBorderStyle = Windows.Forms.FormBorderStyle.None

    f.Dock = DockStyle.Fill

    Me.Tabs.TabPages(key).Controls.Add(f)

    Me.Tabs.SelectedTab = Me.Tabs.TabPages(key)

    'Asigna el nuevo form al tag del tabpage

    Me.Tabs.TabPages(key).Tag = f

    'Por si desde el propio form quieres cerrar y eliminar el tab

    f.Tag = Me.Tabs.TabPages(key)

    f.Show()

End Sub

Podeis descargar el proyecto de ejemplo desde:

Y para los que siempre me tiráis los puntosycoma en cara, lo he realizado en VB (eh Jorge? :-D).
Un saludo desde Andorra!

** Modificación (02/07/2008) para agregar un menú contextual a las pestañas **

A petición de Carlos. De este modo es puede cerrar la pestaña actual o todas las pestañas menos la que estamos viendo ahora. El menú es un objeto ContextMenuStrip, de modo que es totalmente extensible para agregar vuestra propia funcionalidad.

La nueva versión está disponible en:

Saludos,

** crossposting desde el blog de Lluís Franco en geeks.ms **

Los viejos rockeros nunca muere, o soporte a VB6 en Windows 2008

lfranco — Mon, 17 Mar 2008 10:36:17 GMT

Está claro que todavía existe un gran parque de aplicaciones realizadas en VB6, muchas de las cuales todavía no han podido ser migradas, o mejor dicho rediseñadas para la plataforma .NET, ya sea por falta de tiempo, recursos, etc.

Para todos aquellos que (como yo) estaban sufriendo con la llegadas de los nuevos sistemas operativos Vista y Windows 2008, el equipo de VB nos informa de algunas de las mejoras del soporte del runtime en estos sistemas:

http://blogs.msdn.com/vbteam/archive/2008/03/15/improvements-to-visual-basic-6-runtime-support-on-vista-windows-server-2008-by-paul-yuknewicz.aspx

Y en el siguiente artículo todavía se detalla más:

http://msdn2.microsoft.com/en-us/vbrun/ms788708.aspx

No deja de ser una noticia curiosa en estos tiempos, pero hay que pensar que no todos tenemos la suerte de trabajar con las nuevas tecnologías, y que en ocasiones todavía tenemos que ponernos el antiguo mono de trabajo para mantener algunas viejas (y buenas) aplicaciones.

Nos leemos,

** crossposting desde el blog de Lluís Franco en geeks.ms **

Visual Basic 6.0 Service Pack 6 - oleaut32.DLL Security Update

lfranco — Wed, 13 Feb 2008 08:08:21 GMT

Microsoft ha hecho público el parche de seguridad correspondiente a Visual Basic 6.0 Service Pack 6 y en concreto a la librería oleaut32.DLL.

El parche de apenas 1.4 Mb, está disponible en todos los idiomas disponibles de la plataforma incluido el español.

Este parche resuelve la posibilidad de que un ordenador con Visual Basic 6.0 Service Pack 6, pueda ser atacado externamente.

Podrás acceder a este parche en este enlace (1.4 Mb).

(Notícia original del blog de Jorge en geeks.ms)

¿Quieres conocer las tripas del MsgBox?

lfranco — Tue, 22 Jan 2008 12:12:23 GMT

El código del runtime de VB2008 ha sido liberado...

...esta noticia junto a la de la liberación del Framework ha corrido como la pólvora desde hace unos días. Así que los chicos del VBTeam nos han preparado un pequeño artículo para demostrar cómo activar esta depuración, y así poder llegar hasta las tripas de este maldito código generado en el valle de Mordor. Me he tomado la libertad de traducirlo 'al vuelo' así que espero que no se hayan 'colado' demasiados errores... Vamos a ver algunos ejemplos:

Ejemplo de depuración clásica sin el código del runtime:

Hemos creado una simple aplicación de consola, que realiza una llamada a una función 'foo'. En esta función hemos activado un punto de interrupción, de modo que al ejecutar nos detendremos y veremos como el editor de VS no muestra detalles de estas llamadas en la pila de llamadas, simplemente lo muestra cómo "[External Code"].

Desactivar "My Just Code"

El siguiente paso consiste en desactivar esta opción en las opciones de depuración, para así poder acceder a los detalles que no forman parte de nuestro código.

Después de desactivar esta opción, observaremos que eran llamadas realizadas antes de alcanzar a la función destino. Como el compilador no conoce en tiempo de compilación que función debe ser llamada, delega la llamada al enlazador del runtime. Lo que observamos en la pila de llamadas en medio del código de nuestras funciones es el código de la librería del runtime de VB, y si intentamos acceder a él haciendo doble click nos mostrará un mensaje diciendo que no existe código disponible para la localización actual:

Configurar la información de origen del código

Ahora, desde que el código de Microsoft.VisualBasic ha sido liberado nosotros podemos decirle a Visual Studio dónde encontrarlo. Para ello, usaremos el soporte de servidor de código en VS (para que esto funcione deberá estar instalado el siguiente hotfix: Visual Studio 2008 QFE, que actualiza el componente del depurador que trae los ficheros de código:

1. En Visual Studio 2008 seleccionar Tools -> Options -> Debugging
2. En la pestaña “General”
a. Desmarcar “Just My Code”
b. Marcar “Enable Enable Source Server Support”

En este paso vamos a decirle a VS dónde encontrar los símbolos, así como dónde vamos a guardarlos en local. Este paso es importante porque acceder a los símbolos en una ubicación local es mucho más rápido que acceder desde un servidor remoto.

En la pestaña “Symbols”

a. Hacer click en el icono "nuevo" y agregar la ubicación remota: http://referencesource.microsoft.com/symbols
b. Marcar la casilla “Search the above locations only when symbols are loaded manually”
c. Introducir una ruta de acceso local en el campo de texto. Debe ser una ubicación sobre la cual tengamos permiso de escritura.
d. Pulsar OK

A continuación, haremos clic con el botón derecho sobre el primer marco del runtime y seleccionaremos "LoadSymbols". Esperaremos a que los símbolos se carguen (esto se demorará un momento la primera vez, y nos preguntará si aceptamos el EULA). Una vez cargados los símbolos, podemos hacer doble clic y ¡qué diferencia! ¡Ahora podemos ver el código fuente del runtime! (En un primer momento tal vez se tome demasiado tiempo, pero una vez tenga los símbolos en la caché local no volverá a suceder...)

Estableciendo puntos de interrupción dentro del runtime de VB

Y todavía más. Ahora nosotros podemos navegar con F11 a través del código del runtime e incluso establecer puntos de interrupción. Si eres un poco curioso puedes establecer un punto de interrupción al principio de la llamada y reiniciar el proyecto. Una vez alcances el punto de interrupción podrás navegar con F11 a través del código y ver cómo fue implementado.

Notaremos que hay una advertencia - Es debido que el código del servidor no es "exactamente" el mismo. Existen unas pequeñas diferencias, como los flags de copyright al final, etc. Debido a eso VS se queja de la diferencia del código.

Esto puede solucionarse fácilmente haciendo clic con el botón derecho sobre el punto de ruptura, abriendo el menú "Location" y seleccionando "Allow source file to be different from the original location". Existe un modo de hacerlo de forma global, pero que no recomendamos porque afectaría a todos los proyectos.

También para estar seguros de que los símbolos son cargados antes de que la ejecución alcance al punto de ruptura, necesitamos deshabilitar la opción "manual only" de la carga de los símbolos.

Esto causará que todos los símbolos serán cargados bajo demanda y esto incluye algunas librerías del Framework .NET, con lo que esto puede tomar bastante tiempo cuando lanzamos la sesión de depuración. Una vez los símbolos han sido cargados deberíamos ser capaces de alcanzar este punto de ruptura en el runtime.

¿Que hay dentro del MsgBox?

Otro escenario interesante que debería funcionar ahora es la navegación mediante F11 por el interior de las funciones del runtime de VB. Una de las más usadas por todos parece ser el MsgBox, de modo que vamos a dar una ojeada a su interior. En un nuevo proyecto podemos usar una llamada a MsgBox e insertar un punto de interrupción:

Cuando alcancemos el punto de interrupción, basta con pulsar F11 y Wow!!! Ahora podemos introducirnos dentro del código de la función MsgBox, navegar a través de él y ver como funciona.

Questiones conocidas, FAQ:

1) Acceder a los símbolos de forma remota no es demasiado rápido. Esto causa ciertos retrasos en VS cuando los recursos son accedidos. Incluso con la caché local activada en algunos escenarios VS comprueba cuándo la información es actual. Podemos sortear esto yendo a: Tools -> Options -> Debugging -> Symbols configuration, y desmarcando “Search the above locations when symbols are loaded manually”. Y posteriormente depurar el proyecto. Tardará un tiempo en cargar todos los símbolos (incluidas varias librerías .NET) en la configuración (en algunas ocasiones pueden llegar a cargarse más de 50Mb). Después de que VS termine la carga, volver a Tools -> Options -> Debugging -> Symbols y marcar “Search the above locations…”. Esto hará que el depurador no se conecte al servidor cuando nosotros no queremos.

2) En ocasiones podemos observar que algunas variables o métodos no están disponibles. El motivo es porque estamos usando una versión optimizada. Un resultado de usar versiones optimizadas es que cierta información no está disponible. De modo que tenemos el código pero no somos capaces de acceder a los datos o agregar puntos de ruptura. Por otra parte, todo lo demás debería ser normal.

3) Funcionará con la edición VB Express? No. Esta funcionalidad no está disponible para esta edición ya que no incorpora estos componentes de Visual Studio.

Es posible consultar el artículo original aquí.

Saludos desde Andorra,

** crossposting desde el blog de Lluís Franco en geeks.ms **

Mejoras en el IDE de VB2008

lfranco — Wed, 09 Jan 2008 09:48:13 GMT

:-)

Siempre me he sentido más cómodo escribiendo código C# que VB dentro del IDE de Visual Studio 2005, tal vez será porque el soporte para IntelliSense está más desarrollado, porque me conozco mejor los atajos de teclado, o quizás porque debido a la sintaxis del lenguaje escribo menos para realizar lo mismo (aquí he tenido alguna discusión en la terraza de un bar con el Guille :-P).

La cuestión es que ahora el equipo de VB2008 acaba de publicar un post en el que se explican las *muchas* mejoras que se han realizado en cuanto al soporte para IntelliSense. No las voy a enumerar aquí pero se resumen en el título del post: IntelliSense Everywhere!

Tal vez ahora le pague aquella cerveza que nos apostamos al Guille... ;-)

** crossposting desde el blog de Lluís Franco en geeks.ms **

TableAdapters transaccionales? Si por favor!

lfranco — Fri, 04 Jan 2008 16:48:53 GMT

¿Usar DataSets Tipados o no? Uhm...

Hola a todos,

En el proyecto que actualmente me ocupa, al desarrollar la capa de acceso a datos he pensado usar DataSets Tipados en lugar de otro modelo habitual basado en clase - colección genérica. ¿Por qué? Bueno porque en principio simplifica el desarrollo, ya que (cómo ya sabéis) el diseñador de DataSets se ocupa de generar las operaciones básicas de lectura/escritura en la base de datos. Esto ahorra bastante tiempo de desarrollo y permite centrarnos en lo realmente importante: La lógica de la aplicación.

Además este método es de fácil extensión mediante el uso de las clases parciales (una de las características que más me gustan del FWK 2.0), de forma que si deseamos agregar más funcionalidad al adaptador, podemos hacerlo extendiendo la clase de forma muy sencilla:

Namespace AdventureWorksDALTableAdapters

    Partial Public Class CurrencyTableAdapter

        'Implementar aquí el código que extiende la clase

    End Class

End Namespace

¿Fácil verdad? Por un lado tenemos una herramienta que nos genera automáticamente el código de la capa de datos, y que además nos permite extenderlo… entonces ¿dónde está el truco?

Bueno, los DataSets Tipados aportan un montón de ventajas pero también tienen sus inconvenientes: Por ejemplo, nunca serán tan ligeros como una lista genérica de objetos, ya que precisamente aportan mucha funcionalidad (que no siempre es necesaria). Por otro lado el hecho de ser un código autogenerado hace que mucha gente (yo al principio) lo mire con cierto recelo, ya que al margen de los patrones habituales cada desarrollador tiene su propio método de hacer las cosas, y muchas veces uno piensa que sólo su código es el apropiado (ese defecto lo tenemos muchos :-P).

Figura 1 - DataSets Tipados generados a partir de la B.D. AdventureWorks

Pero tal vez el mayor inconveniente que particularmente les encontraba a los DataSets Tipados es lo complicado que resulta utilizarlos en un entorno transaccional, más cuando esto es algo básico, que casi todo desarrollador necesita utilizar hoy en día.

El contexto transaccional ¿cómo definirlo?

¿Quién no se ha encontrado ante la necesidad de realizar varias operaciones de lectura/escritura contra un origen de datos que precisen que se validen todas como una sola? El clásico ejemplo sencillo es el de un documento que contiene n líneas, aunque podemos imaginarnos lo que sería de los entornos bancarios sin la posibilidad de realizar transacciones… Pero sigamos, no quiero apartarme de tema que nos ocupa.

Actualmente el Framework proporciona dos alternativas para el uso de entornos transaccionales, la primera consiste en el viejo modelo conocido por todos, el clásico, en el que a partir de una conexión abierta con un origen de datos se inicia una transacción, a continuación se realizan todas las operaciones implicadas, y posteriormente se termina con éxito (Commit) o con error (Rollback), de forma que todas las operaciones se guardan o se vuelve al estado inicial.

Figura 2 - La clase SqlTransaction

La segunda alternativa es nueva de la versión 2.0 del Framework y consiste en el uso del nuevo espacio de nombres “System.Transactions” que forma parte de los "Enterprise Services Team" de Microsoft. La verdad es que el concepto es muy atractivo ya que permite cosas impensables hasta ahora, como por ejemplo definir un ámbito de contexto transaccional mediante una cláusula Using - End using, en la que todas las operaciones realizadas pertenecerán implícitamente a dicho contexto transaccional.

Figura 3- La clase TransactionScope

Otra característica destacable de este nuevo modelo es que permite escalar de forma automática una transacción, pasando de transacción ligera a transacción distribuida. Esto es así porque con al definir una nueva transacción, por defecto se intenta crear una transacción ligera, que significa que sólo accede a un recurso y es manejada por el “Lightweight Transaction Manager” o LTM, incluido con el espacio de nombres "System.Transactions". En el momento que esa transacción excede las capacidades del LTM, ya sea porque accede a un segundo recurso en la misma transacción o porque utiliza múltiples dominios de aplicación, ésta es promovida a lo que se llama "transacción distribuida" y pasa a ser manejada por el servicio coordinador de transacciones distribuidas o DTC.

Este proceso se realiza de forma automática, y la transacción resultante (que es controlada por COM+) ofrece un rendimiento bastante inferior al anterior, con que lo convierte en menos atractivo a nuestros ojos salvo en algunos casos puntuales (como implementar transaccionalidad entre distintas bases de datos).

Figura 4 - El coordinador de transacciones distribuidas en acción

A día de hoy, utilizar esta nueva metodología transaccional tiene una serie de desventajas frente al modelo clásico, ya que lo interesante sería usar siempre que fuese posible transacciones ligeras, y esto no siempre es posible. De hecho es bastante complicado ya que actualmente sólo existe soporte para SQL Server 2005, así que si usamos una versión anterior u otro motor de datos como Oracle no podremos usar las transacciones ligeras. Del mismo modo, antes he comentado que si se exceden las capacidades del LTM también se promocionan automáticamente a transacciones distribuidas, y realmente es bastante sencillo que esto ocurra. Basta con utilizar dos variables de conexión (aunque realmente apunten a la misma) dentro del contexto transaccional para promoverse a transacción distribuida.

A lo que íbamos, creando un adaptador transaccional

Bien, armado con el conocimiento de lo que nos ofrece el Framework me propuse implementar transaccionalidad en mis DataSets Tipados, algo sencillo en su concepto pero complicadillo en su implementación ya que en el código que se genera automáticamente cada adaptador dispone de una colección de objetos Command, y debemos alterar su comportamiento predeterminado para lograr nuestro propósito.

¡Manos a la obra! Empezaremos por definir el modelo transaccional, usaremos transaccionalidad clásica mediante el uso del objeto SqlTransaction. Partiremos de un modelo de datos conocido por todos: la base de datos AdventureWorks, y en esta ocasión usaremos el viejo y bueno VB como lenguaje de desarrollo.

Una vez tenemos en nuestro proyecto un conjunto de datos llamado AdventureWorksDAL.xsd (similar al de la figura 1) con los DataAdapters y DataTables necesarios, vamos extender las clases generadas mediante el uso de clases parciales. Para ello es importante saber que las clases a extender se encuentran dentro de un namespace llamado igual que el archivo del conjunto de datos más el sufijo “TableAdapters”:

Imports System.Data.SqlClient

Namespace AdventureWorksDALTableAdapters

    Partial Public Class CurrencyTableAdapter

        Private _Transaction As SqlTransaction

        Public Property Transaction() As SqlTransaction

Get

                Return _adapter.SelectCommand.Transaction

            End Get

            Set(ByVal value As SqlTransaction)

                If _adapter Is Nothing Then InitAdapter()

                For Each cmd As SqlCommand In Me.CommandCollection

                    cmd.Transaction = value

                Next

                If Not _adapter.InsertCommand Is Nothing Then _

                    _adapter.InsertCommand.Transaction = value

                If Not _adapter.UpdateCommand Is Nothing Then _

                    _adapter.UpdateCommand.Transaction = value

                If Not _adapter.DeleteCommand Is Nothing Then _

                    _adapter.DeleteCommand.Transaction = value

            End Set

        End Property

    End Class

End Namespace

Nótese que el código crea una propiedad de tipo SqlTransaction, a la cual asignaremos posteriormente el valor de una transacción iniciada, y que dicho valor será propagado por todos los objetos SqlCommand que contiene el adaptador llamado “_adapter”, el cual es privado e inaccesible por cualquier otro método que no sea la extensión de esta clase parcial.

Una vez realizado esto por cada una de las clases de nuestro conjunto de datos, vamos a ver cómo se utilizan estas clases en un entorno real. Let’s play! En primer lugar comprobaremos si la transaccionalidad en un solo adaptador funciona y posteriormente complicaremos un poco más el ejemplo y realizaremos cambios en distintos adaptadores para ver si realmente disponemos de un completo y robusto entorno transaccional.

Imports System.Data.SqlClient

Imports TestSqlTransaction_Adapters.AdventureWorksDAL

Imports TestSqlTransaction_Adapters.AdventureWorksDALTableAdapters

Public Class Form1

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

        Dim Transaction As SqlTransaction = Nothing

Try

            Dim CurrencyAdapter As New CurrencyTableAdapter()

            'Abre la conexión, inicia la trasnsacción y la asigna

            'a la nueva propiedad 'Transaction' para su propagación

            CurrencyAdapter.Connection.Open()

            Transaction = CurrencyAdapter.Connection.BeginTransaction()

            CurrencyAdapter.Transaction = Transaction

            Using Currencies As CurrencyDataTable = CurrencyAdapter.GetData()

                Dim Currency As CurrencyRow = Currencies.FindByCurrencyCode("EUR")

                Currency.Name += "*"

                Dim Changes As CurrencyDataTable = _

                  CType(Currencies.GetChanges(), CurrencyDataTable)

                If Not Changes Is Nothing Then CurrencyAdapter.Update(Changes)

            End Using

            Dim r As DialogResult = MessageBox.Show( _

              "Save changes to EUR?", _

              "Transaction", MessageBoxButtons.YesNo)

            If r = Windows.Forms.DialogResult.Yes Then

                Transaction.Commit()

            Else

                Transaction.Rollback()

            End If

        Catch ex As Exception

            Transaction.Rollback()

            MessageBox.Show(ex.Message)

        End Try

    End Sub

End Class

El ejemplo anterior ha sido sencillo y hemos podido comprobar cómo configurar nuestro adaptador y observar cómo era capaz de revertir a su estado anterior o de guardar los cambios. Vamos a realizar el mismo proceso con varios adaptadores para ver un ejemplo de uso un poco más real, de los de la calle vamos…

Imports System.Data.SqlClient

Imports TestSqlTransaction_Adapters.AdventureWorksDAL

Imports TestSqlTransaction_Adapters.AdventureWorksDALTableAdapters

Public Class Form1

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

        Dim Transaction As SqlTransaction = Nothing

Try

            Dim CurrencyAdapter As New CurrencyTableAdapter()

            Dim Currency As CurrencyRow

            'Abre la conexión, inicia la trasnsacción y la asigna

            'a la nueva propiedad 'Transaction' para su propagación

            CurrencyAdapter.Connection.Open()

            Transaction = CurrencyAdapter.Connection.BeginTransaction()

            CurrencyAdapter.Transaction = Transaction

            Using Currencies As CurrencyDataTable = CurrencyAdapter.GetData()

                Currency = Currencies.FindByCurrencyCode("EUR")

                Currency.Name += "*"

                Dim Changes As CurrencyDataTable = _

                  CType(Currencies.GetChanges(), CurrencyDataTable)

                If Not Changes Is Nothing Then CurrencyAdapter.Update(Changes)

            End Using

            Dim CurrencyRateAdapter As New CurrencyRateTableAdapter()

            'Propaga la conexión y la transacción a este adapter

            CurrencyRateAdapter.Connection = CurrencyAdapter.Connection

            CurrencyRateAdapter.Transaction = Transaction

            Using CurrencyRates As CurrencyRateDataTable = CurrencyRateAdapter.GetData()

                'Inserta una nueva fila con una cotización a fecha de hoy

                Dim oNewRate As CurrencyRateRow = _

                  CurrencyRates.AddCurrencyRateRow(DateTime.Today, Currency, _

                    Currency, 10D, 11D, DateTime.Now)

                Dim Changes As CurrencyRateDataTable = _

                  CType(CurrencyRates.GetChanges(), CurrencyRateDataTable)

                If Not Changes Is Nothing Then CurrencyRateAdapter.Update(Changes)

            End Using

            Dim r As DialogResult = MessageBox.Show( _

              "Save changes to EUR?", _

              "Transaction", MessageBoxButtons.YesNo)

            If r = Windows.Forms.DialogResult.Yes Then

                Transaction.Commit()

            Else

                Transaction.Rollback()

            End If

        Catch ex As Exception

            Transaction.Rollback()

            MessageBox.Show(ex.Message)

        End Try

    End Sub

End Class

Creo que con este ejemplo queda claro que la implementación de transaccionalidad en objetos TableAdapter no es demasiado complejo, y el resultado bien merece la pena. Al fin y al cabo ¿quién no necesita transaccionalidad hoy en día?

Saludos a todos y ser buenos, o los reyes no os traerán nada...

** crossposting desde el blog de Lluís Franco en geeks.ms **