Cargar información de reflection sin cargar el assembly

 ·  ☕ 5 min  ·  ✍️ eiximenis

    Nota: Este post ha sido importado de mi blog de geeks.ms. Es posible que algo no se vea del todo "correctamente". En cualquier caso puedes acceder a la versión original aquí

    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:

        ///

        /// Carga el tipo TObj en un AppDomain nuevo.

        /// TObj DEBE ser MarshalByRef

        ///

        private static TObj LoadFromType(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;

        }

     

        ///

        /// Obtiene información (de tipo TR) de un System.Type.

        ///

        /// Tipo de información que se devuelve. Debe ser Serializable

        /// Tipo de la clase que extrae la información a partir del System.Type

        /// Nombre del System.Type a cargar (con assembly incorporado)

        /// Ruta fisica real del assembly

        /// La información extraída del System.Type

        public static TR GetTypeInfo(string fullName, string locationPath)

            where TU : TypeLoader

        {

            var appDomain = AppDomain.CreateDomain(Guid.NewGuid().ToString());

            var tloader = LoadFromType(appDomain);

            var result = tloader.LoadTypeInfo(fullName, locationPath);

            AppDomain.Unload(appDomain);

            return result;

        }

    }

    La clase TypeLoader es como sigue:

    ///

    /// Carga información de un tipo.

    ///

    public class TypeLoader : MarshalByRefObject

    {

        ///

        /// Carga el tipo y extrae la información

        ///

        public TR LoadTypeInfo(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);

        }

     

        ///

        /// 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

        ///

        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:

    1. 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[]).
    2. Obtiene el tipo (System.Type) especificado.
    3. 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! 😉

    Si quieres, puedes invitarme a un café xD

    eiximenis
    ESCRITO POR
    eiximenis
    Compulsive Developer