Este artículo proviene de un motor de traducción automática.

Instintos básicos

Aplicaciones de Visual Basic con compatibilidad con múltiples versiones (multi-targeting) en Visual Studio 2010

Spotty Bowles

Anteriores a Visual Studio 2008, escribir aplicaciones que las distintas versiones de Microsoft .NET Framework de destino requiere la instalación de las distintas versiones del entorno de desarrollo de Visual Studio. Cada instalación de Visual Studio que ofrece una experiencia de desarrollador diferentes y utiliza el espacio en disco considerable. Además, el formato de archivo de proyecto cambia entre cada versión de Visual Studio. Como resultado, podría acabar con varias versiones de un proyecto o solución al desarrollar un componente para su uso en proyectos destinados a distintas versiones de .NET Framework.

Visual Studio 2008 fue la primera versión totalmente compatible con varios destinos en un IDE único, que permite a los programadores escribir aplicaciones orientadas a las distintas versiones de .NET Framework (2.0, 3.0 y 3.5) mediante una única instalación de Visual Studio. ¿Cuál es el resultado? Una experiencia de desarrollador consistente con los requisitos de espacio en disco reducido.

Ha trabajado destinos múltiple en Visual Studio 2008 porque cada uno de los marcos de trabajo disponibles utiliza el mismo CLR 2.0 subyacente. Además, cada versión de la interfaz que se basa en la base de .NET Framework 2.0, que proporciona funcionalidad adicional mediante el uso de hacer referencia a ensamblados. En última instancia, tenía el compilador de Visual Basic de la línea de comandos de .NET Framework 3.5 (vbc.exe).

En este artículo se analizarán los compiladores de 3,5 pulgados y 4, que hace referencia a los compiladores que se instala como parte de .NET Framework 3.5 respectivas y las instalaciones de 4. El compilador 3.5 es la versión proporcionada con Visual Studio 2008 y Visual Basic 9, mientras que el compilador 4 es la versión proporcionada con Visual Studio de 2010 y 10 de Visual Basic.

Por lo tanto, let’s tomar a ver cómo varios destinos funciona en Visual Studio en la actualidad, y cómo debe enfocar varios destinos en los proyectos.

Identificación de múltiple en Visual Studio

En Visual Studio 2008, cambiar el marco de destino deseada no tan sencilla como seleccionar el destino de una lista desplegable en las propiedades del proyecto, como se muestra en de figura 1. Esto agrega o quita algunas referencias específicas necesarias para cada versión del marco de trabajo y realiza el cambios de marcos de trabajo sin inconvenientes.

Figura 1 de cambiar el marco de trabajo de destino deseado de Visual Studio 2008

Era simplemente cambiar los ensamblados de referencia que se utiliza para la compilación de la línea de comandos.

Algunos cambios importantes suministrado con Visual Studio de 2010, sin embargo. El nuevo 4 de .NET Framework ofrece una nueva versión de CLR. Esto significa que el enfoque adoptado en Visual Studio 2008 no es práctico en 2010 de Visual Studio. Como resultado, 2010 de Visual Studio utiliza el compilador de la versión 4 para todos los multi-targeting, incluso cuando las versiones anteriores de .NET Framework de destino. Esto permite que muchas de las características del lenguaje más recientes que se utilizará para destinos de abajo y proporciona una experiencia de desarrollo simplificado de mucho.

Sin embargo, una desventaja de poder utilizar las características de Visual Studio de 2010 para objetivos de nivel inferior es que los archivos de origen no sea compatible con el tiempo de diseño si se utiliza con versiones anteriores de Visual Studio. Esto puede ser un problema si se comparte código fuente para los proyectos generados con distintas versiones de Visual Studio y su uso en distintas versiones de .NET Framework.

Si se dispone de los proyectos de Visual Studio de 2010 para todo el trabajo de tiempo de diseño, tendrá un mejor rendimiento. Podrá volver a generar los ensamblados destinados a .NET Framework 2.0 hacia arriba sólo con 2010 de Visual Studio y .NET Framework 3.5 SP1.

Compatibilidad de tiempo de diseño

