El número 8 de la revista DotNetMania está puesto a disposición pública para que el que lo desee lo pueda descargar en PDF y leerlo de manera gratuita.

Puedes consultar sus contenidos en http://www.dotnetmania.com/Articulos/008/index.html, y descargarlo usando el enlace que aparece en el lateral de la página o desde la sección "Números publicados".

¡Qué te aproveche!

(Pincha sobre la imagen para ver la felicitación en Flash)

• FELICES NAVIDADES Y PROSPERO AÑO NUEVO.
• BOAS FESTAS E PROSPERO ANINOVO.
• BON NADAL I FELIÇ ANY NOU.
• ZORIONAK ETA URTE BERRI ON.

En mi anterior "post" comentaba la forma de conseguir que los proyectos de Visual Studio ubicados en un recurso compartido funcionasen con las mismas capacidades que los locales, lo cual pasaba por modificar la configuración de seguridad de la plataforma.

Alguna gente que ha intentado seguir el método me ha comentado que tenían un problema gordo, y es que cuando intentaban enumerar las políticas existentes en su equipo (o en cualquier otra rama), se le mostraba un error en el árbol como el que se puede observar en la siguiente figura:

(Pulsa para agrandar)

Algunas versiones no inglesas de la herramienta de configuración de .NET tienen un problema con los recursos localizados y producen este indeseable efecto. El problema se produce debido a problemas de seguridad cargando los recursos localizados y muestra en su lugar un mensaje de error en inglés.

Para solucionarlo sólo hay que resetear la cofiguración de las políticas de acceso a código y todo volverá a la normalidad. Basta con abrir una línea de comandos y escribir:

caspol -all -reset

para que todo funcione a la perfección.

Es muy frecuente en empresas que los archivos de trabajo residan en un servidor, de forma que se mantengan centralizados (para copias de seguridad, versionamiento, etc...) y varias personas puedan trabajar al mismo tiempo sobre ellos.

En el caso de los programadores de Visual Studio esto puede suponer un problema.

Dicho problema viene dado porque, si ejecutamos Visual Studio con código que reside en un recurso compartido de la red (aunque sea una unidad "mapeada"), obtendremos advertencias a la hora de ejecutarlo e incluso errores en función del código que hayamos escrito, sobre todo en modo de depuración. Este problema se produce aunque tengamos control total para gestionar los archivos del recurso compartido.

Este comportamiento se debe a la configuración de seguridad por defecto de .NET, que trata de manera diferente al código según sea su procedencia. En el caso de código o programas ubicados en nuestra red local se usan los criterios de seguridad de "LocalIntranet", mientras que cuando ejecutamos un programa .NET en nuestro propio equipo el perfil de seguridad es "FullTrust" (es decir, confianza total).

Para evitar el problema sólo tenemos que cambiar la configuración de la seguridad .NET. Se utiliza la herramienta de configuración de la plataforma .NET, que podrás encontrar dentro de las Herramientas Administrativas del sistema. En ésta hay que buscar la directiva de seguridad para "LocalIntranet_Zone". En sus propiedades, dentro de la pestaña "Conjunto de permisos" cambia "LocalIntranet" por "FullTrust".

Ya está. A partir de ahora ya no habrá problemas para usar Visual Studio con proyectos guardados en la red local. Eso sí, habrá que tener especial cuidado con lo que ejecutamos desde ubicaciones remotas pues ahora todos los programas en recursos compartidos tienen los mismos permisos que si estuvieran en local y puede ser peligroso.

Imaginemos que tenemos que crear un servicio Web para una tarea determinada (para simplificar, digamos, realziar una suma), y dicha tarea debe trabajar con diferentes tipos de datos.

En una clase .NET podemos crear versiones sobrecargadas de un método cada una de las cuales tomará el tipo de datos pertinente, siendo el propio compilador el que llamará a la versión sobrecargada que convenga encada caso.

En el caso de un servicio Web a priori puede parecer que no seremos capaces de obtener el mismo efecto, ya que no podemos exponer dos métodos Web con el mismo nombre. Sin embargo existe un atributo llamado MessageName que permite conseguir un efecto similar.

