Un título algo duro ¿no? Se trata de un problema común cuando trabajamos con Webservices. Al incluir la referencia del webservice con el que trabajamos tenemos que indicar la IP o el nombre del equipo que provee el servicio. Pero ¿Qué pasa cuando esa dirección cambia? Normalmente, que tenemos que recompilar la aplicación. Si esto hay que hacerlo en pocas ocasiones no hay problema, pero si los cambios son frecuentes lo indicado es hacer que esta dirección se pudiera configurar desde el web.config.

Esto es posible hacerlo de dos maneras, cada una con sus ventajas e inconvenientes. Las dos necesitan añadir una clave en el web.config:

La primera es utilizando la fuerza bruta. Cada vez que llamemos al Webservice cambiamos su URL. POr ejemplo:

service = new Acmeco.AcmecoService();
service.Timeout = 10000;
service.Url = ConfigurationSettings.AppSettings["MyWebServiceURL"];

(Ejemplo tomado de aquí: Setting Web Service References Dynamically )

Si llamamos al servicio en pocos sitios esta solución es completamente válida, pero si lo hacemos en muchos sitios puede ser una labor engorrosa.

Otra solución es cambiar la URL en la referencia que importa el IDE de .NET. Lo encontramos aquí:

Web References –> my_web_service –> Reference.map –> Reference.cs

Este archivo se genera automáticamente cuando añadimos la referencia así que ¡ojo! si volvemos importar la referencia porque el proveedor del servicio ha realizado cambios tendremos que volver a modificar el archivo. Una vez allí cambiamos:

this.Url = System.Configuration.ConfigurationManager.AppSettings["MyWebServiceURL"];

Si nos encontramos con que lo anterior nos da un error, tenemos que añadir la referencia System.configuration en las referencias.

Con esto tendremos un webservice cuya dirección podremos configurar dinámicamente desde el web.config

Los programadores de PHP están acostumbrados a poder llamar a una función por vía de una variable. Esto es muy útil para ejecutar determinadas funciones dependiendo de las reacciones del usuarios. Una explicación de esto se encuentra en este enlace: funciones variables. Basta con asignar a una variable el nombre de la función y llamarla:

$mifuncion=”RaizCuadrada”;

$mifuncion(4);

Sin embargo, realizar lo mismo en .NET no es tan fácil ni intuitivo. Pero puede conseguirse. Para ello viene en nuestra ayuda la función GetMethod. El siguiente código nos permite hacerlo:

Type t;
MethodInfo mi;

try
{

//Cargamos el Type e Instanciamos la clase
t = pruebas.GetType();

//Cargamos el método y lo ejecutamos
mi = t.GetMethod(”Nombre de la función o método”); // Get the method
mi.Invoke(pruebas, null); // Call the method
}
catch (Exception ex)
{
throw ex;
}
finally
{
t = null;
mi = null;
}

Hay que tener cuidado con los valores nulos si no encuentra la función.

Cuando se crean clases en VB .NET se pueden sobreescribir los métodos de la clase base. Esto es lógico y permitido en cualquier lenguaje orientado a objetos. Pero VB incorpora una característica curiosa, la posibilidad de ocultar (Shadow) el método de la clase base. Las diferencias son sutiles, pero están muy bien explicadas en el siguiente artículo:

Cuidado con lo que deseas…

Para resumirlo pronto: Shadow sólo debe utilizarse en casos muy contados, ya que la forma correcta es Overrides. La diferencia de comportamiento estriba cuando un objeto de la clase base contiene un objeto de la clase derivada. Si el método se ha definido con Overrides siempre se usa el método de la subclase. Si se ha ocultado con Shadows siempre se usa el de la clase base. Un artículo muy ilustrativo.