martes, 9 de marzo de 2010

Visual Studio 2008 vshost.exe has encountered a problem and needs to close

Este es un problema que me ha sucedido recurrentemente y como después de un tiempo tiende al olvidarse uno se rompe la cabeza reinstalando cosas y buscando posibles causas en la red, por ello he decidido dejarlo documentado.

Contexto

Se instala Visual Studio 2008 en diferentes ediciones e idiomas.

  1. Instalé Visual Studio 2008 Professional Edition en inglés.
  2. Instalé Visual Studio 2008 Express en español (todos los productos de caja).
  3. Instalé el Service Pack 1 para cada idioma (no es determinante para que ocurra el problema descrito).

Situación

Al terminar la instalación, e independientemente del Service Pack 1, el IDE de Visual Studio 2008 Professional queda configurado en una mezcla de español e inglés que es visible en el IDE.

Como se ve en la figura, a pesar de que el producto de VS2008 Professional es en inglés, el IDE ha cambiado su configuración al español.

image 

Problema

Al abrir un proyecto existente con Visual Studio 2008 Professional o Visual C# (ó VB) 2008 Express, a los pocos segundos, el IDE falla y muestra una ventana con el problema mencionado.

image

El problema sucede al abrir o crear un proyecto específico, no al abrir el IDE solamente.

No es posible depurar (hacer debugging) el proyecto en el que se quiere trabajar.

image

Solución

El problema NO se resuelve reparando instalaciones o volviendo a instalar los productos.

IDE en inglés

La solución consiste en cambiar simplemente el idioma de VS2008 Professional a su idioma de instalación.

Así queda después de la instalación referida.

image

Simplemente abra el IDE sin crear o abrir ningún proyecto y cambie la configuración al idioma original de instalación. Así debe quedar:

image

Presione aceptar y reinicie el IDE

image

Listo el IDE funciona ahora normalmente.

La causa no es evidente pero, el cambio de idioma como solución, indica que el IDE falla por no poder tener acceso a algún recurso que espera con ciertas características específicas o en una ubicación específica.

image

image

Etiquetas de Technorati: ,,

miércoles, 24 de febrero de 2010

The specified named connection is either not found in the configuration (Visual Studio 2010 RC)

En versiones anteriores de Visual Studio, como la 2008, había probado la lectura de la configuración (x.config) de una aplicación desde una capa intermedia sin mayor problema.

Por ejemplo una capa de datos que tuviera un ConnectionString (digamos por omisión) en su propio archivo de configuración. Se tendría entonces:

DAL.dll y DAL.dll.config con la conexión al origen de datos.

En tal caso, con las versiones previas, no había ningún problema y sólo si un cliente (Windows, Web) requería redefinir esta conexión entonces simplemente se redefinía la misma, en el archivo de configuración correspondiente al cliente y listo.

Al realizar un ejercicio similar con Visual Studio 2010 RC (entiendo que con el beta pasa lo mismo) y ADO.NET Entity Framework no me era posible conectarme al origen de datos con el siguiente error (o BUG):

System.ArgumentException: The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.

image

El problema sucede en el constructor predeterminado del contexto de mis entidades. En este constructor, al no especificar la conexión, se espera que la misma se lea justamente desde la configuración.

Intenté redefinir la conexión en el archivo de configuración de mi consola y el mismo error sucedía.

La solución la encontré en este foro y es básicamente darle vuelta haciendo dos cosas:

  1. Copiar la cadena de conexión al archivo de configuración de su aplicación cliente o consumidora (Windows, Web). Esto no es opcional.
  2. tomar la conexión del proveedor de System.Data.EntityClient y en la cadena de conexión (connectionString) buscar la parte que se refiere al proveedor su base de datos y cambiar las entidades XML “"” por una comilla simple (‘). Esto es evidentemente un BUG.

Colocar las comillas simples en el archivo de configuración de la capa intermedia tampoco funciona.

Luego de estos dos cambios me funcionó bien. Espero que sea un BUG y no un cambio de paradigma.

Etiquetas de Technorati: ,,

sábado, 3 de octubre de 2009

BUG Warehouse. CSPS. La cadena vacía '' no es un nombre válido (The empty string ‘’ is not a valid name)

CSPS: Contexto, Situación, Problema, Solución
Bug: Defecto