MessageName se utiliza para asignar alias a los métodos Web que definamos, de forma que podemos identificar de manera única a cada uno de ellos, incluso aunque el nombre asignado a la función sea el mismo. De este modo, si queremos exponer como servicio Web una clase que posee un método con varias sobrecargas sólo tenemos que emplear este atributo asignándole un identificador diferente a cada una. Por ejemplo (sacado de la propia documentación de la plataforma .NET):

 public class Calculadora : WebService {
    // El valor de MessageName coge como valor por defect el del método, en este caso 'Sumar'
    [WebMethod]
    public int Sumar(int i, int j) {
       return i + j;
    }  
    [WebMethod(MessageName="Sumar2")]
    public int Add(int i, int j, int k) {
       return i + j + k;
    }  
 }

Con esto conseguimos el efecto de métodos Web sobrecargados sin demasiado esfuerzo.

Hoy estaba echando un vistazo al Blog de un lector boliviano de mi Blog y tenía este estupendo recurso en uno de los "post": www.koders.com

Se trata de un buscador de código fuente. Lo que hace es buscar los términos que le pongamos en la búsqueda dentro del código fuente de miles de archivos Open Source que hay por el mundo adelante. Es especialmente útil para encontrar ejemplos de uso de APIs, módulos que se ocupen de determinadas tareas, etc... Hay que echarle imaginación a la hora de buscar para encontrar lo que necesitamos ya que busca exclusivamente dentro del código y hay que "cambiar el chip" respecto a una búsqueda normal como la que haríamos en Google (por palabras). Os lo recomiendo (y también el Blog en el que lo encontré).

El portal ClubDevelopers.com dedicado a la programación Web con .NET, Delphi y C&C++ ha incluido en su página principal el contenido sindicado (RSS) de este blog (JASoft.org), junto a las noticias y artículos de MSDN, Mono Project y BULMA. ¡Gracias!

¡Añáde ese portal también a tus favoritos!.

Cuando creamos una vesión móvil de una aplicación Web suele veir bien dar acceso a ésta desde la misma URL tanto a los clientes Web "normales" como a los usuarios que accedan desde el móvil. Hay quien directamente construye dos URLs diferentes, en plan, www.miapp.com y movil.miapp.com, pero es un poco excesivo ¿verdad?

La mejor manera de hacerlo es meter cada aplicación en su propia carpeta e incluir un código similar a esto en la página por defecto del dominio por el que se accede a ambas aplicaciones:

<script runat="server" language="c#">
    public void Page_Load(Object sender, EventArgs e)
    {
        if (Request.Browser["IsMobileDevice"] == "true" )
        {
            Response.Redirect("AppMovil/");
        }
        else
        {
            Response.Redirect("AppWeb/");
        }
    }
</script>

Pero OJO, esto no es todo aunque pueda parecerlo.

Si lo dejamos así simplemente veremos que funcionará en muchos casos pero en muchos otros no será así. Esto se debe a que en muchos dispositivos móviles no están soportadas las URLs relativas, es decir, que siempre hay que facilitarle la URL completa para que puedan encontrar los recursos. Podemos hacerlo metiéndola siempre en el código pero es un poco suplicio. Los diseñadores de ASP.NET ya pensaron en eso e incluyeron un atributo dentro de Web.Config que nos permite olvidarnos del asunto. Se trata de useFullyQualifiedRedirectUrl. Basta con asignarlo para que se usen de manera automática URLs completas y el código anterior funcione siempre bien:

<configuration>
    <system.web>
        <httpRuntime useFullyQualifiedRedirectUrl="true" />
    </system.web>
</configuration>

Es la típica cosa que la probamos y parece estar bien y,de repente, un mes más tarde, nos empiezan a bombardear los usuarios con llamadas, así que hay que tenerla miy en cuenta.

La versión publicada es la candidata a publicación final del Service Pack 1 para Windows Server 2003, y hay que señalar que está destinada sólo para su instalación en entornos de prueba.  Aunque éste proceso puede ser recomendable en determinados entornos para comprobar y evaluar las nuevas características y su impacto en los sistemas.

