Problemas conocidos cuando se utilizan las ediciones Express de Microsoft Visual Studio 2005

En este documento se informa de los problemas conocidos con los que se puede encontrar a la hora de utilizar las ediciones de Microsoft Visual Studio 2005 Express. Para obtener información acerca de problemas relacionados con la instalación del producto, consulte el archivo readme.htm.

Publicado: 10 de Julio de 2006

Para obtener una lista de los cambios importantes producidos entre la versión beta 2 y la versión final, consulte el vínculo siguiente http://go.microsoft.com/fwlink/?LinkId=51223

Para obtener la información más reciente sobre los problemas conocidos, consulte la información en línea de los problemas conocidos de Visual Studio 2005 Express en http://go.microsoft.com/fwlink/?LinkId=51325

En esta página
1. Todas las ediciones Express 1. Todas las ediciones Express
2. Visual C# Express2. Visual C# Express
3. Visual Basic Express3. Visual Basic Express
4. Visual J# Express4. Visual J# Express
5. Visual C++ Express5. Visual C++ Express
6. .NET Framework6. .NET Framework
7. MSDN Express7. MSDN Express
8. Entorno de desarrollo integrado de Visual Studio8. Entorno de desarrollo integrado de Visual Studio
9. Visual Web Developer Express9. Visual Web Developer Express
*

1. Todas las ediciones Express

1.1 Los cambios de codificación pueden no aparecer cuando se vuelve a cargar un archivo en el editor

Visual Studio 2005 no detecta los cambios de codificación cuando se vuelve a cargar un archivo. Si ha efectuado cambios en la codificación de un archivo en un editor diferente del actual, o si ha llevado a cabo una operación de control de código fuente que haya cambiado la codificación de un archivo abierto en el editor, Visual Studio vuelve a cargar el archivo automáticamente. El contenido del archivo puede mostrarse de manera incorrecta una vez cargado en el editor.

Para resolver este problema

Cierre el archivo sin guardar los cambios.

En el menú Archivo, seleccione Abrir y elija Archivo

En el cuadro de diálogo Abrir archivo, haga clic en la flecha situada junto al botón Abrir y haga clic en Abrir con.

En la lista del cuadro de diálogo Abrir con, seleccione el editor con el que desea abrir el archivo, como el Editor binario o el Editor de recursos. Para abrir el archivo con una codificación determinada, seleccione un editor que admita codificación, como el editor XML con codificación.

Haga clic en Aceptar.

En el cuadro de diálogo Codificación, seleccione la codificación correcta en la lista desplegable Codificación.

Haga clic en Aceptar.

1.2   Excepciones de equivalencia en el comportamiento de Visual Studio y .NET Framework en plataformas de 32 bits y 64 bits 

1.

Extensiones de servidor de Front Page para IA64 WOW64

Cuando se utilice .NET Framework 1.1 para crear sitios Web en equipos IA64 remotos que ejecutan .NET Framework 1.1, no se admitirá la utilización de FrontPage. Cierta funcionalidad básica funcionará mediante un mecanismo para compartir archivos.

2.

J# no se puede ejecutar en plataformas nativas de 64 bits. El código de J# sólo se puede ejecutar en WOW64 en plataformas de 64 bits.

3.

SQL Server Express no se puede ejecutar en plataformas de 64 bits para .NET Framework 2.0.

4.

No hay ninguna garantía en cuanto al rendimiento o escalabilidad para aplicaciones ASP.NET de carga elevada que se ejecuten en .NET 1.1 mediante WOW64 para IA64.

5.

Los puntos de interrupción de datos no funcionan cuando Visual Studio se ejecuta en IA64 mediante WOW64.

6.

La característica Editar y continuar del depurador no funciona en plataformas de 64 bits

7.

En Visual Studio 2005, excepciones de VC ATL:

El sistema de generación no registra archivos dll cuyo destino sean plataformas de 64 bits en wow64

Se obtiene el mensaje de error "%1 no es una aplicación de Win32 válida" al depurar el proyecto de servidor ATL predeterminado en un equipo con una plataforma de 64 bits

En proyectos de servidor ATL con configuraciones de 64 bits, los campos del ejecutable que se va a depurar y de la dirección URL no se rellenan con valores predeterminados

IE no se mostrará con el archivo .srf especificado por el usuario al depurar el proyecto de servidor ATL de 64 bits

El tipo de depurador para la configuración de 64 bits del servidor ATL tiene como valor predeterminado el depurador de Windows local en lugar del depurador de servicios Web

Las propiedades de depuración no se propagan a nuevas configuraciones en un proyecto. Esto significa que, por ejemplo, si se empieza con un proyecto de servidor ATL en x86, luego se crea una configuración de 64 bits para él, la depuración no funcionará sin cambiar el código que está siendo depurado para que sea IE.

8.

No hay compatibilidad con la depuración de interoperabilidad (depuración de modo mixto: administrada + no administrada) en 64 bits

9.

Algunos MDA no son compatibles con plataformas de 64 bits. Ejemplos: Reentrancy, LoaderLock, PInvokeStackImbalance

10.

Los compiladores de C++ IA64 y x64 no admiten extensiones intrínsecas de MMX.

11.

Los compiladores de C++ IA64 y x64 no admiten el código ensamblador en línea.

12.

MASM para x64 no admite la mayoría de las construcciones de lenguaje de alto nivel.
MASM no admite IA64, pero ofrecemos el ensamblador de Intel (ias.exe)

13.

Los compiladores de C++ x64 e IA64 no admiten el modificador /ARCH:SSE del compilador de VC++.

14.

Las API System.Diagnostics.Process.MainModule y System.Diagnostics.Process.Modules producirán un error si se ejecutan bajo WOW64 en un proceso secundario de 64 bits.

15.

No se pueden registrar al mismo tiempo los componentes proporcionados por COM+ de 32 y 64 bits con los mismos identificadores GUID/CLSID.

16.

El SDK de 64 bits no incluye DBGCLR nativo. El depurador DBGCLR sólo funcionará en WOW64.

17.

El SDK de 64 bits no incluye un archivo DEXPLORE.EXE nativo. El archivo DEXPLORE.EXE sólo funcionará en WOW64.

18.

No hay paquetes de manifiesto de programas previos para x64 e IA64. No hay ningún programa previo de 64 bits para ClickOnce u otras aplicaciones. En cualquier equipo de 64 bits con .NET Framework instalado, si intenta instalar una aplicación ClickOnce, se produce un error y se muestra el mensaje "La versión de .NET Framework 2.0 no es compatible con un sistema operativo de 64 bits. Póngase en contacto con el proveedor de la aplicación." Esto sucede incluso con aplicaciones creadas sólo para 32 bits y que deberían ejecutarse en WOW64.

19.

Visual Studio no se instala en IA64

VS2005 (ninguna unidad SKU) no se instalará en IA64 (no hay compatibilidad en tiempo de diseño para IA64). VC tendrá un instalador de herramientas de línea de comandos IA64 nativo

20.

Sólo Visual Studio Team System permitirá crear aplicaciones que tengan como destino IA64

21.

Las firmas P/Invoke con tipos representables como bits/bytes son tratadas de diferente manera en plataformas de 64 bits;

P/Invoke se implementa de otra manera en plataformas de 64 bits, de ahí que haya casos en los que firmas P/Invoke incorrectas que accidentalmente funcionaban en plataformas de 32 bits no funcionan en las de 64.

22.

Las plataformas de 64 bits no admiten Visual Studio Tools para Office (VSTO).

