Jorge Serrano
  • Home

Cada vez que migras una línea de código de VB6 a .NET se muere un gatito en el mundo

  • By jorge
  • Oct-27-2010
  • Sin categoría
  • 21 Comments.

Desde hace un corto espacio de tiempo a esta parte le he cogido gustillo al Twitter, y debo admitir que cada vez más.

He comprobado que esta herramienta no sólo se puede usar adecuadamente, sino que se puede usar de forma inadecuada hasta casi mantener un chat.
Eso es lo que ha pasado recientemente cuando algunos de las personas que me siguen en Twitter comenzamos a lanzar mensajes sobre migraciones de VB6 a .NET.

En este punto volvió a surgir la posibilidad de hacer un evento en MADNUG (el Grupo de Usuarios de .NET de Madrid) sobre este tema, algo sobre lo que ya estaba trabajando.

No obstante, surgieron interesantes comentarios al respecto y que me gustaría comentar.

Por un lado, hay muchísimas empresas hoy día que tienen productos Software desarrollados en VB6 (en la que actualmente trabajo sin ir más lejos).
También es cierto, que muchas empresas que tienen su Software desarrollado en VB6 creen que migrarlo a .NET es prácticamente automático (gran error).
Evidentemente, esas empresas no saben lo que son las pruebas unitarias ni tampoco consideran que aporten valor al Software (más que nada porque sus aplicacionesde VB6 adolecían de esto y funcionan «muy bien»).
Otras muchas piensan que al llamarse igual, ló único que varía es el «6» por «.NET».
En muchos otros sitios, se piensa que Interop es la solución a todos los males.
Siguiendo con Interop, también hay muchas empresas o desarrolladores, que creen que Microsoft Windows Interop 2.1 es el aliado perfecto para continuar creciendo nuestro «engendro» creando un híbrido entre VB6 y .NET.
Incluso se piensa que ese híbrido entre VB6 y .NET es fácilmente mantenible y que Interop Forms Toolkit nos proporcionará más ventajas que una aplicación desarrollada únicamente con .NET.
Otras empresas migran y dejan la migración tal y como está (ADO, wrappers & Interop, etc).
Finalmente, otras piensan que todo eso está muy bien pero que es necesario empezar el desarrollo de cero.

Lo cierto es que cada uno tiene sus opiniones y experiencias, y lo que está claro es que no es lo mismo migrar una aplicación «simple» de VB6 a .NET, que una aplicación compleja.
Tampoco es directo el uso de controles de terceros y migrarlos por arte de magia a .NET.
También nos podemos encontrar con que determinadas propiedades de controles de VB6 no tienen su equivalente en .NET.
E incluso podríamos toparnos de bruces con objetos curiosos como VBA.Collection por citar uno con el que me he topado recientemente.

Son obstáculos, salvables muchísimos de ellos, pero muchos creen que no es necesario migrar, y ya no digamos empezar un desarrollo de cero desde VB6 a .NET.
Cierto es el dicho de si funciona no lo toques, pero cuidado con las cosas que no se tocan si quieres o tienes pensado abordar ciertos retos que hoy por hoy VB6 no te puede ofrecer (nuevas tecnologías, interoperabilidad, seguridad, etc).

Otro aspecto a tener en cuenta, es el soporte de VB6.
Por ahora vamos bien, porque utilizar un Software desarrollado en VB6 en sistemas operativos actuales (hasta Windows 7) es factible gracias al trabajo desempeñado por Microsoft para que así sea, sin embargo, la propia Microsoft no asegura que en un hipotético windows 8, VB6 continúe ejecutándose sin problemas como hasta ahora.
¿Qué hacer?. Muchos piensan que hasta que eso ocurra no nos debemos preocupar. De hecho, recientemente he ido a una administración pública en España y esta en concreto están llevando un concurso ahora para migrar sus Windows 2000 a Windows XP.
Se me ponen los pelos de punta con tan sólo pensarlo. No sé si será posible pasar ahora a un sistema operativo del año 2001, posiblemente no sea así y tenga que ser más actual, pero tener a finales del año 2010 un sistema operativo de hace 10 años da un poco de repelús, sinceramente (mi primer Linux lo instalé en el año 1996 y no se me ocurriría instalarlo hoy, me iría a la última versión o la más reciente posible).
Pero en este punto me he encontrado con otro problema (y cuento mi experiencia). Nuestro desarrollo de .NET es en .NET 4.0. Tenemos nuestra aplicación de VB6 y en este caso y por necesidades del guión, una pequeña utilidad que está desarrollada en .NET, sin embargo, y debido al soporte de windows 2000, nos vemos en la obligación de desarrollarla en .NET 2.0 para que se ejecute en Windows 2000 sin problemas.
Es decir, que para este caso concreto, el híbrido es más híbrido aún, teniendo una misma librería desarrollada en .NET 4.0 con LINQ (tal y como se había programado originalmente) y para este caso concreto, una «especial» en .NET 2.0.

