En Visual Basic (clásico y .NET) hay un par de funciones para tratamiento de matrices que siempre me han parecido muy útiles. Se trata de Redim y Redim Preserve. Ambas sirven para redimensionar una matriz sin tener que volver a declararla. La diferencia entre ellas estriba en que la primera crea una amtriz nueva y se pierden los elementos que contenía, mientras que la segunda (la más interesante), permite crear una matriz nueva de diferente tamaño y que conserva los elementos que ésta contuviera previamente. En C# la primera función tiene poco sentido ya que podemos redefinir una matriz cuando queramos, por ejemplo: int[] matriz = new int[5];matriz = new int[8]; Ningún problema con esto. Por lo único que se me ocurre ahora mismo que podríamos necesitar la función Redim es para hacer lo anterior de forma genérica, es decir, para poder hacerlo sin importar el tipo de datos que contiene la matriz original. Esta función sería tan sencilla como la siguiente:  private Array Redim(Arr... [Más]

Esta cuestión es probable que a alguno le resulte trivial, si bien es cierto que a muchos programadores de C# (incluso a algunos experimentados) se les pasa por alto a veces, así que no está de más hacer un recordatorio. La cuestión es la siguiente: ¿cómo construyo un método (función) que me permita pasarle un número cualquiera de parámetros? Por ejemplo, imaginemos para simplificar que quiero construir una función que sume todos los enteros que se le pasen. Puedo definir varias versiones de la misma, cada una de las cuales tomando un número diferente de parámetros (un entero, dos enteros, tres, etc...). Hacerlo así, obviamente, aparte de ser una pérdida de tiempo es una cuestión bastante absurda: siempre encontraríamos un límite de parámetros, aparte de ser algo así como "matar moscas a cañonazos". La solución en C# es muy sencilla: basta con indicarle al compilador que nuestra función necesitará un número arbitrario de parámetros, que no sabemos de antemano cuántos serán. Esto se ... [Más]

Este nuevo dispositivo puede representar un nuevo hito en el sector de la computación portátil, al constituir un híbrido que, en el tamaño de una PDA, encierra una completa computadora operando bajo Windows XP. Hasta ahora, el OQO parecía más un caso típico de "vaporware" (software o hardware que se anuncia, despierta grandes expectativas, pero no se llega a presentar nunca de forma oficial como producto acabado) que una apuesta de futuro real. No obstante, recientemente ha sido presentado al público y lanzado a la venta. El aparato en cuestión representa un "gadget" electrónico muy avanzado, una computadora personal portátil que monta un procesador Crusoe de Transmeta a 1 Ghz., disco duro de 20 Gb., 256 Mb. de RAM DDR, conectividad a redes inalámbricas 802.11b, Bluetooth, FireWire, USB 1.1, y una docking station que incluye otro puerto USB, otro FireWire y puerto Ethernet. Todo esto encerrado en una minúscula caja de tamaño no muy superior al de una PDA: 12,4 centímetros de largo p... [Más]

Las expresiones regulares son una de las herramientas más útiles con las que contamos los programadores a la hora de analizar cadenas de texto, esto es, contenidos de archivos, expresiones y comandos, etc... Por analizar me refiero no sólo a buscar partes de textos sino a extraerlas, transformarlas, y muchas otras tareas. Se trata de un elemento que desde mi punto de vista todo programador que se precie debiera conocer. Las expresioes regulares pueden llegar a ser muy complejas. Cuando se establece una expresión regular se genera en memoria código especializado que implementa el análisis indicado por éstas. Debido a ello cada vez que se declara una se debe generar dicho código, lo cual puede ser más o menos costoso en función de la complejidad de la expresión regular. Para expresiones sencillas no tendremos demasiado problema. Con expresiones muy complejas que usemos mucha veces (muy a menudo) dentro de una aplicación esta compilación previa ya puede ser más significativa. Para mejo... [Más]

Al hilo del post de ayer me parece apropiado comentar que, para averiguar nosotros mismos qué permisos ha declarado un ensamblado (exe o dll), podemos utilizar una pequeña utilidad incluida en el SDK de la plataforma .NET llamado permview.exe. Su sintaxis es la siguiente: permview nombre_ensamblado.exe o permview nombre_ensamblado.exe /otuput: archivo.txt para enviar los resultados a un archivo. Lo que hace es "escupir" la información sobre los permisos declarados en formato XML, distinguiendo los permisos mínimos requeridos, los opcionales y los restringidos por la propia aplicación (tal y como vimos). Necesitarás ejecutarlo desde la consola del SDK o de Visual Studio. Puede resultar útil como herramienta de diagnóstico.

Si desarrollamos una aplicación que deberá tener acceso a ciertos recursos del sistema restingidos normalmente por motivos de seguridad (por ejemplo acceso al sistema de archivos) es posible que en determinados casos falle por carecer de dichos permisos. Esta carencia de permisos puede deberse a configuración del sistema (por ejemplo permisos NTFS) o bien por la cofiguración de permisos de la propia plataforma .NET (por ejemplo un ensamblado que se ejecute desde Internet o desde la Intranet). ¿No sería interesante en estos casos hacer que la aplicación, directamente, ni siquiera se ejecutase si no tiene los permisos suficientes? Se puede conseguir este efecto declarando directamente en el ensamblado qué permisos son necesarios. Incluso más interesante aún: se pueden restringir más todavía los permisos de nuestro programa respecto a los que le otorga el propio entorno (.NET o el sistema operativo) evitando así un uso indebido de nuestras aplicaciones. Para conseguirlo lo que se hace... [Más]

Desde el mes pasado ya está en funcionamiento la nueva revista Netveloper.com de la cual soy colaborador habitual. Se trata de una publicación dirigida específicamente a programadores de la plataforma .NET que tratará de traer periódicamente consejos, artículos y técnicas de programación a sus visitantes. Se divide en los siguientes apartados ASP.NET, ADO.NET, C#, VB.NET, SQL Server y Varios (en este último tienen cabida todo tipo de cosas). El último mes he publicado en ella media docena de consejos y artículos cortos inspirados en cuestiones que se han publicado en este Blog. Te la recomiendo.

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!

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

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]