1.3 Puede que las referencias a componentes COM de 32 bits no funcionen en aplicaciones de VB y C# que se ejecuten en plataformas de 64 bits

La mayoría de los componentes COM existentes sólo están disponibles para plataformas de 32 bits y no se ejecutarán en un proceso de 64 bits en una plataforma de 64 bits (si bien se ejecutarán correctamente en un proceso de 32 bits en una plataforma de 64 bits). Las aplicaciones de VB y C# que hacen referencia a estos componentes COM de 32 bits no se ejecutarán de forma predeterminada en una plataforma de 64 bits, ya que la aplicación se iniciará como proceso de 64 bits de forma predeterminada.

El problema surge cuando un proyecto con una o más referencias COM:

1. Se migra a VS 2005 y se ejecuta en plataformas de 64 bits
O bien-
2. Se crea utilizando VS 2005 en plataformas de 64 bits

En VS 2005 los compiladores de VB y C# utilizan la propiedad de destino de plataforma para determinar si el archivo .exe o .dll debe ejecutarse en el modo de arquitectura de CPU de 32 o 64 bits. El valor predeterminado de esta propiedad en Visual Studio 2005 se establece como ‘Cualquier CPU’, lo que indica que la aplicación se puede ejecutar tanto en modo de 32 bits como en modo de 64 bits, en función de la plataforma del host. En esta situación, puede aparecer un error del tipo "No se puede crear una instancia de la clase…" al depurar o ejecutar estas aplicaciones.

Para resolver este problema

Establezca la propiedad de destino de plataforma en ‘X86’ para los proyectos de VB o C# que incluyen referencias a componentes COM.

Para proyectos de C#:

1.

Haga clic con el botón secundario del mouse (ratón) en el proyecto en el Explorador de soluciones y abra 'propiedades'

2.

Elija la ficha Generar

3.

Establezca la propiedad de la plataforma de destino como 'X86'

Para proyectos de VB:

Haga clic con el botón secundario del mouse en el Explorador de soluciones y abra 'propiedades'

Elija la ficha Compilar

Presione el botón Opciones de compilación avanzadas

Establezca la propiedad CPU de destino como 'X86'

Edición Express:

Los productos Express de VB y C# muestran la propiedad de destino dentro del entorno de desarrollo. Deberá modificar con todo cuidado el archivo del proyecto mediante un editor de texto o XML.

1.

Cierre el proyecto y/o la solución

2.

Seleccione Abrir archivo en el menú Archivo

3.

Desplácese hasta el directorio del proyecto y resalte el archivo de proyecto

4.

Presione el botón Abrir, el archivo de proyecto se debe abrir en el editor XML

5.

Busque la primera sección <PropertyGroup> y agregue la siguiente línea:<PlatformTarget>x86</PlatformTarget>

6.

Guarde el archivo de proyecto

7.

Vuelva a abrir el proyecto y/o la solución utilizando el comando Abrir proyecto/solución del menú Archivo

8.

Continúe con el desarrollo, la depuración y las pruebas

También, si la aplicación está destinada a plataformas de 64 bits, puede asegurarse de que los controles COM agregados a la aplicación tengan equivalentes de 64 bits en los equipos de desarrollo e implementación.

1.4 La utilización de perfiles móviles de Windows puede hacer que en cada inicio se muestre un cuadro de mensaje de inicio

Cuando se utiliza cualquier producto de la familia de Visual Studio 2005 con perfiles móviles de Windows, el mensaje que aparece cuando se inicia la aplicación por primera vez dice "Visual Studio 2005 está configurando el entorno para el primer uso. Esta operación puede tardar varios minutos." y puede aparecer en cada inicio de sesión. Esto puede ocasionar una ralentización innecesaria en el rendimiento del inicio.

Para resolver este problema

Haga clic en Herramientas > Opciones. Seleccione "Importar y exportar configuraciones" y cambie la ruta de acceso bajo "Guardar automáticamente mi configuración en este archivo:" a una ruta de acceso que NO esté bajo el directorio "Mis documentos".

1.5 Las opciones de fuente y de color no se verán reflejadas inmediatamente nada más restablecerlas

El restablecimiento de los valores de configuración del entorno se puede llevar a cabo haciendo clic en Herramientas > Importar y exportar configuraciones y, a continuación, eligiendo "Restablecer todas las configuraciones". El restablecimiento de los valores de configuración del entorno también se puede realizar emitiendo el comando "Tools.ImportAndExportSettings /reset" situado dentro de la ventana Comandos. En cualquier caso, las opciones de fuente y de color no se verán reflejadas hasta que se reinicie Visual Studio.

Para resolver este problema

Una vez llevada a cabo la operación de restablecimiento, reinicie Visual Studio.

1.6 DMO no funciona con el Service Pack 4 de Windows 2000

El Service Pack 1 de MDAC 2.8 no está instalado como parte de los Productos de Visual Studio Express. Las aplicaciones que dependen del Service Pack 1 de MDAC 2.8, como aquellas que utilizan SQL DMO, deben descargar MDAC 2.8 por separado.

Para resolver este problema

Descargue el Service Pack 1 de MDAC 2.8 desde http://go.microsoft.com/fwlink/?LinkId=50233

1.7 La propiedad DataBindings de los controles no es correcta después de copiar y pegar un campo de la ventana Orígenes de datos

Si copia y pega (en lugar de arrastrar y colocar) campos de una base de datos de origen para generar controles en el Diseñador de Windows Forms, las propiedades de enlace de datos se establecerán en la tabla en lugar de en los campos de la tabla. Los orígenes de datos Web y de objetos no se ven afectados.

Para resolver este problema

Para cada control agregado al Diseñador de Windows, edite las propiedades y cambie la propiedad (DataBindings) al origen de datos correcto.

Principio de la páginaPrincipio de la página

2. Visual C# Express

2.1 Los métodos abreviados de los fragmentos de código de C# no pueden contener marcas sin espacio

Los fragmentos de código de C# están definidos en XML dentro de los archivos .snippet. Una de las posibles etiquetas en el esquema es <Shortcut></Shortcut>. Los métodos abreviados se pueden utilizar para insertar un fragmento de código muy rápidamente. Para ello, el usuario sólo necesita escribir la cadena del método abreviado y, a continuación, presionar la tecla TABULADOR.

En las cadenas de métodos abreviados se pueden utilizar muchos caracteres Unicode, pero las marcas sin espacio encontradas en idiomas con escritura compleja no se reconocen como caracteres de métodos abreviados válidos. Esto significa que algunas cadenas de idiomas con escritura compleja no se pueden utilizar como métodos abreviados. Si un método abreviado no contiene ninguna marca sin espacio, al escribir la cadena del método abreviado y presionar la tecla TABULADOR se insertará un carácter de tabulador pero no se insertará el fragmento de código.
Nota: el método abreviado del fragmento de código continuará apareciendo en IntelliSense.

Para resolver este problema

1.

Elija un nombre de método abreviado Unicode que no contenga ninguna marca sin espacio.

2.

Inserte el fragmento de código mediante la interfaz de usuario del Selector de fragmentos de código en lugar de utilizar métodos abreviados.

2.2 Advertencia para el paquete de Microsoft Visual J# Redistributable 2.0 en el cuadro de diálogo Requisitos previos

El paquete para Microsoft Visual J# Redistributable 2.0 aparece con un icono de advertencia en el cuadro de diálogo Requisitos previos, al que se tiene acceso desde la ficha Publicar del diseñador de proyectos.

Para resolver este problema