Cuento esta pequeña experiencia porque todos y cada uno de nosotros tenemos la nuestra propia.
¿Migrar de VB6 a .NET?, ¿empezar el desarrollo completo de cero de VB6 a .NET?, ¿pasar bloques o partes de VB6 a .NET poco a poco?, ¿pros?, ¿contras?, ¿acceso a datos?, ¿apis?, ¿controles personalizados?, ¿controles de terceros?, ¿recursos?, ¿multidioma?, ¿seguridad?,… etc.

Ernesto por su parte, nos invitó a acceder y leer una entrada que él mismo ha publicado recientemente sobre este tema, entrada que conviene leer por tener sus particulares puntos de vista (la experiencia de todos es la que nos da una visión más enriquecedora).

Si se lleva a cabo el evento en MADNUG de migración de Software de VB6 a .NET, promete ser muy entretenido y dispar.
No obstante, si te atreves y te ves con ganas y fuerzas, me gustaría que indicaras aquí tu experiencia para nos enriquezcamos todos.

Es muy interesante que hablemos de estas cosas sin ningún tipo de rubor, digamos lo que pensamos y quizás nos animemos a tomar el toro por cuernos sin miedo a ser cogidos.
Cada vez que se migra una línea de código de VB6 a .NET no se muere ningún gatito en el mundo. Creo que en esto hay mucho temor, mucho más del que muchos admiten públicamente, y muchas empresas no se atreven aún en dar el salto a .NET porque temen que algún gatito fallezca por el camino.

P.D.: Y ya no hablo de migraciones de FoxPro a .NET porque esto es ya para nota.

Un saludo.

Comments

