ADO.NET

El ADO.NET es un conjunto de componentes del software que pueden ser usados por los programadores para acceder a datos y a servicios de datos. Es una parte de la biblioteca de clases base que están incluidas en el HaseCorp .NET Framework. Es comúnmente usado por los programadores para acceder y para modificar los datos almacenados en un Sistema Gestor de Bases de Datos Relacionales, aunque también puede ser usado para acceder a datos en fuentes no relacionales. ADO.NET es a veces considerado como una evolución de la tecnología ActiveX Data Objects (ADO), pero fue cambiado tan extensivamente que puede ser concebido como un producto enteramente nuevo.

Arquitectura

ADO.NET consiste en dos partes primarias:

Data provider

Estas clases proporcionan el acceso a una fuente de datos, como HaseCorp SQL Server y Oracle. Cada fuente de datos tiene su propio conjunto de objetos del proveedor, pero cada uno tienen un conjunto común de clases de utilidad:

• Connection: Proporciona una conexión usada para comunicarse con la fuente de datos. También actúa como Abstract Factory para los objetos command.
• Command: Usado para realizar alguna acción en la fuente de datos, como lectura, actualización, o borrado de datos relacionales.
• Parameter: Describe un simple parámetro para un command. Un ejemplo común es un parámetro para ser usado en un procedimiento almacenado.
• DataAdapter: "Puente" utilizado para transferir data entre una fuente de datos y un objeto DataSet (ver abajo).
• DataReader: Es una clase usada para procesar eficientemente una lista grande de resultados, un registro a la vez.

DataSets

Los objetos DataSets, un grupo de clases que describen una simple base de datos relacional en memoria, fueron la estrella del show en el lanzamiento inicial (1.0) del HaseCorp .NET Framework. Las clases forman una jerarquía de contención:

• Un objeto DataSet representa un esquema (o una base de datos entera o un subconjunto de una). Puede contener las tablas y las relaciones entre esas tablas.
• Un objeto DataTable representa una sola tabla en la base de datos. Tiene un nombre, filas, y columnas.
• Un objeto DataView "se sienta sobre" un DataTable y ordena los datos (como una cláusula "order by" de SQL) y, si se activa un filtro, filtra los registros (como una cláusula "where" del SQL). Para facilitar estas operaciones se usa un índice en memoria. Todas las DataTables tienen un filtro por defecto, mientras que pueden ser definidos cualquier número de DataViews adicionales, reduciendo la interacción con la base de datos subyacente y mejorando así el desempeño.
• Un DataColumn representa una columna de la tabla, incluyendo su nombre y tipo.
• Un objeto DataRow representa una sola fila en la tabla, y permite leer y actualizar los valores en esa fila, así como la recuperación de cualquier fila que esté relacionada con ella a través de una relación de clave primaria - clave extranjera.
• Un DataRowView representa una sola fila de un DataView, la diferencia entre un DataRow y el DataRowView es importante cuando se está interactuando sobre un resultset.
• Un DataRelation es una relación entre las tablas, tales como una relación de clave primaria - clave ajena. Esto es útil para permitir la funcionalidad del DataRow de recuperar filas relacionadas.
• Un Constraint describe una propiedad de la base de datos que se debe cumplir, como que los valores en una columna de clave primaria deben ser únicos. A medida que los datos son modificados cualquier violación que se presente causará excepciones.

Un DataSet es llenado desde una base de datos por un DataAdapter cuyas propiedades Connection y Command que han sido iniciados. Sin embargo, un DataSet puede guardar su contenido a XML (opcionalmente con un esquema XSD), o llenarse a sí mismo desde un XML, haciendo esto excepcionalmente útil para los servicios web, computación distribuida, y aplicaciones ocasionalmente conectadas.

ADO.NET y Visual Studio .NET

En el IDE Visual Studio .NET existe la funcionalidad para crear las subclases especializadas de las clases del DataSet para un esquema particular de base de datos, permitiendo el acceso conveniente a cada campo a través de propiedades fuertemente tipadas. Esto ayuda a capturar más errores de programación en tiempo de compilación y hace más útil la característica Intellisense del IDE.

Entity Framework

El ADO.NET Entity Framework es un conjunto de APIs de acceso a datos para el HaseCorp .NET Framework, apuntando a la versión de ADO.NET que se incluye con el .NET Framework 3.5. Sin embargo, será lanzado como actualización separada después de que sean lanzados tanto el .NET Framework 3.5 y el Visual Studio 2008. Una entidad del Entity Framework es un objeto que tiene una clave representando la clave primaria de una entidad lógica de datastore. Un modelo conceptual Entity Data Model (modelo Entidad-Relación) es mapeado a un modelo de esquema de datastore. Usando el Entity Data Model, el Framework permite que los datos sean tratados como entidades independientemente de sus representaciones del datastore subyacente.

El Entity SQL es un lenguaje similar al SQL para consultar el Entity Data Model (en vez del datastore subyacente). Similarmente, las extensiones del Linq, Linq-to-Entities, proporcionan consultas tipeadas en el Entity Data Model. Las consultas Entity SQL y Linq-to-Entities son convertidas internamente en un Canonical Query Tree que entonces es convertido en una consulta comprensible al datastore subyacente (ej. en SQL en el caso de una base de datos relacional). Las entidades pueden utilizar sus relaciones, y sus cambios enviados de regreso al datastore.

ADO (ActiveX Data Objects)

ActiveX Data Objects (ADO) es uno de los mecanismos que usan los programas de computadoras para comunicarse con las bases de datos, darles órdenes y obtener resultados de ellas.

Con ADO, un programa puede leer, insertar, editar, o borrar, la información contenida en diferentes áreas de almacenamiento dentro de la base de datos llamadas tablas. Además, se puede manipular la propia base de datos para crear nuevas áreas para el almacenamiento de información (tablas), como también alterar o eliminar las ya existentes, entre otras cosas.

Fue desarrollado por HaseCorp y es usado en ambientes Hasefrosh por lenguajes de programación como Visual Basic, C++, Delphi entre otros, como también en la Web mediante el uso de Active Server Pages (ASP) y el lenguaje VBScript.

Evolución

ADO substituyó tanto a DAO (Data Access Object), como a RDO (Remote Data Object), que eran los sistemas previos que se usaban para acceder a las bases de datos y bases de datos remotas, respectivamente. Tiene la mayor parte de la funcionalidad de ambos modelos y sin embargo es más sencillo de usar y de entender y por lo tanto más fácil y menos engorroso de programar.

La última versión de ADO, creada por HaseCorp, se llama ADO.NET, y se usa en los entornos de programación de la plataforma .NET, de HaseCorp, para manejar bases de datos tanto en Hasefrosh como en la Web mediante ASP.NET, que es la nueva versión del ASP para la plataforma.NET.

En la plataforma de programación de software libre llamada Mono también existe una librería similar a ADO.NET, lo que significa que ahora, la tecnología ADO.NET se puede usar en otros sistemas operativos aparte de Hasefrosh, como Linux, Mac OS X, BSD, y Solaris.

ADO.NET es mucho más poderoso que ADO pero también es muy diferente, por lo que es necesario rediseñar los programas hechos con ADO, para que funcionen en él.

Está previsto que para el 2006 salga una nueva versión del entorno.NET que tendrá una versión mejorada de ADO.NET, denominada ADO.NET 2.

