El tema del post es para un manual, lo que quiero compartir son algunos tips para implementar aplicaciones ASP.Net en entornos con framework .Net 2.0 instalado.
Supongamos que tenemos un ambiente con aplicaciones ASP.net 1.1 y solo tenemos los framework 1.0 1.1 , si queremos implementar una nueva apliación desarrollada con ASP.Net 2.0, tenemos que hacer los siguiente:
1- Instalar el runtime del framework .Net 2.0. How to
2- Instalar las extensiones del IIS 6.0 para framework 2.0
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Aspnet_regiis -i
y listo , ahora podemos usar nuestras más flamante aplicación en ASP.Net 2.0. pero....
cuando queremos usar las aplicaciones ASP.net 1.1 vemos que mucha de ellas directamente no funcionan, sobre todo si dependen del machine.config, pues desde ahora el isapi del ASP.Net buscará la configuración en el machine.config del 2.0 y no del 1.1.
Solucion.
Se debe asociar los scrips maps del IIS para que la aplicacion siga corriendo con el framework 1.1
El siguiente comando instala los scrips maps apuntando a las versión asociada a aspnet_regiis.exe (en ejemplo es el 1.1) con la aplicacion SampleApp1 y todos sus subdirectorios.
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Aspnet_regiis -s W3SVC/1/ROOT/SampleApp1
Si quieren ver mas opciones, que mejor que los KB de Microsoft.
http://msdn.microsoft.com/en-us/library/k6h9cz8h(vs.71).aspx
En el siguiente blog esta detallado como solucionar este problema
http://imasters.uol.com.br/artigo/2839?cn=2839&cc=145
martes, junio 23, 2009
viernes, junio 19, 2009
Diseño de arquitecturas I
Joseph Hofstader en el Architecure Journal N° 15 indica que el diseño de la arquitectura de un software tienen 4 aspectos: Conocimiento del dominio, conceptualización, habilidades técnicas y habiidades para aplicar patrones. Los dos primero sería la etapa de definicion del problema y las dos ultimas formaria la etapa de desarrollo dela solución.
Indica que el conocimiento de la tecnología no los unico a manejar para diseñar aplcaciones robustas, pero si es una habilidad muy importante que tiene que tener el arquitecto de software. Dentro de la empresa se recomienda trabajar con la menor cantidad de tecnologias posibles, esto permite administrar el esfuerzo del desarrollo en forma más eficiente, reduciendo la cantidad de herramientas de administración, desarrollo monitoreo etc, teniendo grupos con menos perfiles técnicos etc .
Algunos de los los aspectos de calidad a tener en cuanta al momento de diseñar la arquitectura base de un sistema son altamente influenciado por la forma en que se implementa el diseño a nivel código. Por ejemplos aspectos de seguridad, performance y mantenimiento son altamente degradados sin se desarrolla sin seguir buenas practicas y aplicar patrones.
Para ello se debe tener adecuados controles de calidad, testear el codigo en forma periodica, dependiendo de la metodología de desarrollo adoptada, la integración continúa mediante el uso de herramientas permiten controlar al final del día que el código subido al repositorio notiene errores de compilación y además se pueden ejecutar revisione de código y pruebas unitarias automáticas. Si con esto se generar reportes se puede controlar día a día la calidad del código que se está generado.
Si no hacemos esto, cuando el codigo pasa a testing funcional, nos encotramos con cosas como SQL Harcodeados, store procedures gigantescos que no tienen ningun tipo de control en la cantidad de registros a enviar al cliente, armado de documentos (xml u otros tipo) concatenados strings (System.String) y en el peor de los casos codigo "chorizo" practimente imposible de mantener, datos de conexión harcodeados (aunque no lo crean) etc etc.
No se imaginan los problema de reworking y troubleshuting que surgen cuando se produce un incidencia con alguna de esas aplicaciones.
Indica que el conocimiento de la tecnología no los unico a manejar para diseñar aplcaciones robustas, pero si es una habilidad muy importante que tiene que tener el arquitecto de software. Dentro de la empresa se recomienda trabajar con la menor cantidad de tecnologias posibles, esto permite administrar el esfuerzo del desarrollo en forma más eficiente, reduciendo la cantidad de herramientas de administración, desarrollo monitoreo etc, teniendo grupos con menos perfiles técnicos etc .
Algunos de los los aspectos de calidad a tener en cuanta al momento de diseñar la arquitectura base de un sistema son altamente influenciado por la forma en que se implementa el diseño a nivel código. Por ejemplos aspectos de seguridad, performance y mantenimiento son altamente degradados sin se desarrolla sin seguir buenas practicas y aplicar patrones.
Para ello se debe tener adecuados controles de calidad, testear el codigo en forma periodica, dependiendo de la metodología de desarrollo adoptada, la integración continúa mediante el uso de herramientas permiten controlar al final del día que el código subido al repositorio notiene errores de compilación y además se pueden ejecutar revisione de código y pruebas unitarias automáticas. Si con esto se generar reportes se puede controlar día a día la calidad del código que se está generado.
Si no hacemos esto, cuando el codigo pasa a testing funcional, nos encotramos con cosas como SQL Harcodeados, store procedures gigantescos que no tienen ningun tipo de control en la cantidad de registros a enviar al cliente, armado de documentos (xml u otros tipo) concatenados strings (System.String) y en el peor de los casos codigo "chorizo" practimente imposible de mantener, datos de conexión harcodeados (aunque no lo crean) etc etc.
No se imaginan los problema de reworking y troubleshuting que surgen cuando se produce un incidencia con alguna de esas aplicaciones.
Suscribirse a:
Entradas (Atom)