21 Responsesso far

  1. elbruno dice:
    27 octubre, 2010 a las 10:20 am

    Pues ya sabes que cuentas conmigo para la mesa redonda … VB6 es una de mis escuelas y la verdad es que hay mucho para comentar al respecto ^^

    Salu2

    Responder
  2. jorge dice:
    27 octubre, 2010 a las 10:45 am

    ¡Por supuesto!
    Muchas gracias Bruno.
    Podemos ir preparando ya el evento. 😉

    Responder
  3. adiazmartin dice:
    27 octubre, 2010 a las 11:04 am

    Yo no veo que se pueda llamar migración. Como sabemos, realmente deberían de desarrollar una aplicación nueva desde cero.

    ¿no sería recomendable aprovechar para volver a analizar y mejorar el producto?

    Responder
  4. rfog dice:
    27 octubre, 2010 a las 11:06 am

    ¿Ve? Yo no tengo ese problema.

    Nunca he migrado una línea de VB6 a .NET… ni ya de paso escrito siquiera una. 🙂

    Responder
  5. jorge dice:
    27 octubre, 2010 a las 1:57 pm

    Muchas gracias por comentar Alberto y Rafael.

    @Alberto, no es migración y sí lo es. En Visual Studio hay una herramienta (creo recordar que en VS 2010 ya no está disponible) que migra un proyecto de VB6 a .NET. Arregla unas cuantas cosas y otras las deja para que las arregles tú.
    Sin embargo, apuntas una cosa que aplaudo a más no poder, la posibilidad de aprovechar el momento para analizar y mejorar el producto.
    Interesante tema para debatir, porque a lo mejor es bueno adaptar el Software de acuerdo a los requerimientos, pero no todas las empresas tienen los recursos económicos ni el personal cualificado o preparado para llevar a cabo esta tarea.
    Es interesante, muy interesante lo que apuntas, pero ¿es realmente viable?.

    @Rafael, ¡suerte que has tenido!. Te envidio, aunque pasar una línea de código de VB6 a .NET es muy interesante, se convierte incluso a veces en un reto. 🙂

    Responder
  6. anonymous dice:
    27 octubre, 2010 a las 2:02 pm

    ¿Y qué podemos decir de la siguiente cuestión?

    ¿Y si tenemos que migrar nuestra aplicación de VB6 a C#? Creo que ahí si estaríamos ante la tesitura de analizar y mejorar el producto o pasar por una doble conversión con lo que podría haber una pérdida de código asociada.

    VB6 <> VB.NET
    VB.NET <> C#

    Saludos.
    Fran

    Responder
  7. jtorrecilla dice:
    27 octubre, 2010 a las 2:11 pm

    @Fran, personalmente si el paso se va a realizar de VB6 a C#, yo sin pensarlo, lo haria directemante, porque pasarlo primero a VB .NET y luego a C# sería realizar, casi un proyecto nuevo en VB.NET, y luego una migración.

    Hablamos de migraciones a .NET, concretamente a VB.NET, porque el desarrollador de VB6 se puede sentir mas cómodo a la hora de codificar, porque todavía existen cosas que funcionan en VB.NET provenientes de VB6, sin embargo, si pasamos a C# para que dichas funcionalides «funcionen», valga la redundancia, sería necesario exportar el namespace VisualBasic…

    Soy muy PRO VB.NET, pero algo que si que considero que ayudaria a un desarrollador de VB6 a conocer mejor el FrameWork, sería empezar con C#, para tener un cambio de forma de pensar.

    Saludos.

    Responder
  8. crisfervil dice:
    27 octubre, 2010 a las 2:15 pm

    Y con lo que mola el VB6!! Cuántas horas, jajaja, y qué recuerdos!
    Pero si las migraciones molan! Ahora estoy trabajando en una de Power Builder a Asp.net, o sea de una plataforma de escritorio a un entorno cliente-servidor. Menudo reto!!
    Una de las conclusiones que he sacado, es que el momento de la migración, es momento de reanálisis. En mi caso creo que habría supuesto un ahorro de costes. Básicamente por que la aplicación tiene la tira de años, y un montón de funciones que ya nadie recuerda para qué servían. Y las hemos tenido que migrar de todos modos. Un reanálisis, viendo qué es imprescindible, en el que se fueran migrado funciones de a poco, habría supuesto sin duda un ahorro.

    Responder
  9. anonymous dice:
    27 octubre, 2010 a las 2:18 pm

    Totalmente de acuerdo contigo.

    Un buen conocimiento del .NET Framework ayudará a realizar una mejor migración y llegado el caso a readaptar toda la aplicación, pero como mencionaba Jorge todo ello requiere de personal y recursos varios.

    Saludos.
    Fran

    Responder
  10. adiazmartin dice:
    27 octubre, 2010 a las 8:09 pm

    Viable o no viable el re-análisis y las mejoras tienes que llegar.

    Aunque sea en forma de UX o de rendimiento del código.

    La migración automática no era muy buen y poco recomendable cuando utilizas OCX (cosa que era muy habitual en vb6)

    Responder
  11. anonymous dice:
    27 octubre, 2010 a las 9:43 pm

    Sinceramente, antes de pensar en migrar una aplicación de Vb6 a .NEt, pensaría primero en realizar un proyecto nuevo (a ser posible pequeño) que entre a tu empresa, en Vb.Net y cuando te sientas suelto, pensar en migrar la aplicación. Por supuesto en .Net partir con alguna Suite de controles de terceros.

    Responder
  12. anonymous dice:
    28 octubre, 2010 a las 8:06 am

    nadie llorará unos miserables gatitos…

    Responder
  13. anonymous dice:
    28 octubre, 2010 a las 11:25 am

    deberiamos mirar aver si de alguna forma pudieramos diseñar algun programa para hacerlo compatible…eso seria genial asi de un plumazo seguiriamos en Vb6 en los nuevos Windows…Esto va a afectar a millones de empresas que tienen programas de arquitectura Vb6.

    Responder
  14. anonymous dice:
    29 octubre, 2010 a las 9:34 am

    Pues yo tengo experiencia en .Net, y eso definitivamente es muy necesario si se quiere acometer una migracion, el problema es cuando te falta la otra parte, el conocimiento de lo que hacia internamente la aplicación a migrar.

    Cuenta conmigo para lo de la sesion, en este momento estoy probando tres herramientas de apoyo que vienen a ayudar mucho en el workflow que estoy pensando para una migración efectiva.

    Como dije en mi post, en un momento Microsoft decidio romper la compatibilidad de manera radical, haciendo un gap muy grande, pues los cambios son en dos areas: lenguaje y framework (COM/.NET), siendo que el primero es el que da mas problemas por los comportamientos que esperabas en algunas acciones.

    Responder
  15. anonymous dice:
    29 octubre, 2010 a las 2:47 pm

    Yo tampoco voy a hablar de migraciones de RM/Cobol 85 a C#.NET porque tambien son palabras mayores. 🙂

    Me lo tomo como hobby ..

    Responder
  16. anonymous dice:
    1 noviembre, 2010 a las 7:13 am

    Aquí va la segunda parte de mis reflexiones acerca de una migración…. si se decide que ese es el camino.

    http://www.consultorinternet.com/2010/10/pensando-en-estrategias-de-migracion-de.html

    Espero sus comentarios 🙂

    Responder
  17. anonymous dice:
    8 noviembre, 2010 a las 5:42 pm

    La verdad es que todo esto es muy entretenido, yo paso de migraciones, loq ue estoy haciendo es pasando el código poco a poco y como puedo, de otra manera en lo que se refiere acceso a datos, no pasando a NET PURO estás bien jodido, de tomas maneras bien jo… estamos.

    un saludo a todos, y aquí estoy para lo que querais.

    Jesús

    Responder
  18. anonymous dice:
    11 noviembre, 2010 a las 1:59 am

    Con visual basic 6 hacemos y hemos hecho auténticas virguerías. Y si las hemos hecho se debe a que no era nada complicado el programar con éste maravilloso lenguaje.

    Formularios, funciones y módulos.

    Bueno, también estaban algunos más atrevidos creando ocx, dll’s. Que por cierto me hace gracia lo de crear dll’s ya que con visual basic 6 había unos pocos que creían saber programar dll’s y eso es un poco discutible.

    Para mi, una dll que chute, y bien, como mínimo debe de tener 200 líneas de código y a ver que código.

    Para meter menos líneas en una dll para eso te creas una simple function y arreando.
    A bacilar a la cibeles!! jeje

    Ahora que pasa, pues que viene el Visual Basic.NET. Bueno eso de que viene lleva viniendo desde el año 2002.

    De programar en vb6 a vb.net sigue siendo programar. Hasta ahí deacuerdo, pero viene con un regalito llamado framework.

    Sálvese quien pueda.

    Quien diga, crea o piense que sabe programar con visual basic.net está diciendo que conoce framework. Y conocer framework es saber de dónde cuelga lo que hace que tu código funcione. Sí o sí?

    Me escojono cuando veo ofertas donde pone
    programadores en .net

    sería tan amable de explicarme que lenguaje es el que requiere ese puesto de trabajo? gracias!!

    Mas que nada porque hay C#, Visual Basic, Delphi (Object Pascal), C++, J#, Perl, Python, Fortran, Prolog (existen al menos dos implementaciones, el P#[1] y el Prolog.NET[2] ), Cobol y PowerBuilder.

    Claro, lo mejor es pensar que la persona que pone el anuncio no tiene porque saber de tecnologías. Me parece correcto pero a la persona que pone el anuncio alguien le pasará lo que requiere el puesto de la oferta no?

    Jamás existirá un experto en .NET al igual que en JAVA.

    Visual basic.NET no es visual basic.

    Saludos !!

    Responder
  19. anonymous dice:
    22 marzo, 2011 a las 4:53 pm

    Migra una aplicacion, es como una matrimonio, es un evento importante, que debe considerar compromiso, pero para adoptar el compromiso debes conocer los pro y los contra, segun mi experiencia antes de migrar una aplicacion debes tener en cuenta si vale la pena el cambio, asi de simple

    Responder
  20. Roberto Miguel Garcia Aguirre dice:
    9 octubre, 2018 a las 9:19 pm

    Al final si hay diferencias considerables desde VB6 a VB.NET. Yo recomiendo comprender la lógica y recrear de 0 en VB.NET.

    Responder
  21. Roberto dice:
    18 julio, 2019 a las 10:26 pm

    Es bien complejo el tema. Si no tienes tiempo…hay que migrar con Interop o como puedas. Si tienes tiempo y recursos, directamente reescribe todo en .NET Es mas robusto y será mantenible por más tiempo.

    Responder