La advertencia se puede pasar por alto sin ningún problema.

Algunas aplicaciones generadas con las ediciones Express no pueden ser depuradas con, o ejecutadas en, Windows para procesadores de 64 bits

De manera predeterminada, se establecerá que las aplicaciones creadas con VB, C# o J# Express se carguen en "Cualquier CPU". Estas aplicaciones se cargarán en el CLR de 64 bits si existe; en caso contrario, se cargarán en el CLR de 32 bits. Sin embargo, hay ciertos tipos de aplicación que no funcionarán si se ejecutan en el CLR de 64 bits. Concretamente, las aplicaciones que utilizan referencias a componentes COM de 32 bits o a ciertas versiones de DirectX pueden no ejecutarse correctamente en plataformas de 64 bits. Aunque la plataforma de destino se puede cambiar de "Cualquier CPU" a "x86" en productos que no correspondan a ninguna edición Express de Visual Studio, esta opción no está disponible en las ediciones Express.

Para resolver este problema

1.

Abra Herramientas -> Opciones

2.

Active "Mostrar todas las configuraciones>

3.

Active "Proyectos y soluciones -> Mostrar configuraciones de generación avanzadas

4.

Abra Generación -> Administrador de configuración

5.

Seleccione el cuadro combinado situado debajo de la columna "Plataforma" correspondiente al proyecto cuya plataforma de destino desea que sea x86

6.

Elija "

7.

Bajo "Nueva plataforma", seleccione x86

8.

Haga clic en Aceptar y, luego, en Cerrar

9.

Tenga en cuenta que el cuadro combinado de la barra de herramientas para la configuración de la plataforma muestra ahora tanto x86 como Cualquier CPU, y que se encuentra seleccionada la opción x86

10.

Generar, ejecutar y depurar generará ahora binarios de sólo x86. Para cambiarlo, siempre puede volver a la configuración Cualquier CPU.

2.4 Al llevar a cabo diversas acciones en el entorno IDE, puede mostrarse el mensaje "Microsoft C# 2005 IntelliSense ha detectado un problema"

En ciertos casos, el mensaje "Microsoft C# 2005 IntelliSense ha detectado un problema. Sentimos las molestias" puede aparecer al llevar a cabo varias acciones en el editor. En la mayoría de los casos, el origen está en un error al recuperar datos de origen.

Entre algunos ejemplos de acciones que pueden ocasionar la aparición de este cuadro de diálogo de error se incluyen:

El cambio de nombre de un alias externo

El llevar a cabo una búsqueda de todas las referencias en un proyecto Web sin el atributo 'runat="server"'

Este cuadro de diálogo no es grave. Al hacer clic en el botón para enviar informes se permite al usuario continuar trabajando de forma segura, tal como se espera, y se impide la pérdida de datos.

Para resolver este problema

Hay dos maneras posibles de desactivar la aparición de todos los mensajes de error no graves del servicio del lenguaje C#. Para ello, modifique el Registro en la ruta del mismo:

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\CSharp\Options\Editor]

(1) "Watson_ReportExceptions"=dword:00000001
Si se agrega la siguiente clave de Registro con el valor especificado, se deshabilitará el informe de errores por completo.

Nota: la utilización de esta clave del Registro y la desactivación de la aparición de mensajes de error no graves del servicio del lenguaje C# pueden impedir la recopilación de información en escenarios no relacionados con este error.

(2) "Watson_DeferSendingUntilLater"=dword:00000000
Si se agrega la siguiente clave del Registro con el valor especificado, se desactivará la aparición de mensajes de error pero se continuará enviando información a Microsoft. El IDE no responderá durante un breve período de tiempo, mientras se recopila la información para enviarla.

2.5 La utilización de los tipos definidos por el usuario como configuraciones pueden ocasionar comportamientos inesperados en el Diseñador de configuración

La utilización de tipos definidos por el usuario como configuraciones puede ocasionar problemas si el ensamblado en el que reside el UDT se actualiza mientras el proyecto que se está usando está abierto. Si se da este escenario, puede solucionar el problema haciendo que el ensamblado del tipo definido por el usuario tenga en cuenta el incremento de versión.

Para resolver este problema

Si el tipo definido por el usuario que se está utilizando como configuración reside en una biblioteca de clases, cree una versión incrementada de la biblioteca para mitigar el problema. Si el tipo definido por el usuario reside en un archivo EXE, se debe cerrar y reiniciar el IDE para que los cambios efectuados en el UDT surtan efecto.

2.6 El Instalador de contenido de VS sufre un error cuando se desinstala C# Express

Si el usuario instala C# Express, instala a continuación una de las SKU principales y, a continuación, desinstala la SKU de C# Express, el Instalador de contenido de VS sufrirá un error al iniciar.

Para resolver este problema

Repare Visual Studio

Principio de la páginaPrincipio de la página

3. Visual Basic Express

3.1 No habrá ninguna propiedad Forms en "My" dentro de un proyecto de control de usuario

My.Forms no estará disponible en un proyecto de control de usuario

3.2 No se puede llamar a un método de objeto mediante depuración remota si se detiene en la espera

Si se está ejecutando el código siguiente en un equipo remoto, conéctese a la ejecución del código mediante la depuración remota e interrúmpala, pero como la ejecución es efectuada por la llamada Sleep(), no podrá evaluar los valores de los miembros de la variable c.

c = New c1     'se da por supuesto que c1 es una clase válida
While True
Threading.Thread.Sleep(1000)
End While

Para resolver este problema

Salga de Sleep(), entonces podrá evaluar los objetos con normalidad.

3.3 No se puede pasar una estructura a una propiedad de variante en un objeto EXE de ActiveX

En Windows 98 no se puede pasar una estructura a una propiedad de variante en un objeto EXE de ActiveX. El problema se da en un equipo limpio con Windows 9X, el archivo DLL del sistema rpcrt4.dll no se registró de forma predeterminada, de forma que al sistema operativo le falta la clave de registro [HKEY_CLASSES_ROOT\CLSID\{B5866878-BD99-11D0-B04B-00C04FD91550}].
La llamada sufre un error debido a la pérdida del registro.

Para resolver este problema

Vaya a C:\Windows\System e invoque de forma manual RegSvr32.exe rpcrt4.dll.

3.4 La utilización de New en parámetros de tipo con restricciones cíclicas hace que el compilador de VB se bloquee junto con más asignaciones de memoria

Si se pega el código siguiente en una aplicación de consola, hará que se bloquee.

Class C1(Of U As U)    
	  'las restricciones cíclicas originan el problema ulterior
End Class

Partial Class C1(Of U)
Dim x As New U        
	'Problema: esto hace que se cree un bucle infinito y que el uso 
	de la memoria se mantenga en crecimiento hasta que la memoria 
	ya no sirva

End Class

Para resolver este problema

Quite la restricción cíclica

3.5 Los parámetros del controlador StartupNextInstanceEvent no contendrán argumentos de línea de comandos si la aplicación se inició utilizando ClickOnce

Los parámetros del controlador StartupNextInstanceEvent no contendrán los argumentos de la línea de comandos de la segunda instancia de la aplicación si ésta se inició utilizando ClickOnce. Debe utilizar la propiedad My.Application.Deployment.ActivationUri para obtener los argumentos de la línea de comandos.

Para resolver este problema

Utilice las clases en tiempo de ejecución de ASP para obtener los argumentos de la línea de comandos de la manera siguiente:

Imports System.Web

Dim commandLineArgs as NameValueCollection = _
HttpUtility.ParseQuery(My.Application.Deployment.ActivationUri)

