Carlos Walzer : ASP.NET

Recursos destacados en MSDN ASP.NET Home

cwalzer — Wed, 21 Oct 2009 13:36:00 GMT

Me ha tocado la grata tarea de seleccionar y promover los links que se listan en la sección de Recursos Destacados de MSDN ASP.NET Home.

La idea es promover artículos originales de autores de la comunidad de habla hispana, sobre temas de desarrollo Web. Estaré seleccionando unos 10 artículos al mes.

Algunos temas de ejemplo: ASP.NET, Silverlight, IIS, Seguridad, AJAX, IE, ASP.NET MVC, ASP.NET 4.0

Si encuentras algún artículo interesante o quieres promover el tuyo, comunícate conmigo vía http://twitter.com/cwalzer.

Saludos

Using Modal Dialog Boxes in ASP.NET Applications

cwalzer — Thu, 21 Aug 2008 12:08:00 GMT

Este articúclo publicado originalmente en AspToday (hace años), muestra como resolver mediante XmlHttpRequest el post desde una ventana modal del explorador.

Si bien hoy tenemos Ajax, UpdatePanels y derivados, creo que el artículo sigue vigente....

http://microsoft.apress.com/asptodayarchive/73815/using-modal-dialog-boxes-in-aspnet-applications

Video: Load Test en Visual Studio 2008

cwalzer — Fri, 01 Aug 2008 04:29:00 GMT

Como preparar, correr y analizar un Web Test utilizando Visual Studio 2008 Team Systems.

Duración: 12:59

Extraído del Lanzamiento de Visual Studio 2008

Video: Web Test en Visual Studio 2008

cwalzer — Thu, 24 Jul 2008 00:40:00 GMT

Vídeo que muestra como grabar, personalizar y ejecutar un Web Test utilizando Visual Studio 2008 Team Systems.

Duración: 9:04

Extraído del Lanzamiento de Visual Studio 2008

Conferencia: IIS 7 para Desarrolladores

cwalzer — Tue, 20 May 2008 12:18:00 GMT

En esta presentación online de MSDN (20/mayo/08) que realizamos con José Marcenaro, destacamos algunos de los aspectos de la nueva plataforma de hosting en Windows Server 2008 y Windows Vista, enfocados desde la óptica de los desarrolladores.

Puede descargar aquí la presentación (.PPTX) y el ejemplo de código WAS (Windows Service Activation Process) que muestran servicio WCF accedido por protolos non-http.

Próximamente podrán ver la presentación por demanda aquí.

Conferencia: Materiales de Desarrollando aplicaciones en IIS 7.0.

cwalzer — Wed, 27 Feb 2008 14:49:00 GMT

Adjunto encontrarán los materiales de la Conferencia OnLine MSDN: Desarrollando aplicaciones bajo la plataforma Internet Information Server 7.0, que brindé con el amigo Miguel Angel Saez.

En algunos días podrán verla a demanda aquí.

Espero haya sido de ayuda.

Descargar Materiales

Diagnóstico de caída del w3wp.exe con ASP.NET 2.0 y WCF

cwalzer — Thu, 07 Feb 2008 14:47:00 GMT

La información de este post está basada en el uso empírico del siguiente artículo “Las excepciones no controladas hacen aplicaciones que se las cierran inesperadamente en el .NET Framework, 2,0, basadas en ASP.NET”.

Cuando nos enfrentamos a caídas del worker process en Internet Information Server, la información que encontramos en el Event Log es una de las puntas para empezar la investigación.Ante una caída (crash) del proceso w3wp.exe (worker process) el sistema operativo informa el hecho en el Event Viewer con 3 entradas.
A continuación un ejemplo muestra los eventos sucedidos en forma cronológica:

Sección Application
Event Type:        Error
Event Source:        .NET Runtime 2.0 Error Reporting
Event Category:        None
Event ID:        5000
Date:                1/8/2008
Time:                7:23:11 AM
User:                N/A
Computer:        PC
Description:
EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.3959, P3 45d6968e, P4 mscorlib, P5 2.0.0.0, P6 46b3e871, P7 331e, P8 21c, P9 system.io.ioexception, P10 NIL.

