Burbujas en .NET : visual studio

El problema de la WebGrid con VS2012RC y ASP.NET MVC4

Eduard Tomàs i Avellana — Thu, 02 Aug 2012 11:23:45 GMT

Nota: Este post está basado en la versión RC de VS2012 y la versión RC de MVC4 y es posible (o eso espero, vaya!) que en la versión final no haya los problemas que este post menciona!

Buenas! Coje un VS2102RC y crea un nuevo proyecto ASP.NET MVC4, con la plantilla “Basic”.

Crea el HomeController, crea la acción Index y añádele un código tal como:

        1: public ActionResult Index()

       2: {

       3:     var data = new List<dynamic>() { new { Name = "Edu", Twitter = "eiximenis" } };

       4:     return View(data);

       5: }

Finalmente crea la vista Index.cshtml:

       1: @{

       2:     var grid = new WebGrid(Model, new [] {"Name", "Twitter"});

       3: }

       4: @grid.GetHtml()

Seguro que esperas ver una grid con las dos columnas y una fila no? ¡Pues no! Lo que verás es:

Obtendrás el error “CS0246: The type or namespace name 'WebGrid' could not be found (are you missing a using directive or an assembly reference?)”.

Si repites este mismo procedimiento pero cojes la plantilla “Empty” el código funcionará sin problemas :)

¿Y donde está el problema?

Pues eso me he estado preguntando un buen rato. Por supuesto antes de intentar hacer nada he usado el comodín de Google pero esta vez me ha fallado. La única referencia que he encontrado es un post en los blogs de ASP.NET (http://forums.asp.net/t/1823940.aspx/1?MVC4+WebGrid+problem+in+View+Razor+) donde alguien más experimenta el problema pero no se llega a ninguna solución.

Al final lo que he hecho para solucionar el problema ha sido:

Desde NuGet desinstalar el paquete ASP.NET MVC4 RC 4.0.20505. Eso ha desinstalado también los paquetes Microsoft.AspNet.WebPages 2.0.20505.0 y Microsoft.AspNet.Razor 2.0.20505.0
Volver a instalar el paquete ASP.NET MVC4 RC 4.0.20505 desde NuGet. Me ha dado un error y ha hecho un rollback.
Intentar de nuevo volver a instalar el paquete ASP.NET MVC4 RC 4.0.20505. Ahora todo ha funcionado correctamente.

Después del tercer punto, la WebGrid ya funcionaba correctamente.

Honestamente desconozco la causa, pero bueno… si alguien se encuentra con ello, ya lo sabe. Que pruebe esto a ver si le funciona! :)

Un saludo!

Cargar información de reflection sin cargar el assembly

Eduard Tomàs i Avellana — Thu, 10 May 2012 15:27:46 GMT

Bueno… veamos un post rapidito. En un proyecto en el que he participado hemos estado personalizando Visual Studio a través de varios custom editors, plugins, packages y demás fauna que pulula por la selva de extensibilidad de Visual Studio.

Estos editores, addines y demás necesitaban acceder a información de Reflection de la propia DLL que se estaba compilando. Teóricamente obtener la información es muy sencillo. Basta con obtener la ruta a la DLL que se está compilando:

private static EnvDTE.DTE DTE
{
    get { return (EnvDTE.DTE)Package.GetGlobalService(typeof(EnvDTE.DTE)); }
}
 
public static string ObtenerRutaEnsamblado()
{
    var project = DTE.ActiveDocument.ProjectItem.ContainingProject;
    return project.Properties.Item("LocalPath").Value.ToString() +
        project.ConfigurationManager.ActiveConfiguration.Properties.Item("OutputPath").Value.ToString();
}
 
public static string ObtenerNombreEnsamblado()
{
    var project = DTE.ActiveDocument.ProjectItem.ContainingProject;
    return string.Concat(ObtenerRutaEnsamblado(), project.Properties.Item("OutputFileName").Value.ToString());
}

