The section can't be defined in this configuration file (the allowed definition context is 'MachineToApplication')

La verdad que este error si me a quitado el sueño no solo una vez, sino en repetidas ocasiones, la primera vez si que dure mucho tiempo para buscarle una solucion pero no fue de mi agrado, las otras ocasiones descubri otras variantes para solucionar el error, hoy me volvi a tocar con lo mismo y me anime a escribir un poco de aquello.

Primero entendamos y conoscamos el error a fondo y despues hablemos de soluciones posibles:

Cuando tenemos una aplicacion que deseamos usar el membership, por lo tanto roles tambien, al probarla en nuestro ambiente de Mono, es posible que obtengamos este error:

The section can't be defined in this configuration file (the allowed definition context is 'MachineToApplication')

Verlo a primer encontronazo, nos quedamos perplejos, un error muy extraño que no nos dice mucho, solo que la definicion del roleManager no se puede declarar en el webconfig, sino en otro contexto, pero sucede que nuestra aplicacion trabaja bien en nuestro ambiente de windows, en el caso de que sea que estemos portandolo desde alli. Pues googleando un poco no encontramos absolutamente nada que nos ayude, un error poco discutido, incluso solo vi algunos que suguieren que actualizemos a una version mas nueva de mono si hay alguna... esta solucion me parece a la que dan algunos soportes tecnicos a los usuarios cuando tienen cualquier tipo de problema que sin saber mucho la situacion solo dicen "resetea el computador, si persiste llamame, adios". Obviamente esta no es la solucion, ya que he visto el mismo error en versiones diferentes de mono.

El problema radica en que el mod_mono no esta viendo nuestra aplicacion como una real aplicacion, sino como una carpeta comun. Este error ocurre si no tenemos configurada (o no lo esta correctamente) nuestra aplicacion en el mod_mono.conf o si estamos trabajando con el AutoHosting.

Si configuramos nuestra aplicacion manualmente en el mod_mono.conf no veremos mas este error y todas las aplicaciones que hostiemos la debemos de configurar correctamente alli, aconsejable utilizar esta utilidad que nos genera la configuracion correcta para nuestra aplicacion http://go-mono.com/config-mod-mono/

Otra forma de resolver el error sin enliarnos mucho con la configuracion es copiar nuestra aplicacion en el root de nuestro site, es decir, fuera de cualquier carpeta, con el solo hecho de escribir http://midominio.com esta entre inmediatamente. Esta solucion es viable si no pensamos hostear ninguna otra aplicacion mas, solo una.

Pero que sucede si deseo utilizar el AutoHosting y estoy recibiendo este error?

El autohosting permite que tengamos muchas aplicaciones en un mismo dominio separados por carperas y que estas no sean necesarias ser configuradas en ningun archivo de configuracion, definitivamente el autohosting es la mejor opcion para trabajar, pero este error nos hace la vida imposible ya que si tenemos 10 aplicaciones hosteadas y una sola de estas utilizara el membership y nos arroja este error, pues nuestras otras 9 aplicaciones se bloquean!!

Por que el AutoHosting no reconoce nuestra aplicacion como tal??? pues lo que sucede es que el autohosting para considerar que una carpeta es una aplicacion solo toma en cuenta si existe un archivo "Global.asax" o una carpeta "bin". Asi que si no tenemos ninguno de los dos, pues a crearlo... Pero por su puesto que tengo por lo menos la carpeta "Bin" en mi aplicacion y sigue presentando el error.... dije "Bin" con la B en mayuscula? pues ahi esta el problema, el autohosting es CASE-SENSITIVE, el esta buscando un "bin" no un "Bin".

WebForms vs MVC

Recuerdo que en el año 2003 cuando el bum del Framework.Net de microsoft se hacia fuertemente popular donde ellos planteaban un nuevo paradigma de construcción de paginas web mucho "mas fácil" que los métodos convencionales conocidos, pues yo me resistía al cambio ya que desde que comencé a investigar su funcionamiento, me daba cuenta que el control de lo que se construía no me pertenecía, estabas atado a lo que el framework quisiera hacer por ti, también me preguntaba en donde iba a dejar mi tan amado JavaScript (JS), como iba a administrar los controles de los formularios sin una integración realmente adecuada con el JS y eso de estar posteando al servidor para que los eventos se disparasen y otras acciones se realizaran en una misma pagina, el viewstate que reentilizaba considerablemente las cargas de las paginas, pues todo me parecia muy mal visto por mi, siempre fui un programador fuerte de lo convencional ASP 3.0 (el clasico) y PHP, construía a mano todos mis recursos de JS, mis clases para mis aplicaciones, un total dominio de los tags de HTML... en fin, mi cambio al .Net no fue de mi agrado pero tuve que hacerlo.

