Gerardo Contijoch

Experiencias del día a día trabajando con .NET – ASP.NET, C#, ASP.NET MVC y demas…

Posts Tagged ‘error’

Como resolver el error ‘It is an error to use a section registered as allowDefinition=’MachineToApplication’ beyond application level.’

Posted by Gerardo Contijoch en febrero 22, 2009

Hoy mientras estaba configurando la autenticación de un site me encontré con este error. Es un tanto críptico, pero no tan difícil de entender si pensamos un poco (y conocemos otro poco). El mensaje básicamente nos esta diciendo que hay una sección de la configuración (en mi caso la sección <authentication>, pero puede ocurrir lo mismo con otras secciones) que esta registrada con un atributo allowDefinition=’MachineToApplication’ y por eso utilizarla más allá del nivel de aplicación no esta permitido.

El archivo web.config de mi aplicación se ve algo así (resumido para mayor claridad):

   1: <?xml version="1.0"?>
   2: <configuration>
   3:     ...
   4:     <location path="Admin">
   5:         <system.web>
   6:             <authentication mode="Forms">
   7:                 <forms loginUrl="Login.aspx" name=".ASPXFORMSAUTH" defaultUrl="~/Inicio.aspx" protection="Validation"/>
   8:             </authentication>
   9:
  10:             <authorization>
  11:                 <deny users="?" />
  12:             </authorization>
  13:         </system.web>
  14:     </location>
  15:     <system.web>
  16:         <authorization>
  17:             <allow users="*" />
  18:         </authorization>
  19:         ...
  20:     </system.web>
  21: </configuration>

Aparente no tiene nada de raro, se configura la autenticación y autorización del site, así como una de las secciones del site (la rama Admin). El error me decía que la linea 6 era la del problema.

Ahora veamos de entender el problema para poder resolverlo.

Si buscamos en nuestro web.config veremos que la sección <authorization> no esta definida en ningún lugar y eso se debe a que la misma esta definida en el archivo machine.config. El mismo se encuentra en el path ‘C:\Windows\Microsoft.NET\Framework\<versión del framework>\CONFIG\machine.config’.

La sección <authentication> se encuentra definida de la siguiente manera:

   1: <configuration>
   2:     <configSections>
   3:         ...
   4:         <sectionGroup name="system.web" type="System.Web.Configuration.SystemWebSectionGroup, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
   5:             ...
   6:             <section name="authentication" type="System.Web.Configuration.AuthenticationSection, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" allowDefinition="MachineToApplication"/>
   7:             ...
   8:         </sectionGroup>
   9:     </configSections>
  10: </configuration>

Como se puede ver, efectivamente esta sección esta ‘configurada’ para que solo pueda ser utilizada en el machine.config, en el web.config que se encuentra junto con el machine.config o en el web.config que se encuentra en el root de nuestra aplicación (para ver los posibles valores de este atributo y sus significados pueden ir a esta página). Y justamente ese era el problema. En mi web.config la seccion <authentication> estaba siendo utilizada dentro de la sección <location>. Esto es lo mismo que colocarla dentro de un web.config en el directorio especificado en el atributo path de la sección <location> y por eso ASP.NET se quejaba.

Todo se solucionó cuando moví la sección problemática fuera de <location> quedando el web.config de la siguiente manera:

   1: <?xml version="1.0"?>
   2: <configuration>
   3:     <location path="Admin">
   4:         <system.web>
   5:             <authorization>
   6:                 <deny users="?" />
   7:             </authorization>
   8:         </system.web>
   9:     </location>
  10:
  11:     <system.web>
  12:         <authentication mode="Forms">
  13:             <forms loginUrl="Login.aspx" name=".ASPXFORMSAUTH" defaultUrl="~/Inicio.aspx" protection="Validation"/>
  14:         </authentication>
  15:
  16:         <authorization>
  17:             <allow users="*" />
  18:         </authorization>
  19:     </system.web>
  20: </configuration>

