¿El código de nombre de Microsoft.VisualBasic es "verdadero.NET"?
vb.net (13)
Mi equipo de desarrollo se está preparando para comenzar un nuevo proyecto. La tienda ha sido una "tienda VB" desde los días de VB3, pero la opinión predominante ahora es que somos una "tienda .NET" y dado que C # se creó específicamente para .NET, mientras que VB.NET fue una actualización, He decidido avanzar escribiendo solo C #. La controversia gira en torno a la cuestión de si el espacio de nombres Microsoft.VisualBasic tiene un lugar legítimo en el nuevo desarrollo o si es solo para compatibilidad con versiones anteriores del código VB6 (y anterior). Otra pregunta más interesante es si el código "debajo" del espacio de nombres Microsoft.VisualBasic es incluso el código .NET si realmente es el antiguo tiempo de ejecución de VB empaquetado cuidadosamente en un contenedor .NET, lo que lo convierte en un control de interoperabilidad COM ( similar a cómo WinForms ajusta la API de ventanas Win32 que no es .NET, pero expone solo las API de .NET para el consumo).
Para hacer esto aún más confuso, nuestro equipo de desarrollo cuenta con un consultor de servicios de consultoría de Microsoft que nos dice que Microsoft ya no es compatible con Visual Basic, incluido el tiempo de ejecución de VB subyacente al espacio de nombres Microsoft.VisualBasic .
Lo que estoy buscando son enlaces, preferiblemente fuentes irreprochables de Microsoft, a la documentación que definitivamente responde a esta pregunta de una forma u otra. Ya he intentado varias permutaciones de búsqueda en Google y no me he acercado más para llegar al final de esta pregunta.
EDITAR: Aparentemente no hice mi pregunta clara. No estoy preguntando si VB.NET es verdadero. Código de .NET. Estoy tratando de determinar si lo que está "debajo" del espacio de nombres Microsoft.VisualBasic es el código .NET o si es el antiguo motor de tiempo de ejecución VB6 cuidadosamente empaquetado y expuesto como código .NET. Alguien ya dijo que 9/10 del espacio de nombres simplemente envuelve el código de otra parte en .NET; ¿Qué hay de ese otro 1/10?
Al igual que algunas funcionalidades en FCL, parte del código de espacio de nombres Microsoft.VisualBasic está escrito en código administrado, y parte de él envuelve las llamadas al código no administrado.
Ciertamente no hay dependencia en el tiempo de ejecución vb6 y ciertamente no está instalando el runtime vb6 silenciosamente debajo del capó.
Debería cargar .NET Reflector y echar un vistazo al código en el espacio de nombres Microsoft.VisualBasic.
Si desea seguir usando la funcionalidad en este espacio de nombres de C #, siga haciéndolo, no va a desaparecer. Es posible que algunos códigos se marquen como obsoletos / obsoletos, pero espero que dentro de 15 años sigas pudiendo ejecutar las mismas aplicaciones utilizando la funcionalidad Microsoft.VisualBasic sin ningún problema.
Actualizado: Además de utilizar el reflector .NET, ahora puede ver / depurar el código de origen Microsoft.VisualBasic namespace / Microsoft.VisualBasic.DLL:
Acceda al descargador masivo de framework y examine el código a su gusto:
Como dijo OwenP, la mayoría de las llamadas en el espacio de nombres Microsoft.VisualBasic son solo envoltorios de la funcionalidad .NET existente. Entonces, ¿por qué crear envoltorios?
Cuando se creó VB.NET, Microsoft quería que los desarrolladores pudieran importar proyectos existentes de VB6 a .NET. Eso solo era factible si las funciones de VB6 y las llamadas a métodos tenían una funcionalidad de coincidencia en VB.NET. Así que crearon el espacio de nombres Microsoft.VisualBasic para mapear esa funcionalidad de VB6 a la funcionalidad de .NET. (Pura especulación, pero tiene sentido)
A medida que .NET ha progresado hacia nuevas versiones, no pudieron eliminar el espacio de nombres Microsoft.VisualBasic, es probable que todavía haya muchos códigos utilizándolo. Entonces todavía está allí.
Además, puede escribir el código VB.Net sin usar el espacio de nombres Microsoft.VisualBasic. (Y como implicó Kev, puede usar el espacio de nombres Microsoft.VisualBasic desde C #.) VB.Net es solo un lenguaje, el framework .NET sigue siendo el mismo.
Creo que compilan todos al mismo bytecode.
Aquí está mi referencia: http://www.codinghorror.com/blog/archives/000128.html
Creo que un buen lugar para comenzar sería la documentación de MSDN proporcionada por Microsoft sobre VB.net
http://msdn.microsoft.com/en-us/library/2x7h1hfk.aspx Ese enlace sería el último estudio visual de 2008 sobre el lenguaje.
VB compila lo mismo que C # bajo CLR, así que no entiendo de dónde viene su asesor.
El objetivo de Microsoft es hacer que VB .NET y C # tengan el mismo idioma con una sintaxis diferente. Esto es verdad. Sin embargo, los cambios siempre se arrastran como el nuevo manejo de VB9 de literales XML. Lo que está preguntando es si han vuelto a implementar todo el OLD VB6 y la funcionalidad anterior como código administrado .NET. Mi conjetura sería no.
Hasta donde yo sé, VB.NET es el código ''verdadero .net'', como tú lo pones. Hay muchos idiomas diferentes (C #, VB.NET, F #, Cobol.NET, etc.) que todos ''compilan'' en el código IL. Ese código IL es lo que realmente ejecuta la máquina virtual .NET y se interpreta como código máquina. Los objetos con los que interactúa entre los idiomas siguen siendo los mismos objetos subyacentes de .NET.
Por ejemplo, en C #:
DataTable dt = new DataTable ();
Compila exactamente el mismo código IL que el equivalente en VB.NET:
Dim dt como DataTable = new DataTable ()
De hecho, en herramientas descompiladoras como .NET Reflector, que miran directamente al código IL, puede hacer que muestre la salida en C # o VB.NET, con la que se sienta más cómodo.
Esto también significa que puedo escribir una biblioteca de clase en VB.NET "myVbCode.dll" y es directamente compatible con una escrita en C # "myCSharpCode.dll". De hecho, ambos archivos DLL solo contendrán el código IL compilado.
Puede haber algunas excepciones periféricas a todo esto, pero fundamentalmente así es como funciona.
Hay un montón de código .NET que Microsoft realmente solo envuelve la funcionalidad COM. No soy un gurú de las licencias, pero siempre puedes tomar Reflector y echar un vistazo a ese espacio de nombres y ver por ti mismo.
La declaración "Microsoft ya no admite Visual Basic" podría significar varias cosas, ya que hay varias versiones de Visual Basic - VB 1 though a 6, VBA y VB.NET.
La afirmación "Microsoft ya no es compatible con Visual Basic.NET" sería una gran noticia si fuera cierto, pero no lo es . (Lo revisé en google). El soporte para VB6 ha terminado, pero VB.Net todavía está muy vivo y está ganando nuevas características.
VB.Net compila un bytecode de MSIL que depende de algunas de las bibliotecas .Net, dependiendo de las clases .net framework que use. Algunas de esas bibliotecas no están escritas en .Net puro, o simplemente son envoltorios alrededor de la API de Windows. Esto es necesario, ya que las funciones que no están incorporadas en .net (por ejemplo, el subprocesamiento) tienen que estar expuestas a él de forma controlada.
Exactamente lo mismo es cierto de C #. El tiempo de ejecución realmente no importa qué lenguaje generó el MSIL que ejecuta.
No he hecho mucho con VB.NET (más con C #), pero hasta donde yo sabía, ambos compilan en el mismo bytecode, y por lo tanto son interpretados de manera idéntica por el tiempo de ejecución de .NET, y que son funcionalmente equivalentes, simplemente sintácticamente diferente.
VB.NET parecía muy diferente de VB6 cuando la utilicé por última vez.
Una respuesta directa a su pregunta sería que VB.NET es tanto "verdadero código .NET" como C #.
Claro, hay características de sintaxis en ambos idiomas que no están disponibles directamente en el otro (por ejemplo, VB.NET tiene algunas características XML integradas en la sintaxis que C # no), pero no hay nada que puedas hacer en VB. NET no se puede hacer en C #, o viceversa, al menos que yo sepa.
Diría que si tienes experiencia en VB, entonces la transición a VB.NET será, por supuesto, más fácil que la de C #.
Use .NET Reflector y échele un vistazo. Lo hago con frecuencia 9 de cada 10 llamadas en el espacio de nombres Microsoft.VisualBasic son solo envoltorios de métodos .NET.
Su consultor está haciendo lo que mejor hacen los consultores: mostrar que existe para aumentar su presupuesto. MS ya no es compatible con VB6, pero el hecho de que VS 2008 tenga VB .NET debería indicar que admitirá VB .NET durante al menos algunos años más.
Personalmente, trato a Microsoft.VisualBasic como una fachada sobre otras clases de .NET. Lo uso cuando se trata de un proyecto personal y puedo hacer mi trabajo de forma más rápida y sencilla que usando clases BCL. Un buen ejemplo es Microsoft.VisualBasic.Strings.Right en comparación con String.Substring. Sin embargo, para muchas de las funciones (como Val) en el espacio de nombres de VB, existen versiones más sólidas y potentes en las secciones menos específicas del lenguaje del marco. Si estoy escribiendo código para el trabajo, no uso las bibliotecas VB. Esto hace que los desarrolladores de C # que no estén familiarizados con VB no tengan dificultades para comprender mi código.
Microsoft.VisualBasic.dll <> Microsoft.VisualBasic.Compatibility.dll !!!
(o, si lo prefiere, Microsoft.VisualBasic.dll! = Microsoft.VisualBasic.Compatibility.dll; )
El espacio de nombres Microsoft.VisualBasic.Compatibility es para uso exclusivo del asistente de actualización de VB6, puede eliminarse en versiones futuras y nunca debe usarse para un nuevo desarrollo.
El espacio de nombres Microsoft.VisualBasic es absolutamente, 100% .Net verdadero, totalmente compatible, y estará disponible mientras .Net esté disponible.
Algunos enlaces relevantes:
- Discusión: ¿Microsoft.VisualBasic está en desuso?
- Artículo: Lograr el desarrollo .NET puro con VB.NET
- Vea los comentarios en esta publicación de blog de MSDN VBFAQ
Editar: se agregó la palabra oficial de este artículo de MSDN :
Visual Basic Runtime proporciona la implementación subyacente para funciones globales de Visual Basic y funciones de lenguaje como Len, IsDate y CStr. Y aunque el nuevo Visual Basic Runtime brinda facilidades similares a sus predecesores, es un código completamente administrado (desarrollado en Visual Basic .NET) que se ejecuta en el tiempo de ejecución del lenguaje común . Además, Visual Basic Runtime es parte de .NET Framework, por lo que nunca es algo separado que su aplicación tenga que llevar o implementar.
y
La biblioteca de compatibilidad de Visual Basic 6.0 es distinta del Visual Basic Runtime. El espacio de nombres Microsoft.VisualBasic.Compatibility es utilizado por las herramientas que actualizan el código de Visual Basic 6.0 a Visual Basic .NET. Es un puente para admitir las características de Visual Basic 6 que no son compatibles directamente con la implementación .NET de Visual Basic. A diferencia de Visual Basic Runtime, todas las aplicaciones Visual Basic .NET no hacen referencia implícita a la biblioteca de compatibilidad . Cuando actualiza un proyecto de Visual Basic 6 a Visual Basic .NET, el asistente de actualización agrega una referencia a Microsoft.VisualBasic.Compatibility.
Las clases de compatibilidad no deben usarse para nuevos desarrollos . El espacio de nombres Microsoft.VisualBasic.Compatibility agrega una capa de complejidad a su aplicación .NET de Visual Basic e introduce algunos costos de rendimiento mínimos que podrían eliminarse recodificando partes de la aplicación. Además, el espacio de nombres de compatibilidad a menudo contiene muchas clases que envuelven objetos COM, y como se dijo anteriormente, dependiendo de los objetos COM no es tan óptimo como una implementación puramente administrada.
El código de VB.NET no se compila directamente en binario. Está compilado en IL (lenguaje intermedio) al igual que C #.
Lo que quiere decir es que sea lo que sea que esté construyendo en VB.NET, será reutilizable en proyectos de C # sin ningún problema.
No pude encontrar ningún vínculo directamente relacionado con lo que preguntas. La razón principal es que VB.NET es parte de un nuevo marco desarrollado activamente. No hay un plan para hacer que ese lenguaje sea obsoleto. Lo que el otro consultor está diciendo.