Mam niestandardowe zadanie MSBuild, które zagląda do złożenia, aby uzyskać pewne metadane atrybutów.

Assembly assembly = Assembly.ReflectionOnlyLoadFrom(AssemblyFile)

Jest to używane przez nasz zautomatyzowany proces budowania / wydawania i działa doskonale na złożeniach używanych przez biblioteki klas, aplikacje konsolowe i projekty internetowe. Zadanie MSBuild jest wywoływane po skompilowaniu projektów przez inny proces MSBuild.

Wczoraj przestał działać, gdy dodałem projekt WPF, który odwoływał się do tego konkretnego zespołu - biblioteki klasy .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)

Wiem, że WPF jest powiązany, ponieważ nie jest generowany żaden wyjątek, jeśli zmienię AssemblyFile, aby wskazywał na inny zespół w tym samym rozwiązaniu, do którego nie odwołuje się projekt WPF.

Komunikat wyjątku wspomina o tym

... already loaded from a different location.

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

Zwróć uwagę na część o tej samej domenie aplikacji.

Zmodyfikowałem więc kod, aby przechwycić ten wyjątek i zajrzeć do 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);                    
    }
}

Jest rzeczą oczywistą, że omawiany zespół nie był w bieżącej domenie (co może mieć sens, ponieważ pojawił się inny proces MSBuild, który wykonuje kompilację), więc zakładając, że komunikat o błędzie jest prawdziwy, jak mam się dowiedzieć, gdzie to żyje? Jest to mylące, ponieważ komunikat o błędzie do mnie sugeruje, że powinien to być CurrentDomain.

Czy może ktoś z większym doświadczeniem WPF może wyjaśnić, dlaczego ten zestaw nadal pływa w domenie aplikacji po udanej kompilacji?

Otoinne pytanie od kogoś, kto uderzył w ten wyjątek.