El método ObtenerNombreEnsamblado da la ruta física de la DLL que se está compilando. A partir de aquí, debería bastar con usar LoadAssembly, para cargar la DLL y listos. Pero por supuesto, si esto fuese así, esta entrada del blog no existiría :)

El tema está en que cuando accedemos a un Assembly via Reflection, este assembly se carga en el CLR. Y una vez un Assembly está cargado no puede ni cargarse de nuevo (para ver las modificaciones, por ejemplo, recordad que estamos cargando la propia DLL que el usuario está creando en VS) ni tampoco descargarse. Además el archivo físico se puede crear bloqueado (lo que en nuestro caso impedía que pudieses compilar el proyecto, ya que estaba bloqueado por el addin). Si alguno de vosotros está pensando en cargar el proyecto “solo para Reflection”, que se olvide. Cargar un assembly “solo para Reflection” lo carga igual y tampoco se puede ni cargar de nuevo ni descargar.

¿La solución? Bueno, pues utilizar un AppDomain nuevo. Para los que no lo sepáis los AppDomains son como “procesos” dentro del CLR. Un programa se ejecuta dentro de un AppDomain pero puede crear más AppDomains, del mismo modo que un proceso puede crear procesos hijos. Por supuesto la comunicación entre dos AppDomains se trata como comunicación interproceso: o a través de proxies (objetos MarshalByRef) o pasando objetos serializables. ¡Viva la vida!

Al final, terminé con una clase AppDomainUtils, con métodos estáticos parecidos a los siguientes:

    /// <summary>
    /// Carga el tipo TObj en un AppDomain nuevo.
    /// TObj DEBE ser MarshalByRef
    /// </summary>
    private static TObj LoadFromType<TObj>(AppDomain appDomain)
    {
        var tokens = typeof(TObj).AssemblyQualifiedName.Split(',');
        var assName = tokens[1];
        var typeName = tokens[0];
        var obj = appDomain.CreateInstanceAndUnwrap(assName, typeName);
        return (TObj)obj;
    }
 
    /// <summary>
    /// Obtiene información (de tipo TR) de un System.Type.
    /// </summary>
    /// <typeparam name="TR">Tipo de información que se devuelve. Debe ser Serializable</typeparam>
    /// <typeparam name="TU">Tipo de la clase que extrae la información a partir del System.Type</typeparam>
    /// <param name="fullName">Nombre del System.Type a cargar (con assembly incorporado)</param>
    /// <param name="locationPath">Ruta fisica real del assembly</param>
    /// <returns>La información extraída del System.Type</returns>
    public static TR GetTypeInfo<TR, TU>(string fullName, string locationPath)
        where TU : TypeLoader
    {
        var appDomain = AppDomain.CreateDomain(Guid.NewGuid().ToString());
        var tloader = LoadFromType<TU>(appDomain);
        var result = tloader.LoadTypeInfo<TR>(fullName, locationPath);
        AppDomain.Unload(appDomain);
        return result;
    }
}

La clase TypeLoader es como sigue:

/// <summary>
/// Carga información de un tipo.
/// </summary>
public class TypeLoader : MarshalByRefObject
{
    /// <summary>
    /// Carga el tipo y extrae la información
    /// </summary>
    public TR LoadTypeInfo<TR>(string fullName, string locationPath)
    {
        var type = Type.GetType(fullName);
        if (type == null)
        {
            var tokens = fullName.Split(',').Select(x => x.Trim()).ToArray();
            var assFileName = tokens[1];
            var assFileNameWithExtension = string.Concat(assFileName.Trim(), ".dll");
            var assembly = AssemblyLoader.CargarAssemblyDesdeByteArray(Path.Combine(locationPath, assFileNameWithExtension));
            var typeName = tokens[0];
            type = assembly.GetTypes().FirstOrDefault(x => x.FullName == typeName);
        }
        return type != null ? (TR)Select(type) : default(TR);
    }
 