3.6 El compilador de VB no admite el atributo InternalsVisibleTo

<Ensamblado: InternalsVisibleTo("Foo.Dll, PublicKeyToken=a29c01bbd4e39ac5")>

Este atributo expone tipos Friend a otros ensamblados. El compilador de VB no admite este atributo.

Algunas tecnologías de comprobación de unidades que se basan en este atributo para los tipos privados de comprobación no funcionarán de la manera esperada.

Para resolver este problema

Este problema no tiene una solución conocida.

3.7 Advertencia para el paquete de Microsoft Visual J# Redistributable 2.0 en el cuadro de diálogo Requisitos previos

El paquete para Microsoft Visual J# Redistributable 2.0 aparece con un icono de advertencia en el cuadro de diálogo Requisitos previos, al que se tiene acceso desde la ficha Publicar del diseñador de proyectos.

Para resolver este problema

Este problema no tiene una solución conocida.

3.8 My.Application.Log.WriteEntry puede producir una excepción si el usuario no tiene permiso de E/S para el archivo

1.

Cree una nueva aplicación de consola con el código siguiente:

    My.Application.Log.DefaultFileLogWriter.CustomLocation = "D:\temp"
    My.Application.Log.WriteEntry("Foo")

2.

Ejecute la aplicación

RESULTADOS:

Se crea un archivo de registro en D:\temp, pero el directorio D:\Documents and Settings\<nombreDeUsuario>\Application Data\Microsoft\WindowsApplication1\1.0.0.0 también se crea si no existe. En el caso de que el usuario no tenga permisos para ello, se producirá una excepción. Esto es probable que suceda cuando se utiliza una biblioteca de clases en una aplicación Web, ya que, de forma predeterminada, el proceso de ASP.NET no tiene permiso de escritura para ningún directorio de Application Data.

Para resolver este problema

1.

Quite el FileLogTraceListener predeterminado mediante app.config y vuelva a configurar My.Application.Log para utilizar otro TraceListener.

2.

Escuche el evento de excepción no controlada y simplemente continúe cuando se obtenga

3.

Coloque un bloque Try/catch en cada llamada que se registre (o como mínimo en las que tengan mayores probabilidades de ser las primeras en ejecutarse).

La utilización de los tipos definidos por el usuario como configuraciones pueden ocasionar comportamientos inesperados en el Diseñador de configuración

La utilización de tipos definidos por el usuario como configuraciones puede ocasionar problemas si el ensamblado en el que reside el UDT se actualiza mientras el proyecto que se está usando está abierto. Si se da este escenario, puede solucionar el problema haciendo que el ensamblado del tipo definido por el usuario tenga en cuenta el incremento de versión.

Para resolver este problema

Si el tipo definido por el usuario que se está utilizando como configuración reside en una biblioteca de clases, cree una versión incrementada de la biblioteca para mitigar el problema. Si el tipo definido por el usuario reside en un archivo EXE, se debe cerrar y reiniciar el IDE para que los cambios efectuados en el UDT surtan efecto.

3.10 La capacidad de interoperabilidad de Long (VT_I8) está limitada a Windows XP

Las llamadas enlazadas en tiempo de ejecución en Windows 2000 o Windows 9x que pasan Long (VT_I8) fallarán. Windows XP es la única plataforma admitida para VT_I8 mediante la automatización OLE.

Para resolver este problema

Utilice integer en lugar de long.

Principio de la páginaPrincipio de la página

4. Visual J# Express

4.1 La utilización de los tipos definidos por el usuario como configuraciones pueden ocasionar comportamientos inesperados en el Diseñador de configuración

La utilización de tipos definidos por el usuario como configuraciones puede ocasionar problemas si el ensamblado en el que reside el UDT se actualiza mientras el proyecto que se está usando está abierto. Si se da este escenario, puede solucionar el problema haciendo que el ensamblado del tipo definido por el usuario tenga en cuenta el incremento de versión.

Para resolver este problema

Si el tipo definido por el usuario que se está utilizando como configuración reside en una biblioteca de clases, cree una versión incrementada de la biblioteca para mitigar el problema. Si el tipo definido por el usuario reside en un archivo EXE, se debe cerrar y reiniciar el IDE para que los cambios efectuados en el UDT surtan efecto.

Principio de la páginaPrincipio de la página

5. Visual C++ Express

5.1 La utilización de los tipos definidos por el usuario como configuraciones pueden ocasionar comportamientos inesperados en el Diseñador de configuración

La utilización de tipos definidos por el usuario como configuraciones puede ocasionar problemas si el ensamblado en el que reside el UDT se actualiza mientras el proyecto que se está usando está abierto. Si se da este escenario, puede solucionar el problema haciendo que el ensamblado del tipo definido por el usuario tenga en cuenta el incremento de versión.

Para resolver este problema

Si el tipo definido por el usuario que se está utilizando como configuración reside en una biblioteca de clases, cree una versión incrementada de la biblioteca para mitigar el problema. Si el tipo definido por el usuario reside en un archivo EXE, se debe cerrar y reiniciar el IDE para que los cambios efectuados en el UDT surtan efecto.

Principio de la páginaPrincipio de la página

6. .NET Framework

6.1 AuthorizationStoreRoleProvider: el Administrador de autorizaciones devuelve errores incorrectos o confusos

AuthorizationStoreRoleProvider depende del Administrador de autorizaciones. No todos los mensajes de error que devuelve dicho administrador indican la causa principal de un problema. A continuación se enumeran mensajes de error conocidos que son incorrectos o imprecisos.

"COMException (0x8007052b): No se puede actualizar la contraseña. El valor proporcionado como contraseña actual es incorrecto".

Este es en realidad un error de acceso denegado. Dicho error se puede producir si se cumplen las condiciones siguientes: ASP.NET se ha implementado en IIS 5.0, en IIS 5.1 para Windows XP o en el modo de aislamiento de IIS 5.0 en Windows Server 2003; la aplicación se ha configurado para utilizar la autenticación integrada de Windows; y el archivo de directivas está ubicado en la estructura de directorios de la aplicación ASP.NET actual. Este error también se puede producir si ASP.NET se ejecuta como cuenta de un equipo local e intenta obtener acceso a un almacén de directivas de una instancia remota de AD o ADAM.

"Hay más datos disponibles"

En realidad, este error significa que no se pudo encontrar el almacén de directivas. Este error puede producirse si la cadena de conexión apunta a una instancia de ADAM, pero hace referencia a una partición de ADAM que no existe. Por ejemplo, en la cadena de conexión siguiente "LDAP://localhost:4000/Cn=storename, DC=Partition14000, se producirá este error si Partition1 no existe en la instancia de ADAM.

"El servidor especificado no puede ejecutar la operación solicitada"

Este error en realidad significa que no se pudo encontrar el servidor especificado. Este error puede producirse si la cadena de conexión apunta a un servidor no existente o utiliza un número de puerto que no escuchan AD o ADAM.

"ArgumentException: El parámetro es incorrecto"

En realidad, este mensaje de error indica que un grupo de consultas LDAP del Administrador de autorizaciones utilizado para determinar si un usuario pertenece a una función no es válido.

Para resolver este problema

Revise las causas posibles de cada una de las condiciones de error indicadas anteriormente. Si la configuración de una aplicación coincide con una de estas causas, modifique o corrija dicha configuración basándose en la información indicada anteriormente.

6.2 Las instancias de usuario de SQL Server Express deben deshabilitarse en equipos host compartidos