Deja un comentario Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

← Previous Post Next Post →

Jorge Serrano

MVP Reconnect


¡Subscríbete a mi canal!
YouTube

Donaciones
Donation

Entradas recientes

  • Go – Arrays
  • Go – Operators
  • Go – Constants
  • Go – Tipos de Datos
  • Go – Variables
  • Hello Go-rld!
  • Introducción a Go o Golang
  • JSON Patch en ASP.NET Core 5 Web API
  • Null Checking en C#
  • ¿Porqué mi página web por defecto de ASP.NET Core no se vé en mi Azure Web App y me da un 404?

Categorías

  • .NET 5
  • .NET Core
  • .NET Core 3.0
  • .NET Core 3.1
  • .NET Framework 2.0
  • .NET Framework 3.0
  • .NET Framework 3.5
  • .NET Framework 4.0
  • .NET Framework 4.5
  • .NET Framework 4.6
  • .NET Framework 4.7
  • .NET Framework 4.8
  • .NET Standard 2.0
  • .NET Standard 2.1
  • AMQP
  • Android
  • Angular
  • API REST
  • Apple
  • Apple iOS
  • Apple macOs
  • Arquitectura
  • ASP.NET
  • ASP.NET Core
  • ASP.NET Core 3
  • ASP.NET Core 5
  • AWS
  • Azure App Service
  • Azure Application Insights
  • Azure Cosmos DB
  • Azure Database Migration Service
  • Azure Databricks
  • Azure DevOps
  • Azure Event Grid
  • Azure Functions
  • Azure IoT
  • Azure Portal
  • Azure PowerShell
  • Azure Queue Storage
  • Azure SQL
  • Azure Storage
  • Azure Virtual Datacenter
  • Azure WebApps
  • Big Data
  • Bing
  • Blazor
  • Blog
  • Bots
  • C#
  • C# 7.0
  • C# 7.1
  • C# 7.2
  • C# 7.3
  • C# 8.0
  • C# 9.0
  • Channel 9
  • Codeplex
  • Codespaces
  • Containers
  • Debugging
  • DevOps
  • Docker
  • Electron
  • Entity Framework
  • Entity Framework Core
  • Entity Framework Core 3.0
  • Entity Framework Core 5
  • Eventos
  • F#
  • FaaS
  • FeatureFlags
  • FeatureToggles
  • Feeds
  • Fluent Assertions
  • General
  • GIMP
  • Git
  • GitHub
  • Go
  • Google
  • Google Analytics
  • Gradle
  • gRPC
  • GSA
  • Historia de la Informática
  • HoloLens
  • HtmlAgilityPack
  • IdentityServer4
  • Inkscape
  • Ionic
  • iOS
  • IoT
  • Java
  • JavaScript
  • JDBC
  • JSON
  • Kubernetes
  • Lenguajes de Programación
  • Libros y Cursos
  • LINQ
  • Linux
  • LiteDB
  • Machine Learning
  • macOS
  • Microservices
  • Microsoft
  • Microsoft .NET Framework 4.5
  • Microsoft 365
  • Microsoft Azure
  • Microsoft Build
  • Microsoft Ignite
  • Microsoft Learn
  • Microsoft Orleans
  • Microsoft Surface Go
  • Microsoft Teams
  • ML.NET
  • MQTT
  • MRO
  • MS-DOS
  • MsCoders Madrid
  • MVP
  • NancyFx
  • Node.js
  • NoSQL
  • NuGet
  • NUnit
  • OData
  • ODP.NET Core
  • Office 2007
  • Office 2010
  • Office 2013
  • Office 2016
  • Office 2019
  • Office 365
  • Open Source
  • Open XML SDK
  • Opinión
  • Orchard CMS
  • OT
  • PaaS
  • Patterns
  • PdfSharpCore
  • Performance
  • PHP
  • Postman
  • Power BI
  • PowerShell
  • PowerShell Core
  • Productividad
  • Project Server 2019
  • R
  • Rendimiento
  • Scala
  • Scraper
  • Security
  • Serverless
  • Service Fabric
  • SharePoint Server 2019
  • SignalR
  • Sin categoría
  • Sistemas Distribuidos
  • Skype
  • Skype for Business Server 2019
  • Small Basic Online
  • SQL Server 2005
  • SQL Server 2008
  • SQL Server 2012
  • SQL Server 2014
  • SQL Server 2016
  • SQL Server 2017
  • SQL Server 2019
  • STOMP
  • Swagger
  • Testing
  • TFS 2017
  • TFS 2018
  • Tools
  • TypeScript
  • Unity
  • UWP
  • UX
  • Visio
  • Visual Basic
  • Visual Studio 2010
  • Visual Studio 2012
  • Visual Studio 2013
  • Visual Studio 2015
  • Visual Studio 2017
  • Visual Studio 2017 for Mac
  • Visual Studio 2019
  • Visual Studio 2019 for Mac
  • Visual Studio App Center
  • Visual Studio Code
  • Visual Studio IntelliCode
  • Visual Studio Live Share
  • Visual Studio Live Share Audio
  • Visual Studio Online
  • VS Anywhere
  • Vue.js
  • Web API
  • WebAssembly
  • WinDbg
  • Windows
  • Windows 10
  • Windows Compatibility Pack
  • Windows Phone 10
  • Windows Phone 7
  • Windows Phone 8
  • Windows Server 2008
  • Windows Server 2012
  • Windows Server 2016
  • Windows Server 2019
  • Windows Service
  • WinForms
  • WinUI
  • WPF
  • Xamarin
  • Xbox
  • Xcode
  • Xiaomi Mi Band 2
  • xUnit
  • YAML

