El tipo no está resuelto para el miembro “X”.

El contexto

Se desarrolla un especialización para IIdentity y se establece un nuevo IPrincipal mediante GenericPrincipal con MVC3.

El síntoma

System.Runtime.Serialization.SerializationException was unhandled by user code
  Message= Type is not resolved for member 'X'.
  Source=WebDev.WebHost40

Todo bien antes de autentificarse.

Ingresar las credenciales

Horror

Causa poco estudiada a detalle

El problema con la serialización logré reproducirlo tanto en un sitio con Telerik (quién reportaba el error y parecía un responsable, pero nada que ver) y con un proyecto nuevo y limpio de MVC3, quién sabe por qué en mi proyecto Web antiguo (MVC2) convertido a MVC3 sí funcionaba bien.

En fin, la causa no está muy bien explicada y tiene que ver con que el Servidor Web de desarrollo de ASP.NET (WebDev.WebHost40) se ejecuta de alguna forma en la que carga el serializador por un lado (GAC) y al intentar aplicar la deserialización no encuentra el ensamblado. Por algún motivo trata de buscar el ensamblado de seguridad personalizado en otros lugares pero no el el directorio bin del propio proyecto de desarrollo.

Existen algunas soluciones alternativas recomendadas en los sitios Web

Referencia 1: Implementing a Custom Identity and IPrincipal in MVC

Referencia 2: Update on my struggles with the ASP.NET Development Server

El problema sólo sucede durante la depuración utilizando en Servidor Web de desarrollo de ASP.NET. Cuando publicas en un sitio Web de IIS no hay problemas en el encontrar el tipo.

• Hay algunas soluciones como copiar los ensamblados relacionados a las carpetas del Net Framework correspondientes bajo Windows, pero a mí no me funcionaron.
• Otra solución con el GAC que en ningún caso adoptaré ni lo recomiendo, además a mi tampoco me funcionó y es como volver al pasado (¡DLL HELL!).
• Otra es personalizar completamente la serialización implementando ISerializable, es relativamente  tedioso aunque fácil, pero requiere pruebas y es absurdo en mi caso, no me gusta.

En conclusión es posible utilizar su API y publicar en los sitios de destino con IIS sin problemas.

Para poder depurar tendría que ejecutar el VS en modo administrador y cambiar el servidor Web para utilizar IIS local en las propiedades de tu proyecto.

Una solución más simple es la siguiente

Abrir en el explorador de Windows la ubicación de su servidor Web de desarrollo (WebDev.WebHost40), en mi caso:

C:\Program Files (x86)\Common Files\microsoft shared\DevServer\10.0

Copiar allí, en la raíz, sus ensamblados que están relacionados y son necesarios para ejecutar su código de seguridad, sólo se requieren los ensamblados con los métodos que se cargarán durante la ejecución de su código de seguridad. No son necesarios otros ensamblados, que aunque estén relacionados en términos de referencias, no se utilicen en la comprobación.

Listo, en mi caso funciona perfecto y sigo utilizando el servidor Web de desarrollo y Visual Studio se puede ejecutar en modo de usuario, no administrador.

Gracias por todas las respuestas anteriores que me permitieron encontrar esta solución.

Saludos,

Etiquetas de Technorati: MVC,IPrincipal,IIdentity,Security,GenericPrincipal

SharePoint. No se puede listar todos los elementos (“AllItems.aspx” ha sido reemplazado)

Al utilizar un sitio de SharePoint Server 2010 me ha sucedido algo que no habría esperado fuera posible hacer.

Origen del problema

Tome un archivo de Excel y guardé el el archivo “como…” y en vez de conectarme paso a paso a la biblioteca de documentos copié la liga completa del sitio Web y hasta una carpeta específica, es decir:

http://[mi server]/[mi sitio]/Shared%20Documents/Forms/AllItems.aspx

Lo que sucedió fue que de alguna manera se reemplazó el archivo AllItems.aspx con mi archivo de Excel. (Lamentablemente traté de reproducirlo nuevamente y no pude)