Ahora let’s echar un vistazo a un ejemplo de un gotcha de compatibilidad de tiempo de diseño. El código de de figura 2 utiliza tanto la continuación de línea implícita como la función de la propiedad implementada automáticamente, ambos se introdujeron en Visual Studio de 2010. Este código puede compilarse como destino cualquier marco de trabajo de 2.0 hacia adelante, cuando se compila utilizando Visual Studio de 2010. Por lo que el ensamblado generado es compatible con el tiempo de ejecución.

La figura 2 de utilizar New Language Features que trabajo estará en destinos de nivel inferior

Sin embargo, adoptar este mismo archivo de código fuente y pruebe a compilar con las versiones 3.5 o 2.0 del compilador: va a generar los errores que se muestra en de figura 3.

La figura 3 código de Visual Studio de 2010 no es el tiempo de diseño compatible con Visual Studio 2008

Esto ocurre porque las versiones anteriores del compilador saben nada acerca de estas características y tratan como código no válido. Por lo tanto, los archivos de origen no son compatibles con el tiempo de diseño. Para compatibilizar este tiempo de diseño, deberá utilizar sólo las características disponibles en el compilador 3,5.

Compatibilidad de tiempo de diseño tiene implicaciones para los proyectos Web también. Para muchos proyectos Web, compilación lleva a cabo en el servidor y el servidor, por supuesto, compila las páginas utilizando el compilador de marco de destino está instalado en el servidor. Por lo tanto, si dispone de una página Web escrita en Visual Basic, el compilador de 3,5 pulgadas de destino, se compilará la página en el servidor utilizando la versión 3.5 del compilador de Visual Basic (vbc.exe). Cualquier uso de las nuevas características de lenguaje de Visual Studio de 2010 produciría un error como el compilador 3,5 sabe nada acerca de ellos.

Para el código desarrollado en Visual Studio 2010, que utiliza la versión 4 del compilador, necesita una manera de identificar este requisito en tiempo de compilación para evitar errores inesperados cuando la página Web se implementa en el servidor. Esto puede hacerse con el modificador /langversion, que se utiliza para desarrollar proyectos Web para generar los errores de las características más recientes de sintaxis de lenguaje que no se compilación en compilador de un entorno de versiones anteriores. Al generar tipos de proyecto ASP.NET, este modificador se utiliza internamente para generar errores si el código utiliza las nuevas características de Visual Studio de 2010, pero que se va a utilizar versiones anteriores del marco de trabajo.

Aunque no se utiliza el modificador de /langversion de forma predeterminada para cualquiera de los otros tipos de proyecto, puede ser útil si desea comprobar que el código fuente es compatible con el tiempo de diseño con las versiones anteriores de Visual Studio.

Identificación de múltiples en el IDE de Visual Studio 2010

El usuario de varios destinos experiencia en el IDE de Visual Studio 2010 es casi idéntico de Visual Studio 2008. Control se realiza desde dentro de las propiedades del proyecto, pero en una instalación predeterminada no puede ver los marcos de destino anteriores. Para reducir el tamaño de la instalación, el equipo de Visual Studio decidió no incluyen el marco de trabajo de 3,5 en la instalación predeterminada de Visual Studio de 2010. Este cambio significa que no se ven estas opciones de marco de trabajo que aparece en el marco de destino desplegable o cuadro de diálogo nuevo proyecto.

Para agregar estos marcos adicionales, deberá instalar el Service Pack 1 de .NET Framework 3.5. Para hacer este derecho en el entorno IDE. En la parte superior del cuadro de diálogo nuevo proyecto, verá un menú desplegable para elegir el marco de destino. Si sólo se instala el 4 de .NET Framework, el menú contiene un vínculo para descargar más. Si instaló cualquier otro, sin embargo, verá sólo .NET Framework 3.5 SP1 en el menú desplegable porque Visual Studio sólo reconoce la instalación de .NET Framework 3.5 SP1 aquí.

Otro cambio que se tiene que ver con los perfiles de cliente. Éstos se introdujeron en el Service Pack 1 de .NET Framework 3.5 y permiten que las aplicaciones utilizan una versión ligera del marco de trabajo, lo que mejora las implementaciones al no requerir la inclusión de componentes de servidor del marco de trabajo, como ASP.NET. Estos perfiles están disponibles para los destinos de marco de trabajo de 3,5 pulgadas y 4.

