SoloCodigo

Hola Angel_K_ido   ..mmmm...las similitudes entre el VB.net y el C#..es que los 2 utilizan el Net Framework.. ...Vb.Net ahora trae una visión orientada a objetos (asemejandose a la vision de C++) y C# ahora trae más facilidades  parecidas a las de visual basic..y tambien trae una orientacion a eventos..(como en visual basic..osea programar en el click de un botón que insertaste del toolbord )... ..Para el Net Framework trabajar en VB.Net o C# es transparente ya que ambos se compilan en el CLR  y generan un codigo intermedio llamado MIL (haciendo invisible el lenguaje)..este MIL se ejecutara por el JIT dependiendo del dispositivo... ..es decir si es un teléfono movil o una Pocket etc...(esa es otra ventaja..no tienes que preocuparte en donde se ejecutará el programa.. )..el Net Framework tambien se le pueden adaptar tecnologias antiguas como el COM.. ..bueno es eso y otras cositas más que se me escapan ..pero segun yo esto es lo ´más importante.. ..
Más tarde te paso unos Links... ..
Bye!.. ..espero no haberte confundido.. ..sino cualquier cosa nos avisas..

 Muchachos...

Es mejor de lo que yo imaginaba y según veo, muy flexible en cuanto a las distintas plataformas, mejor dicho, independiente.

Me gusta mucho la idea. Y por eso desde hoy me meto de lleno en el tema.

Muchas gracias.

Nos vemos  

Un vistazo al Visual Basic .NET y su relación con el .NET FrameWork

El entorno de desarrollo de Visual Basic.NET, trabaja bajo el .Net FrameWork, que es la plataforma sobre la cual trabajan todos las herramientas de desarrollo .NET, ya sea C#.NET, C++.NET, VB.NET, entre muchas otros.
   Algo importante a tomar en cuenta al utilizar no solo Visual Basic.NET, sino todas las herramientas que trabajan bajo el .NET FrameWork es que todos son ejecutados bajo el CLR (Common Language RunTime), además de existir
Un lenguaje, el IL (Intermediate Lenguage), que de hecho es el único lenguaje que reconoce el CLR. Todos los lenguajes compilan su código fuente al lenguaje intermedio (gracias al CLR Jut-In-Tme Compiler ) para después ser procesador por el CLR. (Este ultimo a su vez componente del .NET FrameWork)
   Una gran diferencia con Visual Basic 6.0 es la nueva concepción de OOP (Programación orientada a objetos) que adoptó Microsoft, donde ahora se pueden utilizar explícitamente los constructores, la herencia, creación de interfaces, eventos, sobrecargas, entre muchas otras cosas.
   Al estar todas estas herramientas bajo el .NET FrameWork existe una gran compatibilidad entre lenguajes, es decir, se puede utilizar librerías de C# perfectamente en VB.NET con solo llamar la referencia.
   Existe un CLS (Common Language Specifications) que se encarga de mantener una cierta compatibilidad entre los lenguajes. Aunque no es tan perfecto, Ej. C#.NET es KeySe... bueno, diferencia las mayúsculas de las minúsculas, en cambio VB.NET no, al llamar a una librería C#, que tenga dos métodos con el mismo nombre pero uno en Mayúscula y otro en minúscula (Es muy difícil que en un caso practico se dé, pero eso no justifica el que se de) VB.NET intentara sobre cargar este método, a pesar que para C# son dos métodos completamente distintos, es más, en el menú que se despliega cuando se presiona Ctrl+Space ese método solo se muestra una vez, y cuando es seleccionado lanza un error "Overload resolution failed".
   Otra ventaja de VB.NET es que no este amarrado al sistema operativo, es más, ni siquiera a la plataforma, este último pues existe un FrameWork especialmente hecho para ejecutar Smart Device Aplications (Pocket PC, Windows CE, y otros). Además .NET FrameWork no deja de lado la compatibilidad con otras tecnologías como lo es COM.
Con .NET FrameWork se termino el Infierno de los DLLs (DLL-Hell) ya que entran en juego los assemblys, cuya definición envuelve muchas cosas,  pero una sencilla y muy especifica seria que es un PE (Portable Ejecutable), con Metadata, y un archivo manifiesto que lo auto describen, bueno vienen siendo los DLLs o ejecutables creados con el .NET FrameWork, en el caso de los DLLs ya no es necesario registrarlos como en COM, hay dos formas de utilizar estos assemblys: privados o públicos, los privados seria tenerlos en el dominio de cada aplicación,  y los públicos serian globales, como por ejemplo el FCL (FrameWork Class Library).
   Además, no se debe dejar de lado que VB.NET al igual que todas las herramientas que trabajan con el FrameWork, están bajo un ambiente administrado, es decir, que el FrameWork provee el Garbage Collector, que es el que se encarga de administrar la memoria en tiempo de ejecución.

Dirán que todo lo anterior no tiene casi nada que ver con VB.NET específicamente, esto es, pues el .NET FrameWork envuelve todos los puntos de interés. Ejemplo de ello es que no se puede hablar de ADO.NET o ASP.NET para Visual Basic.NET, tendría que hablar de ADO.NET o ASP.NET para las herramientas de desarrollo .NET sin importar cual sea. Por eso si se sabe programar en C#.NET (por ejemplo) o viceversa no se te haría tan complicado aprender VB.NET.


Nota: Se aceptan criticas con respecto al presente documento!!