    /// <summary>
    /// Este método recibe un Type y debe devolver la info que se necesita de dicho Type.
    /// Este objeto DEBE ser serializable y debe ser una instancia (o casteable) de TR
    /// </summary>
    protected virtual object Select(Type type) { return null; }

La idea es cargar un System.Type, extraer información de él y devolverla. Evidentemente esto debe hacerse en un AppDomain nuevo. El método GetTypeInfo lo que hace es crear este AppDomain nuevo y luego, dentro de este AppDomain crear una instancia de un objeto propio, de un tipo cualquiera TU, pero que TU derive de TypeLoader. Y llama al método LoadTypeInfo de este objeto propio. El método LoadTypeInfo (definido en la clase TypeLoader) es el método que:

Carga el assembly (usando un método propio que lo carga desde un array de bytes para asegurar que el fichero no se queda bloqueado. Simplemente lee todo el contenido del fichero en un byte[] y luego usa Assembly.Load pasándole este byte[]).
Obtiene el tipo (System.Type) especificado.
Llama al método Select que recibe un System.Type y debe devolver un objeto serializable con la información. Este objeto es el que se transmitirá al AppDomain principal (de ahí que deba ser serializable). Y no, System.Type no lo es.

El uso al final es bastante sencillo:

var data = AppDomainUtils.GetTypeInfo<TypeIdInfo, TypeIdInfoLoader>(tag.TypeName, OperativaReader.ObtenerRutaEnsamblado());

En la variable tag.TypeName está el nombre del tipo (full-qualified) a cargar. Al ejecutar esta línea en data tenemos un objeto de tipo TypeIdInfo que contiene la información que nos interesaba extraer del objeto System.Type. La clase TypeIdInfoLoader es la que transforma un System.Type en un TypeIdInfo:

class TypeIdInfoLoader : TypeLoader
{
    protected override object Select(Type type)
    {        
        var data = new TypeIdInfo() { FullName = type.FullName };
        return data;
    }
}

El código del méotdo Select de la clase TypeIdInfoLoader se ejecuta en el otro AppDomain, de ahí que deba devolver un objeto serializable (la clase TypeIdInfo debe estar marcada como tal).

En fin… comentar tan solo que todo este peñazo de usar AppDomains es porque los señores de Microsoft no han tenido a bien proporcionar una API que permite usar Reflection sin cargar la DLL dentro del CLR. Y no, lo siento, pero esta API no me sirve. Quiero algo que para usarlo no deba morir mil veces.

Saludos! ;-)

[Channel 9] Uso de snippets en VS2010

Eduard Tomàs i Avellana — Wed, 22 Dec 2010 07:48:00 GMT

Muy buenas!

Post cortito, cortito sólo para decir que han publicado en Channel 9 Spain mi vídeo sobre cómo usar los snippets en VS2010.

Si no conoces lo que son, o bien los usas pero no sabes como definirte los tuyos propios, igual el vídeo te puede ayudar! Lo tenéis en:

http://channel9.msdn.com/Blogs/channel9spain/Cmo-usar-Snippets-en-Visual-Studio

Un saludo!

PD: Ayer fue un día intenso en Channel 9, también se publicó el vídeo de Josue Yerai sobre MVVM en Silverlight y el de Actualidad y futuro sobre HTML5 de Alejandro Martín!

Un saludo!

VS bloquea assemblies cargados desde la web

Eduard Tomàs i Avellana — Fri, 28 May 2010 13:03:00 GMT

¡Hola!

Situación explicada rápidament: Si te descargas un assembly directamente desde internet, y añades una referencia a dicho assembly, la referencia te aparecerá como añadida, pero VS no hará caso de ella. Cuando compiles te aparecerá un error parecido a:

Unable to load the metadata for assembly 'AvalonDock'. This assembly may have been downloaded from the web. See http://go.microsoft.com/fwlink/?LinkId=179545. The following error was encountered during load: Could not load file or assembly 'AvalonDock, Version=1.2.2691.0, Culture=neutral, PublicKeyToken=85a1e0ada7ec13e4' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)

En mi caso, efectivamente me descargué la última versión de AvalonDock (desde su página de descargas puedes descargarte un msi que lo instala o simplemente el assembly que contiene la librería y que es lo que yo hice).