Como resultado, el perfil predeterminado para los distintos tipos de proyecto se ha cambiado. Los tipos de proyecto de cliente, las aplicaciones de consola de Windows, Office y Windows Presentation Foundation (WPF), le de forma predeterminada, el perfil de cliente. Sin embargo, para las aplicaciones Web el perfil predeterminado será “ completo ” causa de las referencias a bibliotecas que no se implementan con el perfil de cliente, como, por ejemplo, System.Web.

Las bibliotecas de clases también el perfil completo de forma predeterminada, pero pueden cambiar fácilmente a un perfil de cliente si está en función únicamente en las referencias que se implementan con el perfil de cliente. Si la biblioteca de clases está establecida en el perfil completo y, a continuación, se utiliza en un proyecto con un perfil de cliente, seguirán funcionando siempre que la biblioteca no depende de las referencias que no forman parte de los ensamblados de marco de trabajo cliente.

De forma predeterminada, ninguna de las referencias agregadas para el tipo de proyecto de biblioteca de clase requiere un perfil completo. Sin embargo, debido a que se está implementado con una aplicación, el perfil de la implementación de aplicaciones es la opción importante para garantizar la funcionalidad completa de la aplicación. Si la biblioteca depende de las referencias fuera del ámbito del cliente, deben emplear el perfil completo tanto en la biblioteca de la aplicación está usando.

Especificar múltiples utilizando el compilador de línea de comandos

El compilador de la versión 4 tiene un número de modificadores de línea de comandos, Desafortunadamente, ninguno de los cuales, controla el marco de destino por lo que es importante comprender un poco acerca de cada uno de los modificadores y su funcionamiento.

Si está instalado el 4 de .NET Framework, es posible crear aplicaciones con vbc.exe, que las versiones anteriores del marco de destino sin necesidad de Visual Studio instalada en el equipo de generación. Las secuencias de comandos de generación que se llama directamente al línea de comandos del compilador se utilizan a menudo en entornos de desarrollo más grandes. Si va a utilizar versiones anteriores de la línea de comandos, para ello, los archivos instalados con la versión anterior de marco de trabajo de que destino, por lo que es el mejor plan tiene .NET Framework 3.5 SP1 y el 4 de .NET Framework instalado en el equipo.

Con esta idea en mente, algunos de los modificadores posibles para múltiples destinos se detallan en de figura 4.

La figura 4 de la línea de comandos de generación de los conmutadores para Multi-identificación de control

Modificador	Descripción
langversion	Proporciona los errores de código fuente mediante las características que no cumplen con la versión de idioma específico. (9.0 se refiere a objetivos de seguridad para .NET Framework 3.5, 10 está relacionado con los objetivos de .NET Framework 4). Esto no realmente determina el marco de destino o CLR que se va a utilizar, pero permite que los proyectos de Web identificar las características de 2010 de Visual Studio que se utiliza en escenarios de destino de abajo.
vbruntime	Aunque hay una versión diferente de Microsoft.VisualBasic para el 4 de .NET Framework, simplemente intentando especificar la versión 2.0 de Microsoft.VisualBasic.dll no funciona y genera un ensamblado dependiente de la versión 4 NetFX.
nostdlib	Impide que la referencia a system.dll desde que se agrega al ensamblado. Aunque es posible utilizar esta opción junto con una referencia a la versión de system.dll en el marco de trabajo 2.0, el resultado sigue siendo un ensamblado de la versión 4.
sdkpath	Una opción de clave que especifica qué versión de MSCorLib.dll y Microsoft.VisualBasic.dll que se utilizará si el modificador vbruntime, no especifica que se va a utilizar. Sin embargo, esto no es una referencia explícita que normalmente aparece en la lista de referencias. En su lugar, el compilador Esto incluye las referencias estándar. Agregarlo es parte de la solución para varios destinos cuando se desea que la versión 2.0 de MSCorLib, no es la versión 4.
noconfig	Hace que el compilador evitar agregar las referencias predeterminadas, importaciones y contenidos en el archivo vbc.rsp, que se utilizaría en caso contrario, los conmutadores.

