Migración de tecnología ASP 3.0 con componentes ActiveX a Asp.Net
Fecha: 16/Nov/2005 (2005/11/14)
|
Introducción
Objetivo
El objetivo del presente es en primer lugar analizar las actuales opciones disponibles para realizar una migración satisfactoria entre las tecnologías ASP 3 con componentes ActiveX desarrollados en Visual Basic 6.0 y la tecnología ASP.Net (Framework 1.1). En segundo lugar, se propone encontrar cuáles de estas opciones son las que tendrán mayor adaptación a cada proyecto en particular. Esto significa que se enfrentará una doble migración de tecnologías, por un lado habrá una migración de páginas ASP 3.0 a su correspondiente sucesor ASP.Net. Por el otro, de componentes hechos con el lenguaje Visual Basic 6.0 a assemblies generados a partir de Visual Basic.Net.
Este documento intenta describir el proceso que Ud. podrá transitar para lograr la migración tecnológica que mencionamos, para lo cual intentamos aproximarlo a los principales problemas con los cuales se podrá encontrar en dicha migración. Tenga en cuenta que este documento no intenta ser una receta para ser aplicada tal cual como se presenta y que es altamente recomendable que cuente con personal capacitado en ambas tecnologías para lograr una transición efectiva.
El presente documento intenta abarcar los principales aspectos a enfrentar en una migración entre las tecnologías descriptas. Sin embargo, deja de lado aquellas cuestiones relacionadas con el diseño y arquitectura que implementa toda aplicación.
Problemas
Los proyectos que contemplan una migración de estas tecnologías, en general, se encuentran con los siguientes tres problemas principales:
Costos
En general, este tipo de proyectos no cuenta con grandes recursos para su realización, debido a que en general es difícil transmitir al cliente los beneficios que podrá obtener a partir de la incorporación de una nueva tecnología y, en caso de lograr la persuasión, no se logra conseguir apoyos significativos. Este contexto lleva a realizar una migración tecnológica con una inversión racional de esfuerzos de codificación y pruebas, a lo cual se suma que los tiempos para realizar esta transición deben ser lo más acotados posible. Estos factores dificultan en gran medida poder realizar las pruebas iniciales necesarias para poder garantizar el éxito del mismo.
Rendimiento
En general se hace difícil poder cuantificar el impacto que los cambios producirán en el rendimiento final de la aplicación y asegurar que el mismo sea satisfactorio. Además se hace difícil poder identificar los niveles de rendimiento esperados para cada una de las opciones de migración que se pueden presentar.
Conocimiento
Para poder llevar a cabo una transición satisfactoria entre ambas tecnologías es necesario poder crear un proyecto de migración que considere no generar grandes distancias cognitivas entre la vieja aplicación y la nueva. Esto se debe a que en general el equipo de desarrollo de la vieja aplicación será el mismo equipo de desarrollo que estará involucrado en el proyecto de migración y en su posterior mantenimiento. Sin embargo, como se describe en ésta introducción, deberá considerar tener entre el equipo de desarrollo involucrado en el proyecto a personal altamente capacitado en la nueva tecnología.
Posibles soluciones
Entre las posibles soluciones para este tipo de proyectos se encuentran las dos opciones principales típicas: 1) no hacer nada y/o dejarlo para más adelante y 2) afrontar el proyecto y realizarlo. El presente documento intenta ayudarlo para el caso que Ud. haya tomado la decisión de afrontar el proyecto y realizarlo. En la elaboración del mismo se contemplan los tres factores de problemas detectados y qué medidas y opciones se pueden implementar para poder minimizarlos.
Componentes ActiveX en ASP.NET
Objetivo
El objetivo de esta sección es analizar las opciones disponibles para hallar la mejor forma de lograr que componentes ActiveX desarrollados con tecnología Visual Basic 6.0 interactúen de manera satisfactoria con tecnología ASP.Net.
Problemas
Desarrollaremos en este apartado el impacto que tendrá lograr la integración tecnológica entre componentes ActiveX y ASP.Net, sin considerar el esfuerzo de una migración de la librería Microsoft ActiveX Data Object, en la cual se contienen tres objetos principales utilizados en la mayoría de las aplicaciones: Connection, Recordset y Command. Sobre el impacto de dicha librería volveremos más adelante.
Costos
Los costos que se deberán enfrentar para lograr un correcto funcionamiento entre componentes desarrollados en Visual Basic 6.0 y páginas ASP.Net dependerán en gran medida del nivel de re codificación que se desee emplear y la cantidad de pruebas que se esté dispuesto a realizar. Dentro de las soluciones más extremas para este punto existen opciones de no re codificación y opciones de re codificación total. Para cada una de ellas intentaremos mostrar los costos que se deberán afrontar para su implementación.
Rendimiento
De los componentes desarrollados con tecnología Visual Basic 6.0 se puede decir que la mayoría podrá funcionar en ASP.NET, aunque este funcionamiento repercutirá negativamente en el rendimiento de la aplicación debido a que dichos componentes funcionan en un modo de procesamiento STA (Single-Threaded Apartment), contrariamente al modo en que funcionan las páginas en ASP.Net por defecto (MTA: Multi-Threaded Apartment). Este modo de subdividir los procesos es el factor que repercute negativamente en el rendimiento debido a que para poder utilizar componentes STA desde las páginas ASP.Net es necesario especificar que las mismas deben operar bajo este modo de procesamiento, dejando de lado las opciones de rendimiento existentes en el modo MTA.
Conocimiento
Aquí intentaremos lograr la integración de dichos componentes con páginas ASP.Net sin necesidad de que quien realice estos cambios tenga un conocimiento detallado de la arquitectura ASP.Net. Sin embargo, se debe contemplar la participación en este sentido de personal que cumpla con el rol de diseñador de la aplicación.
Posibles soluciones
Dentro de las posibles soluciones existentes se encuentran tres opciones:
Mantener los componentes ActiveX en el estado actual
Esta opción es la que requiere menor esfuerzo de codificación, debido a que los únicos cambios a considerar son los cambios que presente el lenguaje Visual Basic para su codificación en las páginas ASP.Net descritos en el Anexo I. Para esta opción el modo de instanciación de los componentes se realizará en tiempo de ejecución, de la misma manera que se hacía con las tecnologías ASP 3.0. Para ejemplificarlo, esto significa que la instanciación deberá hacerse de la siguiente forma:
miObjeto = Server.CreateObject(“MiProyecto.MiClase”)
En este caso se debe afrontar las consecuencias producidas en el rendimiento debido a que este tipo de instanciación producirá que el modelo de procesamiento de la página sea STA, para lo cual se deberá agregar el atributo AspCompat=”true” en la directiva @Page de la página ASP.NET.
Enmascarar los componentes ActiveX actuales
Esta opción representa un punto intermedio en el esfuerzo requerido de re codificación para la cual deberán realizarse tres pasos principales:
1. Primeramente se deberá crear un componente que actúe de intermediario entre ASP.NET y el componente Visual Basic 6.0, lo cual se puede realizar de forma automática con el aplicativo tlbImp.exe proporcionado por Microsoft para tal efecto, con lo cual este punto se puede desestimar debido a su alto nivel de automatización.
2. Como segundo paso se debe crear un proyecto ASP.Net y agregar las referencias correspondientes a los componentes intermediarios descriptos en el punto anterior o, en su defecto, agregar las referencias a los componentes desarrollados en Visual Basic 6.0 directamente, para lo cual Visual Sudio.Net creará de forma automática el componente intermediario para su funcionamiento con tecnología ASP.Net.
3. Por último se deberá cambiar el modo de instanciación de los componentes a tiempo de diseño. Para ejemplificarlo, esto significa que la instanciación deberá hacerse de la siguiente forma:
Dim miObjeto As New MiProyecto.MiClase
Al pasar a un modo de instanciación en tiempo de diseño se logra una mejora en el rendimiento debido a que las ligaduras se hacen en forma temprana con el assembly intermediario logrando así que el modo de procesamiento de la página sea MTA.
Nota: Para aquel lector que cuenta con experiencia en Visual Basic 6, el modo de instanciación anterior no tiene repercusión negativa en el rendimiento de la aplicación, como sí la tenía para la versión 6.
Migrar los componentes ActiveX a tecnología .NET
Esta opción representa el punto máximo de esfuerzo de codificación. Aquí se debe enfrentar el elevado costo de codificación para pasar del lenguaje Visual Basic 6.0 al lenguaje Visual Basic.Net y el elevado riesgo inherente a un cambio de esta categoría. En esta opción se debe contemplar la creación de un proyecto ASP.Net y dependiendo de las características del proyecto uno o varios proyectos VB.Net.
Sin embargo, en la actualidad existen herramientas que automatizan en un alto grado la migración de este tipo de componentes. En Visual Studio.Net se incluye en su instalación normal un componente que cumple con este propósito de una manera muy eficiente y hace que la migración completa de estos componentes de Visual Basic 6.0 a Visual Basic.Net se logre rápidamente. Para acceder a este componente de migración debe abrir Visual Studio.Net y dirigirse a la opción de menú Archivo / Abrir / Convertir…. Allí encontrará la opción de migración propuesta por ArtInSoft (http://www.artinsoft.com). En este sentido es necesario considerar los cambios producidos en el lenguaje Visual Basic para poder mitigar algunas de las instrucciones que quedan sin migrar debido a que no es posible detectar todas las opciones posibles. Esto se ve claramente en algunas instrucciones realizadas en Visual Basic 6.0 donde, por ejemplo, se utilizan las instrucciones goto “etiqueta” , lo cual ya no es compatible en Visual Basic.Net, no siendo así para las instrucciones on error goto “etiqueta”, que sigue siendo compatible con Visual Basic.Net.
Migración de páginas ASP 3 a ASP.NET
Objetivo
En este apartado se intenta aproximar una solución a la problemática de cada aplicación en particular. Para poder abordar esta problemática distinguimos dos modelos de codificación distintos: uno orientado a la codificación tradicional, al cual denominaremos Modelo ASP tradicional, que se realiza en las páginas con tecnología ASP 3, y uno más innovador, como lo es el modelo de codificación de páginas con tecnología ASP.Net, llamado Modelo ASP.Net. Para distinguir las principales diferencias entre el primero y el segundo, detallamos a continuación sus principales características:
Modelo ASP tradicional:
- Se distingue este modelo de codificación por tener la mayor parte del código programático dispuesto entre los operadores <%...%>.
- No contemplan la implementación de visibilidad de elementos HTML del lado del servidor.
- El modelo de páginas no contempla la implementación de eventos provocados en el servidor.
- Se tiende a mezclar la codificación programática de la página con los elementos HTML de la misma.
Modelo ASP.Net:
- Se distingue este modelo de codificación por tener la mayor parte del código programático dispuesto entre los bloques <script runat=”server”>…</script>. O, en su defecto, porque su código programático se localiza en clases superiores de las cuales la página hereda.
- Contemplan la implementación de visibilidad de elementos HTML del lado del servidor.
- El modelo de páginas contempla la implementación de eventos provocados en el servidor.
- Se tiende a tener una fuerte división entre la codificación programática de la página y los elementos HTML de la misma.
Identificados los dos modelos de codificación que se pueden dar normalmente entre ambas tecnologías, el objetivo de este apartado es determinar el modelo de codificación, ya sea en forma pura o intermedia, que se puede aplicar dentro de las páginas ASP.Net considerando los esfuerzos y conocimientos requeridos para la implementación de dicho modelo.
Problemas
El principal inconveniente en este sentido es el de poder identificar qué modelos de codificación se pueden implementar para poder realizar la migración y cuáles son sus variantes. Este tema trae consigo una serie de cuestiones inherentes al cambio de paradigmas de codificación, los cuales son tratados con mayor detalle en la sección “Desafíos a resolver”.
Costos
Para lograr una efectiva migración de páginas ASP 3 a páginas ASP.Net se pueden enfrentar distintos niveles de esfuerzos en la codificación y pruebas a realizar. Afortunadamente en este sentido existen herramientas de terceros que nos pueden ayudar en la migración de código en estas tecnologías, con lo cual esta tarea pude pasar a transformarse en una revisión de los resultados del proceso automatizado de migración. Un componente altamente recomendado es la que provee ArtInSoft para la migración de páginas ASP 3 a páginas ASP.Net (http://www.artinsoft.com/ne_home.aspx - ASP to ASP.NET Migration Assistant 1.0). Sin embargo, esta automatización no comprende una migración entre los mismos modelos de codificación, esto es, si la aplicación actual está en un Modelo ASP tradicional, la aplicación resultante del proceso estará codificada bajo el mismo modelo. Además se deberá considerar aquellas incompatibilidades entre las distintas versiones de VB Script, Visual Basic 6 y Visual Basic.Net.
Rendimiento
Las páginas ASP.Net presentan dos modos de procesamiento: STA y MTA, descriptos anteriormente. La decisión de implementar uno de estos dos modos restringe las opciones de migración a elegir, debido a que si se quiere que el modo de procesamiento de una página sea MTA la instanciación de los Componentes ActiveX debe realizarse en tiempo de diseño. Para lograrlo hay dos posibilidades: generar componentes intermedios o migración completa del Componente ActiveX a assemblies Visual Basic.Net.
Conocimiento
El nivel de conocimiento requerido para realizar de manera efectiva la migración por parte del equipo de desarrollo deberá adecuarse a la realidad de cada proyecto en particular, para lo cual se podrá trazar una suerte de paralelismo entre las características de la aplicación antes de la migración y la aplicación que surja como producto de este proyecto.
Posibles soluciones
Para lograr una efectiva migración de páginas ASP 3 a páginas ASP.Net se identificaron tres opciones que pueden resultar efectivas de acuerdo a las características particulares de cada proyecto. Entre los modelos identificados tenemos la opción que representa el punto menor de esfuerzo, nos referimos al Modelo ASP tradicional, y la opción que representa el punto mayor de esfuerzo, nos referimos al Modelo ASP.Net.
Modelo ASP tradicional
Esta opción representa el punto mínimo de esfuerzos y conocimientos a aplicar para la tarea de migración. Básicamente esta compuesto por 3 tareas principales:
- Se renombran todas las extensiones de las páginas ASP 3.0 (.asp) a ASP.NET (.aspx), con lo cual logramos que la interpretación de la página la pase a hacer la ISAPI de ASP.Net destinada a cumplir con este propósito (ASPNet_isapi.dll).
- Se incluye en todas las páginas ASP.Net la directiva <%@Page Language=”vb” AspCompat=”true” ...%>. La directiva Option Explicit tiene el valor verdadero por defecto, para lo cual deberá considerar este punto para las páginas ASP 3 que no tengan dicha directiva. La declaración obligatoria de variables es una práctica aconsejada dentro del desarrollo profesional de aplicaciones y se aconseja mitigar este punto utilizando la opción por defecto. Sin embargo, para aquellos casos en los que no se puede lograr, se puede declarar Option Explicit en falso en la directiva page, como se describe a continuación:
<%@Page Language=”vb” AspCompat=”true” Explicit=”false” ...%>
- Se aplican todos los cambios descriptos en el Anexo 1.
Modelo ASP tradicional con MTA
Esta opción requiere mayor esfuerzo y conocimiento que el Modelo ASP tradicional y representa un mejor rendimiento de procesamiento. Esta opción esta compuesta por 6 pasos principales:
- IDEM Paso 1, Modelo ASP tradicional.
- IDEM Paso 2, Modelo ASP tradicional, salvo que en la directiva @Page no se incluye el atributo AspCompat:
<%@Page Language=”vb” ...%>
- IDEM Paso 3, Modelo ASP tradicional.
- Se crea un proyecto ASP.Net que contenga todas las páginas ASP.Net que se renombraron.
- Se agregan las referencias a los Componentes ActiveX desde Visual Studio.Net, el cual creará de forma automática el componente intermediario para cada uno de los Componentes ActiveX.
- Se reemplazan las instrucciones del tipo:
objeto = Server.CreateObject (“PROYECTO .CLASE”)
por la instrucción:
objeto = New PROYECTO.CLASE
De este modo se logra una instanciación en tiempo de diseño, lo cual tiene mejor rendimiento que una instanciación tardía o en tiempo de ejecución.
Cabe aclarar que el Modelo ASP tradicional con MTA logra que el procesamiento de la página sea MTA debido a que las instanciaciones se hacen en tiempo de diseño. En esta opción no hay que perder de vista que los componentes intermediarios creados para poder lograr la integración entre ASP.Net y componentes ActiveX se comunican con estos últimos en modo STA, lo que produce una suerte de “cuello de botella” en los llamados que se realicen a dichos componentes intermediarios.
Modelo ASP.Net
Este modelo requiere un cambio sustancial en el esfuerzo y conocimiento que se deben aplicar. En este modelo se debe considerar, además de los pasos dispuestos en el Modelo ASP tradicional con MTA, que todo el código dispuesto entre los operadores <%...%> debe disponerse entre los bloques <script runat=”server”>…</script> o, en su defecto, en clases superiores de las cuales cada página hereda su identidad, estado y comportamiento. Además se deberá codificar en base a los eventos disparados por la clase System.Web.UI.Page, los cuales son: Page_Init, Page_Load, Page_PreRender, Page_Unload y en base a los eventos particulares enviados desde cada elemento con visibilidad en el servidor.
En este punto, generalmente, de debe considerar la re codificación casi total de la capa de presentación y posiblemente la comunicación de esta capa con la capa de servicios y/o negocios.
El nivel de cambios a implementar en este punto es muy grande y para considerarlos a todos deberá plantearse como un proyecto de re ingeniería, si se quiere enfocada al diseño, de la aplicación a migrar.
Desafíos a resolver
A lo largo de este documento fuimos dejando algunos puntos sin resolver para simplificar la interpretación del mismo y poder enfocarnos en lo central de cada punto. Ahora llegó el momento de revisar estos puntos que quedaron sin definición y analizar qué impactos tendrán.
Migración de ADO a ADO.Net
Este punto es uno de los factores centrales en la mayoría de los proyectos que incluyan una migración de estas tecnologías. Esto sucede debido a que, en general, la aplicación no cuenta con el nivel apropiado de acoplamiento para realizar la instanciación de los objetos contenidos en la librería ActiveX Data Object. Este aspecto puede hacer que esta librería sea conocida en todos los niveles de la aplicación.
Además de los esfuerzos que implicará la migración de esta librería se debe considerar que esta tarea traerá consigo un impacto positivo en el rendimiento final de la aplicación. Esto se debe a que se elimina el “cuello de botella” que mencionamos anteriormente para la resolución de los llamados que se produzcan desde el modo MTA al modo STA, como funciona esta librería.
Para facilitar la comprensión de las tareas que implicaría una migración de esta librería a su sucesor (ADO.Net), analizaremos los tres objetos principales de esta librería: Connection, Recordset y Command. Para el caso de necesitar realizar esta migración de librerías, es altamente recomendable que se intente utilizar, analizar y probar el Bloque de Aplicación de Acceso a Datos propuesto por Microsoft.
El objeto Connection
Dependiendo de las características de diseño de cada proyecto en particular, el reemplazo de este objeto puede ser relativamente sencillo o sumamente tedioso. En este sentido puede suceder:
- Que el acceso a los datos esté contenido dentro de una única clase que provee de acceso a los datos a todas las demás y las abstrae de los detalles de implementación para realizar la conexión. De esta forma los cambios a realizar quedan restringidos a cambios en esta librería. Aquí el cambio puede realizarse rápidamente si, solo si, se puede realizar el cambio rápidamente en los objetos Recordset y Command.
- Que la conexión para realizar el acceso a datos sea conocida por todas las clases Visual Basic 6 y páginas ASP 3. En este caso se deberá analizar la posibilidad de diseñar una clase que provea del acceso a datos a todas las demás, de modo de poder abstraer los detalles de implementación de la misma. Aquí el cambio podrá ser más paulatino debido a los esfuerzos que se deben enfrentar para re codificar cada segmento de código que haga referencia al objeto Connection.
El objeto Recordset
Como se describe en el artículo publicado por Microsoft “Diseño de componentes de niveles y traspaso de los datos a través de éstos”, el formato de los datos que se transfieren a través de los distintos niveles de la aplicación puede variar para cada aplicación en particular. Para las aplicaciones desarrolladas con Visual Basic 6 y ASP 3 es común encontrar que el formato de estos datos se corresponda con el de los objetos Recordset provistos por la librería Microsoft ActiveX Data Object. Así, este objeto puede llegar a ser conocido por todas las capas del proyecto, lo cual involucra un cambio sustancial en el mismo.
El objeto Recordset tiene dos sucesores principales: DataSet y DataReader. Estos proveen mecanismos desconectados y conectados hacia el origen de datos. La decisión de cuál de estos objetos reemplazará al objeto Recordset en general será cercana a la decisión previa que se tomó en su momento para hacer que el objeto Recordset trabaje en modo desconectado o conectado. Para ayudar a esta decisión imagine dos escenarios bien distintos: el primero donde se debe capturar un conjunto delimitado de datos de un origen de datos para mostrar en una grilla. El segundo, donde se debe acceder a un conjunto de datos no delimitado que puede involucrar una cantidad de registros significativos para un proceso de cálculo tipo batch. Estos dos escenarios son candidatos a implementar objetos desconectados y conectados respectivamente. La decisión del reemplazo de este tipo de objetos por su correspondiente sucesor en la nueva versión de ADO.Net es crucial para el alto impacto en los costos de codificación y altos beneficios en el rendimiento
El objeto Command
Este objeto se utiliza para representar procedimientos almacenados o instrucciones de Transact-SQL que posteriormente se ejecutarán contra un motor gestor de base de datos como MS SQL Server. Dependiendo de las características particulares de cada aplicación, la migración de este objeto a alguno de sus sucesores (SQLCommand, OleDbCommand, OdbcCommand o OracleCommand) puede ser relativamente sencilla, debido a que es normal encapsular a este objeto dentro de una clase que se encargue de administrar su funcionamiento. Para el caso en que este objeto se conozca en toda la aplicación, el reemplazo del mismo representará un esfuerzo circunstancial.
Flexibilidad y calidad pretendida
La dificultad que implica decidir y evaluar cuál de estas opciones es la que más se ajusta a la realidad del proyecto radica en identificar el factor de flexibilidad y calidad esperada del producto del proyecto. Esto es, qué nivel de flexibilidad y calidad se espera obtener de la aplicación cuando el proyecto termine y cuál será el nivel de implementación del paradigma orientado a objetos que se requerirá. Para poder analizar este punto tenemos dos cuestiones principales que atender para llegar a una conclusión certera: la primera es que la migración que estamos describiendo puede involucrar también un cambio de paradigma en la programación, esto es, se cambia de un paradigma orientado a eventos (en los Componentes ActiveX) a uno orientado a objetos en los niveles de aplicación ASP.Net y sus clases Visual Basic.Net. Esto tiene sus repercusiones en todo el diseño de la aplicación y replantea los conceptos de relación entre clases y reutilización de código. El segundo es cuán lejos se espera quedar de la implementación del primer punto debido a que en este documento se describen caminos de fácil transición para los cuales podemos afirmar que se ha realizado la migración entre estas tecnologías. Sin embargo el camino a recorrer para implementar un modelo orientado a objetos puede ser muy significativo. Dicho de otra manera, el camino a transitar se acortó en el sentido de que la nueva plataforma soporta un paradigma orientado a objetos. Pero el nivel de esfuerzo a aplicar para transitar efectivamente el cambio desde un paradigma orientado a eventos a un paradigma orientado a objetos, en lo que refiere a capacitación del equipo y a costos por codificación, sigue siendo importante.
Cuantificar el rendimiento
Como se señala en la introducción del presente, es necesario poder cuantificar las mejoras en el rendimiento final de la aplicación. Para ello existen herramientas que nos permiten poder cuantificar este rendimiento de una forma sencilla y eficiente. Una de esta herramientas es la proporcionada por Microsoft para el Stress de aplicaciones web denominada "Web Application Stress Tool" (Ver referencias). Esta herramienta implementa una suerte de grabación de toda la navegación que se produce en Internet Explorer. Luego se realizan las pruebas de stress correspondientes que informarán entre otros datos: los hits totales realizados en cada página, el tiempo promedio de recepción del primer byte de cada página, el tiempo promedio de recepción del ultimo byte de cada página, los tipos y cantidad de errores producidos durante el stress y el promedio de peticiones por segundo.
Ambientes mixtos
Puede darse el caso de que necesite trabajar en ambientes mixtos, esto es ambientes con tecnología ASP 3 y teconología ASP.Net. Aquí el principal problema que se presenta es que los objetos intrínsecos de estas tecnologías (Response, Request, Application, Server y Session) son diferentes, o sea, son objetos de diferentes clases. Esto significa que el estado, por ejemplo del objeto Session de ASP 3 no es el mismo del objeto HttpSessionState de ASP.Net.
Para solucionar este punto en particular podemos contar con diferentes soluciones, entre las cuales se alla la propuesta que hace Peter Bromberg en su artículo "Transfer Session Variables from Classic ASP to ASP.NET", que es verdaderamente práctica y sencilla.Referencias
Cambios en el lenguaje Visual Basic.
http://msdn.microsoft.com/library/SPA/vbcn7/html/vaconDifferencesBetweenVB6AndVB7.asp?frame=trueResumen de cambios de los elementos de programación ofrecidos.
http://msdn.microsoft.com/library/SPA/vbcn7/html/vaconProgrammingElementsChangesInVB7.asp?frame=trueCompatibilidad del componente COM.
http://msdn.microsoft.com/library/SPA/cpguide/html/cpconcomcomponentcompatibility.asp?frame=trueDiseño de componentes de niveles y traspaso de los datos a través de éstos.
http://www.microsoft.com/spanish/msdn/articulos/archivo/221102/voices/BOAGag.aspData Access Application Block
http://msdn.microsoft.com/library/en-us/dnpag2/html/daab.asp?frame=trueAsistente para la migración de páginas ASP 3 a páginas ASP.Net
http://www.asp.net/migrationassistants/asp2aspnet.aspx?tabindex=0&tabid=1Web Application Stress Tool
http://www.microsoft.com/downloads/details.aspx?FamilyID=E2C0585A-062A-439E-A67D-75A89AA36495&displaylang=enTransfer Session Variables from Classic ASP to ASP.NET
http://www.eggheadcafe.com/articles/20021207.asp
ANEXO 1 – Resumen de cambios en el lenguaje Visual Basic
Objetivo
El objetivo de esta sección es detectar los cambios más relevantes que se han realizado entre la versión Visual Basic 6.0 y VB Script para con su nueva versión Visual Basic .NET, la cual contempla a ambos lenguajes. Para una descripción más detallada de los cambios producidos en el lenguaje puede consultar la sección de referencias al final de este documento.
Principales cambios
A continuación se describen los principales cambios que se detectaron entre los lenguajes VB Script (ASP 3.0), Visual Basic 6 y su sucesor VB.Net (ASP.Net). Para una mejor comprensión de los mismos se ha dispuesto la lista en dos áreas: VB Script – VB 6 a VB.Net y ASP 3 a ASP.Net.
VB Script – VB 6 a VB.Net
- Se debe colocar paréntesis alrededor de la lista de parámetros en todas las llamadas a métodos.
- Las instrucciones Set y Let ya no se admiten.
- La mayoría de los objetos ya no tienen propiedades por defecto.
- Se deben convertir explícitamente todos los tipos de datos, especialmente en las llamadas a los componentes ActiveX.
- Al concatenar cadenas, el operador & siempre debe encontrarse entre espacios en blanco.
- Todas las instrucciones If deben construirse en varias líneas, para lo cual las codificaciones con la forma:
if … then… [else][…][end if]
deben ser reemplazadas por la forma:
If … then
…
[else]
[…]
end if
- Option Explicit está activada de manera predeterminada.
- Las funciones Date y Time han sido reemplazadas por Today y TimeOfDay respectivamente.
- La instrucción Date que anteriormente identificaba una función, ahora representa un tipo de dato.
- Las funciones Date$ y Time$ han sido reemplazadas por DateString y TimeString.
- Las funciones Now y Timer fueron reemplazadas por propiedades de solo lectura con el mismo nombre.
- La instrucción Array, que anteriormente identificaba una función, ahora representa un tipo de dato, para lo cual todas las instrucciones con la forma:
MiArray = Array(1,2,3,4)
deben ser reemplazadas por la forma:
Dim MiArray() = {1,2,3,4}
- Las declaraciones de matrices dinámicas deben especificar la cantidad de dimensiones a utilizar, por ejemplo:
Dim MiMatriz(,) as Integer 'Matriz de 2 dimensiones
- La instrucción Goto Etiqueta ya no es soportada en el lenguaje Visual Basic. En cambio la instrucción On Error Goto Etiqueta si.
- Las instrucción IsNull ha sido reemplazada por IsDBNull
ASP 3 a ASP.Net
- A todas las páginas ASP 3 se les deberá agregar la directiva: <%@Page ...%>
- Los objetos de Session y Application no son compartidos entre páginas ASP 3.0 y ASP.NET.
- El código descrito entre los operadores <%...%> solo es visible para los bloques de código que se hallan entre estos operadores, por lo cual una variable declarada entre los operadores <%...%> no será accesible desde el código contenido entre los bloques <script runat=”server”>…</script>.
- Las funciones (function nombre() … end function) codificadas entre los operadores <%...%> son incompatibles con el modelo de objetos, por lo cual se deberán disponer entre los bloques <script runat=”server”>…</script>.
- La propiedad ExpiresAbsolute del objeto HttpResponse es del tipo Date, por lo cual no acepta valores indistintos de Date. Se debera reemplazar las instrucciones del tipo:
Response.ExpiresAbsolute = 0
por:
Response.ExpiresAbsolute = Now.AddYears(-1) 'Un año menos
