Hecho este descargo, el motivo fue que hice un pequeño programita que escribía en un archivo, para ello me basé en la ayuda de Microsoft que utilizaba el keyword using de la siguiente manera

using(StreamWriter w = new StreamWriter("BuildAll.sql")) {
// hago lo que quiero con el writer
}

Un poco tardíamente (ya que esto existe hace varios años)  me surgió la duda de para que servía realmente using. El saber popular dice que es para asegurarse que se liberan los recursos que podrían haberse reservado, pero esta explicación no era suficiente para mi y quería saber realmente como funcionaba.

Consultando en internet encontré en CodeProject el artículo titulado The “using” Keyword in C# en el cual el autor comenta  su investigación sobre el asunto. Recomiendo a cualquiera que le interese un poco el funcionamiento interno de las cosas que le pegue una leida a ese artículo.

En resumen lo que dice es que lo que hace este keyword es crear un bloque try..finally, en donde como última acción se realiza un dispose del objeto que figura en el parámetro del using. Y que si la clase que se esta intentando limpiar no implementa correctamente la interfaz IDisposable no sirve de mucho.

En fin, esto más que nada me pareció una curiosidad que a otros les parecio interesante que escribiera aquí.

La propuesta es muy similar a lo que Java llama Filtros. Básicamente todo request que llegue al servidor, pasaría por estos httpModules quienes harían su trabajo y toman decisiones. Para aquellos que quieren entender de qué estoy hablando en 5 minutos, la idea es muy simple un patrón Observer. Lo que hay que hacer es:

1. Definir estos módulos (así los bautizó MS) deben estar definidas para escuchar un cierto evento que ocurra con el servidor. Por ejemplo, GET (para ver todo los eventos que se pueden atrapar, ver este link)
2. Modificar el web.config para agregar ese módulo a la configuración de la aplicación web.
3. Tener precaución, porque este filtro actuará sobre todo acceso que se realice con el servidor y nos podría ocasionar problemas si queremos redirigir a una página de error, por ejemplo.

En nuestro caso, necesitábamos evitar que navegadores viejos ingresaran a un sitio. Tan simple como eso. Tuvimos que tomar algunas precauciones, pero luego de mucha búsqueda encontramos una solucíon muy satisfactoria con los módulos (y claramente superior a cualquier chanchada). Aquí les adjunto el código para que lo vean (como dice el dicho: El camino se hace rodando)

using System;
using System.Web;
using log4net;

namespace modulos
{
	public class OldBrowserModule : IHttpModule
	{
		#region IHttpModule Members

		public void Init(HttpApplication application)
		{
			application.BeginRequest += new EventHandler(OnBeginRequest);
		}
		public void Dispose() { }

		#endregion

		public delegate void MyEventHandler(Object s, EventArgs e);
		private MyEventHandler _eventHandler = null;

		public event MyEventHandler MyEvent
		{
			add { _eventHandler += value; }
			remove { _eventHandler -= value; }
		}

		private bool applyFilter(HttpRequest req)
		{
			bool retVal = true;
			retVal != !(req.FilePath.IndexOf("UnsupportedBrowserGlobal.aspx") > 0);
			retVal != req.FilePath.EndsWith(".aspx");
			return retVal;

		}

		public void OnBeginRequest(Object s, EventArgs e)
		{
			HttpApplication app = (HttpApplication)s;
			HttpRequest req = app.Context.Request;
			if (applyFilter(req))
			{
				if (req.Browser.Browser.Equals("IE") && req.Browser.MajorVersion < 6)
				{
					app.Response.Redirect("~/UnsupportedBrowserGlobal.aspx");
				}
			}
		}

	}
}

Es muy importante la confiabilidad de los datos en la base de datos. Recordemos que el Membership Provider de .NET usa unas tablas en el servidor específicamente para su propio funcionamiento.

Lo que pasó fue que el Membership Provider se asocia con un Application Name, y este nombre, si no se especifica, se calcula. Y la forma de calcularlo del IIS es diferente a la del ASP.NET Development Server.

Por tal motivo, es siempre bueno recordar que hay que especificar puntualmente cual es el nombre de la aplicación, para que despues, un movimiento de servidor u otro cambio no afecte en nada al sistema.

Esto lo aprendí de ScottGu’s Blog en donde también explica como se especifica este nombre muy facilmente.