En la curva del aprendizaje y la experiencia del día a día, me enamore de C#, una riqueza inmensa e incomparable en un lenguaje de programación que no le tiene que envidiar nada a ninguno, sin lugar a dudas mi favorito entre muchos que conozco y en mi opinión personal diría que es el mejor.

La ventaja inmediata a la creación de los WebForms era la gran rapidez de desarrollo, la facilidad de hacer cosas que me tomaban horas y días de hacer antes lo hacia en un santiamén, quizás no tenia el control total de lo que hacia pero mi productividad se disparo por los cielos. El no tener el control total de lo que hacia ya no me quitaba el sueño porque no me impedía construir aplicaciones a mis gustos y sin dificultad, pues el resultado de los proyectos siempre era el deseado y de calidad. También con la experiencia se aprendían trucos para realizar algunas acciones que pensábamos que no eran posible sin tener "dicho control", pero la verdad es que "casi" todo era posible, solo era asunto de ingeniársela y buscarle la vuelta. Microsoft siempre abogo y defendió haber tenido el mejor framework y herramienta para el desarrollo web con los WebForms y al final de la historia le di la razón.

Al pasar los años comencé a oír mucho de los framework MVC existentes en otras plataformas y de sus grandes ventajas, también al parecer muchos desarrolladores de Microsoft siempre se quedaron con la queja que yo tuve desde un inicio como la falta de control y otros aspectos negativos que siempre estuvieron latentes en los WebForms como la lentitud de la carga de las aplicaciones por el complejo ciclo de vida de una pagina , la falta de trabajar en un contexto real para entorno web ya que el concepto de los WebForms era como simular el desarrollo como si se tratase de aplicaciones WinForm, etc. Por lo tanto, el paradigma MVC proponía una solución a todas estas cuestiones, por lo cual Microsoft se embarco a lanzar su primer MVC soportado por su Framework.Net y con el tiempo ha seguido evolucionando a un producto mas acabado y pulido por ellos.

Ahora la pregunta del millón es: debo de cambiar a este nuevo concepto de desarrollo web? lo que se me vendió como "lo ultimo y mejor" por muchos años para desarrollo web ya no lo es, y me lo quieren reemplazar por algo que ya existía en otras plataformas y ahora me quieren decir que es mejor? debo llorar o reír?

Pues me tomare la libertad de responderme a mi mismo tomando como inicio un solo punto: los WebForms no han sido reemplazados ni descontinuados por Microsoft, por lo tanto el MVC solo representa una opcion diferente para el desarrollo de aplicaciones Web para atraer a una comunidad grande que apoya y trabaja sobre este patrón y para satisfacer las necesidades de un sector que aclamaba algo diferente.

El modelo que propone el MVC esta mejor conceptualizado para contruir aplicaciones Web que los WebForms, es cierto, pero por esto no lo considero la panacea. Cuando veo la capa de las vistas de la pagina, en donde tengo que volver a recurrir a mi programacion "espaguettis", donde tengo que unir el HTML con el codigo fuente de la aplicacion para mapear mis variables, imprimir mis resultado, construir mis JS o utilizar un framework de ajax, pues siento que estoy volviendo al pasado otra vez en donde ahora solo se me obliga a separar mis tareas en diferentes lugares (lo que complica un poco el asunto si no estamos familiarizados con los MVC): ponme la lógica en este folder, ponme la base de datos aqui y despues has todo lo que quieras en esta pagina, tags de HTML, tags de programacion, javascript (si son necesarios), estilos, etc. En donde queda el RAD (Rapid Application Development) que me ofrece los WebForms? en donde queda mi multitudes de controles de servidor que hacen todo el trabajo pesado por mi? sacrificare mi productividad, mi rapidez en desarrollo, mi comodidad que me he venido acostumbrando y ganando durante todos estos años para volver a lo que tenia en el pasado y ya lo había dejado atrás... "el control".

Lo de volver al pasado lo digo en forma literal ya que en el MVC seguiremos contando con el rico lenguaje C#, los recursos del framework.Net y muchas otras librerías mas que siempre han estado a nuestra disposición en esta plataforma.

En resumen, no pongo en duda la superioridad del MVC para el desarrollo Web, pero tampoco le quito méritos a los WebForms con todo y sus defectos, seguirá siendo la mejor opción RAD y se seguirán haciendo aplicaciones robustas y estables como lo hemos estado haciendo por años, simplemente sera un asunto de preferencia utilizar uno u el otro y en algunos casos dependerá del proyecto que desearemos embarcarnos.

Por lo menos si aconsejo que las personas que nunca habían conocido ningún lenguage de desarrollo web lo empiecen hacer desde el MVC porque solo así se puede conocer bien el funcionamiento y el mecanismo de las paginas Web en un contexto real. Luego utilizar los WebForms para sacar sus propias conclusiones, aunque este ultimo es mas fácil de aprender de entrada por su similitud al desarrollo de aplicaciones WinForms.