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 qu... [Más]

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 emp... [Más]

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... [Más]

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) de... [Más]

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 HttpWebClientPro... [Más]

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.... [Más]

Pensemos por un momento cómo podemos construir en C# 1.0 o 1.1, una clase contenedora de datos que se pueda utilizar con la construcción foreach para iterar por los elementos que contiene... Para empezar la clase debe implementar la interface IEnumerable. Esto tampoco supone mucho trabajo ya que, al fin y al cabo, sólo se debe implementar un método, GetEnumerator(). Ahí se empieza complicar la cosa un poco ya que este método devolverá un objeto que implementa la interfaz IEnumerator y que nosotros debemos definir también. La implementación de esta clase es algo más compleja y además debe mantener una referencia al objeto enumerable original. Ya de por sí, como podemos comprobar, se trata de algo bastante tedioso. Pero es que además de eso en algunos casos es algo muy complicado de hacer. Por ejemplo, si queremos implementar una clase enumerable que contenga los nodos de una jerarquía (un árbol de carpetas, por ejemplo) y que, enumerándolo con foreach, nos devuelva por el orden correc... [Más]