Esto produjo un error general en la página Web de la biblioteca de documentos en la que sólo aparecía en la pagina un error comentando que AllItems.aspx contenía código prohibido para ejecutarse.

Como SharePoint 2010 guarda los documentos en al base de datos, pues parecía un problema a resolver con SQL y con programación en caso de tener que extraer el contenido de los documentos desde la base de datos con algún stream writer.

Solución simple, reemplazar de nuevo el archivo AllItems.aspx con uno original

Me conecté al mismo sitio por medio del explorador de Windows con WebDav, agregando una ubicación de red.

Esto me permitió explorar el sitio hasta encontrar un archivo AllItems.aspx original, cualquiera de lista de documentos, ya que es una archivo común.

Luego abrí ese archivo con Visual Studio 2010 (o Web Express) y revisé que fuera un aspx y a continuación los guarde “como… “ y anoté en la caja del diálogo la dirección completa que quería volver reemplazar, que es la de la biblioteca de documentos que no podía leer, es decir en mi caso:

http://[mi server]/[mi sitio]/Shared%20Documents/Forms/AllItems.aspx

Me preguntó si quería reemplazar el archivo existe, ..pues sí y…

listo, se corrigió el problema.

Etiquetas de Technorati: SharePoint

No se puede cargar el tipo 'System.ServiceModel.Activation.HttpModule'

Solución probada

Fuente: http://msdn.microsoft.com/es-es/library/aa751852.aspx

No se puede cargar el tipo ‘System.ServiceModel.Activation.HttpModule’ del ensamblado ‘System.ServiceModel, Version 3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’

Este error se produce si se instala .NET Framework 4 y, a continuación, se habilita la activación HTTP de .NET Framework 3,5 WCF. Para resolver el problema ejecute la siguiente línea de comandos desde el símbolo del sistema de Visual Studio 2010:

aspnet_regiis.exe -i –enable

Resultado = OK

Etiquetas de Technorati: Net Framework,WCF,ServiceModel

Sobre configuraciones redundantes

Ns, 2Ns, N+1 y 2(N+1) … Sobre configuraciones redundantes de UPS @ CENTRO DE DATOS NIXVAL

El proveedor 'Microsoft.ACE.OLEDB.12.0' no está registrado en el equipo local

Tengo una aplicación que lee datos de un Excel y me sucedió el siguiente error:

Se detectó System.InvalidOperationException
  Message=El proveedor 'Microsoft.ACE.OLEDB.12.0' no está registrado en el equipo local.
  Source=System.Data

Entre paréntesis, mi cadena de conexión a Excel es:

Code Snippet

1. <add name="AserewareExcelDataSource" connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data Source=FileName.xlsx;Persist Security Info=False;Extended Properties=&quot;Excel 12.0 Xml;HDR=YES;IMEX=1&quot;" providerName="System.Data.OleDb" />

Bueno después de buscar y encontrar este link, donde al parecer no existe un driver adecuado hice lo siguiente.

Mi máquina es de 64bits y tenía esto en el destino de la plataforma, lo que difiere de lo comentado el vínculo de referencia:

Lo cambié a “Any CPU” o bien “x64”:

Y listo,… funcionando perfectamente.

Imagino que instalé la versión de 64 bit del driver..que ya está.

Etiquetas de Technorati: OLEBD,Drivers,Excel,DataSources,Visual Studio 2010

Niveles de disponibilidad

Regularmente ando buscando esta información y no la tenía a la mano…

---

Entonces, ¿qué porcentaje de disponibilidad será el adecuado para una aplicación determinada? A continuación se incluyen algunas pautas:

Categoría	Número de errores anual	Tiempo de inactividad anual	Tiempo medio de reparación	Disponibilidad
No comercial	10	88 horas	10 horas	99.00%
Comercial	5	44 horas	8,8 horas	99.50%
Crítica para la empresa	4	8,5 horas	2,25 horas	99.90%
Crítica para una misión	4	1 hora	0,25 horas	99.99%

