Versiones de VS 2010 por Daniel Laco

15. abril 2010

Siempre es motivo de preguntas el tema de que trae cada versión de Visual Studio y cuanto cuesta cada una de ellas. Aqui les dejo un link donde ver una matriz con las comparaciones de cada versión de Visual Studio 2010.

Visual Studio

Extensibilidad en el Entity Framework Designer en VS2010 por Daniel Laco

23. marzo 2010

 

Una de las cosas mas intersantes que tiene el diseñador del EF en Visual Studio 2010 es la posiblidad de extender las funcionalidades mediante el agregado de nuevas propiedades a una entidad, o la posibilidad de poder interceptar el momento de grabar un archivo edmx, u otras opciones mas.

Esto es muy útil para cuando hay equipos de desarrollo extendidos, o varios proveedores diferentes trabajando en una empresa  y se quiere mantener una uniformidad al momento de escribir código.

Asi que mediante un ejemplo sencillo explicaremos los pasos necesarios para poder implementar una propiedad en las entidades que nos permita definir si una entidad es auditada o no.

Mostraremos como agregar esa propiedad y como utilizarla posteriomente en nuestro código.

Aclaración: todo lo mostrado en este artículo, está realizado sobre la RC de VS2010.

Como paso siguiente, manos a la obra!!

El equipo de ADO.NET publicó en CodePlex el ADO.NET Entity Data Model Designer Extension Starter Kit que nos permite hacer mucho mas fácil la tarea, y ya tiene varias opciones configuradas por default.

Podemos por ejemplo: 

      • Que el ADO.NET Entity Data Model Wizard agregue anotaciones personalizadas en cada tipo de entidad. El fundamento del tema lo encontramos en un ar tículo del blog de ADO.NET referido a diseño en http://blogs.msdn.com/efdesign/archive/2008/08/12/structural-annotations-one-pager.aspx (en inglés)
      • Que el ADO.NET Entity Data Model Wizard agregue anotaciones personalizadas durante las actualizaciones en cada entidad que se agregue al modelo conceptual.
      • Que el ADO.NET Entity Data Model Wizard agregue anotaciones personalizadas cuando las entidades son seleccionadas en el Designer o en el Model Browser.
      • También se puede extender el modo en se que cargan y graban los archivos .admx.
      • O permitir que el Diseñador grabe o carge archivos en un formato personalizado.

 

Paso 1: Instalar la extensión que se baja desde CodePlex

ExtensionManager

Paso 2: Crear el proyecto.

CrearProyecto

Paso 3: Una vez que tenemos el proyecto creado, podemos hacer las modificaciones que nos interesan. En este caso vamos a crear una propiedad para cada Entidad que nos permita habilitar o deshabilitar la auditoría. Creamos entonces una clase AuditarProperty:

using System;
using System.Linq;
using System.Xml.Linq;
using System.ComponentModel;
using Microsoft.Data.Entity.Design.Extensibility;
 
namespace EFEjemploExtension
{
    /// <summary>
    /// </summary>
    class AuditarProperty
    {
        internal static readonly string _namespace = "http://schemas.vemn.com/EFExtensions";
        internal static XName _xnMyNamespace = XName.Get("AuditarProperty", _namespace);
        internal const string _category = "Extensiones";
 
        private XElement _parent;
        private PropertyExtensionContext _context;
 
        public AuditarProperty(XElement parent, PropertyExtensionContext context)
        {
            _context = context;
            _parent = parent;
        }
 