Archivos

  • enero 2021
  • diciembre 2020
  • noviembre 2020
  • octubre 2020
  • septiembre 2020
  • agosto 2020
  • julio 2020
  • junio 2020
  • mayo 2020
  • abril 2020
  • marzo 2020
  • febrero 2020
  • enero 2020
  • diciembre 2019
  • noviembre 2019
  • octubre 2019
  • septiembre 2019
  • agosto 2019
  • julio 2019
  • junio 2019
  • mayo 2019
  • abril 2019
  • marzo 2019
  • febrero 2019
  • enero 2019
  • diciembre 2018
  • noviembre 2018
  • octubre 2018
  • septiembre 2018
  • agosto 2018
  • julio 2018
  • junio 2018
  • mayo 2018
  • abril 2018
  • marzo 2018
  • febrero 2018
  • enero 2018
  • diciembre 2017
  • noviembre 2017
  • octubre 2017
  • septiembre 2017
  • agosto 2017
  • julio 2017
  • junio 2017
  • febrero 2015
  • octubre 2014
  • junio 2014
  • marzo 2014
  • febrero 2014
  • enero 2014
  • diciembre 2013
  • septiembre 2013
  • agosto 2013
  • julio 2013
  • junio 2013
  • abril 2013
  • febrero 2013
  • enero 2013
  • diciembre 2012
  • noviembre 2012
  • septiembre 2012
  • agosto 2012
  • junio 2012
  • mayo 2012
  • abril 2012
  • marzo 2012
  • febrero 2012
  • enero 2012
  • diciembre 2011
  • noviembre 2011
  • octubre 2011
  • septiembre 2011
  • agosto 2011
  • julio 2011
  • junio 2011
  • mayo 2011
  • abril 2011
  • marzo 2011
  • enero 2011
  • diciembre 2010
  • noviembre 2010
  • octubre 2010
  • septiembre 2010
  • agosto 2010
  • julio 2010
  • junio 2010
  • mayo 2010
  • abril 2010
  • marzo 2010
  • febrero 2010
  • enero 2010
  • diciembre 2009
  • noviembre 2009
  • octubre 2009
  • septiembre 2009
  • agosto 2009
  • julio 2009
  • junio 2009
  • mayo 2009
  • abril 2009
  • marzo 2009
  • febrero 2009
  • enero 2009
  • diciembre 2008
  • noviembre 2008
  • octubre 2008
  • septiembre 2008
  • agosto 2008
  • julio 2008
  • junio 2008
  • mayo 2008
  • abril 2008
  • marzo 2008
  • febrero 2008
  • enero 2008
  • diciembre 2007
  • noviembre 2007
  • octubre 2007
  • septiembre 2007
  • agosto 2007
  • julio 2007
  • junio 2007
  • mayo 2007
  • abril 2007
  • marzo 2007
  • febrero 2007
  • enero 2007
  • diciembre 2006
  • noviembre 2006
  • octubre 2006
  • septiembre 2006
  • agosto 2006
  • julio 2006
  • junio 2006
  • mayo 2006
About This Site

A cras tincidunt, ut tellus et. Gravida scel ipsum sed iaculis, nunc non nam. Placerat sed phase llus, purus purus elit.

Archives Widget
  • January 2010
  • December 2009
  • November 2009
  • October 2009
Categories
  • Entertainment
  • Technology
  • Sports & Recreation
  • Jobs & Lifestyle
Search
  • twitter

Powered by WordPress  |  Business Directory by InkThemes.

This site uses cookies: Find out more.