Seltsame FileLoadException beim Laden einer Assembly, auf die vom WPF-Projekt mithilfe von Assembly.ReflectionOnlyLoadFrom verwiesen wird

Ich habe eine benutzerdefinierte MSBuild-Aufgabe, die einen Blick in eine Assembly wirft, um einige Attribut-Metadaten abzurufen.

Assembly assembly = Assembly.ReflectionOnlyLoadFrom(AssemblyFile)

Dies wird von unserem automatisierten Build- / Release-Prozess verwendet und funktioniert perfekt für Assemblys, die von Klassenbibliotheken, Konsolen-Apps und Webprojekten verwendet werden und auf die von diesen verwiesen wird. Die MSBuild-Task wird aufgerufen, nachdem ein anderer MSBuild-Prozess die Projekte kompiliert hat.

Es hat gestern aufgehört zu funktionieren, als ich ein WPF-Projekt hinzugefügt habe, das auf diese bestimmte Assembly verweist - eine .NET 3.5-Klassenbibliothek.

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)

Ich weiß, dass es sich um eine WPF handelt, da keine Ausnahme ausgelöst wird, wenn ich die AssemblyFile so ändere, dass sie auf eine andere Assembly in derselben Projektmappe verweist, auf die das WPF-Projekt nicht verweist.

Die Ausnahmemeldung erwähnt dies

... already loaded from a different location.

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

Beachten Sie den Teil über die gleiche Appdomain.

Deshalb habe ich den Code geändert, um diese spezielle Ausnahme abzufangen und in CurrentDomain nachzuschauen:

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);                    
    }
}

Es versteht sich von selbst, dass die fragliche Assembly nicht in der aktuellen Domäne war (was möglicherweise sinnvoll ist, da ein anderer MSBuild-Prozess erstellt wird, der die Kompilierung durchführt). Wenn also die Fehlermeldung wahr ist, wie kann ich herausfinden, wo es lebt? Es ist verwirrend, weil die Fehlermeldung mir vorschlägt, dass es CurrentDomain sein sollte.

Oder kann jemand mit mehr WPF-Erfahrung erklären, warum diese Assembly nach einer erfolgreichen Erstellung immer noch in einer App-Domäne schwebt?

Hier isteine andere Frage von jemand anderem, der diese Ausnahme getroffen hat.

Antworten auf die Frage(1)

Ihre Antwort auf die Frage