Como comenté el otro día he estado jugueteando con el desarrollo .NET para Smartphone y lo cierto es que me he encontrado con cosas, al parecer básicas, pero de las que no sabía nada. Por ejemplo de algo tan tonto como los menús. La aplicación de ejemplo que quería hacer era un pequeño editor de texto que guardara el contenido cifrado (primera sorpresa: nada de System.Security.Criptography en Smartphones, hubo que buscarsela vida). Añadí un formulario, un campo de texto multilínea, código para ajustar su tamaño (nada de docking tampoco) y un menú de Abrir, Guardar, Salir y este tipo de cosas... El entorno no se quejaba pero en cuanto ejecutaba la "aplicación" recibía una excepción del tipo NotSupportedException. Para más "INRI", la línea en la que lo indicaba era una tontería (asignaba el título del formulario sin más). ¡Misterio! Bueno, el caso es que al final el error estaba en otro lugar (error de VS2003 marcando su ubicación, pasa bastante a menudo) y tenía que ver con la forma ... [Más]

He de reconocerlo: nunca he desarrollado nada para ejecutarse en Smartphones. Sin embargo últimamente y dado que existe desde hace tiempo un SDK para .NET y Visual Studio 2003, he estado haciendo unas pruebecillas tontas para cogerle el puntito al desarrollo en esta plataforma. La verdad es que estoy bastante desilusionado. El desarrollo desde .NET para Smartphone es bastante limitado y desde luego ofrece un soporte mucho menor de .NET que la Compact Framework (CF) de un PocketPC. Para casi todo hay que recurrir a P-Invoke y llamar a la API, el soporte de controles es muy reducido, etc... La documentación del SDK para la CF no es que sea para echar cohetes tampoco, la verdad :-( La versión 2.0 de la Compact Framework unifica el desarrollo en ambos sistemas. Ahora está en fase beta (con VS 2005) y está muchísimo mejor, pero claro sólo sirve para terminales con Windows Mobile 5.0. En Pocket PC existe la posibilidad de descargar l a beta de la CF 2.0 y todo listo, pero los Smartphone... [Más]

De acuerdo, se trata de un tarea bastante básica si sabes cómo hacerlo, claro, pero lo cierto es que es una pregunta que me hacen de vez en cuando amiguetes, visitantes, y demás.... Cuando te pones a buscar en las clases de entrada y salida de datos algo sobre renombrar un archivo, seguramente buscas algo así como un método Rename o similar. No existe tal método. El truco es que para renombrar un archivo lo que hay que hacer es... ¡moverlo!. Al mismo sitio pero con otro nombre. Así de tonto. Sabiendo esto la función renombrar sale directa: private static void RenameFile(string sFileFullPath,string sNewFileName) {  File.Move(sFileFullPath, Path.Combine(Path.GetDirectoryName(sFileFullPath), sNewFileName)); } Lo único que se hace es mover el archivo poniendo como destino la misma carpeta (se obtiene con Path.GetDirectoryName) pero un nombre diferente. ;-)

Haz una prueba.... Crea un servicio web sencillo (sumar dos números por ejemplo), y en IIS desactiva la casilla de autenticación anónima, dejando marcada alguna de las que exigen autenticación Windows. A continuación llama al servicio web desde un cliente cualquiera...  ¡Moooc! Falla, como es lógico, porque al contrario que al usarlo desde un navegador, no aparece un diálogo de autenticación que te solicite las credenciales. Entonces, ¿cómo hacemos? Lo normal es que queramos pasarle automáticamente las credenciales del usuario actual, para así validarlo y hacer la autorización en los métodos del servicio web en función de los roles a los que pertenezca. En realidad es muy sencillo conseguirlo, sólo hay que usar el siguiente código: servicioWeb.Credentials= System.Net.CredentialCache.DefaultCredentials; Esto hace que se le pasen las credenciales por defecto usando para ello un objeto de la clase NetworkCredential. Por cierto mucho cuidado al usar esto desde ciertos tipos de clie... [Más]

¿Te has preguntado alguna vez esto? Cuando en Internet Information Server tenemos activado el acceso anónimo a una aplicación Web, al ejecutar páginas ASP clásicas, éstas se ejecutan bajo el contexto de seguridad de una cuenta especial llamada IUSR_Nombremaquina, siendo "Nombremaquina" el nombre de red del servidor en el que está instalado IIS. Bueno en realidad esto es así cuando se usa el tipo de aislamiento bajo para la aplicación en las propiedades del servidor virtual de IIS. En caso de usar aislamiento medio o alto, la cuenta suplantada para el usuario anónimo se llama IWAM_NombreMaquina. En ASP.NET se suplanta por defecto al usuario ASPNET en Windows XP, o al usuario Servicio de Red en Windows Server 2003. Pero, con autenticación anónima en IIS, si se incluye en web.config lo siguiente: <identity impersonate="true"> Entonces el comportamiento es exactamente el mi... [Más]

