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):
|
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
17 Responsesso far
Buen artículo, ya decía yo porque seguía la referencia de VisualBasic… pensaba que la memoria me jugaba una mala pasada…
Jorge otra ventaja de no usar esta librería es que el cambio de pasar de VB a C# es más natural. Una programador VB.Net debería estar apto para postular a ofertas laborales donde pidan C#, pero si usa las funciones de esta librería (Microsoft.VisualBasic.dll) va tener que averiguar como se hacen lo mismo pero en C#… y ahí empiezan los problemas…
He visto casos que amigos se desaniman a postular a una oferta porque pedían programadores C#, y ellos sabían VB.Net… Es más las empresas deberían no pedir programadores C# o Vb.Net, sólo deberían pedir programadores .Net, pero eso es harina de otro costal…
Saludos,
Muy buenas indicaciones Sergio.
Todo lo que sea cerrarse puertas es un error, y la clave es ser multidisciplinar, incluso dentro de los ámbitos de los lenguajes de desarrollo.
Desde mi punto de vista, Microsoft.VisualBasic.dll ofrece muchas ventajas (comodidad, salto a .NET, etc), pero a la vez, ofrece muchos inconvenientes que se sufren a la larga.
Algunos de esos inconvenientes, los has indicado perfectamente en tu comentario.
Un saludo,
Jorge
Excelente articulo Jorge¡¡¡
un saludo desde Lima , Perú.
Jorgito,
La posibilidad de eliminar la referencia a Microsoft.VisualBasic.dll la anunció por primera vez Paul Vick aquí:
http://www.panopticoncentral.net/archive/2007/05/31/20766.aspx
Se implementó con la Beta 2 de Orcas.
Abrazo – Octavio
¡Gracias Octavio!
Entonces, según el bueno de Paul solo se puede realizar desde la línea de comandos (desde Visual Studio 2008 como indicaba en la entrada), por lo que falta que se implemente desde Visual Studio (que es lo que hecho en falta como digo en el artículo).
Lo que no tenía ni idea es de los aspectos relativos a los helpers.
No sé si lo habrán arrastrado a la versión RTM o si lo habrán solucionado, o si realmente, una librería sin referencia a Microsoft.VisualBasic.dll como la de esta entrada, fallará por los motivos que expone Paul de que chequea esa librería se utilice o no. ¿?
Esto tengo que investigarlo un poco más. :-)))
Gracias Octavio.
Bueno, yo no tengo mucha idea del tema… Solo me acordaba de ese post porque soy un gran detractor de Microsoft.VisualBasic.dll y casi todo lo que tiene dentro 😉
No estoy al día en el tema, pero creo que en el CLR para Silverlight no estará esa DLL, así que deberían arreglar eso en el entorno, ¿no?
Abrazo – Octavio
Gracias Jorge por compartir este TIP!
Tambien en nuestros proyectos como comenta Sergio, tenemos desarrolladores C# y VB por lo tanto las guias de desarrollo tiene que ser un poco «generales» si utilizar My por ejemplo.
Bueno, como bien dices esta libreria deberia ser OPCIONAL 🙂
Saludos
bah, me da mucha lástima que gasten tanta energía escribiendo e investigando sobre esto. Me pregunto si el gasto de tiempo, los scripts nant, y todas esas cosas extras que se realizan (incluyendo explicarles porque tienen que dejar de usar esas clases a los programadores vb que vienen haciendolo hace siglos) para liberar un par de recursos, valen la pena.
Por favor, si hacen estos trabajos de investigación por lo menos dense el trabajo de fundamentar sus aceveraciones con un profiling a una o varias aplicaciónes de tamaño decente para ver si realmente vale la pena.
El tiempo ganado programando con esta librería (especialmente con el namespace My) es insospechadamente benéfico para los proyectos, y personalmente no creo que ninguna ganancia en performance o «recursos» justifique su eliminación.
Me hace pensar si esto es meramente un acto de idealismo purista. Pero con un profiling me podrían cerrar la bocota.
Hay gente para todo y comentarios para todo delm.
Es tu postura, «respeta la de los demás» creo que es un buen principio para que puedas conseguir algo en esta vida.
Si a tí te gusta investigar de esa forma adelante, pero déjanos a los demás investigar, postular, y … como tu lo quieras llamar.
Saludos y buen aporte Jorge.
Gracias.
Francisco J.
Jorgue, creo que deberias pasarte a c#, es broma. Salu2.
Juan, precisamente creo que lo más positivo para un desarrollador de .NET, es conocer los dos lenguajes, VB y C#.
Yo me encuentro tan cómodo con un lenguaje como con el otro, pero un poco más cómodo si cabe con VB. 🙂
Muy buen post si señor, la verdad que todo lo que sea opotimizacion genial. Yo pase de Visual 6 a C# y ahora he vuelto a programar con VB.NET y viendo este post si que me he dado cuenta de que sigo con muchos de los vicios provenientes de VB6, lo que no sabía es que influyesen en el rendimiento.
El problema es que por el momento para el proyecto en el que estoy involucrado, el cual , no es demasiado pequeño me parece demasiado engorroso tener que estar generando los ensamblados desde linea de comandos, asi que de momento esperaré a que lo incluyan en el entorno aunque empezare desde ya a adaptar el codigo para que no use la librería.
Saludos.
Javier
Francisco J:
Si has sentido que te he faltado el respeto a tí o a los lectores del post, no es problema mío. Y con este comentario tampoco falto el respeto.
Sí me puedes acusar de ser duro en las críticas y de no usar palabras suaves. Eso tiene propósito e intención.
Ahora, sobre el tema…
Si algo ayuda a desarrollar de manera rápida, no es malo simplemente debido a que impacta en performance. Hay que ver CUANTO impacta en performance para ver si vale la pena siquiera pensar en esforzarce por cambiarlo, y eso sin mensionar el necesario análisis de impacto en otras áreas como capacitación y resistencia al cambio.
Todo esto es completamente insignificante si estamos hablando de una aplicación crítica o en tiempo real… pero también creo que hay lenguajes más adecuados para esos escenarios.
Siendo un programador de Java y mas recientemente C# y VB.NET (si, no he pasado por VB6), creo que sé algo de purismo fundamentalista. Simplemente no hace bién, y la mejor forma de no ser acusado de fundamentalismo es simplemente mostrando números que respalden tus observaciones.
Ahora, eso lo exijo porque este es un blog de un MVP y no de cualquier pelafustán en la red.
Como un punto aparte, realmente creo que vb y c# se complementan. Encuentro excelente que Microsoft siga con su postura multilenguajes, y espero que sigan saliendo más como F# y IronRuby. Todos aportan.
pues yo creo que está bien que haya este tipo de posts, porque además de la gente «productiva» de empresa que quiere hacerlo todo rapido… hay gente ue le gusta programar bien y no arrastrar vicios e incompatibilidades futuras que solo retrasan el ostiazo x’D
La informatica tiene varios aspectos; productivo, imaginativo, purista, etc … y esta bien que se fomenten todos, ya que hay muchos puntos de vista.
Respecto a lo que es MVP… que coño tendrá que ver eso ? es una persona como todo el mundo, el hecho de ser MVP es su continuo apoyo a la comunidad, y ello supone post «productivos» y posts «puristas».
Happy !
Delm, eres un perdonavidas y un chulo, pero me caes bien. Perdona que sea tan directo, no es una falta de respeto y si te lo tomas a mal es problema tuyo.
Ahora sobre el tema…
En mi opinión, que también soy programador Java (como si eso significara algo) a veces la diferencia entre programar bien o mal es una cuestión de buenas prácticas. Yo creo que este post va en ese sentido. Ahora que conoces cómo hacer lo que comenta Jorge, tú decides si en tus proyectos se va a poder aplicar o no. El hecho de que exijas algo a alguien hace que me parta la caja de risa. ¡Eres la bomba! 😀
¡Qué simpática es la gente por estos lares! Tendré que pasarme más por aquí.
Ánimo con el blog Jorge.
Jorge!!.. excelente post.. yo sigo arrastrando los vicios de Vb6..esto me sirve para obligarme a mi mismo a no hcerlo mas….Muchas gracias por tu aporte… personalmente me sirve muchisimo!!…
Hector desde Buenos Aires
Como se elimina esta referencia en .net 2.0?
pregunto poque intenté hacer esto pero el /vbruntime- no existe
Saludos