ASP.NET 2.0 se integra con SQL Server Express 2005 para proporcionar la creación automática de la base de datos que requieren muchos de los nuevos servicios de aplicaciones de ASP.NET 2.0. Esta funcionalidad se basa en la compatibilidad de SQL Server Express para generar procesos de servidor que se ejecuten con la identidad tanto de un usuario interactivo como de un proceso de trabajo que aloja ASP.NET. En entornos en los que no se confíe, como un servidor de alojamiento compartido, la capacidad de generar procesos de trabajo de SQL Server no debería estar habilitada debido a la posibilidad no intencionada de que se haga un uso compartido de los datos entre aplicaciones ASP.NET.

Para resolver este problema

Si instala SQL Server Express utilizando el instalador independiente, podrá usar las opciones de configuración avanzadas para deshabilitar explícitamente la compatibilidad con la creación de instancias de usuarios.

También podrá deshabilitar de forma manual la creación de instancias de usuario en una instalación existente de SQL Server Express de la manera siguiente:

1.

Cuando se inicie sesión como administrador local, abra una ventana de comandos ejecutando el archivo cmd.exe

2.

Si el archivo osql.exe no estuviera disponible en ningún directorio de los contenidos en la variable de entorno PATH, cambie los directorios al directorio de SQL Server Express que sí contiene el archivo osql.exe.

3.

Conéctese a la instancia principal de SQL Server: osql –E –S .\sqlexpress

4.

Emita los siguientes comandos de SQL:

exec sp_configure 'mostrar la opción avanzada', '1' 
go
reconfigure with override
go
exec sp_configure 'instancias de usuario habilitadas', 0
     go
reconfigure with override
go

6.3 Las cookies persistentes para la autenticación de formularios utilizan ahora la misma configuración de tiempo de espera que las cookies basadas en sesión

En versiones anteriores de ASP.NET, las cookies persistentes de autenticación de formularios tenían un período de duración incluido en código de 50 años. En ASP.NET 2.0 las cookies persistentes de autenticación de formularios tienen su fecha de caducidad establecida como la fecha actual más el valor del atributo "timeout" de la configuración. De manera predeterminada, esto significa que las cookies persistentes tendrán un período de duración de 30 minutos. Si desea establecer un período de duración más largo, deberá incrementar el valor del atributo "timeout". En ASP.NET 2.0 esto significa que los vales de autenticación de formularios almacenados en las cookies persistentes y en las basadas en sesiones utilizarán el nuevo valor de período de duración

Para resolver este problema

Si se quiere que las cookies persistentes tengan otros valores de período de duración, el desarrollador puede obtener una referencia para la cookie de autenticación de formularios tras haber establecido primero la cookie con un método como FormsAuthentication.SetAuthCookie. El desarrollador puede obtener una referencia a la cookie con una llamada a:
Response.Cookies[FormsAuthentication.FormsCookieName]. En la HttpCookie resultante, el desarrollador puede establecer que la propiedad de caducidad tenga otro valor.

6.4 Comportamiento incorrecto del método DeleteRole en AuthorizationStoreRoleProvider

El método DeleteRole del proveedor produce una excepción de forma incorrecta indicando "Elemento no encontrado" si se intenta eliminar una función que no existe. En su lugar, el proveedor debería devolver false. También, si se produce un intento de eliminar una función que contiene usuarios existentes, el proveedor devolverá false en lugar de producir una excepción.

Para resolver este problema

Incluya todas las llamadas al método DeleteRole del proveedor dentro de un bloque try-catch. De esta manera se garantiza que ninguna corrección posterior tenga impacto en el código existente cuando vuelva a habilitar las excepciones al eliminar funciones llenas.

Mire si existe la función antes de intentar eliminarla.

6.5 La característica de perfiles de ASP.NET puede sufrir un error al utilizar la serialización Xml y una identidad de aplicaciones no predeterminada

El mecanismo de serialización de propiedades predeterminado para la característica de perfiles de ASP.NET es la serialización Xml. Si la identidad del proceso ASP.NET es algo distinta de ASPNET (en IIS 5.0 e IIS 5.1) o NETWORK SERVICE (para IIS 6), entonces el proceso de serialización Xml sufrirá un error con una excepción que indique "InvalidOperationException: No se puede generar una clase temporal". Si se utiliza la suplantación de aplicaciones, se dará el mismo problema. Estas excepciones se producen porque XmlSerializer escribe archivos de clase temporales en el directorio %windir%\temp. De manera predeterminada, este directorio sólo concede permisos "Listar carpeta/Leer datos" a las cuentas de ASP.NET predeterminadas. Las cuentas de ASP.NET no predeterminadas pueden escribir archivos temporales en este directorio, pero no tienen el privilegio necesario para buscar después las clases temporales con el fin de que sean utilizadas por XmlSerializer.

Para resolver este problema

En entornos seguros, los desarrolladores deberían utilizar un mecanismo de serialización diferente: serialización binaria o de cadenas. En aplicaciones en las que la posibilidad de que se compartan temporalmente archivos de clase de forma accidental no sea alta, el proceso de trabajo o la identidad de suplantación de la aplicación puede ser garantizada por el privilegio "Listar carpeta/Leer datos" del directorio %windir%\temp.

6.6 Limitaciones del estado de sesión de ASP.NET al utilizar SSE

SSE sólo se debería utilizar en entornos de desarrollo con el estado de sesión basado en Sql Server de ASP.NET ya que con SSE no hay instalado ningún servicio del agente de Sql Server. Como resultado, el trabajo de limpieza del estado de sesión no se ejecuta nunca y los datos del estado de sesión se acumularán en la base de datos. Se pueden eliminar las sesiones caducadas de forma manual conectándose a SSE y ejecutando el comando siguiente: "EXECUTE DeleteExpiredSessions".

Para resolver este problema

Utilice una de las versiones estándar de SQL Server 2005 para las aplicaciones de producción.

6.7 AuthorizationStoreRoleProvider: el valor predeterminado de ApplicationName origina un error del Administrador de autorizaciones

El Administrador de autorizaciones no admite el carácter "/" en los nombres de aplicación. Si applicationName no se establece en la configuración, AuthorizationStoreRoleProvider sigue la misma lógica utilizada por otros proveedores de ASP.NET a fin de determinar un valor predeterminado para applicationName. Al ejecutarse en ASP.NET, el resultado es un valor que comienza por el carácter "/".

Para resolver este problema

Establezca siempre el atributo applicationName en la configuración cuando utilice AuthorizationStoreRoleProvider en una aplicación ASP.NET.

6.8 System.Net ha quitado la lógica para establecer el tiempo de espera de una resolución DNS cuando el tiempo de espera es inferior al tiempo de espera de la API sin administrar a la que llama System.Net para llevar a cabo la resolución

En versiones anteriores de .NET Framework, DNS de System.Net agregaba lógica de tiempo de espera al tipo Dns para evitar tiempos de espera nativos prolongados. Sin un tiempo de espera DNS preciso, no es posible establecer tiempos de espera precisos para otras solicitudes Web. Sin embargo, para implementar este tiempo de espera, la resolución DNS se descarga en otro subproceso. Si el nivel de grupos de subprocesos es bajo, la resolución DNS puede esperar a un subproceso disponible hasta que se supere el tiempo de espera, lo que hará que se produzca una excepción. Para evitar esta excepción, se ha quitado la lógica de tiempo de espera de DNS.

Para resolver este problema

Este problema no tiene una solución conocida.