Contexto
  • Microsoft Visual Studio 2008, NET Framewotk 3.5 SP1
  • Servicio Web ASMX existente expuesto mediante SOAP y HTTPS.
  • Cliente del servicio mediante protocolo SOAP.
Situación
  • Se tiene un servicio Web asmx operativo y conforme con Basic Profile Version 1.1 expuesto a través del protocolo SOAP.
  • Se toma una aplicación cliente cualesquiera (por ejemplo una consola) y se adiciona un referencia de servicio (Service Reference). Las referencias a servicios funcionan tanto con servicios de WCF o bien con servicios heredados tipo asmx. Se hace notar que también podría ser una referencia web (Web Reference) heredada de NET Framework 2.0 (asmx) y se produce el mismo comportamiento.
Problema

Al ejecutar el cliente se obtiene el siguiente mensaje de error:

   1: System.ServiceModel.FaultException was unhandled



   2:  



   3: Message="System.Web.Services.Protocols.SoapException: El servidor no puede procesar la solicitud. ---> System.ArgumentException: La cadena vacía '' no es un nombre válido.\n en System.Xml.XmlTextWriter.ValidateName(String name, Boolean NCName)\n en System.Xml.XmlTextWriter.InternalWriteName(String name, Boolean NCName)\n en System.Xml.XmlTextWriter.WriteQualifiedName(String localName, String ns)\n en System.Web.Services.Protocols.Soap11ServerProtocolHelper.WriteFault(XmlWriter writer, SoapException soapException, HttpStatusCode statusCode)\n en System.Web.Services.Protocols.SoapServerProtocol.WriteException(Exception e, Stream outputStream)\n en System.Web.Services.Protocols.WebServiceHandler.WriteException(Exception e)\n en System.Web.Services.Protocols.WebServiceHandler.Invoke()\n en System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()\n --- Fin del seguimiento de la pila de la excepción interna ---"



   4:  



   5: Source="mscorlib"



   6:  



   7: StackTrace:



   8:  



   9: Server stack trace: 



  10:  



  11: en System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)



  12: ...



  13: Exception rethrown at [0]: 



  14:  



  15: en System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)



  16:  



  17: en System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)



  18: ...



  19: en ....MyApp.MyMethod(UploadCollectionFileRequest request) en C:\...\Reference.cs:línea 357



  20: ...




El error no dice mucho y tampoco contiene información detallada de dónde ha sucedido como para hacer un seguimiento del código fuente. En la línea 19 se muestra un texto de ejemplo del detalle máximo referente al código, donde sólo se observa que hay algún problema con el “request” que se ha creado en nuestra referencia de servicio “Reference.cs”.



Solución


Si observamos la primera parte el problema se refiere a la dificultad de escribir el resultado de una serialización XML de forma correcta, debido a que hay un nombre inválido (vacío).



Al revisar el código fuente del Servicio Web se encontró que el servicio capturaba cualquier excepción y la convertía en una SoapException personalizada con las siguientes características:



try
{
//----------------------------------------------------------
// Custom code that throws an exception...
//----------------------------------------------------------

}
catch (Exception ex)
{
throw new SoapException("Mi descripción personalizada del error.", XmlQualifiedName.Empty, ex);
}
finally
{
// ...


}



Como se observa al preparar la excepción SOAP el parámetro XmlQualifiedName se está pasando con el valor “Empty”, lo que provoca que al intentar serializar la excepción esta no pueda procesarse.



Si bien es cierto que usted podría colocar cualquier nombre calificado, en vez de XmlQualifiedName.Empty y podría evitar este bug referido, por ejemplo, new XmlQualifiedName("Mi nombre para el código de excepción SOAP"), lo recomendable es respetar el estándar para el protocolo, ya que el parámetro del constructor de SoapException que acepta un XmlQualifiedName se llama “code” y se refiere al tipo de código de error de SOAP, por lo tanto el deber ser es, elegir alguno de los códigos disponibles, conocidos como códigos de error SOAP para la versión 1.1 del protocolo SOAP. En nuestro caso así queda la línea de excepción completa:



catch (Exception ex)
{
throw new SoapException("Mi descripción personalizada del error."
, SoapException.ServerFaultCode, ex);
}



Lo anterior resuelve el bug presentado y en su caso permite obtener la excepción subyacente que mostraría el verdadero error que se está produciendo en el servicio web.



---(FIN)---