        // Esta propiedad This property is saved in the conceptual content of an .edmx document in the following format:
        // <EntityType>
        //  <!-- other entity properties -->
        //  <MyNewProperty xmlns="http://schemas.vemn.com/MyNewProperty">True</MyNewProperty>
        // </EntityType>
        [DisplayName("Auditar Entidad")]
        [Description("Configura si la entidad es Auditable")]
        [Category(AuditarProperty._category)]
        [DefaultValue(false)]
        public bool AuditarEntidad
        {
            get
            {
                bool propertyValue = false;
                if (_parent.HasElements)
                {
                    XElement lastChild = _parent.Elements().Where<XElement>(element => element != null && element.Name == AuditarProperty._xnMyNamespace).LastOrDefault();
                    if (lastChild != null)
                    {
 
                        bool boolValue = false;
                        if (Boolean.TryParse(lastChild.Value.Trim(), out boolValue))
                        {
                            propertyValue = boolValue;
                        }
                    }
                }
                return propertyValue;
            }
 
            set
            {
                bool propertyValue = value;
 
 
                using (EntityDesignerChangeScope scope = _context.CreateChangeScope("Set AuditarEntidad"))
                {
                    if (_parent.HasElements)
                    {
                        XElement lastChild = _parent.Elements().Where<XElement>(element => element != null && element.Name == AuditarProperty._xnMyNamespace).LastOrDefault();
                        if (lastChild != null)
                        {
 
                            lastChild.SetValue(propertyValue.ToString());
                        }
                        else
                        {
                            _parent.Elements().Last().AddAfterSelf(new XElement(_xnMyNamespace, propertyValue.ToString()));
                        }
                    }
                    else
                    {
                        _parent.Add(new XElement(_xnMyNamespace, propertyValue.ToString()));
                    }
  scope.Complete();
                }
            }
        }
    }
}

 

Paso 4: Creamos el Factory.

using System.Xml.Linq;
using System.ComponentModel.Composition;
using Microsoft.Data.Entity.Design.Extensibility;
 
namespace EFEjemploExtension
{
    [PartCreationPolicy(CreationPolicy.Shared)]
    [Export(typeof(IEntityDesignerExtendedProperty))]
    [EntityDesignerExtendedProperty(EntityDesignerSelection.ConceptualModelEntityType)]
    class AuditarPropertyFactory : IEntityDesignerExtendedProperty
    {
        /// <summary>
        /// </summary>
        /// <param name="element"></param>
        /// <param name="context"></param>
        /// <returns></returns>
        public object CreateProperty(XElement element, PropertyExtensionContext context)
        {
            return new AuditarProperty(element, context);
        }
    }
}

 

Paso 5: Una vez que hemos terminado, se compila y queda el arc hivo .vsix para ser in stalado en Visual Studio. En el Extension Manager veremos algo asi:

ExtensionInstalada>

Paso 6: Ya tenemos diponible la propiedad en el Diseñador de EF. Cuando agreguemos nuevas tablas o cuando se haga una actualización, las entidades tendrán ahora una nueva propiedad. Si seleccionamos una entidad veremos algo como:

AuditorPropiedad

 Paso 7: Por último, unos extension methods para poder consultar la Metadata del modelo que  nos permita obtener el valor de la propiedad:

 

public static class EFExtension
{
    /// <summary>
    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework
    /// </summary>
    /// <typeparam name="T">Entidad para obtener la propiedad</typeparam>
    /// <param name="workspace"></param>
    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>
    /// <returns></returns>
    public static bool GetExtentionPropertyAsBoolean<T>(this MetadataWorkspace workspace, string propertyName)
    {
        return (GetExtentionPropertyInternal<T>(workspace,propertyName).ToString().ToLower() == "true") ;   
    }
    /// <summary>
    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework
    /// </summary>
    /// <typeparam name="T">Entidad para obtener la propiedad</typeparam>
    /// <param name="workspace"></param>
    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>
    /// <returns></returns>
    public static string GetExtentionPropertyAsString<T>(this MetadataWorkspace workspace, string propertyName)
    {
        return GetExtentionPropertyInternal<T>(workspace, propertyName).ToString();
    }
 