6.9 SqlCacheDependency requiere que se inicialice con una llamada a System.Data.SqlClient.SqlDependency.Start

Debido a cambios en el modo en que funcionan las notificaciones de consultas en SQL Server 2005, los desarrolladores deben llamar al método Start de SqlDependency, al menos en una ocasión, antes de utilizar SqlCacheDependency. Un lugar lógico para llamar a Start es dentro de un método Application_Start de una aplicación Web situado en global.asax:

void Application_Start(object sender, EventArgs e) 
{
System.Data.SqlClient.SqlDependency.Start("cadena de conexión");
}

La cadena de conexión debe ser la misma que la que se utilizará al emitir comandos para utilizarlos con SqlCacheDependency.

6.10 System.Net ya no agrega un carácter CRLF al llamar a WebClient.UploadValues()

En versiones anteriores de .NET Framework, las llamadas a WebClient.UploadValues() habrían agregado un carácter CRLF al contenido descargado, lo que daría por resultado errores de aplicaciones de servidor. Los caracteres CRLF infringen el esquema de codificación de los tipos de contenido application/x-www-form-urlencoded, tal y como se describe en la especificación HTML 4.01. Ya no se agregan caracteres CRLF.

Para resolver este problema

Use WebClient.UploadData() para agregar el carácter CRLF y vuelva a compilar la aplicación, o repare la aplicación de servidor para que no espere el carácter CRLF

6.11 UriBuilder ya no elimina las propiedades Fragment o Query una vez establecidas

UriBuilder es un tipo que permite generar instancias Uri fragmento a fragmento. En versiones anteriores de .NET Framework, no se podían establecer al mismo tiempo las propiedades Query y Fragment. Este error se ha solucionado en la versión 2.0. Las propiedades Query y Fragment se establecen ahora sin que desaparezca ningún campo de forma inadvertida. Las aplicaciones que han solucionado el comportamiento anterior puede que tengan que ajustar su lógica para evitar comportamientos erróneos.

Para resolver este problema

Este problema no tiene una solución conocida.

6.12 Los permisos solicitados antes de aplicar los valores presentes en el elemento system.net de un archivo de configuración de aplicación han cambiado

Los permisos necesarios para aplicar los valores presentes en el elemento System.Net de un archivo de configuración de aplicación han cambiado desde las versiones anteriores de .Net Framework. Los permisos necesarios para aplicar valores desde el archivo de configuración son ahora los mismos que los que necesita la propiedad asociada al cambiar el valor en el código.

Para resolver este problema

Este problema no tiene una solución conocida.

6.13 Si se envía una solicitud FTP seguida de una solicitud FTP mediante SSL (FTP) al mismo directorio, se produce una excepción del tipo "no se puede encontrar el archivo"

Si una aplicación emite una solicitud FTP a un servidor y, a continuación, emite otra solicitud FTP con SSL habilitado al mismo servidor y ruta, la segunda solicitud fallará. Se producirá una excepción de archivo no encontrado. Sin embargo, si la segunda solicitud no está dirigida a la misma ruta, la solicitud se procesará correctamente.

6.14 WebRequest.ServicePoint.Address solicita permiso Web sin restringir sólo cuando el punto de servicio en cuestión es un servidor proxy

Esta nueva solicitud impide que las aplicaciones que se ejecutan con confianza parcial descubran direcciones proxy de red. Las aplicaciones en las que se confía parcialmente y que utilizan la API ServicePoint.Address pueden producir una excepción SecurityException si la dirección apunta a un servidor proxy.

Para resolver este problema

Utilice HttpWebRequest.Address

6.15 System.Net registra ahora una implementación FtpWebRequest predeterminada que puede hacer que las aplicaciones que utilizan su propio componente FTP se dañen

Antes de .NET Framework versión 2.0, las aplicaciones podían registrar componentes para controlar solicitudes FTP utilizando el marco de trabajo del protocolo conectable y extensible de System.Net. Los componentes para controlar diferentes solicitudes Web se registran asociando el componente a un prefijo URI determinado. Cualquier solicitud Web que coincida con el prefijo es controlada por dicho componente. En .NET Framework 2.0, System.Net admite ahora un componente FtpWebRequest registrado de forma predeterminada para el prefijo ftp:". Todas las aplicaciones cuyo código utiliza este prefijo (anteriores a esta edición) podrían no funcionar porque el prefijo (FTP) ya está incluido.

Para resolver este problema

Actualice el archivo de configuración de la aplicación para quitar el componente del protocolo FTP predeterminado antes de registrar su propio componente FTP:

<system.net>
<webRequestModules>
<remove prefix = "ftp:" />
</webRequestModules>
</system.net>

6.16 En .NET Framework 2.0, GlobalProxySelection.Select se comporta de manera diferente que en la versión 1.1 cuando hay una etiqueta System.Net vacía en el archivo machine.config

En la versión 1.1 de .NET Framework, si se especifica un elemento System.Net vacío en el archivo machine.config, GlobalProxySelection.Select devuelve una instancia proxy de Web vacía que indica que no se utilizará ningún proxy. En la versión 2.0, el funcionamiento predeterminado es que en este caso, al igual que en Internet Explorer, se utilizará la configuración proxy del sistema.

Para resolver este problema

Modifique el archivo machine.config para deshabilitar el proxy predeterminado tal como se muestra a continuación.

<system.net>
<defaultProxy enabled="false" />
</system.net>

6.17 System.Uri no incluye el identificador de ámbito IPv6 con el host

En versiones anteriores de .NET Framework, si se creaba una instancia Uri utilizando una dirección IPv6, el id. de ámbito se incluía siempre con la dirección host. El id. de ámbito hace referencia al índice de un adaptador de red local y no tiene ningún significado para un host remoto. El id. de ámbito también utiliza un carácter '%' en su sintaxis, que entra en conflicto con el formato de escape Uri de '%hh'. Si se incluye el id. de ámbito en el host, se interrumpe la capacidad de System.Uri para interactuar con otros analizadores y solucionadores URI. En la versión 2.0, System.Uri ya no incluye el id. de ámbito con un host IPv6 en una instancia Uri. System.Uri también ha agregado una nueva propiedad, DnsSafeHost, que devolverá el id. de ámbito con una dirección de host IPv6.

Para resolver este problema

Utilice Uri.DnsSafeHost que devolverá el id. de ámbito con una dirección de host IPv6

6.18 Si se especifica un clúster como proxy remoto mediante la configuración System.Transactions, se puede producir una excepción TransactionException durante la conmutación por error del clúster

Si se especifica un clúster como proxy remoto en la configuración estableciendo DistributedTransactionManagerName como clúster, se producirá una excepción TransactionException durante la conmutación por error del clúster.

Para resolver este problema

Para especificar un clúster como proxy remoto, utilice el Complemento MMC de Servicios de componentes con el fin de configurar MSDTC para utilizar el clúster como MSDTC remoto.

6.19 Excepción NullReferenceException producida al intentar obtener las transacciones DistributedIdentifier durante la promoción de transacciones

Si se intenta obtener el identificador DistributedIdentifier en una transacción mientras ésta se está promocionando, puede hacer que se produzca una excepción NullReferenceException.

Para resolver este problema

Existen dos formas de resolver este problema:

Asegúrese de que el acceso a la transacción está sincronizado
O bien
Asegúrese de que se ha promovido la transacción antes de seleccionar la propiedad DistributedIdentifier.

6.20 Los servidores proxy del Servicio Web ASP.NET generados con Agregar referencia Web utilizarán la misma dirección URL tomada del archivo de configuración aunque el servicio tenga varios extremos con direcciones URL diferentes