Esta tabla proporciona una descripción rápida de cada uno, pero a fin de crear una compilación destinado a la inferior, debe utilizar una combinación: no hay ningún modificador de varios destinos único. Para un destino de la versión 3.5, el cambio más importante es sdkpath, que se puede utilizar para especificar la versión 2.0 de MSCorlib. A continuación, asegúrese de que las referencias señalan a las versiones correctas de System.dll, System.core.dll y otros ensamblados de framework de destino anterior. (Esto se pueden encontrar en la carpeta de Assemblies\Microsoft\Framework\v3.5 %programfiles%\Reference.)

Debe especificar el modificador noconfig para evitar el uso de los modificadores de la predeterminada en la versión 4 de vbc.rsp, que contiene la configuración predeterminada para la compilación. Sin agregar este modificador crítico, el compilador debe agregar esas referencias predeterminadas 4, las importaciones y así sucesivamente.

Compilación de la línea de comandos destinado a múltiples se explica mejor mediante un ejemplo. Aquí simplemente estoy compilar un archivo de origen simple test.vb, como destino .NET Framework 3.5:

vbc.exe /noconfig /sdkpath:D:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 /r:"D:\Program Files\ReferenceAssemblies\Microsoft\Framework\v3.5\System.Core.dll" d:\school\test.vb  /out:\school\test.exe

Cuando comprenda los modificadores para compilar un ensamblado de 3.5, destinado a 2.0 en su lugar simplemente implica quitar algunas de las referencias, como, por ejemplo, system.core.dll, que son necesarias para el marco de trabajo de 3,5. Los modificadores sdkpath y noconfig siguen siendo los mismos:

vbc.exe /noconfig /sdkpath:D:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 d:\school\test.vb /out:\school\test.exe

Una vez que el binario compilado, puede emplear una herramienta como, por ejemplo, el Desensamblador de MSIL (Ildasm.exe) o .NET Reflector para buscar en las versiones de las referencias que se va a utilizar. Esto le permite determinar si un archivo ejecutable se ejecutará en un marco de destino que desee.

Soluciones de perfil de cliente y mixto de destino.

Anteriormente en este artículo he mencionado que los perfiles de los clientes eran el valor predeterminado para la mayoría de los tipos de proyecto. Cuando se distribuyen dichas aplicaciones, se produce la instalación de una marco de trabajo de menor tamaño. Puede observar que el compilador de línea de comandos se ha implementado como parte de esta implementación. Se trata de la misma versión del compilador que se implementa con el marco de trabajo completo, pero hay un potencial gotcha al intentar compilar una aplicación sencilla en un perfil de cliente.

Mediante este comando en un marco de trabajo cliente produciría un error debido a que los marcos de trabajo de cliente no están incluidos con un vbc.rsp, que contiene las referencias predeterminadas:

vbc.exe test.vb /out: test.exe

Tendría que especificar todas las referencias y las instrucciones de importación que contiene normalmente en la vbc.rsp file o crear las suyos propios.

Los modificadores mínimos imprescindible necesarios para compilar una aplicación de Visual Basic en un marco de trabajo de la instalación de cliente son los siguientes:

/r:System.dll/Imports:System/Imports:Microsoft.VisualBasic

Mediante la inclusión de estos modificadores se puede compilar una aplicación básica de Visual Basic. Sin embargo, se deben compilar las aplicaciones en un equipo 
that tiene el marco de trabajo completo instalado.

Las soluciones de mezcla de destino, generadas con .NET Framework 3.5 se utiliza con una aplicación de cliente, el 4 de .NET framework de destino de las bibliotecas de clases, son compatibles, pero con algunas advertencias. En el IDE de Visual Studio 2010, si está utilizando referencias del proyecto y están acostumbrados a la experiencia que proporcionan, puede obtener esta experiencia si los marcos de destino en las referencias del proyecto utilizan la misma versión de MSCorlib. La figura 5 muestra las versiones de MSCorlib y admite las versiones del marco de trabajo.

La figura 5 de MSCorlib y compatibilidad de versiones de Framework

MSCorlib versión	Entornos compatibles	Perfiles
2.0	2.0, 3.0, 3.5	Cliente y el total de perfiles
4.0	4	Cliente y el total de perfiles

Por lo tanto, si utiliza una biblioteca de clases de destino MSCorlib 2.0 en la aplicación de .NET Framework 3.5, es todavía puede utilizar las referencias del proyecto. De manera similar, una biblioteca de clases de perfil completo de .NET Framework 4 que hace referencia a una aplicación de Windows de .NET Framework 4 perfiles de cliente puede tener una referencia de proyecto a la biblioteca.