    /// <summary>
    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework
    /// </summary>
    /// <typeparam name="T">Entidad para obtener la propiedad</typeparam>
    /// <param name="workspace"></param>
    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>
    /// <returns></returns>
    public static int  GetExtentionPropertyAsInt<T>(this MetadataWorkspace workspace, string propertyName)
    {
        return Convert.ToInt32(GetExtentionPropertyInternal<T>(workspace, propertyName));
    }
    /// <summary>
    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework
    /// </summary>
    /// <typeparam name="T">Entidad para obtener la propiedad</typeparam>
    /// <param name="workspace"></param>
    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>
    /// <returns></returns>
    public static object GetExtentionPropertyAsObject<T>(this MetadataWorkspace workspace, string propertyName)
    {
        return GetExtentionPropertyInternal<T>(workspace, propertyName);
    }
    /// <summary>
    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <param name="workspace"></param>
    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>
    /// <returns></returns>
    private static object GetExtentionPropertyInternal<T>(MetadataWorkspace workspace, string propertyName)
    {
        StructuralType objectSpaceType;
        workspace.LoadFromAssembly(typeof(T).Assembly);
        if (!workspace.TryGetItem<StructuralType>(typeof(T).FullName, DataSpace.OSpace, out objectSpaceType))
        {
            throw new InvalidOperationException(String.Format(CultureInfo.CurrentCulture, "No se puede encontrar este tipo de datos en la Metadata", typeof(T)));
        }
        StructuralType edmType = workspace.GetEdmSpaceType(objectSpaceType);
 
        MetadataProperty mp = edmType.MetadataProperties.Where(x => x.Name == propertyName).Single();
        XElement xc = (XElement)mp.Value;
        return xc.Value;
    }
 
}

 

La forma de utilizar esta propiedad en nuestro codigo es:

NorthwindEntities ctx = new NorthwindEntities();
bool audita = ctx.MetadataWorkspace.GetExtentionPropertyAsBoolean<Customers>("http://schemas.vemn.com/EFExtensions:AuditarProperty");
//Hago algo con la auditoria

 

De esta forma, hemos visto como de manera relativamente sencilla se puede extender el Entity Designer y de que manera nos puede ayudar al momento de estandarizar configuraciones en las entidades.

Por supuesto que la cantidad de escenarios e ideas posibles con esta funcionalidad son muchas como pueden ser:

  • Revisión o Comenarios sobre los datos.
  • Seguridad en los Datos.
  • Agregado de Atributos del CLR
  • Validaciones de Anotaciones.
  • etc.
  • etc.

 

Aqui pueden bajar el código de ejemplo utilizado en el artículo.

 

 

 

 

ADO.NET, Entity Framework, ORM, Visual Studio , ,

Como depurar Store Procedures, Triggers y Functions de SQL Server desde Visual Studio 2008 por Emmanuel Carrara

22. marzo 2010

Una tarea imprescindible en el desarrollo y programación con SQL Server es la depuración (debugging) de Store Procedures, Triggers y Functions. El debugging nos permite ejecutar paso a paso código T-SQL, establecer breakpoints, examinar el contenido de las variables y modificarlos en tiempo de depuración, etc.

Anteriormente, los desarrolladores escribían y depuraban con el Analizador de consultas de SQL Server 2000 (Query Analyzer).

Luego, el SQL Server Management Studio 2005 que lo reemplazó no tenía ningún depurador, por lo cual para poder depurar código T-SQL se utilizaba el depurador que tiene el Visual Studio 2005.

A partir de la versión 2008 de SQL Server, las capacidades de debugging ya vienen incluidas en el Management Studio (solo funcionan con una conexión contra una instancia
de SQL Server 2008), sin embargo en ciertas ocasiones es más conveniente utilizar Visual Studio para el debugging de objetos de SQL.

Requerimientos

  • Versión Professional o Team Edition de Visual Studio.
  • Es importante destacar que al depurar se detendrán todos los threads de ejecución de SQL, de modo que no es recomendable depurar en un servidor que se encuentre en producción.
  • Activar el debugging de CLR en SQL: para esto se debe primero crear una conexión a la base de datos mediante la ventana "Server Explorer" (Menú "View"). Luego dar click derecho sobre la conexión y tildar la opción "Allow SQL/CLR Debugging"

 