La confusión mía estaba en que quería configurar la autenticación dentro de un subdirectorio, cuando en realidad solo tenia que configurar la autorización para ese subdirectorio. La configuración de autenticación se tiene que aplicar a nivel de site y no de subdirectorio, en cambio, la configuración de autenticación si puede ser diferente para distintos subdirectorios.

En esta página pueden encontrar algo mas de información sobre el tema.

Espero que les sea útil.

¡Nos vemos en el próximo post!

Publicado originalmente en https://gerardocontijoch.wordpress.com.

Posted in .Net 2.0, ASP.NET, Desarrollo Web | Etiquetado: , , , | 10 Comments »

Error de compilación CS0016 en site corriendo en IIS

Posted by Gerardo Contijoch en diciembre 30, 2008

Hoy por primera vez necesite levantar un site en II7 sobre Windows Vista y me encontré con un viejo problema: el error de compilación CS0016, que se presenta con el siguiente mensaje:

Compiler Error Message: CS0016: Could not write to output file ‘c:\Windows\Microsoft.NET\Framework\[version de framework]\Temporary ASP.NET Files\root\fc8191ba\bb891bec\App_global.asax.pwk2xkjx.dll’ — ‘Access is denied. ‘

El nombre del archivo puede ser diferente ya que es generado dinámicamente al azar.

Este problema no es nuevo, ya que con otras versiones de Windows también sucede lo mismo y se debe a que el usuario con el cual estamos ejecutando el proceso de compilación no tiene permisos de escritura sobre el path indicado ni sobre el directorio temporal de Windows (esto último no lo dice en ningún lado, pero es así). Este usuario es el usuario configurado en el Application Pool asociado a nuestro site. Por defecto es el usuario NETWORK SERVICE, por lo que el problema se soluciona simplemente dándole permisos de modificación y escritura (no es necesario Full Control como figura en muchos lugares) a ese usuario sobre los paths arriba indicados.

Actualización 10/06/2009:

Luego de investigar un poco más sobre este tema, encontré aquí que el problema también puede ser causado el antivirus McAfee. Resulta que este antivirus tiene una característica que bloquea la ejecución de scripts dentro de carpetas temporales y esto puede estar interfiriendo. Para desactivar esta característica sólo tienen que seguir las instrucciones aquí expuestas.

Otra posibilidad es que el directorio de archivos temporales de Windows no este registrado entre las variables de entorno de sistema (algo raro, pero puede pasar si andamos tocando lo que no debemos). Para verificar esto, tenemos que ir a System Properties (o propiedades de Mi PC) y ahi seleccionar el tab Advanced, al final de todo hay un boton llamado Environment variables…, el cual clickeamos y en la sección System variables de la ventana que se abre tendremos que encontrar a TEMP y a TMP. Si no se encuentra alguno de los dos, entonces hay que agregarlos y asociarles como valor el path de los archivos temporales (tipicamente %Systemroot%\Temp). Luego de hacer esto, reinician IIS y listo. Tengan en cuenta que si no estan seguros de lo que hacen es mejor no tocar estos settings porque pueden dejar de funcionar muchas cosas si hacen algo mal.

Referencias:

¡Nos vemos en el próximo post!

Publicado originalmente en https://gerardocontijoch.wordpress.com.

Posted in ASP.NET, Desarrollo Web | Etiquetado: , | 16 Comments »

Sys.WebForms.PageRequestManagerParserErrorException al hacer un postback parcial

Posted by Gerardo Contijoch en diciembre 26, 2008

Hace unos días me encontré con otro problema bastante molesto en ASP.NET AJAX al cual no le encontré solución. Se presenta cuando se hace un postback parcial y se muestra un error como el siguiente:

Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.

Details: Error parsing near ‘<!DOCTYPE html P’.

(Noten que el nodo <!DOCTYPE> parece estar truncado en la respuesta)

Luego de buscar un rato, me encontré con este post de Eilon Lipton (¡el creador de este error!) donde explica porque sucede y como se puede evitar.

