Obtener el usuario propietario de un proceso
const string query = "SELECT * FROM Win32_Process WHERE Name='explorer.exe'";
var searcher = new ManagementObjectSearcher(query);
foreach (ManagementObject process in searcher.Get())
{
var owner = new String[2];
process.InvokeMethod("GetOwner", owner);
Console.WriteLine(@"Name: {0} User: {1}\{2}", process["Name"], owner[1], owner[0]);
}
En una entrada anterior vimos cómo integrar FxCop con Visual Studio, el siguiente paso lógico que debemos dar es crear nuestras propias reglas de análisis de código. Vamos a ver que la dificultad no está en cómo crear estas reglas, sino en averiguar cuáles son las que necesitamos y cómo de complejo queremos hacer el análisis de esas reglas.
En esta entrada vamos a crear una sencilla regla con la que podremos verificar que las clases de un ensamblado tienen una única responsabilidad. Para los que no sepáis a qué me estoy refiriendo con esto, lo aclaro brevemente: existe un principio de diseño de la programación orientada a objetos, y en concreto sobre el diseño de clases, que dice que una clase debe tener una única responsabilidad. Este principio, como no podría ser de otra forma, se llama Single Responsibility Principle (Principio de única responsabilidad) y es el primero de los cinco primeros principios de diseño, que se engloban bajo el acrónimo de acrónimos SOLID.
Continuar leyendo ▶
Efectivamente, como ya aviso en el título, la entrada trata un tema muy manido, lo podríamos denominar un clásico de las discusiones entre programadores. Es un clásico, pero por algún motivo las discusiones siempre van acompañadas de mitos y leyendas que no sé muy bien de dónde surgen.
Aun lo trillado del tema, no me resisto a escribir una nueva entrada porque en estos días se me ha vuelto a plantear y, ¡cómo no!, han surgido de nuevo los fantasmas alrededor de los métodos estáticos. Voy a tratar de recopilar en esta entrada las ideas esenciales que nos ayudarán a reconocer las situaciones en las que es recomendable el uso de métodos estáticos y en cuáles no.
Antes de comentar estas ideas básicas, vamos a ponernos en situación: Por un lado tenemos los métodos no estáticos, también llamados métodos de instancia. Estos métodos sólo pueden ser llamados en un objeto de la clase a la que pertenece, y pueden acceder tanto a miembros estáticos como no estáticos. Por otro lado, están los métodos estáticos, también llamados métodos de clase, que se pueden llamar tanto en la clase como en un objeto de la clase, pero, por contra, sólo pueden acceder a miembros estáticos.
Continuar leyendo ▶
Publicado el 18 de julio de 2010 por Alex Casquete, en
.NET
Si eres de los que utilizas la edición Professional de Visual Studio 2010 y además programas en VB.NET, tienes muy pocas opciones si quieres añadir análisis estático de código a tus proyectos, yo diría que la única opción gratuita disponible es FxCop.
FxCop 10 es la última versión que ha publicado Microsoft y está incluida en el Windows SDK 7.1 para Windows 7. Esta versión funciona con el CLR v4 e incluye, respecto a versiones anteriores, el nuevo grupo de reglas de transparencia en seguridad.
FxCop dispone de dos aplicaciones: una con interfaz gráfica (FxCop.exe) y otra sin ella (FxCopCmd.exe). Hoy vamos a centrarnos exclusivamente en cómo integrar FxCop con Visual Studio utilizando la segunda opción, la aplicación por línea de comandos.
Continuar leyendo ▶
Desde hace unos días estoy preparando el examen de certificación en desarrollo de aplicaciones Windows, y ha sido buscando información sobre patrones de capa de presentación, cuando me he percatado de la gran cantidad de implementaciones y frameworks de MVVM que existen para WPF y Silverlight. Muchas veces, sin embargo, tener tantas opciones desconcierta a los nuevos desarrolladores, primero por no conocer las diferencias entre cada una de estas opciones, pero sobre todo porque generalmente los ejemplos de implementación no son sencillos o, incluso, contienen errores.
Con esta entrada voy a iniciar una serie dedicada a explicar las distintas implementaciones del patrón MVVM existentes, los principales problemas que nos podemos encontrar y cómo los frameworks de MVVM nos pueden ayudar a resolverlos. Para comenzar, vamos a sentar las bases y en esta entrada veremos la implementación básica del patrón de presentación en una sencilla aplicación de demostración.
Continuar leyendo ▶
En una entrada anterior vimos cómo integrar FxCop con Visual Studio, el siguiente paso lógico que debemos dar es crear nuestras propias reglas de análisis de código. Vamos a ver que la dificultad no está en cómo crear estas reglas, sino en averiguar cuáles son las que necesitamos y cómo de complejo queremos hacer el análisis de esas reglas.