EnableDebugging

Permisos

Para poder depurar código SQL desde Visual Studio 2008 existen dos cuentas de usuario para considerar:

  • La cuenta de la aplicación: es la cuenta de usuario sobre la cual se ejecuta Visual Studio. Esta cuenta es una cuenta de usuario de Windows, y debe ser miembro del grupo sysadmin en el SQL Server a ser depurado.
  • La cuenta de conexión: es la identidad usada para conectarse con SQL Server (Definida en el dialogo de conexión del "Server Explorer", o en el connection string). Esta cuenta puede ser una cuenta de usuario de Windows usando Windows Authentication (en este caso es la misma sobre la cual corre Visual Studio), o puede ser una cuenta de conexión SQL, en cuyo caso debe ser miembro del rol sysadmin para poder depurar.

 

Si no se cumplen los permisos requeridos para la Depuración de SQL Server, y se intenta depurar código de SQL Server, se obtiene el siguiente error:
User 'dbo' could not execute stored procedure 'master.dbo.sp_enable_sql_debug' on SQL Server VSQL01.

Pasos para la depuración

  • Ubicar el objeto a depurar en la ventana "Server Explorer".
  • Dar click derecho sobre el objeto que se desea depurar y seleccionar "Step into ..." ("Step into Store Procedure", "Step into Function", etc.)

 

StepInto 

  • Si requiere parámetros, aparecerá un cuadro de diálogo que permite asignar los valores para cada parámetro.

 

Parametros

  • En todo momento se puede visualizar o modificar el valor de variables locales, para lo cual podemos utilizar la ventana "Locals" de Visual Studio, disponible el menú "Debug" (solo cuando la depuración ha sido iniciada), o también mediante la ventana "Watch".

 

Debug

 

 

  • Para depurar un Trigger, se debe tener en cuenta que no se le puede invocar directamente, por lo cual, lo que se puede hacer es crear un Store Procedure cuyo código fuente invoque al Trigger, y utilizar Step Into (F11 - paso a paso por instrucciones) en vez de Step Over (F10 - paso a paso por el proceso actual) para la depuración, de manera de entrar en el código del Trigger en cuestión.

 

image

En el ejemplo se muestra un store procedure que ejecuta un UPDATE sobre la tabla que tiene el trigger a depurar. Al presionar F11 sobre la instrucción UPDATE se ingresa en modo depuración al código del trigger.

 

image

SQL Server , ,

Que hay de nuevo en VS2010? por Daniel Laco

4. marzo 2010

Ya se viene la liberación de la versión final de Visual Studio 2010 y .NET 4.0 y uno siempre quiere tener una vista rápida de los cambios, agregados, etc.

En http://msdn.microsoft.com/en-us/library/bb386063(VS.100).aspx pueden encontrar un listado de todos los temas nuevos de esta plataforma.

 

.NET, ADO.NET, ASP.NET, Entity Framework, Visual Studio, WCF, WinForms , , , ,

El uso de múltiples monitores incrementa la productividad por Maxi Guillen

22. enero 2010

Un estudio realizado por NEC, ATI y la Universidad de Utah concluye que el uso de múltiples monitores incrementa la productividad

 

El Dr. James Anderson, profesor del departamento de Comunicaciones de la Universidad de Utah afirma:

“El estudio revela que los usuarios de pantallas múltiples trabajan más rápido, 

realizan más tareas y con menos errores al editar documentos,

planillas de cálculo y edición de imágenes en comparación a los usuarios de una sola pantalla.”


Los principales resultados del estudio arrojaron que los participantes, utilizando una configuración de múltiples monitores:

  • Fueron 10% más productivos.
  • Disminuyeron sus errores de edición en un 18%.
  • Fueron un 29% más efectivos al realizar sus tareas.
  • Se sintieron un 24% más cómodos al usar esta configuración para realizar su trabajo.
  • En un 39% les fue más fácil mover ya acomodar sus fuentes de información.