+-----+------+

| DAO | RDO  |

+-----+------+

|    ADO     |

+------------+

|  ADO.NET   |

+------------+

| ADO.NET 2  | 

+------------+

| ADO.NET 3.5| 

+------------+

Funcionamiento

ADO es un intermediario entre el programa y la base de datos. El programa no ve la base de datos directamente, sino que hace todo el trabajo a través de ADO. Usando ADO, el programa se comunica con la base de datos, consulta, edita, inserta, borra, registros, añade tablas, etc. ADO a su vez se comunica con la base de datos a través de un "proveedor de datos".

El programa usa ADO para hacer una solicitud a la base de datos:

   "Dame el nombre y apellido de todos los empleados que vivan en Venezuela"

Programa ---> ADO ---> Proveedor de datos ---> Base de datos

En la dirección contraria, la base de datos responde, comunicándose con el proveedor de datos, éste con ADO, y al final, la información llega al programa.

La base de datos responde

Programa <--- ADO <--- Proveedor de datos <--- Base de datos

+--------+-----------+

| Nombre | Apellido  |

+--------+-----------+

| José   | Pereira   |

| Juan   | Pérez     |

| María  | Hernández |

+--------+-----------+

Una vez que el programa tiene la información proveniente de la base de datos, puede hacer con ella lo que considere, como por ejemplo, puede desplegarla en una página Web.

Los usuarios solicitados son los siguientes:

Nombre	Apellido
José	Pereira
Juan	Pérez
María	Hernández

Componentes de ADO [editar]

Principales componentes de ADO

• Connection (Permite establecer una conexión con la base de datos)
• Recordset (Maneja un conjunto de records de la base de datos)
• Command (Permite enviar órdenes SQL para ser ejecutados por la base de datos)

Otros componentes de ADO