Event Type:        Error
Event Source:        Application Error
Event Category:        (100)
Event ID:        1000
Date:                1/8/2008
Time:                7:23:32 AM
User:                N/A
Computer:        PC
Description:Faulting application w3wp.exe, version 6.0.3790.3959, faulting module kernel32.dll, version 5.2.3790.3959, fault address 0x0000bee7.

Sección System
Event Type:        Warning
Event Source:        W3SVC
Event Category:        None
Event ID:        1011
Date:                1/8/2008
Time:                7:23:35 AM
User:                N/A
Computer:        PC
Description:A process serving application pool 'MiSistema.AppPool' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was '10232'. The data field contains the error number.

La única punta que tenemos hasta el momento es que el tipo de la Excepción que produjo la caída es System.IO.IOException, pero necesitaríamos el stack trace para poder hacer un diagnóstico.

¿Porque se produce una caída del w3wp.exe?

Conocer porqué se produce una caída del worker process nos dará un indicio por dónde empezar a buscar.Una Excepción no atrapada en nuestro código cuyo código corre en un hilo del thread pool de ASP.NET será atrapada por el mismo ASP.NET, formateada en la típica pantalla naranja y mostrada al usuario. Lo mismo sucede con un servicio WCF que corre en IIS, la Excepción no atrapada será lanzada al invocador o en el mejor de los casos podemos atraparla centralizadamente en un behavior implementado la interfaz System.ServiceModel.Dispatcher.IErrorHandler.

La caída se produce entonces cuando la excepción no es atrapada en un hilo secundario al del thread pool de ASP.NET, o cualquier otro hilo que no corra dentro del pipeline de ASP.NET. Podría ser el caso de una excepción no atrapada en:
·         Finalizer (cuyo código se ejecuta en un hilo del GC)
·         Código ejecutado asinrcónicamente mediante un delegado
·         Algún componente que utilice un thread pool propio.
·         Etc.

En la versión de ASP.NET 2.0 el comportamiento por defecto de que sucede cuando una excepción no es atrapada en un hilo que no pertenece el thread pool es producir la caída del worker process. Esto no sucedía en versiones anteriores ASP.NET 1.0 y 1.1, donde el comportamiento es el contrario. Este cambio se debe a que una excepción no atrapada no permite la ejecución de código que en situaciones normales hubiese liberado recursos. De esta forma se evita la degradación del equipo o el abandono de locks.

Evitar caída del Worker Process (no recomendable)

En ASP.NET 2.0 es posible controlar este comportamiento modificando la entrada del aspnet.config

<configuration>
<runtime>
<legacyUnhandledExceptionPolicy enabled="true" />
</runtime>
</configuration>

Demás está decir que esta práctica no es recomendable.

Como información agregada he aquí un extracto del documento CLR Run-Time Breaking Changes

Short Description	Unhandled exceptions will always be fatal to a process
Affected APIs	N/A	Severity	Medium	Compat Switch Available	No

Description	Unhandled exceptions will always be fatal to the process. They weren't necessarily always fatal in V1.0/V1.1.

User Scenario	Applications that throw unhandled exceptions on threads other than the main thread (or ones that come into the runtime from the outside) will crash rather than continue running (when they are potentially in an invalid state)

Work Around	Put a catch block at the top of your non-main thread, threadpool workitem, or finalizer. (Or else fix the bug that led to the exception.) Alternatively, in the section of the application's config file, add the following:`<legacyUnhandledExceptionPolicy enabled="1"/>`

Como registrar Excepciones que producen caídas del w3wp.exe

Una forma no tan simple, pero certera de diagnosticar el problema es hacer un dump del proceso con la herramienta debugdiag.exe al momento de la caída. Pero claro no es una tarea sencilla...

Tal como lo indica el artículo, es posible registrar las excepciones que producen la caída del worker process, agregando un HttpModule de ASP.NET.
La primera ventaja que encontramos aquí es que un HttpModule se puede agregar por configuración sin necesidad de recompilar.
La segunda es que este funciona para cualquier código que corra por el pipeline de ASP.NET, ya sea código ASP.NET, un ASMX o un servicio WCF.
La clave de este module es suscribirse al evento AppDomain.CurrentDomain.UnhandledException que será lanzado frente a una First Chance Exception, y el cual no modifica el curso, con lo cual luego se lanzará la Second Chance Exception, que producirá la caída.
Es aquí entonces donde recibimos por parámetro la excepción ocurrida y la registramos en el Event Log por ejemplo.De esta forma podremos obtener información detallada de la excepción, como ser el mensaje y el stack trace.