Cuando se agrega una referencia Web en Visual Studio 2005, la dirección URL del servicio se tomará automáticamente de la sección AppSettings en el archivo de configuración. Si el servicio Web tiene múltiples extremos con diferentes direcciones URL, se generarán varios tipos de proxy, pero todos utilizarán el mismo valor de URL tomado del archivo de configuración.

Para resolver este problema

Hay dos posibilidades:

. Editar el documento wsdl y dividir cada servicio en un documento diferente
O bien
Editar el archivo de configuración para agregar una clave por cada servicio Web y, a continuación, leer los valores del código utilizando System.Configuration.ConfigurationSettings.AppSettings. Establecer la propiedad URL en las instancias de proxy utilizando esos valores.

6.21 La compatibilidad con el atributo Nullable<T> de forma predeterminada en servidores proxy del Servicio Web ASP.NET generados puede interrumpir el código existente cuando se está volviendo a generar el proxy

Al importar un esquema que contiene el atributo nullable="true" para un Servicio Web ASP.NET, el proxy generado contendrá los tipos Nullable<T>, mientras que anteriormente el atributo se omitía. Este cambio puede ocasionar interrupciones en tiempo de diseño o de ejecución en las aplicaciones.

Para resolver este problema

Entre las posibles soluciones se incluye evitar volver a generar los tipos de proxy, para volver a compilar el código utilizando el nuevo modelo Nullable<T>, o cambiar el esquema para que no se utilice el atributo nullable="true".

6.22 Si se establece la propiedad Proxy como null en una instancia proxy de servicio Web, la solicitud no irá directamente al servidor

El establecimiento de la propiedad Proxy como null en una instancia proxy de servicio Web debe provocar que la solicitud omita cualquier configuración de servidor proxy Web y vaya directamente al servidor. Sin embargo, esta funcionalidad no funciona actualmente. El valor null se omitirá y en su lugar se utilizará cualquier valor de configuración de servidor proxy Web configurado.

Para resolver este problema

Se puede establecer la propiedad Proxy en la solicitud WebRequest subyacente directamente derivándola del tipo de proxy y reemplazando el método GetWebRequest:

protected override WebRequest GetWebRequest(Uri uri)
{
WebRequest req = base.GetWebRequest(uri);
req.Proxy = this.proxy;
return req;
}

6.23 Utilizar la serialización en tiempo de ejecución y .NET Remoting en diferentes versiones de .NET Framework

Cuando se intercambian datos entre una aplicación que se está ejecutando en una versión de .NET Framework y una aplicación que se está ejecutando en otra versión (con la serialización en tiempo de ejecución y .NET Remoting), pueden producirse excepciones al serializar o deserializar ciertos tipos de Framework. Estas excepciones indican que esos tipos no son compatibles entre las diferentes versiones de Framework; es decir, es imposible enviarlos de una versión de Framework a otra.

.NET Framework 2.0 incluye una tecnología denominada Version Tolerant Serialization que compatibiliza versiones y elimina este problema. Sin embargo, las versiones anteriores de Framework se enfrentaban a este problema. Por tanto, habrá una revisión disponible que agregue a .NET Framework 1.1 algunas características de la serialización que compatibiliza versiones. Esta revisión requerirá el Service Pack 1. Tras instalarla, las aplicaciones que se ejecuten en los Framework revisados podrán comunicarse con aplicaciones que se ejecuten en .NET Framework 2.0 sin tener este problema de versiones. No hay planes de implementar dicha revisión en .NET Framework 1.0.

Es importante tener en cuenta que la serialización que compatibiliza versiones sólo está destinada al control de versiones cuando se utiliza la serialización binaria, tanto de manera directa como a través de .NET Remoting. Cuando se utiliza la serialización SOAP (tanto directamente como a través de la clase SoapFormatter o .NET Remoting) entre diferentes versiones de Framework, es posible que se sigan produciendo los problemas de control de versiones tratados anteriormente.

Para resolver este problema

Para obtener esta revisión, consulte el artículo siguiente de Knowledge Base: http://support.microsoft.com/?kbid=907262.

6.24 Al especificar un agente de escucha de seguimiento no predeterminado para el seguimiento System.Transactions no funciona con la confianza parcial

La especificación de un agente de escucha de seguimiento determinado para el seguimiento System.Transactions en la configuración no es compatible con la confianza parcial y hará que se produzca una excepción.

Para resolver este problema

El agente de escucha de seguimiento predeterminado es compatible con la confianza parcial de modo que, si no se especifica ningún agente de escucha en la configuración, los seguimientos serán interceptados por el agente de escucha predeterminado e impresos en debug.outputstring. Estos seguimientos se pueden ver con confianza parcial utilizando DBMon.exe.

6.25 Los cálculos de fecha y hora en los escenarios de los servicios Web o de serialización XML pueden ser incorrectos después de migrar a .NET Framework 2.0

NET Framework 2.0 cambia el modo en que se escriben y se leen la fecha y la hora en XML. Este cambio afecta principalmente a los siguientes escenarios:

Utilización de horas sin especificar zonas horarias o utilización de horas de la zona horaria UTC

Escenarios de interoperabilidad con software de terceros que escribe valores de hora en XML sin especificar una zona horaria o que especifica una zona horaria UTC

Estos cambios pueden hacer que resulten incorrectos ciertos cálculos de fechas y horas, y comparaciones. En estos casos, puede ser necesario volver al comportamiento de fecha y hora anterior.

Para resolver este problema

Para volver al comportamiento de fecha y hora anterior, aplique el cambio de configuración siguiente:

<system.xml.serialization>
<dateTimeSerialization mode="Local" />
</system.xml.serialization>

6.26 Perfiles de usuario de Windows para la creación automática de bases de datos de ASP.NET con SQL Server Express e IIS

El proceso de creación automática de archivos MDF de ASP.NET para proveedores de SQL Server utilizando SQL Server Express e IIS sólo funciona cuando IIS se ejecuta como cuenta de un equipo ASPNET local o como NT AUTHORITY\NETWORK SERVICE. El proceso de creación automática también funciona cuando un desarrollador realiza su trabajo de forma interactiva con Cassini (por ejemplo, sitios Web basados en archivos). Sin embargo, al desarrollar en IIS utilizando una cuenta de usuario de dominio o una cuenta de equipo local diferente, no se podrá realizar el proceso de creación automática de bases de datos dado que dichas cuentas no tienen disponible ningún perfil de usuario de Windows en el servidor Web.

Para resolver este problema

Este problema no se puede solucionar. La creación automática de bases de datos con SSE para sitios Web basados en IIS sólo funcionará con cuentas de ASPNET y de NETWORK SERVICE.

6.27 Comportamiento de caracteres suplentes de Unicode con proveedores de ASP.NET que utilizan un servidor SQL Server 7.0 o 2000

Los proveedores de ASP.NET que utilizan un servidor SQL Server están limitados al nivel de compatibilidad de caracteres suplentes de Unicode proporcionado por SQL Server 7.0 y SQL Server 2000. SQL Server 7.0 y 2000 almacenan y recuperan pares de caracteres suplentes sin pérdidas. Sin embargo, no hay una comparación lingüística para los caracteres suplentes. Dichos caracteres se omiten durante las operaciones de comparación y las comprobaciones de unicidad al utilizar estas versiones de SQL Server. Por ejemplo, esto significa que SqlMembershipProvider considerará dos nombres de usuario que sólo incluyan caracteres suplentes idénticos. Este comportamiento llevará a la infracción de restricciones de unicidad si se intenta crear un segundo usuario con un nombre que difiera del nombre de usuario existente sólo en caracteres suplentes.