Cuando uno hace un postback parcial la respuesta viene en un formato especial el cual es interpretado por los scripts del lado del cliente de ASP.NET AJAX. Si nosotros durante el procesamiento del postback modificamos la respuesta, entonces los scripts van a ser incapaces de procesarla, produciendo este mensaje de error.

Para evitarlo hay que tener presente los siguientes puntos:

Nunca ejecutar Response.Write(“…”); durante un postback asincrónico.

Esto se debe a que al escribir directamente sobre la respuesta, estamos modificándola sin que los objetos encargados de procesarla lo sepan y por lo tanto, no pueden prever esos cambios.

Uso de filtros de las respuestas y HttpModules.

Al igual que con el punto anterior, si modificamos la respuesta de alguna manera, vamos a estar provocando este error seguro.

No habilitar el Trace.

Cuando uno habilita el trace en las paginas, básicamente lo que se esta haciendo es una serie de Response.Write(“…”); con la información de tracing.

Llamadas a Server.Transfer();

Cuando uno ejecuta Server.Transfer(), la respuesta deja de ser la respuesta que espera el objeto que provoca el postback asincrónico y pasa a ser el HTML generado por la página a la cual hicimos el transfer. Obviamente, esto va a interferir con el procesamiento de la respuesta (¡ya que la esta sería una pagina completa totalmente diferente a la respuesta esperada!).

En mi caso particular, no estaba haciendo nada de lo mencionado arriba, sino que estaba agregando una cookie a la respuesta, lo cual evidentemente la modifica, así que podemos agregar a la lista:

No agregar cookies a la respuesta de un postback asincrónico.

Al agregar las cookies a la respuesta, la estamos modificando (ya que enviamos la información de la cookie), por lo que hay que evitar hacerlo.

Entonces, ¿cómo se soluciona el problema cuando no podemos dejar de usar cookies o HttpModules? La solución que encontré yo fue muy simple: reescribí la página en cuestión y saque todo lo referente a ASP.NET AJAX. Todo funcionó de maravillas con un postback clásico.

¡Nos vemos en el próximo post!

PD: Si realmente necesitan modificar la respuesta en una llamada parcial, este post puede serles utiles, yo no lo probe, pero parece que funciona…

Publicado originalmente en https://gerardocontijoch.wordpress.com.

Posted in ASP.NET, Desarrollo Web | Etiquetado: , , | 3 Comments »

Sys.ScriptLoadFailedException al intentar cargar un script dinámicamente con ScriptManager

Posted by Gerardo Contijoch en diciembre 16, 2008

Hoy estaba trabajando en un site que usa ASP.NET AJAX y me encontré con el siguiente error:

Sys.ScriptLoadFailedException: The script ‘http://localhost:49573/scripts/Script.js&#8217; could not be loaded.

Ese es un script que yo cargo dinámicamente mediante el ScriptManager de la siguiente manera:

ScriptManager.RegisterClientScriptInclude(pagina, typeof(Page), "miScript", "scripts/Script.js");

Busqué códigos de ejemplos en internet y todos eran iguales al mío, no encontraba el error hasta que me topé con este post de Bill Robertson.

Resulta que ASP.NET AJAX carga los scritps registrados de esta manera de forma asincrónica y es necesario notificar la finalización de la carga de cada script para que todo funcione como debería. Para realizar la notificación simplemente hay que agregar el siguiente código al final del archivo js al que hagamos referencia:

   1: if(typeof(Sys) != "undefined" && typeof(Sys.Application) != "undefined") {
   2:    Sys.Application.notifyScriptLoaded();
   3: }

La validación de la línea 1 no es necesaria en realidad, pero si usamos este archivo en un site donde no se usa ASP.NET AJAX, la línea 2 va a fallar (debido a que puede no existir el objeto Sys).

Una vez hecho eso, el site comenzó a funcionar como siempre y el script se cargó correctamente.

¡Nos vemos en el próximo post!

Publicado originalmente en https://gerardocontijoch.wordpress.com.

Posted in ASP.NET, Desarrollo Web, Javascript | Etiquetado: , , , | 2 Comments »