Nota Para realizar estos cálculos de disponibilidad se han utilizado 365,25 X 24 = 8.766 horas al año.

fuente: Microsoft MSDN

---

Tal y como se describe en el tema referente a la confiabilidad, se pueden producir errores en las aplicaciones por muchos motivos:

• Comprobación inadecuada
• Problemas relacionados con cambios en la administración
• Falta de control y análisis continuados
• Errores en las operaciones
• Código poco consistente
• Ausencia de procesos de diseño de software de calidad
• Interacción con aplicaciones o servicios externos
• Condiciones de funcionamiento distintas (cambios en el nivel de uso, sobrecargas máximas)
• Sucesos inusuales (errores de seguridad, desbordamientos en la difusión)
• Errores de hardware (discos, controladores, dispositivos de red, servidores, fuentes de alimentación, memoria, CPU).
• Problemas de entorno (red eléctrica, refrigeración, incendios, inundaciones, polvo, catástrofes naturales)

Alrededor de un 40 por ciento del tiempo de inactividad de las aplicaciones se debe a una comprobación inadecuada, a una administración de cambios y a la ausencia de un control continuo de los errores. Otro 40 por ciento se debe a errores operativos producidos por la ausencia de procedimientos rigurosos y a errores de copia de seguridad/restauración. La confiabilidad del hardware ha mejorado durante los últimos años que menos del 10 por ciento del tiempo de inactividad se debe a problemas de hardware. El 10 por ciento restante del tiempo de inactividad se debe a problemas de entorno y a problemas de otro tipo.

En términos generales, se puede decir que la disponibilidad es una medida de la frecuencia con la que se puede utilizar la aplicación. Para ser más exactos, la disponibilidad es un cálculo porcentual del tiempo en que la aplicación está realmente disponible para controlar las solicitudes de servicio en comparación con el tiempo de ejecución total disponible previsto. El cálculo formal de la disponibilidad incluye el tiempo de reparación, ya que una aplicación que se está reparando no está disponible.

En el cálculo de la disponibilidad se utilizan varias medidas:

Nombre	Acrónimo	Cálculo	Definición
Tiempo medio entre errores	MTBF	Horas / número de errores	Duración media de funcionamiento de la aplicación antes de que produzca errores.
Tiempo medio de recuperación	MTTR	Horas de reparación / número de errores	Tiempo medio necesario para reparar y restaurar el servicio después de que se produzca un error.

La fórmula de disponibilidad tiene esta forma:

Disponibilidad = (MTBF / (MTBF + MTTR)) X 100

Considere, por ejemplo, una aplicación concebida para que funcione continuamente. Pongamos un punto de control de 1.000 horas consecutivas, dos errores de una hora durante ese período darían lugar a una disponibilidad de ((1.000/2) / ((1.000/2) + 1)) X 100 = (500 / 501) X 100 = 0,998 X 100 = 99,8 %.

Una forma conocida de describir la disponibilidad es mediante los "nueves": los tres nueves de una disponibilidad de un 99,9%. No obstante, hay que tener en cuenta que las implicaciones de la medición por nueves a veces se malinterpretan. Es necesario realizar algunos cálculos para descubrir que tres nueves (disponibilidad de un 99,9%) representan aproximadamente 8,5 horas de interrupción de servicio en un solo año. El nivel inmediatamente superior, cuatro nueves (99,99%), representa alrededor de una hora de interrupción de servicio en un año. Cinco nueves (99,999%) representan sólo cinco minutos de interrupción al año.

fuente: Microsoft MSDN

Etiquetas de Technorati: Disponibilidad,Distribuidas

Silverlight. WebServices. WCF. Cross-Domain. clientaccesspolicy.xml

Bueno el famoso archivo “clientaccesspolicy.xml” debe colocarse en la raíz de su servidor web, no así en la raíz de un directorio virtual (configurado como aplicación) que usted haya creado.

Si usted tiene una aplicación en un directorio virtual llamado “miaplicación” tal como:

http://midominio/miaplicacion

entonces debe colocar el “clientaccesspolicy.xml” en la raíz:

http://midominio/clientaccesspolicy.xml

Este es el típico archivo predeterminado que permitiría el acceso desde cualquier dominio llamador (claro, esto siempre funcionaría en el supuesto de que sus servicios Web no tengan algún mecanismo de autentificación).

Code Snippet

1. <?xml version="1.0" encoding="utf-8" ?>
2. <access-policy>
3.   <cross-domain-access>
4.     <policy>
5.       <allow-from http-request-headers="SOAPAction">
6.         <domain uri="*"/>
7.       </allow-from>
8.       <grant-to>
9.         <resource path="/" include-subpaths="true"/>
10.       </grant-to>
11.     </policy>
12.   </cross-domain-access>
13. </access-policy>

En cualquier caso si los dominios desde los que se llama son simples alias o entradas en un DNS (CNAME or A records) que apuntan a la misma IP, la seguridad provista por el dominio de su aplicación funcionaría adecuadamente y estaría en el contexto de las llamadas, por lo tanto una llamada a su servicio desde “midominioalias1/miaplicacion/miservicio” o desde “midominioalias2/miaplicacion/miservicio” no debería tener problemas aún cuando haya protegido sus servicios con algún mecanismo de seguridad de acceso como el provisto por ASP.NET. Este otro tema de seguridad se puede ver en Servicios WCF y ASP.NET

Ahora bien para limitar el acceso a su servicio desde dominios conocidos los mejor será eliminar el permisivo “<domain uri="*"/>”  y colocar explícitamente sus dominios en su archivo “clientaccesspolicy.xml”.

En el ejemplo siguiente, con los asteriscos, se aceptan llamadas desde cualquier subdominio de “midominio” y de subdominios de algunos otros dominios específicos (que podrían también ser alias de su propio dominio en un DNS). Podría poner una URL específica que acepta explícitamente, quitando el asterisco y reemplazándolo por “www.midominioalias1.com”.

Code Snippet

1. <?xml version="1.0" encoding="utf-8" ?>
2. <access-policy>
3.   <cross-domain-access>
4.     <policy>
5.       <allow-from http-request-headers="SOAPAction">
6.         <!--<domain uri="*"/>-->
7.         <domain uri="http://midominio.com" />
8.         <domain uri="http://*.midominio.com" />
9.         <domain uri="http://*.midominioalias1.com" />
10.         <domain uri="http://*.midominio2.com" />
11.       </allow-from>
12.       <grant-to>
13.         <resource path="/" include-subpaths="true"/>
14.       </grant-to>
15.     </policy>
16.   </cross-domain-access>
17. </access-policy>

Dado que este archivo reside en la raíz de su sitio web, tal como está el “path” significa que podría llamar a cualquier servicio web que esté ubicado donde quiera bajo este punto de partida. Si necesita limitar el acceso a cierta ubicación debe colocar el “path”, por ejemplo: “path=”/miaplicacion/misservicios”. Vea Restricciones de seguridad de acceso a redes en Silverlight

Etiquetas de Technorati: Silverlight,WCF,WebServices,CrossDomain

No olvidar El mensaje "Código de error: 0x80070002" cita un problema en la comprobación de la licencia después de una actualización en un equipo Dell

[Window Title]
Copias de seguridad de Windows: opciones para solucionar problemas

[Main Instruction]
Comprobar copia de seguridad

[Content]
El sistema no puede encontrar el archivo especificado.


[V] Mostrar detalles [Intentar ejecutar de nuevo la copia de seguridad] [Cambiar configuración de copia de seguridad] [Cancelar]

[Expanded Information]
Hora de copia de seguridad: 04/02/2011 06:28 p.m.
Ubicación de copia de seguridad: Backup (J:)
Código de error:0x80070002


El mensaje "Código de error: 0x80070002" cita un problema en la comprobación de la licencia después de una actualización en un equipo Dell