El estudio menciona los siguientes beneficios de los puestos de trabajo con múltiples monitores:

  • Permite procesar múltiples fuentes de información en forma simultánea, mover y cambiar su tamaño en una o todas las pantallas disponibles para incrementar la productividad.
  • Puede impactar en el ROI de la empresa si se considera la disminución de los errores en cada puesto de trabajo
  • Puede impactar positivamente en la moral de los trabajadores haciendo que se sientan más cómodos y hábiles para completar sus tareas permitiéndoles una navegación más ágil y un enfoque mayor en sus tareas.
  • Tiene una curva de aprendizaje muy baja.


Aplicaciones inmediatas para el desarrollo de software

Podríamos utilizar una pantalla para tener maximizado nuestro entorno de desarrollo y al mismo tiempo, en la otra pantalla, tener un documento con los requerimientos, buscar en internet con un navegador, hacer consultas sobre la BD, etc. Interesante no?

 

Ahora que está demostrado científicamente tal vez las empresas puedan hacer una buena inversión!

Quien se anima a llenar la F-10? (Chiste interno – solo para entendidos!)

 

Para más detalles se pueden consultar las siguientes fuentes

http://www.necus.com/necus/media/press_releases/template.cfm?DID=1947

http://www.nytimes.com/2006/04/20/technology/20basics.html

http://www.tufuncion.com/dos-monitores

http://www.youtube.com/watch?v=TVVLzaMMqRM


Tecnología ,

VSTS 2010 tiene fecha de lanzamiento el 12 de Abril de 2010 por Daniel Laco

14. enero 2010

Rob Caron ha publicado la fecha de lanzamiento para el 12 de Abril de este año. Mas info en http://blogs.msdn.com/robcaron/archive/2010/01/13/9948172.aspx

Visual Studio

Desarrollando WebParts de Sharepoint y AddIn de Outlook para Team Foundation Server por Ariel

21. octubre 2008

Desarrollando WebParts de Sharepoint y AddIn de Outlook para Team Foundation Server

Estamos desarrollando unos componentes que permitan hacer seguimientos de Workitems tanto desde Sharepoint como desde Outlook.

Estos componenets apuntan a otros tipos de stakeholders que no son desarrolladores, pero que necesitan poder hacer un seguimiento de un proyecto. En general son Gerentes de Sistemas, Project Leaders, etc. que no tienen instalado Visual Studio, pero si otro tipo de herramientas.

En el caso de Sharepoint estamos desarrollando unos webparts que casi todo el funcionamiento del Team Explorer, sin la parte de control de versiones.

Ahora podemos recorrer los proyectos, editar WorkItems y hacer consultas desde de un portal de Sharepoint.  Esto es posible porque se puede componer una pagina con varios WebParts conectados entre si.

En Outlook el AddIn cuenta con la misma funcionalidad.

A continuación mostramos algunas imagenes de la beta de estos componentes:

Webparts en esquema de una columna


Por último se puede ver un formulario similar al del Team Explorer en donde se ven todos los detalles de un Workitem.

Webparts en esquema de dos columnas

En la imagen abajo se puede ver la utilización de un arbol fijo en donde se pueden ver las consultas de cada proyecto. Y otro webpart en donde se cargan los Workitems de una consulta.

Plugin para Outlook

Sharepoint, Visual Studio ,

PLK - Como obtener la clave de paquete de extensibilidad por Maxi Guillen

10. marzo 2008

 

Cuando desarrollamos paquetes de extensibilidad para Visual Studio necesitamos obtener una clave conocida como PLK o Package Load Key. En el ambiente de desarrollo podemos probar los componentes de extensibilidad ya que tenemos instalado el kit de desarrollo o SDK de Visual Studio. Pero el usuario final no tiene por qué tener instalado dicho componente.

 