El SP1 para Windows Server 2003 proporciona múltiples mejoras de seguridad que pueden ser de interés para un gran número de administradores. De hecho, todas las razones anunciadas en el "Top Ten de las razones para instalar Windows Server 2003 SP1" están relacionadas de forma directa con la mejora de seguridad.

A diferencia de otros Service Pack que solo podían considerarse como la agrupación de todos los parches publicados, Microsoft ha aprovechado la oportunidad para introducir nuevas funcionalidades a Windows Server 2003.

Las mejoras incluidas son un Firewall similar al publicado con Windows XP Service Pack 2, Post-Setup Security Updates (PSSU) destinado a bloquear todas las conexiones entrantes tras la instalación hasta que se ejecute Windows Update para instalar las últimas actualizaciones necesarias y Security Configuration Wizard (SCW) destinado a bloquear los puertos y servicios no necesarios en función de los roles asignados al servidor.

También se han incluido mejoras en las funcionalidades originales de Windows Server 2003, destinadas a aumentar la seguridad, fiabilidad y la productividad.

Más información sobre esta descarga y sus características en:
http://www.microsoft.com/windowsserver2003/downloads/servicepacks/sp1/default.mspx

Fuente: Hispasec

Poco a poco, sin prisa pero sin pausa, estoy metiendo aquí algunos de los archivos que tenía en mi anterior página, en la era pre-Blog.

Uno de los controles interesantes que tenía en la antigua JASoft.org era este: AniIcon.ocx.

Se trata de un control ActiveX escrito íntegramente en Visual Basic que permite utilizar iconos animados en los formularios. Puede ser útil para destacar ciertas cosas en la interfaz de usuario o como simple divertimento.

El código fuente está comentado por lo que es relativamente fácil de seguir. Es un buen ejemplo de cómo se manejan archivos RIFF, empleados también en otros formatos genéricos aparte de en iconos animados (como algunos archivos de sonido, gráficos,etc...)

Se puede descargar pulsando aquí.

¿Alguien se atreve a migrarlo a .NET y Windows Forms? Debería ser fácil escribirlo en VB.NET. Si alguien lo hace le agradeceré que tenga la deferencia de enviármelo ;-)

A ver, cuestión peliaguda...

En progrmación COM tradicional lo que se solía utilizar a la hora de conectar con un recurso Web mediante HTTP, fuera éste una página o un servicio Web, se solía emplear la biblioteca WinHTTP o bien la clase que a tal efecto proporcionaban las bibliotecas MSXML. En ambos casos si la conectividad se obtenía a través de un Proxy era necesario configurarlo usando una utilidad externa de línea de comandos, lo cual era un verdadero problema en distribuciones grandes o que debíamos hacer manualmente. No digamos si la aplicaci´no era en un servidor Web al que sólo teníamos acceso mediante FTP.

Con .NET la vida es mucho más fácil, como ya es sabido. Así, por ejemplo, cuando vamos a consumir un servicio Web desde una aplicación .NET, al añadir una referencia Web se crea una clase que nos abstrae de la complejidad de llamar a los métodos remotos y gestionar las comunicaciones HTTP. Esta clase hereda de SoapHttpClientProtocol, que a su vez hereda de HttpWebClientProtocol. Ésta dispone de una propiedad llamada Proxy del tipo System.Net.IWebProxy, que nos permite especificar la información del proxy a utilizar.

De este modo, si necesitamos especificar información sobre un Proxy para acceder a la Web basta con escribir código análogo al siguiente:

string DireccionDelProxy = "10.0.0.80";  //La URL o dirección IP del servidor proxy
int PuertoDelProxy = 8080;   //Puerto por el que escucha el proxy
//Se crea una instancia del objeto proxy
System.Net.WebProxy miProxy = new System.Net.WebProxy(DireccionDelProxy, PuertoDelProxy);
//y se asigna al envoltorio del servicio Web (o similar)
miServicio.Proxy = miProxy;

Como vemos muy sencillo.

Si además fuese necesario utilizar unas credenciales (nombre + clave) para poder hacer uso del Proxy sólo tenemos que crear una nueva instancia de la clase System.Net.NetworkCredentials y asignarla a la propiedad Credentials del proxy, así:

miProxy.Credentials = new System.Net.Credentials("Usuario", "contraseña", "dominio");

En algunas ocasiones puede resultar interesante averiguar desde qué otro método o métodos se ha llamado a la función actual. las utilidades pueden ser varias, por ejemplo:

• Un método genérico que se use para llamar a procedimientos almacenados en una base de datos, cuyo nombre (el de los procedimientos) sea idéntico al procedimiento desde el que se llama. Puede acelerar mucho el desarrolo.
• Un método que queremos que sea llamado exclusivamente desde otro procedimiento concreto.
• Una función que deba ser llamada en exclusiva desde el constructor de una clase o desde Main().
• Experimentar con esto, que es interesante, hombre... ;-)

En fin, el caso es que con la plataforma .NET casi cualquier cosa es posible y encima de una forma relativamente sencilla. En este caso debemos usar la clase StackTrace del espacio de nombres System.Diagnostics. Ésta nos permite navegar por la pila de llamadas de la aplicaicón obteniendo información sobre los diferentes métodos que se encuentren en ella. Por lo tanto la solución es directa ya que basta con llamar a los métodos correspondientes (GetFrame y GetMethod) para ir obteniendo la información que deseemos. El siguiente código ilustra una función llamada GetCallerName() que nos permite averiguar el nombre de la función desde la que se ha llamado a la actual:

private static string GetCallerName()
 {
    StackTrace trace = new StackTrace(StackTrace.METHODS_TO_SKIP+2);
     StackFrame frame = trace.GetFrame(0);
     MethodBase caller = frame.GetMethod();
     if( caller == null )
     {
      throw new InvalidProgramException();
     }
     return caller.Name;
   }

Hay que fijarse en un detalle. En el constructor de la clase StackTrace, al principio, le indicamos que queremos posicionar la información de la traza en dos métodos por encima del actual (constante METHODS_TO_SKIP + 2). Si no lo hiciéramos obtendríamos en primer lugar la información del método actual, es decir, del propio GetCallername. Eso implica saltarse un "frame" de la pila de llamadas. De todos modos hemos de tener encuenta que a esta función la llamamos desde aquella sobre la que queremos saber quién la llamó, por lo que ésta también debemos saltárnosla, de ahí el que le sumemos uno más. para entendelo mejor. Supongamos que escribimos el siguiente código:

private static void Funcion1()
{
   Funcion2();
}
private static void Funcion2()
{
   Funcion3();
}
private static void Funcion3()
{
   Console.Write(GetCallerName());
}

La pila de llamadas sería la siguiente vista desde dentro de nuestra función GetCallerName:

Funcion1 > Funcion2 > Funcion3 > GetCallerName

Es decir, nos tenemos que saltar la función actual y la función desde la que se está llamando yasí obtenemos directamente en el primer elemento dela pila el "frame" de la función que nos interesa. También podíamos haber obviado este salto en el constructor y habernos ido directamente al tercer elemento de la pila de llamadas, pero esta técnica es más eficiente.

Al llamar al método GetFrame de la traza, obtenemos una referencia a un objeto de la clase StackFrame, cuyo método GetMethod nos devuelve una referencia a un objeto de la clase MethodBase. Ésta está en el espacio de nombres System.Reflection y permite obtener toda la información que necesitemos del método que representa. Así que lo único que resta es acceder a sus propiedad, en este caso su nombre (propiedad Name) y listo.

He incluido un archivo de ejemplo en el que se muestra una función similar y otra que permite obtener directametne una volcado de la pila de llamadas en la consola. Está escrito en C# pero es muy fácil de pasar a VB.NET.

Esta semana pasada ha sido de locura, por lo que no me ha sido posible escribir nada en el Blog :-(

Me consta que ha habido muchas visitas así que mis disculpas a esa gente....

Esta semana con el famoso puente aquí en España me imagino que será parecida (aunque no por trabajo sino por todo lo contrario), aunque procuraré publicar algunas cosas que tengo en la recámara.

De hecho el mes de diciembre entero es complicado entre unas cosas y otras (mucho viaje de trabajo y mucho día festivo), pero bueno, espero llegar al menos al nivel de publicaciones de noviembre :-)

Saludos a todos.