Sin embargo, si utiliza una referencia de proyecto al proyecto que se utiliza una versión diferente de MSCorlib, la referencia de proyecto se convertirá en un archivo de referencia. Esto significa que será necesario volver a generar manualmente la solución cuando se corrigen errores. La experiencia le resultarán familiar si ha trabajado con soluciones de varios proyectos que se hace referencias, escritos en C# y Visual Basic. Perderá algunas de las prestaciones disponibles con las referencias de proyecto, como cambiar el nombre en todos los proyectos y compilación automáticamente en segundo plano.

El IDE protege un poco de lo que sucede en segundo plano durante la compilación, pero no todos los usuarios se basa en el entorno IDE. La referencia de archivo cambiará automáticamente a una referencia de proyecto si cambian los marcos de destino para que se utilizan marcos de trabajo con una versión común de MSCorlib, por lo que no es una referencia de archivo es true.

¿Qué ocurre si utiliza una biblioteca de clases (3,5) de la inactividad de destino dentro de una aplicación de la versión 4? En realidad, la biblioteca de clases se ejecutará el 4 de .NET Framework. Se ha producido la considerable de pruebas para asegurarse de que este escenario funciona con algunos problemas en tiempo de ejecución. Sin embargo, no es compatible con intentando utilizar una biblioteca de clases de marco de 4.0 trabajo en una aplicación de marco de trabajo de 3,5 y se producirá un error en tiempo de compilación si se genera con MSBuild o Visual Studio. Para utilizar las bibliotecas de clases de marco de trabajo 4.0 en una aplicación de destino de marco de trabajo de 3.5, sin embargo, tendrá que va hacia abajo la biblioteca de clases de .NET Framework 3.5.

No obstante, que con la posibilidad de utilizar las características del lenguaje de Visual Studio de 2010 en escenarios de destino de abajo, destinado a la biblioteca de clases de .NET Framework 3.5 no se debe ser un gran problema, tenga en cuenta. La figura 6 resume las nuevas características que puede esperar a trabajar en proyectos de destino de abajo.

La figura 6 de nuevas características de Studio Visual en escenarios de destino-abajo

Características de lenguaje	Works en escenarios de destino-abajo
Inicializadores de colección	Sí
Inicializadores de matrices	Sí
Propiedades implementadas automáticamente	Sí
Continuación de línea implícito	Sí
Lambdas de instrucción	Sí
No hay PIA	No
Interoperabilidad dinámica	No
Contravarianza/CO	Parcialmente

PIA y la interoperabilidad

Con .NET Framework para programar con el modelo de objetos de Microsoft Office, requiere el uso de ensamblados de interoperabilidad primarios (PIA), que se debe implementar en el equipo del usuario. Estos ensamblados suelen ser muy grandes y la implementación de ellos puede ser una molestia.

La nueva función de incrustación de objetos de tipo permite que estas aplicaciones al implementarse sin necesidad de ensamblados de interoperabilidad primarios en el equipo del usuario. Esto se consigue generar tipos de interoperabilidad incrustados que realizan las llamadas de interoperabilidad para la biblioteca COM directamente. Estos tipos se anotan el compilador de manera que el CLR trata incrustado todas las instancias de tipo de interoperabilidad como equivalentes. El compilador no copia todos los tipos en el PIA en el ensamblado, sólo los que se han utilizado. Para obtener más información, vea “ tipo equivalencia y Embedded interoperabilidad tipos ” en MSDN library (msdn.microsoft.com/library/dd997297(VS.100) ).

La funcionalidad de esta característica no se admite para casos de destino de abajo a continuación el 4 de .NET Framework. Con el IDE de Visual Studio, esto no sería tan evidente como configuración de la referencia incrustados interoperabilidad la propiedad en true en un escenario de destino de abajo el resultado normales de las referencias que se va a utilizar. La experiencia del usuario para la función desde el IDE es que el ensamblado continuará generar, pero debe volver al comportamiento de las referencias estándar, lo que requeriría la implementación de ensamblados de interoperabilidad primarios.