Nota: El hecho de agregar el HttpModuile, no evita la caída del w3wp.exe.

Como probar este funcionamiento

Basta con lanzar una Exception desde un finalizer para producir la caída del worker process.

Código

El código está disponible en este artículo

Conferencia Online MSDN: Desarrollando aplicaciones bajo la plataforma Internet Information Services 7.0.

cwalzer — Thu, 07 Feb 2008 09:34:00 GMT

Conferencia Online MSDN: Desarrollando aplicaciones bajo la plataforma Internet Information Services 7.0 (nivel 200).

Duración:	45 Minutos
Fecha de Inicio:	martes, 26 de febrero de 2008 11:00 a.m. Atlántico Central
Información general del Evento
La última versión de Internet Information Services disponible en Windows Server 2008 incluye grandes cambios con respecto a sus versiones precedentes. En esta sesión exploraremos algunos aspectos técnicos como su nueva arquitectura, el pipeline integrado de ASP.NET, y su nueva consola de administración, pero también conoceremos las forma en que la plataforma puede ser extendida para el soporte de distintas tecnologías. Oradores: Carlos Walzer – Miguel Angel Saez. Registración

Scroll completo para la grilla de ASP.NET

cwalzer — Fri, 16 Nov 2007 00:23:00 GMT

Este artículo plantea al forma de agregar barras de scroll a una grilla de ASP.NET para poder ver todos sus registros y columnas, y sincroniza el movimiento de la tabla con la cabecera.

Es un viejo artículo que se publicó en MSDN en Español y que ya no está en línea.

Ver artículo....

MSDN Radio en Vivo: Discusión: Técnicas y Herramientas para Mejorar el Rendimiento de Aplicaciones y Bases de Datos

cwalzer — Fri, 26 Oct 2007 14:44:00 GMT

Durante el último mes los expertos de Solid Quality Mentors han estado discutiendo técnicas para medir y mejorar el rendimiento de las aplicaciones. Durante este show de MSDN Radio únase a una discusión en vivo sobre cómo optimizar sus aplicaciones, herramientas para medir el rendimiento, mejores técnicas de acceso a datos, tips de optimización de código en SQL Server y cómo mejorar el rendimiento de OLAP y Analysis Server.

Te esperamos para que puedas evacuar tus dudas y debatir acerca de como mejorar el rendimiento de tus aplicaciones .NET y bases de datos.
http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032357579&EventCategory=4&culture=es-AR&CountryCode=AR

Aprovecho la oportunidad para invitarlos a que vean el WebCast de Gustavo Larriera sobre el tema:
Técnicas de ajuste de rendimiento en SQL Server 2005

Accediendo a datos en Excel utilizando ADO.NET y ASP.NET

cwalzer — Wed, 24 Oct 2007 18:40:00 GMT

No es un hecho poco común el que nos encontremos con la necesidad de acceder desde nuestras aplicaciones, ya sean estas de escritorio (Win32) o de Internet (ASP.NET), a datos almacenados en otros formatos que no sean bases de datos. En este articulo les mostraremos como leer una planilla Excel subida por un usuario a un sitio Web utilizando ADO.NET.

Ver artículo completo....

Mes de Mejoras de Desempeño en MSDN por Solid Quality Mentors

cwalzer — Thu, 18 Oct 2007 15:04:00 GMT

En el transcurso de este mes los mentores de Solid Quality Mentors hemos difundido nuestros conocimientos en MSDN Latino América, acerca de las técnicas disponibles para Mejora de Desempeño de aplicaciones Microsoft.

Aquí podrás encontrar la información del wecast que dí, el mismo está en línea para que lo puedas ver a demanda:
Herramientas para mejorar el desempeño de las aplicaciones .NET Framework

Material relacionado con este webcast:

Aquí podrás consultar las otras presentaciones relacionadas con este tema:

¿Hablamos del rendimiento de las aplicaciones? por Daniel Seara
Measuring Performance in ASP.NET Applications por Eugenio Serrano
Techniques for Performance Tuning ADO.NET Data Access Code por Adolfo Wiernik

