Tengo una tarea personalizada de MSBuild que se asoma dentro de un ensamblaje para obtener algunos metadatos de atributos.

Assembly assembly = Assembly.ReflectionOnlyLoadFrom(AssemblyFile)

Esto es usado por nuestro proceso automatizado de compilación / lanzamiento, y ha funcionado perfectamente contra los ensamblajes utilizados y referenciados desde bibliotecas de clases, aplicaciones de consola y proyectos web. La tarea de MSBuild se llama después de que otro proceso de MSBuild haya compilado los proyectos.

Dejó de funcionar ayer cuando agregué un proyecto WPF que hacía referencia a este conjunto en particular: una biblioteca de clases .NET 3.5.

System.IO.FileLoadException: API restriction: The assembly 'file:///bogus.dll' has already loaded from a different location. 
It cannot be loaded from a new location within the same appdomain. 
at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) 
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) 
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) 
at System.Reflection.Assembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, StackCrawlMark& stackMark) 
at System.Reflection.Assembly.ReflectionOnlyLoadFrom(String assemblyFile) 
at RadicaLogic.MSBuild.Tasks.GetAssemblyAttribute.Execute() 
at Microsoft.Build.BuildEngine.TaskEngine.ExecuteInstantiatedTask(EngineProxy engineProxy, ItemBucket bucket, TaskExecutionMode howToExecuteTask, ITask task, Boolean& taskResult)

Sé que está relacionado con WPF porque no se lanza ninguna excepción si cambio el archivo de ensamblaje para que apunte a otro conjunto en la misma solución a la que no hace referencia el proyecto de WPF.

El mensaje de excepción menciona que

... already loaded from a different location.

It cannot be loaded from a new location within the same appdomain.

Tenga en cuenta la parte sobre el mismo appdomain.

Así que modifiqué el código para detectar esta excepción en particular y buscar en CurrentDomain:

Assembly assembly = null;
try
{
    assembly = Assembly.ReflectionOnlyLoadFrom(AssemblyFile);
}
catch (FileLoadException)
{
    List<string> searched = new List<string>();
    foreach (var asm in AppDomain.CurrentDomain.GetAssemblies())
    {
        if (Path.GetFileName(asm.CodeBase).Equals(Path.GetFileName(AssemblyFile), 
            StringComparison.OrdinalIgnoreCase))
        {
            message = string.Format("Found assembly {0} in current domain", 
                asm.CodeBase);
            MSBuildHelper.Log(this, message, MessageImportance.High);
            assembly = asm;
            break;
        }
        else
        {
            searched.Add(Path.GetFileName(asm.CodeBase));
        }
    }
    if (assembly == null)
    {
        message = string.Format(
            "Unable to find {0} after looking in current domain assemblies {1}",
            Path.GetFileName(AssemblyFile), string.Join(", ", searched.ToArray()));
        MSBuildHelper.Log(this, message, MessageImportance.High);                    
    }
}

No hace falta decir que el ensamblaje en cuestión no estaba en el dominio actual (lo que puede tener sentido, ya que se genera otro proceso de MSBuild que realiza la compilación), por lo que, suponiendo que el mensaje de error sea verdadero, ¿cómo puedo averiguar dónde? ¿vive? Es confuso porque el mensaje de error para mí sugiere que debería ser CurrentDomain.

¿O puede alguien con más experiencia en WPF explicar por qué este conjunto todavía flota en un dominio de aplicación después de una compilación exitosa?

Aquí estáotra pregunta de alguien más que ha golpeado esta excepción.