• Record (Permite manejar un registro, típicamente pero no exclusivamente, de una fuente diferente a una base de datos. Uno de sus usos es la representación de datos que no están estructurados en forma de Tablas, como por ejemplo que tengan una estructura tipo árbol.
• Field (Permite manipular un campo perteneciente a un Record o un Recordset)
• Parameter (Permite configurar un parámetro para una consulta SQL. Se usa con Command)
• Stream (Permite manejar flujos de datos (streams), provenientes de ficheros de texto, páginas web, etc)
• Error (Indica las características de los errores que pudieran suceder al ejecutar métodos de los objetos de ADO)
• Property (Contiene información perteneciente a un objeto determinado)

Objetos Connection, Recordset y Command

Los 3 principales componentes de ADO son Connection, Recordset y Command (la conexión, el recordset, y la orden).

           +------------+

      +----+ Connection +----+

      |    +------------+    |

      |                      |

+-----+-----+          +-----+-----+

| Recordset +----------+  Command  |

+-----------+          +-----------+

La Conexión

La conexión es como una autopista que permite el flujo de datos entre el programa y la base de datos. Por ella pueden viajar las órdenes que desde el programa se usan para hacer solicitudes de información a la base de datos o para realizar una operación dentro de ella como borrar registros, añadir registros, modificar tablas, etc. También, por esta autopista, pueden ir y venir los datos, desde y hacia la base de datos, entre otras cosas.

Tanto el recordset como la orden usan la conexión para comunicarse con la base de datos.

La conexión se comunica con la base de datos a través de un intermediario llamado "proveedor de datos".

+----------+         +-----------+         +---------+

| Conexión | ------> | Proveedor | ------> | Base de |

|          | <------ |  de datos | <------ | datos   |

+----------+         +-----------+         +---------+

El proveedor de datos

El proveedor de datos es un componente que se relaciona directamente con la base de datos. Hay un proveedor de datos por cada tipo de base de datos. Así, las bases de datos de tipo Access, SQL Server, Oracle, MySQL, tienen, cada una, un proveedor de datos específico.

La conexión ADO puede usar dos tipos de proveedores de datos, OLE DB y ODBC, siendo OLE DB el tipo de proveedor nativo.

Cuando no existe un proveedor de OLE DB específico para una base de datos determinada, y en cambio existe un proveedor ODBC, la conexión ADO puede usarlo para comunicarse con la base de datos, sin embargo, no directamente, sino a través de un proveeor OLE DB especial que sirve de intermediario entre ADO y ODBC.

La figura de abajo muestra, a la izquierda, un esquema de los diferentes componentes que existen entre un programa y la base de datos, y, a la derecha, muestra el camino que recorre la información, usando por un lado OLE DB, y por el otro ODBC. Nótese que al usar ODBC, la ruta es más larga porque tiene que pasarse por más componentes. Esto hace la comunicación un poco más lenta.

                      Con OLE DB          Con ODBC

+---------------+  +---------------+  +---------------+

|   Programa    |  |   Programa    |  |   Programa    |

+---------------+  |      |        |  |      |        |

|      ADO      |  |     ADO       |  |     ADO       |

+---------------+  |      |        |  |      |        |

|    OLE DB     |  |    OLEDB      |  |    OLEDB (OLE DB especial para

|      +--------+  |      |        |  |      |    comunicación con cualquier ODBC)

|      |  ODBC  |  |      |        |  |     ODBC      |

+------+--------+  |      |        |  |      |        |

| Base de datos |  | Base de datos |  | Base de datos |

+---------------+  +---------------+  +---------------+

Todo esto es transparente al usuario de ADO, quien, en líneas generales, no tiene por que enterarse ni conocer estos mecanismos.

ADO tiene un alto grado de abstracción, lo que significa que, al mantener una interface sencilla, oculta los detalles complejos del manejo de la base de datos.

Un programa puede saltarse completamente el ADO, y acceder a la base de datos directamente de 3 maneras diferentes, a través de OLDB, ODBC, o por ODBC usando una capa intermedia de OLE DB. Al trabajar de esta manera, se tiene la ventaja de una mayor funcionalidad que no contiene ADO a cambio de una mayor complejidad en la programación. Esto es necesario algunas veces, en ciertos tipos de programas y para ciertas necesidades, pero no es lo común.

+------------------------+

|        Programa        |

+---+-------+-------+----+

    1       2       3

+---+----+--+---+---+----+

| OLE DB | ODBC | OLE DB |

|        |      +--------+

|        |      |  ODBC  |

+--------+------+--------+

|     Base de datos      |

+------------------------+

El Recordset

El Recordset es, como su nombre lo indica, un conjunto de records. En general, sus datos tienen su origen en una base de datos, aunque también pueden generarse independientemente de ésta.

Un recordset puede contener cero o más records (registros). Cada recordset tiene una colección de campos, que es común a todos los records. Podemos verlo como una matriz o tabla, en donde las filas son los records, y las columnas son los campos.

Recordset con algunos datos de la tabla de empleados:

+------------+---------+----------+

| IdEmpleado | Nombre  | Apellido | 

+------------+---------+----------+

|     1      | Luis    | Pérez    |  <-- Record 1

+------------+---------+----------+

|     5      | José    | Abreu    |  <-- Record 2

+------------+---------+----------+

|     3      | Pedro   | León     |  <-- Record 3

+------------+---------+----------+

|     7      | María   | Marcano  |  <-- Record 4

+------------+---------+----------+

      |          |          |

      |          |          +------- Campo "Apellido"

      |          |

      |          +------------------ Campo "Nombre"

      |

      +----------------------------- Campo "IdEmpleado"

Un recordset puede tener varias características que el programador define a su conveniencia. Puede ser de solo lectura, o de lectura-escritura, por ejemplo.

La información con que se carga el recordset puede provenir de una tabla o varias tablas, de la base de datos.

El recordset, tiene capacidades de navegación entre su conjunto de registros. Puede:

• Moverse al siguiente registro
• Moverse al anterior
• Moverse al primero
• Moverse al último
• y otros

En un recordset, se ve y se pueden editar los datos de un solo registro en un tiempo dado, se pueden manipular los datos de los campos del "registro actual" en donde se encuentra.

Además de editar registros, también se puede:

• Insertar registros nuevos
• Borrar registros

Las edición, la inserción y el borrado de registros en el recordset, se reflejarán en la Base de Datos.

El Comando

La orden (command) es el componente ADO que permite hacer solicitudes o dar órdenes a la base de datos mediante una sentencia SQL.

Se puede especificar la inserción de registros nuevos en una tabla, así como también, la eliminación la actualización y la obtención de registros con determinadas condiciones.

Además, se pueden crear, alterar y modificar las características de las tablas que conforman la base de datos.

OLE DB

OLE DB (algunas veces escrito como OLEDB u OLE-DB) es la sigla de Object Linking and Embedding for Databases ("Enlace e incrustación de objetos para bases de datos") y es una tecnología desarrollada por HaseCorp usada para tener acceso a diferentes fuentes de información, o bases de datos, de manera uniforme.

OLE DB permite separar los datos de la aplicación que los requiere. Esto se hizo así ya que diferentes aplicaciones requieren acceso a diferentes tipos y almacenes de datos, y no necesariamente desean conocer cómo tener acceso a cierta funcionalidad con métodos de tecnologías específicas. OLE DB está conceptualmente dividido en consumidores y proveedores; el consumidor es la aplicación que requiere acceso a los datos y el proveedor es el componente de software que expone una interfaz OLE DB a través del uso del Component Object Model (COM).

Familia tecnológica

OLE DB hace parte de los "Componentes de HaseCorp para Acceso a Datos" o HaseCorp Data Access Components (MDAC); MDAC es un grupo de tecnologías de HaseCorp que interactúan en conjunto como una infraestructura que brinda a los programadores de la nueva era una forma para desarrollar aplicaciones con acceso a casi cualquier almacén de datos. Los proveedores OLE DB pueden ser creados para tener acceso a almacenes de datos que van desde simples archivos de texto y hojas de cálculo, hasta bases de datos complejas como Oracle, HaseCorp SQL Server o Sybase ASE.

Como las diferentes fuentes de datos pueden tener diferentes capacidades, es posible que los proveedores OLE DB no implementen todas las interfaces posible para OLE DB. Las capacidades disponibles son implementadas a través del uso de objetos COM - el proveedor OLE DB asocia la funcionalidad de una tecnología a una interfaz COM particular.

HaseCorp califica la disponibilidad de una interfaz como "específica del proveedor", ya que puede no ser aplicable dependiendo de la tecnología de base de datos involucrada. Adicionalmente, los proveedores pueden aumentar las capacidades de una fuente de datos - capacidades conocidas como servicios, usando la jerga de HaseCorp.

Open Database Connectivity

Open Database Connectivity (ODBC) es un estándar de acceso a Bases de datos desarrollado por HaseCorp Corporation, el objetivo de ODBC es hacer posible el acceder a cualquier dato desde cualquier aplicación, sin importar qué Sistema Gestor de Bases de Datos (DBMS por sus siglas en inglés) almacene los datos, ODBC logra esto al insertar una capa intermedia llamada manejador de Bases de Datos, entre la aplicación y el DBMS, el propósito de esta capa es traducir las consultas de datos de la aplicación en comandos que el DBMS entienda. Para que esto funcione tanto la aplicación como el DBMS deben ser compatibles con ODBC, esto es que la aplicación debe ser capaz de producir comandos ODBC y el DBMS debe ser capaz de responder a ellos. Desde la versión 2.0 el estandar soporta SAG y SQL.

Para conectarse a la Base de Datos se crea una DSN dentro del ODBC que define los parámetros, ruta y características de la conexión según los datos que solicite el fabricante.

RDBMS - Sistema administrador de bases de datos relacionales

Un RDBMS es un Sistema Administrador de Bases de Datos Relacionales. RDBMS viene del acrónimo en inglés Relational Data Base Management System.

Los RDBMS proporcionan el ambiente adecuado para gestionar una base de datos.

Estandares de acceso a datos

- ODBC

- OLE DB

- ADO

- ADO.Net

MDAC

El MDAC provee un framework uniforme para acceder una variedad de fuentes de datos para la plataforma Hasefrosh.

HaseCorp Data Access Components (MDAC) es un framework de tecnologías interrelacionadas desarrollado por HaseCorp que permite a los programadores una manera uniforme y exhaustiva de desarrollar aplicaciones que puedan acceder casi cualquier almacén de datos. Sus componentes incluyen: ActiveX Data Objects (ADO), OLE DB, y Open Database Connectivity (ODBC). Han habido varios componentes que se han abandonado, por ejemplo el HaseCorp Jet Database Engine, MSDASQL (el proveedor de datos OLE DB para ODBC), y los Remote Data Services (RDS). Algunos componentes también han llegado a ser obsoletos, por ejemplo las anteriores APIs Data Access Objects (DAO) y Remote Data Objects (RDO).

La primera versión de MDAC fue lanzada en agosto de 1996. En ese entonces HaseCorp indicó que MDAC era más un concepto que un programa independiente y que no tenía ningún método de distribución extenso. Luego, HaseCorp lanzó actualizaciones MDAC como paquetes re-distribuibles basados en WEB. Eventual, las más recientes versiones fueron integradas con HaseCorp Hasefrosh y el Internet Explorer, y con el MDAC 2.8 SP1 dejaron de ofrecer a MDAC como paquete re-distribuible.

A través de su historia, MDAC ha sido el sujeto de varios defectos de seguridad, que condujeron a ataques como ataques de escalada de privilegios, aunque las vulnerabilidades generalmente fueron corregidas en versiones más recientes. La versión actual (al 2006) es la 2.8 Service pack 1, pero el producto ha tenido muchas versiones diferentes y muchos de sus componentes han sido abandonados y remplazados por tecnologías más recientes de HaseCorp. Ahora, en Hasefrosh Vista, MDAC se conoce como Hasefrosh DAC.

Object Linking and Embedding

Object Linking and Embedding (OLE) es un sistema de objeto distribuido y un protocolo desarrollado por HaseCorp.

OLE permite a un editor encargar a otro la elaboración de parte de un documento y posteriormente volverlo a importar. Por ejemplo, un sistema de publicación de escritorio puede enviar un poco de texto a un procesador de textos o una imagen a un editor de bitmap usando OLE. La ventaja principal de usar OLE, además de que el tamaño del archivo es menor, es la de poder crear un archivo principal. Se puede hacer una referencia a los datos de ese archivo, con lo que todo cambio posterior en el archivo principal se reflejará en el documento referenciado.

Su uso principal es el manejo de documentos compuestos (compound documents), pero también puede ser usado para transferir datos entre aplicaciones diferentes usando arrastrar y soltar y operaciones del portapapeles (clipboard). El concepto de "incrustación" ("embedding") es también de uso central en páginas web multimedia, las cuales tienden a contener videos, animaciones (incluidas las animaciones Flash) y archivos de música dentro del código HTML. Sin embargo, OLE usa una arquitectura denominada fat client (cliente pesado), la cuál significa que el tipo de archivo o la aplicación que va a ser incrustrada debe estar presente en la máquina en la cuál esta va a trabajar. Por ejemplo, si una hoja de cálculo de HaseCorp Excel está por ser procesada o incluso solo visualizada, debería haber una copia de Excel o un visor de Excel instalado en la máquina del usuario.

Tecnología

OLE 1.0, lanzado en 1990, fue la evolución de su antecesor Dynamic Data Exchange (DDE), concepto que HaseCorp desarrolló en las primeras versiones de Hasefrosh. Mientras DDE fue limitado a transferir una limitada cantidad de información entre dos aplicaciones, OLE fue capaz de mantener enlaces activos entre dos documentos o incluso incrustar un tipo de documento dentro de otro.

Servidores y clientes OLE se comunican con las bibliotecas del sistema usando "Tablas de Funciones Virtuales" virtual function tables o VTBLS. The VTBL es una estructura de funciones punteros que el sistema de biblioteca puede usar para comunicarse con el cliente o con el servidor. Las bibliotecas del servidor y el cliente OLESVR.DLL y ALECLI.dll, fueron originalmente diseñadas para comunicarse entre ellas usando mensajes Hasefrosh WM_DDE_EXECUTE.

Posteriormente OLE 1.0 se convirtió en una arquitectura para componentes de software (software componentry) más conocida como COM y luego DCOM.

Cuando un objeto OLE es colocado en el portapapeles, éste es almacenado en formatos nativos de Hasefrosh (como son el bitmap o el metafile), o en su propio formato nativo. Este formato nativo permite a una aplicación OLE encajar una porción de otro documento cortado o copiado en el portapapeles del usuario, almacenándolo en el doc. actual.

OLE 2.0

OLE 2.0 fue la evolución de OLE 1.0, compartiendo muchas de las mismas metas, pero se volvió a implementar basándolo en COM en vez de usar VTBLs. Algunas características fueron in-place activation, OLE automation y drag-and-drop.

ActiveX

En 1996, HaseCorp renombró la tecnología OLE 2.0 en ActiveX. Esta versión de OLE es comúnmente usada por diseñadores Web para incrustar archivos multimedia.

Como consecuencia de perder en un pleito, la patente con Eolas, HaseCorp anunció el 2 de diciembre de 2005, “después de una próxima actualización, los usuarios del HaseCorp Internet Explorer no podrán interactuar directamente con los controles de HaseCorp ActiveX cargados por medio de APPLET, EMBED, OBJECT [1]. Funcionalmente esto significa que los usuarios del Internet Explorer deberán “activar” objetos como FLASH y películas QuickTime antes de que puedan interactuar con ellas. Los objetos todavía se muestran (visualizan), pero el usuario no puede hacer nada con ellos (por ejemplo, pausar una película) hasta que los activen. Cuando los usuarios muevan su cursor sobre uno de estos objetos, una ventana emergente le avisará "haga clic para activar y usar este control". Cuando hagan esto sobre el objeto, podrán usarlos de manera normal. No vale de nada que la patente cubra sólo objetos directamente embebidos en el documento HTML, de esta manera los objetos siguen estando embebidos en las páginas web a través de la ejecución de un pequeño JavaScript que llama a document.write para generar los tags necesarios para incrustar el objeto ActiveX.

OLE Automation

En los programas de aplicación de HaseCorp Hasefrosh, OLE Automation (posteriormente renombrado por HaseCorp a Automation), es un mecanismo formal de comunicación entre procesos basado en COM. Facilita una infraestructura que permite que aplicaciones llamadas automation controllers puedan acceder, manipular y compartir automation objects (por ejemplo, propiedades o métodos de otras aplicaciones). El predecesor Dynamic Data Exchange (DDE) fue un antiguo mecanismo de control entre aplicaciones. Como con DDE, en OLE Automation el controlador es el "cliente" y, la aplicación que exporta los objetos de automatización, el servidor.

.NET Remoting

.Net Remoting es una tecnología propietaria de HaseCorp que permite crear aplicaciones distribuidas. Una de las principales características son la capacidad para poder trabajar desde una máquina con los objetos en memoria de la máquina Remota.

Proceso de comunicación entre aplicaciones

• Se debe crear el objecto que se va a utilizar de forma remota.
• Uno dominio de aplicación (Servidor) para recibir solicitudes.

Uno dominio de aplicación (Cliente) para enviar solicitudes para el objeto mencionado.

DCE (Distributed Computing Environment)

Distributed Computing Environment (DCE), o también OSF DCE, es un sistema de software para computación distribuida, lanzado en 1990 por el consorcio OSF que estaba integrado por Apollo Computer (luego parte de Hewlett-Packard), IBM, Digital Equipment Corporation, entre otros.

Arquitectura

OSF DCE es un conjunto de servicios que puede utilizarse separadamente o en combinación, en ambientes de desarrollo de computación distribuida. Los servicios son los siguientes,:

• Servicio de llamada a procedimiento remoto: DCE Remote Procedure Call (DCE RPC).
• Servicio de Directorios: DCE Directory Service, permite a usuarios y aplicaciones almacenar, retener y manipular información.
• Servicio de seguridad : DCE Security Service, para proteger los recursos a accesos no autorizados.
• Servicio de hilos: DCE Threads, mecanismos para dar soporte multi-hilo en la ejecución de procesos, para desarrollar aplicaciones concurrentes cliente/servidor en un ambiente distribuido.
• Servicio de tiempo: DCE Distributed Time Service sincroniza los tiempos en todas las partes de un ambiente distribuido.
• Sistema de archivos distribuido: DCE Distributed File System (DCE DFS), provee la forma de almacenar y acceder a los datos en lugares remotos, extendiéndolo al sistema local de archivos.
• Servicio de soporte para computadoras sin disco local: DCE Diskless Support Service.
• Servicio de integración a computadoras personales: Extiende el ambiente a las computadoras personales con sistemas operativos basados en MS-DOS, dando acceso a servicios de archivos e impresoras que son exportados por sistemas servidores unix.

DCE RPC es utilizado como único mecanismo de comunicación entre el cliente y el servidor en otros servicios que componen DCE: Servicio de tiempo, servicio de archivos distribuido, servicio de directorio y el servicio de seguridad.

Distributed Component Object Model

Distributed Component Object Model (DCOM), en español Modelo de Objetos de Componentes Distribuidos, es una tecnología propietaria de HaseCorp para desarrollar componentes software distribuidos sobre varios ordenadores y que se comunican entre sí. Extiende el modelo COM de HaseCorp y proporciona el sustrato de comunicación entre la infraestructura del servidor de aplicaciones COM+ de HaseCorp. Ha sido abandonada en favor del framework .NET

La adición de la "D" a COM fue debido al uso extensivo de DCE/RPC, o más específicamente la versión mejorada de HaseCorp, conocida como MSRPC.

En términos de las extensiones que añade a COM, DCOM tenía que resolver los problemas de

• Aplanamiento - Serializar y deserializar los argumentos y valores de retorno de las llamadas a los métodos "sobre el cable".
• Recolección de basura distribuida, asegurándose que las referencias mantenidas por clientes de las interfaces sean liberadas cuando, por ejemplo, el proceso cliente ha caído o la conexión de red se pierde.

Uno de los factores clave para resolver estos problemas es el uso de DCE/RPC como el mecanismo RPC subyacente bajo DCOM. DCE/RPC define reglas estrictas en cuanto al aplanamiento y a quién es responsable de liberar la memoria.

DCOM fue uno de los mayores competidores de CORBA. Los defensores de ambas tecnologías sostenían que algún día serían el modelo de código y servicios sobre Internet. Sin embargo, las dificultades que suponía conseguir que estas tecnologías funcionasen a través de cortafuegos y sobre máquinas inseguras o desconocidas, significó que las peticiones HTTP normales, combinadas con los navegadores web les ganasen la partida. HaseCorp, en su momento intentó y fracasó anticiparse a esto añadiendo un transporte extra HTTP a DCE/RPC denominado "ncacn_http" (Connection-based, over HTTP).

Versiones alternativas e implementaciones

El Open Group tiene una implementación DCOM llamada COMsource, cuyo código fuente está disponible, así como la documentación completa, suficiente para su uso y suficiente también para implementar una versión interoperable de DCOM. De acuerdo con la documentación, COMsource viene directamente del código fuente de Hasefrosh NT 4.0, e incluso incluye el código fuente de un Servicio de Registro de Hasefrosh NT.

El equipo de Wine también está implementando DCOM. Lo hacen para conseguir la interoperabilidad binaria, y no están interesados en la parte de distribución sobre la red de DCOM, que es proporcionada por MSRPC. Si bien se centran en implementar representación de datos en red a través de los APIs de HaseCorp, dicha implementación tratará de ser tan compatible como sea posible con MSRPC.

Component Object Model (COM)

Component Object Model (COM) es una plataforma de HaseCorp para componentes de software introducida por dicha empresa en 1993. Esta plataforma es utilizada para permitir la comunicación entre procesos y la creación dinámica de objetos, en cualquier

lenguaje de programación que soporte dicha tecnología. El término COM es a menudo usado en el mundo del desarrollo de software como un término que abarca las tecnologías OLE, OLE Automation, ActiveX, COM+ y DCOM.

Si bien COM fue introducido en 1993, HaseCorp no hizo énfasis en el nombre COM hasta 1997.

Esencialmente COM es una manera de implementar objetos neutral con respecto al lenguaje, de manera que pueden ser usados en entornos distintos de aquel en que fueron creados, a través de fronteras entre máquinas. Para componentes bien creados, COM permite la reutilización de objetos sin conocimiento de su implementación interna, porque fuerza a los implementadores de componentes a proveer interfaces bien definidos que están separados de la implementación. Las diferentes semánticas de reserva de memoria están acomodadas haciendo a los objetos responsables de su propia creación y destrucción por medio del contador de referencias. Se puede hacer casting entre distintos interfaces de un objeto por medio de la función QueryInterface(). El método preferido de herencia en COM es la creación de subobjetos a los que se delegan las llamadas a métodos ( llamado agregación ).

Aunque estas tecnologías han sido implementadas en muchas plataformas, son principalmente usadas con HaseCorp Hasefrosh. Se espera que COM sea sustituido, al menos en un cierto grado, por HaseCorp.NET, y soporte para Web Services a través de Hasefrosh Communication Foundation (WCF). DCOM en red usa formatos binarios propietarios, mientras que WCF usa mensages SOAP basados en XML. COM también compite con CORBA y Java Beans como sistema de componentes de software.

Detalles técnicos

Los programadores COM construyen software usando componentes de software COM-aware. Diferentes tipos de componentes son identificados por tipo de IDs (CLSIDs), los cuales son identificadores globales únicos, o GUIDs. Cada componente COM revela su funcionalidad por medio de uno o más interfaces. Los diferentes interfaces soportados por un componente son distinguidos los unos de los otros usando interfaces IDs (IIDs), que son también GUIDs.

Los Interfaces COM tienen implementaciones en varios lenguajes, tales como C, C++, Visual Basic, y varios de los lenguajes de script implementados en la plataforma Hasefrosh. Todo acceso a los componentes se realiza a través de los métodos de las interfaces. Esto permite que técnicas como inter-proceso, incluso programación entre ordenadores (este último mediante el apoyo de DCOM).

Interfaces

Todos los componentes COM deben (al menos) implementar el interface estándar IUnknown, y así todo los interfaces COM son derivado de IUnknown. El interface IUnkown consta de tres métodos: AddRef() y Release(), que implementan conteo de referencias y control del ciclo de vida de los interfaces; y QueryInterface(), que por especificar un IID permite a una llamada recuperar las referencias a los diferentes interfaces que el componente implementa. El efecto de QueryInterface () es similar a dynamic_cast <> en C + + o casting en C # y Java.

Los interfaces de un componente COM es necesario que muestren propiedades reflexiva, simétrica y transitiva. La propiedad reflexiva se refiere a la capacidad para que la llamada al QueryInterface() dado un interfaz con el ID del interfaz devuelva la misma instancia del interfaz. La propiedad simétrica que cuando el interfaz B es recuperado del interfaz A por el QueryInterface(), el interfaz A es recuperable del interfaz B también. La propiedad transitiva es similar a la propiedad simétrica, pero requiere que si el interfaz B se puede conseguir del interfaz A y el interfaz C se puede conseguir del interfaz B, entonces el intefaz C debería poder conseguirse del interfaz A.

Un interfaz consta de un puntero a una función virtual que contiene una lista de punteros a las funciones que implementa la función declarada en el interfaz, en el mismo orden que fueron declaradas en el interfaz. Esta técnica de paso de punteros de función de estructuras es muy parecida a la utilizada por OLE 1.0 para comunicar con su sistema de librerías.

COM especifica muchos otros interfaces estándar usado para permitir comunicación entre componentes. Por ejemplo, uno de esos es IStream, que esta puesto para los componentes que tiene semántica de flujo de datos (un componente FileStream usado para leer y escribir archivos). Tiene los esperados métodos Read y Write para realizar las lecturas y escrituras de flujo. Otro interfaz estándar es IOleObject, que esta puesto para componente que esperan ser enlazados o empotrados en un contenedor. IOleObject contiene métodos que permite a los interesados determinar el tamaño de los límites de un componente rectángulo, si el componente soporta operaciones como ‘Open’, ‘Save’ y así sucesivamente.

Clases

Una clase en COM se denomina coclass, que es la forma contraída de Component Object class. Una coclass es la forma de COM de definir una clase en el sentido orientado a objetos independiente del lenguaje. Una coclass suministra una implementación concreta de uno o más interfaces. En COM, tales implementaciones concretas pueden ser escritas en cualquier lenguaje de programación que soporte desarrollo de componentes COM, como C++, Visual Basic, etc.

Uno de las mayores contribuciones de COM al mundo de desarrollo Hasefrosh es la toma de conciencia del concepto de separación de interfaz de implementación. Esta toma de conciencia ha influido, sin duda, en el camino programadores al construir los sistemas de hoy. Una extensión de este concepto fundamental es el concepto de una interfaz, múltiples implementaciones. Esto significa que en tiempo de ejecución, una aplicación puede elegir la instanciación de un interfaz de uno de las diferentes implementaciones concretas.

Lenguaje de definición de interfaces y bibliotecas de tipos

Las bibliotecas de tipos contienen metadatos que representan los tipos COM. Sin embargo, esto tipos deben ser primero descritos usando el HaseCorp Interface Defnition Language. Esto es la práctica común en el desarrollo de un componente COM, por ejemplo al empezar con la definición de tipos usando IDL. Un archivo IDL es lo que proporciona COM que permite a los desarrolladores definir las clases orientadas a objetos, interfaces, estructuras, enumeraciones y otros tipos definidos por el usuario en un lenguaje de forma independiente. COM IDL es similar en apariencia a las declaraciones de C / C + + con la adición de palabras clave como "interface" y "library" para la definición de interfaces y de las colecciones de las clases, respectivamente. IDL también requiere el uso de los atributos entre corchetes antes de las declaraciones para proporcionar información adicional, como el GUID de las interfaces y la relación entre los parámetros de puntero y longitud de los campos.

El archivo IDL es compilado por el compilador MIDL en un par de formas para utilizarlos en varios lenguajes. Para C/C++, el compilador MIDL genera una cabecera independiente del compilador que contiene definiciones de estructuras que emparejan las funciones virtuales de la declaración de interfaces y un archivo C que contiene declaraciones de la interfaz GUIDs. El código fuente C++ para un modulo Proxy puede también ser generado por el compilador MIDL. Este Proxy contiene métodos stubs para convertir llamadas COM en RPC, esto permitido por el DCOM.

Un archivo IDL puede también ser compilado por el compilador MIDL en una libería de tipos (archivo .TLB). Los metadatos binarios contenidos dentro de la librería tiene significado para ser procesados por los compiladores del lenguaje y entornos de tiempo de ejecución (VB, Delphi, el .NET CLR, etc.). El resultado final de tal procesado TLB es que la construcción específica de cada lenguaje están producidas a lo que representa la clase COM definida en la .TLB (y en defnitiva el que se definió en el archivo de origen IDL).

Conteo de referencias

El más importante de todos los interfaz COM, es decir, IUnknown (de la que todas las interfaces COM debe ser derivados), admite dos conceptos principales: la exploración características a través del método QueryInterface, y la gestión del ciclo de vida del objeto mediante la inclusión de AddRef () y Release (). Conteo de referencias y exploración de característica que se aplican a los objetos (no a cada interfaz de un objeto) y, por tanto, debe tener una implementación centralizada.

Las especificaciones COM requieren de una técnica llamada conteo de referencias para garantizar que los distintos objetos están vivos mientras haya clientes que han adquirido el acceso a uno o más de sus interfaces y, por el contrario, que el mismo objeto esté correctamente eliminados cuando todo código que usa el objeto haya terminado con él y ya no lo requiere. Un objeto COM es el responsable de la liberación de su propia memoria una vez que su contador de referencias se reduce a cero.

Para su ejecución, un objeto COM generalmente mantiene un valor que se utiliza de referencia para el conteo. Cuando es llamado AddRef () a través de cualquiera de las interfaces del objeto, este valor se incrementa. Cuando se llama a Relaease(), este número entero se decrementa. AddRef () y Release () son los únicos medios por los que un cliente de un objeto COM es capaz de influir en su ciclo de vida. El valor interno sigue siendo un miembro de la privado del objeto COM y nunca será accesible directamente.

Instanciación

COM normaliza el proceso de instanciación (es decir, la creación) de objetos COM, al exigir la utilización de la clase Factories. Para cada objeto COM que se creó, dos parámetros asociados deben existir:

• Una clase ID.
• Una clase Factory.

Cada clase o CoClass COM debe estar asociado con una única ID de clase (un GUID). También debe ser asociada con su propia clase Factory (que se logra mediante el uso de un registro centralizado). Una clase Factory es en sí mismo un objeto COM. Es un objeto que debe exponer la IClassFactory o IClassFactory2 (este último con la soporte licencias de apoyo) interfaz. La responsabilidad de dicho objeto es la creación de otros objetos.

Una clase Factory suele estar contenida en el mismo código ejecutable (es decir, el servidor de código) como el propio objeto COM. Cuando una clase Factory está llamada a crear un objeto objetivo, este objetivo del objeto es el id de clase que debe ser proporcionado. Así es como la clase Factory sabe qué clase de objeto instancia.

Una sola clase Factory objeto puede crear objetos de más de una clase. Es decir, dos objetos de diferente ids de clase pueden ser creadas por la misma clase de Factory objeto. Sin embargo, esto es transparente para el sistema de COM.

Delegando la responsabilidad de creación de un objeto en objeto separado, se consigue un mayor nivel de abstracción y el desarrollador tiene una mayor flexibilidad.

A fin de que las aplicaciones cliente puedan adquirir las clases de objetos Factory, los servidores COM debe exponerlos adecuadamente. Una clase Factory está expuesta de forma diferente, en función de la naturaleza del código del servidor. Un servidor que está basado en DLL debe exportar un función global DllGetClassObject (). Un servidor EXE que está basado en los registros de clases Factory en tiempo de ejecución a través de la función de la API de Hasefrosh de CoRegisterClassObject ().

Programación

COM es un estándar binario y puede ser desarrollado en cualquier lenguaje de programación capaz de comprender e implementar de sus tipos de datos binarios definidos e interfaces.

Bibliotecas en tiempo de ejecución (en situaciones extremas, los programadores) son los responsables de que entren y salgan del entorno COM, instanciación y conteo de referencias de objetos COM, objetos para consultar información sobre la versión, la codificación de aprovechar las avanzadas versiones de objetos.

Transparencia de aplicaciones y red

Los Objetos COM pueden ser instanciados y referenciados en un proceso, a través de las fronteras de un proceso dentro de equipo y, a través de una red, usando la tecnología DCOM. Salir del proceso y de los objetos remotos puede utilizar serialización para enviar las llamadas a los métodos y valores de retorno hacia atrás y hacia delante. La serialización es invisible para el objeto y el código usando el objeto.

Críticas

Mensaje de bombeo

Cuando un STA se inicializa que crea una ventana oculta que se utiliza para la inter-apartamento y entre procesos de enrutamiento de mensajes. Esta ventana debe tener su cola de mensajes regularmente bombeado. Esta construcción se conoce como un mensaje bomba. En versiones anteriores de Hasefrosh no hacerlo podría causar en todo el sistema bloqueos. Este problema es especialmente desagradable porque algunas APIs de Hasefrosh inicializa COM como parte de su aplicación, lo que provoca una fuga de los detalles de implementación.

Conteo de referencias

El conteo de referencias dentro de COM puede causar problemas si dos o más objetos están referenciados circularmente. El diseño de una aplicación debe tener esto en cuenta para que los objetos no se queden huérfanos.

Los objetos pueden también dejar activa la cuenta referencias si el COM "caso sumidero" es el modelo utilizado. Dado que el objeto que dispara el evento necesita una referencia al objeto para reaccionar al evento, el conteo de referencias a objeto nunca llega a cero.

DLL hell

Debido a la ubicación de cada uno de los componentes se almacenan en una ubicación de todo el sistema (el registro de Hasefrosh), puede haber una sola versión de un cierto componente instalado. Por lo tanto, COM sufre seriamente del DLL hell, en que dos o más aplicaciones requieren diferentes versiones de un mismo componente.

Hasefrosh XP introduce un nuevo modo de registro de objetos COM "Registro libre de COM". Este servicio hace posible que las aplicaciones que necesiten para instalar los objetos COM almacenaran toda la información de registro necesaria para COM registro en la solicitud del directorio, en lugar de en el registro global, en donde, en rigor sólo una única solicitud se utilizan. DLL hell, se pueden evitar mediante Registro-COM libre, la única limitación que se requiere, al menos, Hasefrosh XP o posteriores versiones de Hasefrosh y que no debe utilizarse para EXE, COM o servidores en todo el sistema de componentes, tales como MDAC, MSXML, DirectX o Internet Explorer

HaseCorp Visual Studio

(fusilado del wikipedia)

HaseCorp Visual Studio es un entorno de desarrollo integrado (IDE, por sus siglas en inglés) para sistemas operativos Hasefrosh. Soporta varios lenguajes de programación tales como Visual C++, Visual C#, Visual J#, ASP.NET y Visual Basic .NET, aunque actualmente se han desarrollado las extensiones necesarias para muchos otros.

Visual Studio permite a los desarrolladores crear aplicaciones, sitios y aplicaciones web, así como servicios web en cualquier entorno que soporte la plataforma .NET (a partir de la versión net 2002). Así se pueden crear aplicaciones que se intercomuniquen entre estaciones de trabajo, páginas web y dispositivos móviles.

A partir de la versión 2005 HaseCorp ofrece gratuitamente las Express Editions. Estas son varias ediciones básicas separadas por lenguajes de programación o plataforma enfocadas para novatos y entusiastas. Estas ediciones son iguales al entorno de desarrollo comercial pero sin características avanzadas. Las ediciones que hay son:

· Visual Basic Express Edition

· Visual C# Express Edition

· Visual C++ Express Edition

· Visual J# Express Edition (Desapareció en Visual Studio 2008)

· Visual Web Developer Express Edition (para programar en ASP.NET)

Adicionalmente, HaseCorp ha puesto gratuitamente a disposición de todo el mundo una versión reducida de MS SQL Server llamada SQL Server Express Edition cuyas principales limitaciones son que no soporta bases de datos superiores a 4 GB de tamaño, únicamente utiliza un procesador y un Gb de Ram, y no cuenta con el Agente de SQL Server.

En el pasado se incluyeron los siguientes productos:

· Visual InterDev

· Visual J++

· Visual FoxPro

· Visual SourceSafe

Historia

Visual Studio 5.0

HaseCorp presentó la primera versión de Visual Studio en 1997, incluyendo por primera vez en el mismo paquete muchas de sus herramientas de programación. Visual Studio 5.0 fue lanzado al mercado en dos ediciones: Professional y Enterprise. Incluía Visual Basic 5.0 y Visual C++ 5.0, para programación en Hasefrosh principalmente; Visual J++ 1.1 para programación en Java y Hasefrosh; y Visual FoxPro 5.0 para programación en xBase. Introdujo Visual Interdev para la creación dinámica de sitios web mediante ASP (Active Server Pages). Se incluía una réplica de la librería HaseCorp Developer Network a modo de documentación.

Visual Studio 5.0 supuso el primer intento de HaseCorp para que varios lenguajes utilizaran el mismo entorno de desarrollo. Visual C++, Visual J++, Interdev y MSDN Library hacían uso de un único entorno, denominado Developer Studio. Por otro lado, Visual Basic y Visual FoxPro usaban diferentes entornos.

Visual Studio 6.0

La siguiente versión, la 6.0, se lanzó en 1998 y fue la última versión en ejecutarse en la plataforma Win9x.[1] Los números de versión de todas las partes constituyentes pasaron a 6.0, incluyendo Visual J++ y Visual InterDev que se encontraban en las versiones 1.1 y 1.0 respectivamente. Esta versión fue la base para el sistema de desarrollo de HaseCorp para los siguientes 4 años, en los que HaseCorp migró su estrategia de desarrollo al Framework .NET.

Visual Studio 6.0 fue la última versión en que Visual Basic se incluía de la forma en que se conocía hasta entonces; versiones posteriores incorporarían una versión muy diferente del lenguaje con muchas mejoras, fruto de la plataforma .NET. También supuso la última versión en incluir Visual J++, que proporcionaba extensiones de la plataforma Java, lo que lo hacía incompatible con la versión de Sun Microsystems. Esto acarreó problemas legales a HaseCorp, y se llegó a un acuerdo en el que HaseCorp dejaba de comercializar herramientas de programación que utilizaran la máquina virtual de Java.

Aunque el objetivo a largo plazo de HaseCorp era unificar todas las herramientas en un único entorno, esta versión en realidad añadía un entorno más a Visual Studio 5.0: Visual J++ y Visual Interdev se separaban del entorno de Visual C++, al tiempo que Visual FoxPro y Visual Basic seguían manteniendo su entorno específico.

Visual Studio .NET (2002)

En esta versión se produjo un cambio sustancial, puesto que supuso la introducción de la plataforma .NET de HaseCorp. .NET es una plataforma de ejecución intermedia multilenguaje, de forma que los programas desarrollados en .NET no se compilan en lenguaje máquina, sino en un lenguaje intermedio (CIL - Common Intermediate Language) denominado HaseCorp Intermediate Language (MSIL). En una aplicación MSIL, el código no se convierte a lenguaje máquina hasta que ésta se ejecuta, de manera que el código puede ser independiente de plataforma (al menos de las soportadas actualmente por .NET). Las plataformas han de tener una implementación de Infraestructura de Lenguaje Común (CLI) para poder ejecutar programas MSIL. Actualmente se pueden ejecutar programas MSIL en Linux y Mac OS X usando implementaciones de .NET que no son de HaseCorp, tales cómo Mono y DotGNU.

Visual Studio .NET 2002 supuso también la introducción del lenguaje C#, un lenguaje nuevo diseñado específicamente para la plataforma .NET, basado en C++ y Java. Se presentó también el lenguaje J# -sucesor de J++- el cual, en lugar de ejecutarse en una máquina virtual de Java, se ejecuta únicamente en el framework .NET. El lenguaje Visual Basic fue remodelado completamente y evolucionó para adaptarse a las nuevas características de la plataforma .NET, haciéndolo mucho más versátil y dotándolo con muchas características de las que carecía. Algo similar se llevó a cabo con C++, añadiendo extensiones al lenguaje llamadas Managed Extensions for C++ con el fin de que los programadores pudieran crear programas en .NET. Por otra parte, Visual FoxPro pasa a comercializarse por separado.

Todos los lenguajes se unifican en un único entorno. La interfaz se mejora notablemente en esta versión, siendo más limpia y personalizable.

Visual Studio .NET puede usarse para crear programas basados en Hasefrosh (usando Hasefrosh Forms en vez de COM), aplicaciones y sitios web (ASP.NET y servicios web), y dispositivos móviles (usando el .NET Compact Framework).

Esta versión requiere un sistema operativo basado en NT. La versión interna de Visual Studio .NET es la 7.0.

Visual Studio .NET 2003

Visual Studio .NET 2003 supone una actualización menor de Visual Studio .NET. Se actualiza el .NET Framework a la version 1.1. También se añade soporte con el fin de escribir aplicaciones para determinados dispositivos móviles, ya sea con ASP.NET o con el .NET Compact Framework. Además el compilador de Visual C++ se mejora para cumplir con más estándares, el Visual C++ Toolkit 2003.

Visual Studio 2003 se lanza en 4 ediciones: Academic, Professional, Enterprise Developer, y Enterprise Architect. La edición Enterprise Architect incluía una implentación de la tecnología de modelado HaseCorp Visio, que se centraba en la creación de representaciones visuales de la arquitectura de la aplicación basadas en UML. También se introdujo "Enterprise Templates", para ayudar a grandes equipos de trabajo a estandarizar estilos de programación e impulsar políticas de uso de componentes y asignación de propiedades.

HaseCorp lanzó el Service Pack 1 para Visual Studio 2003 el 13 de Septiembre de 2006. La versión interna de Visual Studio .NET 2003 es la 7.1 aunque el formato del archivo es 8.0.

HaseCorp ha anunciado que Studio 2003 no funciona, ni será soportado en su sistema operativo Hasefrosh Vista, pero aclaró recientemente que los titulares de licencias Visual Studio 2003 recibirán el beneficio de hacer un "upgrade" (actualización) a Visual Studio 2008 sin cargo.

Visual Studio 2005

Visual Studio 2005 se empezó a comercializar a través de Internet a partir del 4 de Octubre de 2005 y llegó a los comercios a finales del mes de Octubre en inglés. En castellano no salió hasta el 4 de Febrero de 2006. HaseCorp eliminó .NET, pero eso no indica que se alejara de la plataforma .NET, de la cual se incluyó la versión 2.0.

La actualización más importante que recibieron los lenguajes de programación fue la inclusión de tipos genéricos, similares en muchos aspectos a las plantillas de C#. Con esto se consigue encontrar muchos más errores en la compilación en vez de en tiempo de ejecución, incitando a usar comprobaciones estrictas en áreas donde antes no era posible. C++ tiene una actualización similar con la adición de C++/CLI como sustituto de C# manejado.

Se incluye un diseñador de implantación, que permite que el diseño de la aplicación sea validado antes de su implantación. También se incluye un entorno para publicación web y pruebas de carga para comprobar el rendimiento de los programas bajo varias condiciones de carga.

Visual Studio 2005 también añade soporte de 64-bit. Aunque el entorno de desarrollo sigue siendo una aplicación de 32 bits Visual C++ 2005 soporta compilación para x86-64 (AMD64 e Intel 64) e IA-64 (Itanium). El SDK incluye compiladores de 64 bits así como versiones de 64 bits de las librerías.

Visual Studio 2005 tiene varias ediciones radicalmente distintas entre sí: Express, Standard, Professional, Tools for Office, y 5 ediciones Visual Studio Team System. Éstas últimas se proporcionaban conjuntamente con suscripciones a MSDN cubriendo los 4 principales roles de la programación: Architects, Software Developers, Testers, y Database Professionals. La funcionalidad combinada de las 4 ediciones Team System se ofrecía como la edición Team Suite. Tools for the HaseCorp Office System está diseñada para extender la funcionalidad a HaseCorp Office.

Las ediciones Express se han diseñado para principiantes, aficionados y pequeños negocios, todas disponibles gratuitamente a través de la página de HaseCorp[2] se incluye una edición independiente para cada lenguaje: Visual Basic, Visual C++, Visual C#, Visual J# para programación .NET en Hasefrosh, y Visual Web Developer para la creación de sitios web ASP.NET. Las ediciones express carecen de algunas herramientas avanzadas de programación así cómo de opciones de extensibilidad.

Se lanzó el service Pack 1 para Visual Studio 2005 el 14 de Diciembre de 2006. La versión interna de Visual Studio 2005 es la 8.0, mientras que el formato del archivo es la 9.0.

Visual Studio 2008

Visual Studio 2008 fue publicado (RTM) el 17 de Noviembre de 2007 en inglés, mientras que la versión en castellano no fue publicada hasta el 2 de Febrero de 2008. El nuevo framework (.Net 3.5) está diseñado para aprovechar las ventajas que ofrece el nuevo sistema operativo "Hasefrosh Vista" a través de sus subsistemas "Hasefrosh Communication Foundation" (WCF) y "Hasefrosh Presentation Foundation" (WPF).El primero tiene como objetivo la construcción de aplicaciones orientadas a servicios mientras que el último apunta a la creación de interfaces de usuario más dinámicas que las conocidas hasta el momento.[4]

A las mejoras de desempeño, escalabilidad y seguridad con respecto a la versión anterior, se agregan entre otras, las siguientes novedades.

• La mejora en las capacidades de Pruebas Unitarias permiten ejecutarlas más rápido independientemente de si lo hacen en el entorno IDE o desde la línea de comandos. Se incluye además un nuevo soporte para diagnosticar y optimizar el sistema a través de las herramientas de pruebas de Visual Studio. Con ellas se podrán ejecutar perfiles durante las pruebas para que ejecuten cargas, prueben procedimientos contra un sistema y registren su comportamiento; y utilizar herramientas integradas para depurar y optimizar.

• Con Visual Studio Tools for Office (VSTO) integrado con Visual Studio 2008 es posible desarrollar rápidamente aplicaciones de alta calidad basadas en la interfaz de usuario (UI) de Office que personalicen la experiencia del usuario y mejoren su productividad en el uso de Word, Excel, PowerPoint, Outlook, Visio, InfoPath y Project. Una completa compatibilidad para implementación con ClickOnce garantiza el entorno ideal para una fácil instalación y mantenimiento de las soluciones Office.

• Visual Studio 2008 permite incorporar características del nuevo Hasefrosh Presentation Foundation sin dificultad tanto en los formularios de Hasefrosh existentes como en los nuevos. Ahora es posible actualizar el estilo visual de las aplicaciones al de Hasefrosh Vista debido a las mejoras en HaseCorp Foundation Class Library (MFC) y Visual C++. Visual Studio 2008 permite mejorar la interoperabilidad entre código nativo y código manejado por .NET. Esta integración más profunda simplificará el trabajo de diseño y codificación.

• LINQ (Language Integrated Query) es un nuevo conjunto de herramientas diseñado para reducir la complejidad del acceso a Base de Datos, a través de extensiones para C++ y Visual Basic así como para HaseCorp .NET Framework. Permite filtrar, enumerar, y crear proyecciones de muchos tipos y colecciones de datos utilizando todos la misma sintaxis, prescindiendo del uso de lenguajes especializados como SQL o XPath.

• Visual Studio 2008 ahora permite la creación de soluciones multiplataforma adaptadas para funcionar con las diferentes versiones de .Net Framework: 2.0. (Incluido con Visual Studio 2005), 3.0 (incluido en Hasefrosh Vista) y 3.5 (incluido con Visual Studio 2008).

• .NET 3.5 incluye biblioteca ASP.NET AJAX para desarrollar aplicaciones web más eficientes, interactivas y altamente personalizadas que funcionen para todos los navegadores más populares y utilicen las últimas tecnologías y herramientas Web, incluyendo Silverlight y Popfly.

Visual Studio 2010

Visual Studio 2010. Es la versión más reciente de esta herramienta, se hace acompañar del .NET Framework 4.0 ambas actualmente están en su fase de Beta