Y como el mes no terminó, aún queda más material por venir

HTTP 411 Length Required al ejecutar Web Test

cwalzer — Mon, 24 Sep 2007 18:05:00 GMT

Si al ejecutar un Web Test en Visual Studio 2005 recibes un error HTTP 411 del servidor web, es probable que encuentres solución con esta recomendación.

Problema
Al grabar un Web Test con Fiddler, a los requests que no tiene una colección de valores en "Form Post Parameters" le asgina la propiedad Transport.Method = POST.

Cuando se ejecuta el web test el Request generado es el siguiente

POST /localhost/algunallamada.aspx
Content-Type : application/x-www-form-urlencoded
Pragma : no-cache
User-Agent : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Accept : */*
Accept-Language : en-US
Host : walzer3
Cookie : ASP.NET_SessionId=iclqf455ckclxr45fsfeq4yt
Accept-Encoding : gzip

Aca podemos notar que se emite el Content-Length. IIS entonces al no recibir datos ni tener espeficado explícitamente su tamaño (Content-Length : 0), devuelve un error HTTP 411:

Headers:
HTTP/1.1 411 Length Required
Connection : close
Cache-Control : private
Content-Length : 24
Content-Type : text/html
Date : Mon, 24 Sep 2007 20:42:53 GMT

Body:
<h1>Length Required</h1>

Solución
Cambiar la propiedad Transport.Method = GET

Webcast: Herramientas para mejorar el desempeño de las aplicaciones .NET Framework

cwalzer — Thu, 20 Sep 2007 21:58:00 GMT

Los invito a escuchar este webcast que daré el Viernes 5 de Octubre 2007.

Daremos una recorrida por las herramientas que propone Microsoft para Detectar y Diagnosticar problemas de desempeño y mal uso de la memoria de aplicaciones .NET: Visual Studio 2005 Team System para hacer pruebas de carga y stress sobre sitios ASP.NET. CLR Profiler y Visual Studio 2005 Team System para hacer profiling de código y de memoria. Fiddler para hacer debugging de HTTP. Todas ellas, en conjunto, son de gran ayuda al momento de mejorar el desempeño de nuestras aplicaciones.

Registrarse

Visual Studio 2005 Web Test usando XmlHttpRequest y AJAX

cwalzer — Wed, 12 Sep 2007 13:07:00 GMT

Si estás intentando grabar un web test con Visual Studio 2005, te habrás topado con la dificultad de que el grabador no se entera de las llamadas vía XmlHttpRequest, y por ende AJAX (ya que AJAX usa internamente XmlHttpRequest como mecanismo de comunicación).

Acabo de agregar un comentario en la sección "Community Content" del help en línea de Visual Studio Team System "How to: Record a Web Test", justamente haciendo esta aclaración; ya que toda la información que encontré hace referencia a la solución del problema si el sitio usa AJAX, pero nadie habla de XmlHttpRequest.

La solución entonces le cabe a ambas opciones y es usar la herramienta Fiddler para grabar un web test. Aquí se explica Como grabar un Web Test con Fiddler

Ahora bien, como es que Fiddler puede hacerlo y Visual Studio no? La diferencia radica en la técnica que utilizan para grabar. El grabador de Visual Studio 2005 corre dentro del Internet Explorer como un add-on intereceptando los post y get que IE realiza y no tiene inferencia en el código DHTML que se ejecuta, es por eso que no puede detectar los post realizados por XmlHttpRequest. Lo puedes encontrar instalado en la ventana Manage Add-ons de IE.

En cambio Fiddler actúa como un proxy atendiendo en el puerto 8888 del localhost, interceptando los post y get y redireccionándolos a su destino final, el server. De esta forma Fiddler se entrea de todos los post que llegan al servidor, los haya enviado quien fuere. Cuando Fiddler está corriendo verán modificado los valores de WinInet de IE.

El debugging es solo para eso: Depuración

cwalzer — Tue, 11 Sep 2007 16:06:00 GMT

Para confirmar lo que mi amigo Patrick MacKay explica en estos 3 artículos:
¿Por qué debo definir "debug=false" en web.config?, Parte I
¿Por qué debo definir "debug=false" en web.config?, Parte II
¿Por qué no debo compilar en modo debug?, Parte III
,quisiera mostrarles los resultados de la ejecución de test de stress sobre un sitio ASP.NET compilado en modo debug.

Me topé con un caso en el cual el sitio había sido compilado en modo debug y habilitado debug=true en el web.config . Claro no me enteré de esto hasta que me dijeron: "Pusimos a correr la prueba y no anduvo, hay un valor % Time in Jit que está muy alto". Y efectivamente estaba muy alto:

Noten que el contador % Time in Jit de la categoría .NET CLR JIT se mantiene constante durante 3 horas a valores altísimos. Los umbrales propuestos por Visual Studio 2005 para este contador son:
Warning: 25
Critical: 50
Según mi experiencia en una prueba de stress, salvo el primer minuto donde hay picos de hasta 80%, el valor normal no supera el 1%.
Si se fijan la cantidad de Requests/seg que la aplicación logró responder es 0. La aplicación Web está totalmente inhibida.

Una segunda corrida mas corta tratando de encontrar el problema arrojó el mismo resultado:

Estas mediciones confirman lo tratado en el artículo I, donde Patrick muestra como se sucede la compilación de un sitio ASP.NET al hacerse una petición. Excelente tratamiento de parte de Patrick al tema.

El debugging es solo para eso: depuración.

Restricción de seguridad al escribir en el EventLog desde ASP.NET

cwalzer — Fri, 17 Aug 2007 21:08:00 GMT

Si nuestras aplicaciones registran información de excepciones o tracing en el EventLog, es probable que nos encontremos con que no estén funcionando cuando pasemos nuestras aplicaciones a producción.
La escritura de una entrada en el EventLog implica la existencia de una entrada en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application de la Registry. Por ejemplo las aplicaciones ASP.NET que corren en un ambiente de producción, se encuentran bajo un contexto de seguridad restringido, el cual no tiene privilegios de escritura en la Registry. Recordemos que en Windows 2003, las aplicaciones ASP.NET, por defecto corren bajo una cuenta Network Service Account, la cual no tiene acceso de escritura a la registry.
Tal como dijimos, la escritura de una entrada en el EventLog implica la existencia de una entrada en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application de la Registry que se corresponde con el nombre del “Source” que figura en la ventana que lo muestra.Ejemplo: Para Source = EjemploExcepciones

Debe existir la entrada:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\ EjemploExcepciones

El contenido del value EventMessageFile se corresponde con la librería que registra la entrada en el Event Log.
En el caso de .NET: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dllNótese que v2.0.50727 es la versión del .NET Framework con la que corre la aplicación que quiera registrar entradas en el Event Log para ese “Source”.

Solución

Asegurarse que la entrada que se corresponde con el nombre del “Source” exista en la registry. Para ello, recomiendo desarrollar una aplicación del tipo instalador para registrar el “Source”, la cual se ejecutará una sola vez al momento de instalar la aplicación.

Cree un proyecto del tipo Class Library (InstaladorRegistry.dll), e incluya una clase con el siguiente código. O incluya este código en el instalador de su aplicación:Imports System
Imports System.Configuration.Install
Imports System.Diagnostics
Imports System.ComponentModel<RunInstaller(True)> _

Public Class CustomEventLogInstaller
    Inherits System.Configuration.Install.Installer

    Private customEventLogInstaller As EventLogInstaller

    Public Sub New()
        MyBase.New()
        'Registrar el Event Log Source = "MiAplicacionSource" para el log "Application"
        customEventLogInstaller = New EventLogInstaller
        customEventLogInstaller.Source = "MiAplicacionSource"
        customEventLogInstaller.Log = "Application"
        Installers.Add(customEventLogInstaller)
    End Sub

    Public Shared Sub Main()
    End Sub

End ClassUtilizarla de la siguiente forma:
     InstallUtil.exe InstaladorRegistry.dllObservemos el Log del proceso de instalación:
Instalando ensamblado 'c:\carlos walzer\architect\InstaladorRegistry\bin\InstaladorRegistry.dll'.
Los parámetros afectados son:   assemblypath = c:\carlos walzer\architect\InstaladorRegistry\bin\InstaladorRegistry.dll
logfile = c:\carlos walzer\architect\InstaladorRegistry\bin\InstaladorRegistry.InstallLog
Creando el origen de EventLog MiAplicacionSource en el registro Application...
Confirmando ensamblado 'c:\carlos walzer\architect\InstaladorRegistry\bin\InstaladorRegistry.dll'.La misma cumple funciones de desinstalación:
        InstallUtil.exe /u InstaladorRegistry.dllLog del proceso de desinstalación:
Desinstalando ensamblado ‘c:\carlos walzer\architect\InstaladorRegistry\bin\InstaladorRegistry.dll'.
Los parámetros afectados son:   assemblypath = c:\carlos walzer\architect\InstaladorRegistry\bin\InstaladorRegistry.dll
logfile = c:\carlos walzer\architect\InstaladorRegistry\bin\InstaladorRegistry.InstallLog
Quitando el origen de EventLog MiAplicacionSource.

¡Importante!

Ya se habrán imaginado que todo este trabajo que hicimos es para NO dale permisos de escritura sobre la registry al usuario con el cual está corriendo la aplicación. Si bien es el camino más fácil, esto traería consecuencias de inseguridad para nuestro sistema.

Desestime el uso del EventLog

Expuesta la solución me gustaría darles mi punto de vista por el cual desestimar la escritura de información de Excepciones o Tracing en el EventLog:

Como vieron, hay implicancias de seguridad que de no detectarse, harían que información valiosa se estuviera perdiendo.
De la misma forma, se requieren permisos de Administrador para la lectura del eventLog mediante la aplicación EventViewer, lo cual deja afuera a muchos usuarios interesados en ella que no tienen estos privilegios en un ambiente de producción.
Esta información está distribuida en cada servidor, y su recolección y centralización puede ser engorrosa.
El EventLog tiene una capacidad máxima, y por defecto descarta la información mas antigua cuando llega a su tope, con lo cual estarían perdiendo información valiosa a la hora de investigar un problema.
Si para salvar el punto anterior aumentan el tamaño del EventLog, verían afectado la performance de la aplicación. Un valor aceptable no debería superar los 10 Mb.

Otros mecanismos para reemplazar el EventLog

Existen otros mecanismos y librerías totalmente configurables y extensibles que fueron pensadas para el registro de información del tipo Excepciones o Tracing. Les recomiendo que adopten a su gusto cualquiera de estas dos herramientas las cuales me dieron muy buenos resultados:

Log4Net
Logging Application Block

Atributos redundantes del AssemblyInfo.cs de forma centralizada

cwalzer — Sun, 08 Jul 2007 03:28:00 GMT

Es un hecho factible que alrededor del 90% de las aplicaciones desarrolladas en Visual Studio 2003 o 2005 sean soluciones que contengan varios proyectos: Windows Apllication + Class Library o Web Site + Class Library + Web Service, etc. Sea cual fuere el tipo o cantidad de proyectos definidos, es muy probable que en ellos encontremos definidos en archivos AssemblyInfo.cs atributos del tipo [assembly: ]redundantes. La forma de poder centralizar esa información es crear un archivo que llamaremos GlobalAssemblyInfo.cs en la carpeta virtual "Solution Items" de la solución:

using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyCompany("Empresa")]
[assembly: AssemblyProduct("Facturacion")]
[assembly: AssemblyCopyright("Copyright © Empresa 2007")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

// Version information for an assembly consists of the following four values:
// Major Version
// Minor Version
// Build Number
// Revision

// Las siguientes 2 declaraciones dependerán de la política de versionamiento que adopte para cada uno de los assemblies generados.
[assembly: AssemblyVersion("4.0.27.0")]
[assembly: AssemblyFileVersion("4.0.27.0")]

[assembly: AssemblyInformationalVersion("4.0")]

Cada uno de los proyectos entonces contendrá su típico archivos AssemblyInfo.cs con los atributos específicos:

using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.

[assembly: AssemblyTitle("Facturacion User Interface")]
[assembly: AssemblyDescription("Intrefaz de usuario de Factuaracion")]
[assembly: AssemblyConfiguration("")]

Nota: Nótese que las declaraciones que definen la versión del assembly bien pueden estar definidas en el GlobalAssmeblyInfo.cs, si todos los assmblies llevan el mismo número de versión por cada libración, o en el AssemblyInfo.cs, si cada uno de ellos estan versionados independientemente. Para una mejor compresión lea Versionamiento de Assemblies

Resta entonces crear una referencia al archivo GlobalAssemblyInfo.cs en cada proyecto de la solución, para ello:

Haga click derecho sobre el proyecto: "Add", "New Item"
Seleccione el archivo GlobalAssemblyInfo.cs
Haga click sobre la flecha a la derecha del botón "Add"
Seleccione "Add as Link"
Por útlimo arrastre la referencia del archivo GlobalAssemblyInfo.cs a la carpeta propiedades.

Problemas al usar Frames

cwalzer — Thu, 31 May 2007 18:18:00 GMT

Leyendo algunos posts he encontrado una lista de sugerencias de parte de Microsoft a la hora de elegir que técnica usar para mostrar el contenido común a todas las páginas de un sitio:

Usar Master Pages cuando:

No es crítico un refresh completo de la página
El desarrollo requiere un standard de página modificable mediante herencia
Le permitimos al usuario agregar la página a su lista de favoritos del explorador

Usar Frames cuando:

Es costoso hacer un refresh completo de la página
Le permitimos al usuario refrescar sectores de la página en distintos momentos.
El armado del HTML contenido en el frame es muy complejo de generar

Realmente no he encontrado casos en los que no vale la pena reemplazar la estrucura de Frames existente por el uso de MasterPages. En algunas situaciones el anidamiento de sucesivos frames hace la navegación compleja y que el código javascript a tal efecto se torne muy complejo.

Quien haya intentado hacer un Response.Redirect hacia otro frame sabe que no funciona. La redirección de páginas se refieren al Document en la que están actuando. Por lo tanto hay que escribir código DHTML para poder navegar en la jerarquía de frames contenidos en los framesets:

window.parent.parent.parent.parent

Esto es inevitable al utilizar frames, y potencialmente peligroso cuando se mezcla con la funcionalidad de Post-Backs de ASP.NET.

Supongamos que tenemos una página aspx que tiene un botón aceptar, el cual, luego de procesar todo lo necesario necesita forzar la navegación a otra página. Pero la navegación implica cargar HTML en otro frame que solicita la nueva página. Para ello deberíamos registrar un script de DHTML:

Private Sub btn_aceptar_Click(ByVal sender As System.Object, ByVal e As System.Web.UI.ImageClickEventArgs) Handles btn_aceptar.Click

'Procesamiento del botón aceptar

    Dim strClientScript As String
    strClientScript = "<script language=JavaScript> "
    strClientScript += "window.parent.location='" & "../navegacion.aspx?IdOpcion=3" & "'"
    strClientScript += " </script>"
    Me.RegisterStartupScript("navigate", strClientScript)

End Sub

Si bien esto logra el efecto, resulta costoso, ya que la respuesta del servidor luego de procesar la página es todo el HTML que la representa mas el script que acabamos de registrar. El cual se ejecuta no bien termina de parsearse la página en el Browser y hace la redirección. Conclusión, hemos transferido al explorador código HTML totalmente innecesario.

Para evitar todo ese código HTML, y enviar el browser solo el script necesario para la navegación, deberíamos hacer un Server.Transfer(). Esta instrucción corta la ejecución de la página corriente y comienza la ejecución de otra, anulando todo el buffer de salida de la primera y así evitando el HTML innecesario.

Private Sub btn_aceptar_Click(ByVal sender As System.Object, ByVal e As System.Web.UI.ImageClickEventArgs) Handles btn_aceptar.Click

'Procesamiento del botón aceptar

    'Dim strClientScript As String
    'strClientScript = "<script language=JavaScript> "
    'strClientScript += "window.parent.location='" & "../navegacion.aspx?IdOpcion=3" & "'"
    'strClientScript += " </script>"
    'Me.RegisterStartupScript("navigate", strClientScript)

HttpContext.Current.Items.Add("navigateTo", "../navegacion.aspx?IdOpcion=3")
Server.Transfer("redirect.aspx", True)

End Sub

Este es el código de la página redirect.aspx

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load    Dim strClientScript As String
   strClientScript = "<script language=JavaScript> "
   strClientScript += "window.parent.location='" & HttpContext.Current.Items.Item("navigateTo").ToString() & "'"
   strClientScript += " </script>"
   Me.RegisterStartupScript("navigate", strClientScript)

End Sub