Dese hace una temporadita está disponible para todo el mundo la Beta 2 de Visual Studio 2005. Se pude descargar desde MSDN, se incluye en CDs y DVDs de revistas y por lo tanto se está utilizando mucho. El problema con ella viene si la queremos instalar para sustituir a una beta anterior a una versión CTP. No se puede instalar tan alegremente sino que es necesario desinstalar primero los componentes anteriores que hubiese en el equipo. Y no vale hacerlo de cualquier forma. Es indispensable hacerlo en el orden correcto o podríamos tener muchos problemas. El orden adecuado de desinstalación es el siguiente (puedes saltarte lo que no tengas instalado): La versión anterior de Visual Studio 2005. SQL Server 2005 Express Edition SQL Server 2005 Tools SQL Native Client Visual Studio 64-bit prerequisites Beta (de ser el suerto que tiene un equipo de 64 bits) MSDN Express Library 2005 beta Visual Studio Tools for Office System 2005 Runtime Beta Devie Emulator 1.0 Beta .NET Compact Fr... [Más]

En Visual Basic "clásico" existía una propiedad del objeto App llamada PrevInstance que permitía averiguar de manera sencilla si ya se estaba ejecutando la aplicación actual, de forma que era inmediato evitar que se ejecutase dos veces el mismo programa. En .NET no existe nada similar pero es muy fácil simularlo gracias a la clase Process del espacio de nombres System.Diagnostics. El siguiente código permite conseguirlo:  private static bool PrevInstance() {      Process[] procesos = Process.GetProcessesByName(Process.GetCurrentProcess().ProcessName);      return (procesos.Length > 1); } Lo que hace es buscar los procesos existentes que tengan el mismo nombre que el proceso actual. Si hay más de uno es que ya se está ejecutando la aplicación y por lo tanto podemos decidir no continuar. Existen otras técnicas para conseguir el mismo efecto (por ejemplo usando Mutexes o marcadores globales de este estilo que son mucho más seguros), pero este es sin duda el más sencillo y la mayo... [Más]

Hay ocasiones en las que es necesario poder lanzar un programa de línea de comandos (o no) de modo silencioso para realizar una tarea y luego recoger de algún modo el resultado de su ejecución. Un caso típico es el envíod e archivos por FTP. FTP.exe es un ejecutable muy útil que viene con Windows y que permite enviar órdenes a un servidor de archivos meidante un archivo de comandos que se le pasa como parámetro. La siguiente función sirve para ejecutar cualquier programa con su ventana (de haberla) oculta, devolviendo el resultado de la ejecución (normalmente lo que aparecería en la línea de comandos) en una cadena. Si se produce un error se lanza una excepció que recoge los detalles enviados por el programa a la línea de comandos. Puede resultar muy útil. Es necesario incluir System.Diagnostics.  //Lanza un proceso con su ventana oculta y devuelve el resultado private static string lanzaProceso(string Proceso, string Parametros) {  ProcessStartInfo startInfo = new ProcessStartInfo... [Más]

Hay ocasiones en las que creamos una biblioteca de funciones interesante y la compilamos como una DLL de .NET para su uso desde una o varias aplicaciones propias. Si, por el motivo que sea, no deseamos que este ensamblado se pueda utilizar desde aplicaciones ajena tenemos varias formas de hacerlo. La más sencilla tal vez sea la que nos permite averiguar cuál es el ensamblado (normalmente un ejecutable '.exe') que está haciendo uso de nuestro código y comprobar alguna propiedad del mismo para verificar que se trata de uno permitido. El código que nos permite averiguar el ensamblado actual desde el que se ejecuta un método es el siguiente: System.Reflection.Assembly.GetEntryAssembly() Con esto ya podemos comprobar las diversas propiedades del ensamblado para ver si cumple lo que nosotros deseamos, utilizando para ello las diferentes propiedades del objeto Assembly.  Por ejemplo, para aeriguar el nombre del ensamblado que está utilizando nuestro código basta con escribir: System... [Más]

Las diferentes versiones de la plataforma .NET tienen diversas funcionalidades por lo que, cuando usemos algo específico de una determinada, resultaría de mucha utilidad comprobar al comienzo del programa la versión de .NET que esá ejecutando nuestro código. Una primera idea para conseguirlo podría ser cargar el ensamblado MSCorlib.dll y averiguar su versión al igual que se puede hacer con cualquier otro ensamblado propio. Posible pero complicado. La solución es mucho más fácil que todo eso y consiste simplemente en usar el objeto Environment así: Version v = System.Environment.Version; Con esto obtendremos la versión actual de la plataforma dentro de una clase Version. Podemos acceder a cada uno de los números de la versión usando las propiedades Major, Minor, Build y Revision de este objeto (por ejemplo, para ver si estamos usando la versión 1.1 de la plataforma deberemos comprobar que Major y Minor son 1), o la cadena completa con ToString(). La clase Environment tiene alguno... [Más]