Por suerte el propio mensaje de error de VS es más que expícito y si te vas a la página que menciona (http://go.microsoft.com/fwlink/?LinkId=179545) verás la explicación de lo que hay que hacer: Básicamente cerrar VS y con el explorador de archivos abrir las propiedades del archivo y darle a desbloquear:

Y listos! Ya puedes usar tu assembly… ten presente que esto da permisos full trust al assembly, así que… andate con cuidado! ;-)

¿Y como sabe VS que el archivo ha sido descargado?

Esta pregunta se aplica no sólo a VS sinó a Windows en general. Como sabe Windows que dicho archivo ha sido descargado de la web? Si lo mueves de carpeta, lo renombras o incluso lo copias a otro ordenador windows seguirá sabiendo que el archivo ha sido descargado de la web.

La respuesta es realmente simple: Windows guarda esta información en el propio archivo y lo hace gracias a una capacidad no muy conocida de NTFS llamada alternate data streams (ADS). Dicha capacidad (insisto de NTFS) permite asociar metadatos a un archivo. Cuando descargamos un archivo de la red, windows crea un ADS en dicho archivo y lo marca como descargado de la red. Los ADS se crean junto con el archivo (no se guardan en ningún sitio separado).

Para poder abrir un ADS basta con saber el nombre de este y añadirlo junto con dos puntos (:) al nombre del archivo. P.ej. el ADS que windows asocia a los archivos descargados de internet se llama “Zone.Identifier”. Así, en mi caso si yo hago:

notepad AvalonDock.dll:Zone.Identifier

obtengo lo siguiente:

Cuando pulso el botón de “Unblock” desde el explorador de archivos lo que hace es borrar dicho ADS del archivo.

Usando explorer no podeis saber fácilmente si un archivo contiene ADS o no: aunque los ADS modifican el tamaño real del archivo (puesto que se guardan junto a este), el explorador de archivos sólo os muestra el tamaño del flujo principal (o sea el del archivo sin los ADS) y lo mismo hace el comando “dir” de MS-DOS. Si quereis saber los ADS que tienen vuestros archivos, hay por ahí afuera varios visores de ADS (aunque yo no he probado ninguno).

Por cierto, que os he dicho que los ADS, dado que se guardan junto con el archivo, se mantienen cuando se copia, se modifica o se mueve el archivo y esto es cierto siempre que se use NTFS. Si se copia un archivo que contiene ADS a un sistema que no los soporta (p.ej. FAT32 usado en las llaves USB), el ADS se pierde.

Un saludote!! ;-)

VS se queja con un "Could not retrieve the current project" en un archivo .dbml

Eduard Tomàs i Avellana — Fri, 12 Sep 2008 06:19:00 GMT

Síntoma: tienes una solución que ayer (o hace algunos días, da igual) funcionaba y compilaba bien. Hoy lo abres y aparece un error que dice:

Build failed due to validation errors in C:\edu.tmp\Wof\ClientServer\WoFServer\WoFData.dbml. Open the file and resolve the issues in the Error List, then try rebuilding the project.

Recompilar la solución no sirve para nada. Entonces si intentas abrir el archivo .dmbl, VS se queja con el "Could not retrieve the current project".

La solución? Invocar VS desde una línea de comandos con:

devenv /ResetSkipPkgs y listos, todo volverá a funcionar!

La causa de esto es que en alguna carga previa de VS, el paquete (en este caso el diseñador de LINQ) no se carga bien por alguna razón y VS "lo desactiva" para el futuro. Aunque VS avisa de ello (aparece un warning en la ventana de output) es fácil no verlo, o incluso si es un paquete que usamos raramente, no acordarnos.

Evidentemente, en mi caso, el problema se dió con el diseñador de LINQ, pero se puede dar con cualquier paquete de VS que haya tenido algún error de carga.

Nos leemos ;-)

Más info sobre ResetSkipPkgs: http://msdn.microsoft.com/en-us/library/ms241276.aspx