En resumen, el Membership provider debe quedar de la siguiente manera.

Algo similar se debe hacer con el Role Provider si es que se emplea uno.

Yo usé como nombre “/” porque ese es el nombre de applicacion que ya tenía anteriormente, pero en forma implícita. Sería recomendable usar algún otro nombre, para de esa manera poder tener tal vez varias aplicaciones corriendo sobre la misma base de datos, y con permisos diferentes.

Sin embargo, si heredo de CompositeControl, no tengo esa opción de pasarle al constructor un parámetro, y por default simpre usará un Span.

Si yo quiero que mi clase heredada de CustomControl tenga un tag diferente al div, deberé sobrecargar la propiedad TagKey, como hago en este ejemplo para que mis controles estén contenidos en un tag Div.

public class FiltersControl : CompositeControl
{
    ///

    /// Envolvemos el control en un tag Div
    /// 

    protected override HtmlTextWriterTag TagKey
    {
        get
        {
            return HtmlTextWriterTag.Div;
        }
    }
}

Me tropecé con un montón de trabas, así que en lugar de intentar mi problema original, comencé con casos muchos mas simples para intentar apuntar a cada problema que tenía específico. El más molesto de todos ellos era que el ViewState se perdía en cada postback.

Originalmente mi clase de prueba, que agregaba dos textbox y un botón para testear el postback era así:

public class FiltersControl : WebControl
{
    public FiltersControl() : base(HtmlTextWriterTag.Div) { }

    protected override void CreateChildControls()
    {
        TextBox text1 = new TextBox();
        TextBox text2 = new TextBox();

        Button button = new Button();
        button.Text = "Postback!";

        Controls.Add(text1);
        Controls.Add(text2);
        Controls.Add(button);
    }
}

Pero fallaba inmediatamente, sin embargo si lo heredaba de CompositeControl funcionaba perfectamente. Gracias a Lutz Roeder’s Reflector e investigando como funcionaba CompositeControl llegué a la conclusión que agregando únicamente la interfaz marcador INamingContainer se solucionaban todos los problemas, al menos en ese código tan simple.

Así que el siguiente código funciona como uno esperaría, y se puede apreciar que es idéntico al anterior, pero esta vez la clase tiene una interfaz.

public class FiltersControl : WebControl, INamingContainer
{
    public FiltersControl() : base(HtmlTextWriterTag.Div) { }

    protected override void CreateChildControls()
    {
        TextBox text1 = new TextBox();
        TextBox text2 = new TextBox();

        Button button = new Button();
        button.Text = "Postback!";

        Controls.Add(text1);
        Controls.Add(text2);
        Controls.Add(button);
    }
}

Moraleja, si implementan un control, que contiene otros controles, aún cuando saben que no habrá conflictos de nombres, o heredan de CompositeControl o lo hacen de Control (o alguna clase que herede) y marcan la clase con la interfaz INamingConteiner para no tener problemas con el ViewState

El problema que me surgió hoy, fue que necesitaba utilizar el método IList.Remove() pasándole un objeto pero para mi sorpresa no eliminaba nada. Entonces comenzando a investigar encontré el método Equals() y la sobrecarga del operador == y estas son las conclusiones a las que llegué.

Tanto Equals() como operator== tienen por default la misma implementación. O sea las siguientes expresiones son equivalentes, si no redefino ni el método Equals ni el operador igual.

o1  == o2;
o1.Equals(o2);

¿Y como es la comparación que realizan? Simplemente una comparación de referencias (punteros para los mas vejetes como yo) Si dos objetos representan lo mismo, pero son instancias diferentes, y no sobrecarga ni el opeardor == ni Equals, entonces en cualquier comparación serán diferentes.

Tal vez con un ejemplo se aprecie mejor.Imaginemos que tenemos la clase NumeroComplejo que su constructor requiere dos parámetros: el primero la parte real, y el segundo la parte imaginaria. Entonces el siguiente código dirá dos veces que son números diferentes a pesar de ser conceptualmente el mismo numero.

NumeroComplejo num1 = new NumeroComplejo(1,2);
NumeroComplejo num2 = new NumeroComplejo(1,2);

Console.WriteLine(num1 == num2);
Console.WriteLine(num1.Equals(num2));