Desde la línea de comandos, las referencias se agregan normalmente con el modificador de la opción /reference. Para incrustar, en su lugar se utiliza el modificador/Link. Intente utilizar el modificador/Link para escenarios objetivo bajo da como resultado errores de compilación.

A continuación, presentamos un ejemplo de una línea de comandos la incrustación de tipos del ensamblado de interoperabilidad de Word:

D:\Windows\Microsoft.NET\Framework\v4.0.30128\Vbc.exe /imports:Microsoft.VisualBasic,System /link:"D:\Program Files\Microsoft Visual Studio 10.0\Visual Studio Tools for Office\PIA\Office14\Microsoft.Office.Interop.Word.dll" /reference:"D:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Client\System.Core.dll","D:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Client\System.dll" /out:ConsoleApplication16.exe /target:exe Module1.vb

Este comportamiento es importante porque, de forma predeterminada, las referencias de COM agregadas un proyecto de Visual Studio de 2010, establezca la propiedad de la interoperabilidad de incrustar en true. Por lo tanto, cambiar el marco de destino no debe tener como resultado errores adicionales, pero debe proporcionar el beneficio de los tipos de interoperabilidad incrustados cuando sea posible.

Otra característica nueva en 2010 de Visual Studio que no se admite para casos de inactividad de destino es interoperabilidad dinámica porque, hasta 2010 de Visual Studio, no existía el tiempo de ejecución de lenguaje dinámico (DLR).

Otros problemas

Covarianza y contravarianza se pueden utilizar con interfaces definidas por el usuario. Sin embargo, no se cambian las interfaces de la biblioteca de clases base (BCL) de los objetivos de nivel inferior y, por tanto, se utiliza la función con estas clases base no es compatible. Para obtener más información acerca de la covarianza y contravarianza, consulte la columna de Basic Instincts en el de 2010 de marzo de MSDN Magazine (msdn.microsoft.com/magazine/ee336029 de ).

Si dispone de un proyecto o solución que creó en una versión anterior de Visual Studio que se abre en Visual Studio de 2010, verá el cuadro de diálogo de actualización estándar. Visual Studio hará que los cambios necesarios para los archivos de proyecto o solución para trabajar con Visual Studio de 2010. Sin embargo, hay dos acciones distintas conlleva la actualización de los archivos que puedan afectar a varios destinos.

Si tiene instalado .NET Framework 3.5 SP1, el cuadro de diálogo actualización permitirá que los archivos de proyecto o solución para su actualización a Visual Studio de 2010, pero los marcos de destino especificados para el proyecto permanecerá intactos. Por lo tanto, si se actualiza una aplicación de destino de .NET Framework 3.5, después de la actualización se debe aún orientar el marco de trabajo de 3,5 pulgadas.

Si no tiene instalado .NET Framework 3.5 SP1, no se puede generar multi-targets correctamente porque se necesita la versión 2.0 de MSCorlib y los ensamblados de referencia. El cuadro de diálogo le proporcionará la opción para cambiar el destino para un marco de trabajo de la versión 4 o no actualizar el proyecto. La mejor en este caso es cancelar la actualización, instale el Service Pack 1 de .NET Framework 3.5, a continuación, ejecutar el proceso para actualizar el proyecto de nuevo.

Si conoce un poco más de los detalles de implementación de varios destinos en 2010 de Visual Studio de Visual Basic, puede escribir código que genera los ensamblados que se pueden implementar en las versiones anteriores del marco de trabajo utilizando el IDE o la línea de comandos, pero aún aprovechan algunas de las nuevas características de Visual Studio de 2010. Aunque varios destinos con algunas advertencias, se conserva la capacidad para desarrollar e implementar las aplicaciones que no se pueden actualizar inmediatamente para utilizar el 4 de .NET Framework.

Adrian Spotty Bowles ha desarrollado utilizando todas las versiones de Visual Basic y a encontrar su forma de Redmond, Washington, donde trabaja en el equipo de producto de Visual Basic como una herramienta de comprobación de ingeniero de diseño de software que se centra en el compilador de Visual Basic. Es un apasionado sigue a Visual Basic y a menudo se puede encontrar que responde preguntas en los foros de MSDN de Visual Basic. Se puede llegar a Bowles en Abowles@microsoft.com .

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Kevin Halverson y Beth Massi