Para resolver este problema

Este problema no tiene una solución conocida.

6.28 FileWebRequest.PreAuthenticate sólo devuelve false

Los tipos que heredan de WebRequest heredan una propiedad PreAuthenticate. Esta propiedad se utiliza para habilitar el envío de información de autenticación junto con la solicitud sin tener que esperar una comprobación del servidor. FileWebRequest no admite la autenticación previa, de tal modo que su propiedad PreAuthenticate debería devolver siempre false. En versiones anteriores de .NET Framework, si una aplicación tenía establecida como true la propiedad PreAuthenticate, devolvería true cuando más tarde se requiriera su valor. Ya no es el caso. La propiedad PreAuthenticate de FileWebRequest devolverá siempre false.

Para resolver este problema

Los usuarios no deben utilizar la propiedad PreAuthenticate en FileWebRequest

6.29 Utilizar tipos genéricos con .NET Remoting y la serialización SOAP

La tecnología de .NET Remoting admite tanto la serialización binaria como SOAP; es decir, los mensajes de acceso remoto pueden ser representados en formato binario específico de Microsoft o como XML de SOAP. Sin embargo, los tipos genéricos (que son una característica nueva en .NET Framework 2.0) sólo se pueden utilizar con la serialización binaria. No se admite el uso de genéricos con la serialización SOAP, tampoco mediante .NET Remoting ni con el uso de la clase SoapFormatter directamente.

Para resolver este problema

Este problema no tiene una solución conocida.

6.30 Las características de control de versiones no funcionan en algunas ocasiones cuando se utilizan tipos genéricos con .NET Remoting o la serialización binaria

Tanto .NET Remoting como la serialización binaria pueden funcionar en modo de correspondencia imprecisa (que se selecciona estableciendo FormatterAssemblyStyle en Simple, includeVersions en False y strictBinding en False), donde la versión del ensamblado de un tipo serializado no tiene que coincidir con la versión del ensamblado desde la que se cargó el tipo en la deserialización. Esta característica tiene por misión facilitar el control de versiones. Por ejemplo, un servidor de .NET Remoting se puede actualizar sin tener que actualizar los clientes.

Sin embargo, hay ocasiones en que este mecanismo no funciona. Concretamente, cuando se utilizan tipos genéricos, si cambia la versión del ensamblado de los tipos de parámetros genéricos, es posible que la deserialización no funcione incluso en modo de correspondencia imprecisa. Por ejemplo: cuando se deserializa MyType1, con un parámetro de tipo MyType2, si la versión del ensamblado que contiene MyType2 es diferente en la deserialización de cómo era en la serialización, puede que la deserialización no funcione.

Para resolver este problema

Para solucionar esta limitación, se debe evitar el uso de tipos genéricos tanto en .NET Remoting como en la serialización binaria si el escenario del control de versiones es importante, o utilizar la característica de redirección del enlace de ensamblados de .NET Framework para redirigir la solicitud de carga de una versión no existente a una versión existente en el equipo que realiza la deserialización. Otra solución posible consiste en utilizar el evento AssemblyResolve para detectar el momento en que la carga del ensamblado no funciona y volver a intentar la carga del ensamblado utilizando sólo su nombre parcial.

Principio de la páginaPrincipio de la página

7. MSDN Express

No hay problemas conocidos actualmente.

Principio de la páginaPrincipio de la página

8. Entorno de desarrollo integrado de Visual Studio

No hay problemas conocidos actualmente.

Principio de la páginaPrincipio de la página

9. Visual Web Developer Express

9.1 Cuando se llevan a cabo operaciones de refactorización en un sitio Web de C#, puede que se informe de errores de generación sin que realmente exista ninguno

En algunos casos, cuando se ejecuta un comando de refactorización en un sitio Web de C# que no contiene ningún error de generación, el usuario puede recibir una advertencia en la que se le indique que el proyecto o una de sus dependencias no se genera actualmente, y que no se pueden actualizar las referencias.
Este cuadro de diálogo se puede pasar por alto sin riesgo, haciendo clic en los botones Continuar o Anterior. La refactorización se realizará satisfactoriamente y se actualizarán todas las referencias.

A continuación se muestran ejemplos de configuraciones de proyectos comunes en las que se mostrará esta advertencia:

Los proyectos Web migrados de versiones anteriores de Visual Studio, que contienen un archivo global.asax en el directorio Web y uno global.asax.cs en el directorio App_Code.

Los proyectos Web en los que las páginas Web hacen referencia a controles de usuario Web que, a su vez, hacen referencia a tipos declarados en el directorio App_Code.

Para resolver este problema

Este problema no tiene una solución conocida. Sin embargo, la advertencia se puede pasar por alto sin ningún problema.

9.2 Los métodos abreviados de los fragmentos de código de C# no pueden contener marcas sin espacio

Los fragmentos de código de C# están definidos en XML dentro de los archivos .snippet. Una de las posibles etiquetas en el esquema es <Shortcut></Shortcut>. Los métodos abreviados se pueden utilizar para insertar un fragmento de código rápidamente. Para ello, el usuario sólo necesita escribir la cadena del método abreviado y, a continuación, presionar la tecla TABULADOR.

En las cadenas de métodos abreviados se pueden utilizar muchos caracteres Unicode, pero no se admiten marcas sin espacio. Esto significa que algunas cadenas de ciertos idiomas no se pueden utilizar como métodos abreviados. Si un método abreviado no contiene ninguna marca sin espacio, al escribir la cadena del método abreviado y presionar la tecla TABULADOR se insertará un carácter de tabulador pero no se insertará el fragmento de código.

Para resolver este problema

1.

Elija un nombre de método abreviado Unicode que no contenga ninguna marca sin espacio.

2.

Inserte el fragmento de código mediante la interfaz de usuario del Selector de fragmentos de código en lugar de utilizar métodos abreviados.

9.3 Al expandir archivos de datos en el Explorador de servidores en sitios Web de FTP puede bloquearse el entorno integrado de desarrollo (IDE)

Si abre un sitio Web de FTP y agrega un archivo de datos (MDB o MDF) al directorio App_Data y luego abre la ventana del Explorador de servidores y expande la conexión al archivo de datos situada debajo del nodo Conexiones de datos, el entorno IDE puede bloquearse y es posible que se pierdan los datos no guardados.

Para resolver este problema

Desarrolle el sitio Web desde una ubicación de archivos local utilizando un sistema de archivos o un sitio Web de IIS y utilice el comando Copiar sitio Web para transferir archivos a y desde la ubicación FTP.

9.4 La utilización de los tipos definidos por el usuario como configuraciones puede ocasionar comportamientos inesperados en el Diseñador de configuración

La utilización de tipos definidos por el usuario como configuraciones puede ocasionar problemas si el ensamblado en el que reside el UDT se actualiza mientras el proyecto que se está usando está abierto. Si se da este escenario, puede solucionar el problema haciendo que el ensamblado del tipo definido por el usuario tenga en cuenta el incremento de versión.

Para resolver este problema

Si el tipo definido por el usuario que se está utilizando como configuración reside en una biblioteca de clases, cree una versión incrementada de la biblioteca para mitigar el problema. Si el tipo definido por el usuario reside en un archivo EXE, se debe cerrar y reiniciar el IDE para que los cambios efectuados en el UDT surtan efecto


Principio de la páginaPrincipio de la página