Esto se debe a que tanto == como Equals comparan la instancia, sin saber nada de su contenido. Ni siquiera hacen una comparación bit a bit, así que como son objeto diferentes, la comparación dice que lo son.

Obviamente, a nosotros nos convendría que digan que son iguales, no es muy intuitivo ver que código que básicamente dice if(1==1) no se ejecute, o en mi caso, sabiendo que una lista tenía un objeto especifico, llamar al método Remove con un objeto conceptualmente igual y que no elimine nada.

Entonces. ¿Que método debía sobrecargar? En algunos lugares leí que todos, pero no me convencía ese enfoque. Después de todo alguna diferencia deben tener, sino no tendría sentido que existan los dos. Por tal motivo seguí investigando y encontré en el lugar mas obvio, la msdn de microsoft, algunos indicios que me indicaron lo siguiente.

1. Ni microsoft sabe bien la diferencia
2. Si es un tipo de valor, efectivamente recomiendan sobrecargar todos
3. Si es un tipo de referencia, se debe sobrecargar Equals
4. Todos concuerdan que si se redefine Equals, hay que sobrecargar GetHashCode, y si se redefine el operador == se debe sobrecargar el operador !=

O sea, cuando la clase es un numero complejo, o algo en que haga sentido sumar, restar y operar en general, entonces debería sobrecargar todos los operadores porque representa un valor… en cambio si fuera un objeto de clase Persona, lo correcto sería sobrecargar solo Equals() y utilizar, asimismo Equals() cuando se quieren comparar por su valor.

Admito que es una linea bastante delgada, pero creo que esa es la idea, lo cual no sería raro ya que se parece mucho también a la misma dualidad que hay en Java.

En fin, mi caso puntual hoy era un objeto de clase Requerimiento, por lo cual redefiní el método Equals() y magicamente mi IList comenzó a eliminar objetos. Lo cual significa que esta implementada usando el método Equals en lugar del operador== y solo espero todas las demás clases tengan el mismo comportamiento.

Descubrí que no siempre el atributo DesignMode funciona como se piensa, asi que lo que esperaba fuera un problemita simple y rapido de solucionar, resulto en una invetigación en internet de como hacer mi propio DesignMode que sea confiable.

Aparentemene el problema se debe a que DesignMode solo informa si el control/formulario que se esta editando actualmente esta en tiempo de diseño, pero si es parte de una herencia, y es el padre el que necesita el DesignMode, a este le dice que no esta en diseño (lo cual es entre comillas cierto, ya que no es el padre el que se esta editando, sino el hijo pero genera conflictos y exceptions igual)

En fin, en internet encontré varias formas, tal vez todas igual de válidas y efectivas, pero al fin y al cabo la que yo implementé (lo cual no significa que sea la mejor) es la que figura en el blog de Derik Whittaker

Este método consiste en definir un nuevo método llamado IsInDesignMode (que yo agregé a una clase propia de la cual heredan todos mis formularios) que realiza dos checkeos para determinar si estamos en la IDE o no.

El primer chequeo consiste en el clásico Designtime, si este retorna false, hace el segundo chequeo (si ya este retornó true no hace falta) El segundo chequeo es ver cual es el nombre del proceso que se está ejecutando. Si es DEVENV estamos dentro de la IDE, por lo tanto en tiempo de diseño.

Copio aquí el código, pero para mayores referencias aconsejo ver su blog

public static bool IsInDesignMode()
{
	bool returnFlag = false;
#if DEBUG
	if ( System.ComponentModel.LicenseManager.UsageMode ==

		System.ComponentModel.LicenseUsageMode.Designtime )
	{
		returnFlag = true;
	}
	else if ( Process.GetCurrentProcess().ProcessName.ToUpper().Equals( "DEVENV" ) )
	{
		returnFlag = true;
	}
#endif
	return returnFlag;
}

No pequeña fue mi desilusión al advertir que no es trivial el hacer esto, en especial cuando Vb6 recuerdo que tenía algo, rudimentario, pero útil que hacía esto mismo.

En fin, buscando en internet encontré varias formas de conseguir este objetivo usando macros o mini programitas. Supongo que cuando tenga más tiempo usaré algunas de ellas.

Les dejo, entonces, dos sites con información de este tema http://weblogs.asp.net/egarmon/archive/2003/12/03/41101.aspx y http://www.codeproject.com/KB/macros/VSBuildNumberAutomation.aspx