Microsoft requiere que cada paquete de extensibilidad para Visual Studio tenga una clave generada y registrada por Microsoft. El PLK permite que Microsoft realice un seguimiento de todos los paquetes lanzados por terceras partes a través de su firma. Dado que la clave se genera a partir de los datos registrados esta información debe ser exactamente igual a la declarada en el paquete de extensibilidad de lo contrario no funcionará.

La clave puede obtenerse gratis desde el sitio Visual Studio Industry Partner (VSIP):

 

El PLK es una clave que se forma a partir de los datos específicos del paquete de extensibilidad:

  1. Package GUID, o identificador único del paquete.
  2. Package Name, nombre del paquete.
  3. Product Name, nombre del producto.
  4. Company Name, nombre de la empresa que desarrolla el paquete.

 

Una vez obtenido el PLK desde el sitio mencionado anteriormente, el mismo debe almacenarse en un archivo de recursos del paquete de extensibilidad por ejemplo: “VSPackage.resx”. En este archivo se guarda el string de la clave y se le asigna un ID, como se muestra a continuación.

 

Ilustración 1 En rojo: donde se coloca el string del PLK

 

 Luego se debe editar la clase del proyecto que herede de “Package” o “PackageBase” y agregarle los atributos “Guid” y “ProvideLoadKey”. Por ejemplo:

 

   1:  [ProvideLoadKey("Standard","1.0.0.0",”AzManDSLTool”, “MaxiMegaCorporation”, 105)]
   2:  [Guid(“STRING DEL GUID”)]
   3:  internal sealed partial class AzManDslToolPackage : AzManDslToolPackageBase
   4:  {
   5:  }

 

El ejemplo anterior muestra la registración de un PLK en un proyecto DSL pero esto aplica también para los paquetes de extensibilidad en general.
 
Los parámetros del atributo “ProvideLoadKey” son:

  1. Versión mínima de Visual Studio, para la que aplica el paquete.
  2. Versión del proyecto.
  3. Nombre del producto.
  4. Nombre de la empresa que lo desarrolla.
  5. Identificador del String que contiene el PLK, en el archivo de recursos.

 

La combinación de los primeros cuatro parámetros de “ProvideLoadKey” están codificados dentro del PLK y por lo tanto deben ser iguales a los declarados al obtener la clave.

Antes de distribuir los archivos de instalación o siquiera intentar instalarlo en nuestras máquinas, cuestión que puede llevarnos varios valiosos minutos de nuestro tiempo, tenemos el beneficio de poder comprobar la correcta carga de la clave por parte del IDE. Solo hace falta ingresar en la sección de “Debug” dentro de las propiedades del proyecto e ingresar lo siguiente en Comand line arguments: “/rootsuffix Exp /noVSIP”. Por supuesto también deben configurar que al ejecutar el paquete se abra otra instancia de Visual Studio como se muestra en la siguiente imagen.

 

 

Ilustración  2  Configuración del proyecto

 

Luego si se ejecuta el proyecto se abrirá otra  instancia del IDE donde podemos probar nuestro paquete de extensibilidad. En caso de falla en la carga del PLK veremos un mensaje de error. Una vez efectuadas estas tareas y hecho el build del correspondiente proyecto de instalación pueden distribuir los archivos.

Mantenimiento 

Un tema muy importante que debemos tener en cuenta es que cuando hacemos algún mantenimiento al paquete de extensibilidad, ya sea que se corrijan funcionalidades o se agreguen nuevas y siempre y cuando cambiemos la versión (p.e. 1.0.0.0 a 1.0.0.1), seguramente vamos a tener que generar un nuevo instalador para desplegar la nueva versión. Atención! si se cambia la versión del producto se deberá actualizar la clave del paquete de extensibilidad (PLK) en el archivo de recursos correspondiente.

 Fuentes:

 

 

 

 

Visual Studio