Załaduj bieżący zestaw do innej AppDomain

Question

Utworzono AppDomain z innym katalogiem bazowym. Jednak nie mogę załadować aktualnie wykonywanego zespołu do drugiej domeny aplikacji bez posiadania kopii bieżącego zespołu wykonawczego w katalogu podstawowym. Próbowałem nawet załadować go z bajtów.

mam żadnego wyjątku, gdy próbuję załadować, ale gdy próbuję użyć:

domain.DoCallBack(new CrossAppDomainDelegate(... 

uzyskać:

Nie można załadować pliku lub zestawu ....... .... System nie może odnaleźć określonego pliku.

Mój kod wygląda następująco:

private static void SaveAssemblies(Assembly ass, List<byte[]> assemblyByteList) 
{ 
    AssemblyName[] assNames = ass.GetReferencedAssemblies(); 
    foreach (AssemblyName assName in assNames) 
    { 
     Assembly referedAss = Assembly.Load(assName); 
     if (!referedAss.GlobalAssemblyCache) 
     { 
      SaveAssemblies(referedAss, assemblyByteList); 
     } 
    } 
    byte[] rawAssembly = File.ReadAllBytes(ass.Location); 
    assemblyByteList.Add(rawAssembly); 
} 

public static AppDomain CreateAppDomain(string dir, string name) 
{ 
    AppDomainSetup domainSetup = new AppDomainSetup(); 
    domainSetup.ApplicationBase = dir; 
    domainSetup.ApplicationName = Path.GetFileName(dir); 
    domainSetup.PrivateBinPath = Path.Combine(dir, "Libs"); 

    AppDomain domain = AppDomain.CreateDomain(name, null, domainSetup); 
    //Load system assemblies needed for the module 
    List<byte[]> assemblyByteList = new List<byte[]>(); 
    SaveAssemblies(Assembly.GetExecutingAssembly(), assemblyByteList); 

    foreach (byte[] rawAssembly in assemblyByteList) 
     domain.Load(rawAssembly); 

    domain.DoCallBack(new CrossAppDomainDelegate(SetupLogging)); 
    return domain; 
} 

Aktualizacja:

Wydaje się, że zespół jest ładowany, gdy patrzę na wyjściu widzę to

„TaskExecuter.Terminal.vshost. exe '(zarządzany (v4.0.30319)): Załadowano' NLog ' ' TaskExecuter.Terminal.vshost.exe '(Zarządzany (v4.0.30319)): Załadowano' TaskExecuter ', załadowano symbole.

ale wciąż wyjątek ... Nie rozumiem tego

System.IO.FileNotFoundException był nieobsługiwany Message = Nie można załadować pliku lub zestawu „TaskExecuter, Version = 1.0.4244.31921, Kultura = neutralny, PublicKeyToken = null 'lub jedna z jego zależności. System nie może znaleźć określonego pliku. Source = mscorlib
FileName = TaskExecuter, wersja = 1.0.4244.31921, Culture = neutralny, PublicKeyToken = null FusionLog ==== Informacje o stanie pre-bind === LOG: Użytkownik = Peter-PC \ Peter LOG: DisplayName = TaskExecuter, Version = 1.0.4244.31921 Kultura = neutralne TokenKluczaPublicznego = NULL (pełni funkcjonalne) log: Appbase = plików /// C:/ProgramData/TaskExecuter/TaskLib/uTorrentTasks log: Początkowa PrivatePath = C: \ ProgramData \ TaskExecuter \ TaskLib \ uTorrentTasks \ Libs Wywołanie zespołu: (Nieznany). === LOG: To powiązanie rozpoczyna się w domyślnym kontekście ładowania. LOG: przy użyciu pliku konfiguracyjnego aplikacji: d: \ users \ peter \ documents \ visual studio 2010 \ Projects \ TaskExecuter \ TaskExecuter.Terminal \ bin \ Release \ TaskExecuter.Terminal.vshost.exe.Config LOG: Użycie pliku konfiguracyjnego hosta : LOG: przy użyciu konfiguracji urządzenia plik z C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ config \ machine.config. LOG: Zasada nie jest stosowana do odniesienia w tym momencie (prywatne, niestandardowe, częściowe lub oparte na lokalizacji powiązanie zespołu). LOG: Próba pobrania nowego adresu URL : /// C: /ProgramData/TaskExecuter/TaskLib/uTorrentTasks/TaskExecuter.DLL. LOG: Próba pobrania nowego adresu URL file: /// C: /ProgramData/TaskExecuter/TaskLib/uTorrentTasks/TaskExecuter/TaskExecuter.DLL. LOG: Próba pobrania nowego adresu URL file: /// C: /ProgramData/TaskExecuter/TaskLib/uTorrentTasks/Libs/TaskExecuter.DLL. LOG: Próba pobrania nowego adresu URL file: /// C: /ProgramData/TaskExecuter/TaskLib/uTorrentTasks/Libs/TaskExecuter/TaskExecuter.DLL. LOG: Próba pobrania nowego adresu URL file: /// C: /ProgramData/TaskExecuter/TaskLib/uTorrentTasks/TaskExecuter.EXE. LOG: Próba pobrania nowego adresu URL file: /// C: /ProgramData/TaskExecuter/TaskLib/uTorrentTasks/TaskExecuter/TaskExecuter.EXE. LOG: Próba pobrania nowego adresu URL file: /// C: /ProgramData/TaskExecuter/TaskLib/uTorrentTasks/Libs/TaskExecuter.EXE. LOG: Próba pobrania nowego adresu URL file: /// C: /ProgramData/TaskExecuter/TaskLib/uTorrentTasks/Libs/TaskExecuter/TaskExecuter.EXE.

StackTrace: na System.Reflection.RuntimeAssembly._nLoad (AssemblyName fileName, String CODEBASE, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, logiczne suppressSecurityChecks) na System.Reflection. RuntimeAssembly.nLoad (AssemblyName fileName, String cODEBASE, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, logiczne suppressSecurityChecks) w System.Reflection.RuntimeAssembly.InternalLoadAssemblyName (AssemblyName assemblyRef dowody assemblySecurity, StackCrawlMark & stackMark, Boolean forIntrospection, logiczne suppressSecurityChecks) w System.Reflection.RuntimeAssembly.InternalLoad (String assemblyString, Evidence assemblySecurity, StackCrawlMark & stackMark, Boolean forIntrospection) na System.Reflection.Assembly.Load (String assemblyString) na System.Runtime.Serialization.FormatterServices.LoadAssemblyFromString (String AssemblyName) na System.Reflection.MemberInfoSeriali zationHolder..ctor (SerializationInfo informacji, kontekst StreamingContext) na System.AppDomain.DoCallBack (CrossAppDomainDelegate callBackDelegate) na TaskExecuter.AppDomainHelper.CreateAppDomain (String dir, String name) w D: \ Users \ Piotr \ Documents \ wizualny studio 2010 \ Projects \ TaskExecuter \ TaskExecuter \ AppDomainHelper.cs: linia 50 na TaskExecuter.TaskManagment.TaskFinder.Probe() in d: \ Users \ Piotr \ Documents \ visual studio 2010 \ Projects \ TaskExecuter \ TaskExecuter \ TaskManagment \ TaskFinder.cs: linia w TaskExecuter.TaskManagment.TaskManager.LoadTasks() w d: \ users \ peter \ documents \ visual studio 2010 \ Projects \ TaskExecuter \ TaskExecuter \ TaskManagment \ TaskManager.cs: linia na TaskExecuter.TaskManagment.TaskManager.Start() in d: \ Users \ Piotr \ Documents \ visual studio 2010 \ Projects \ TaskExecuter \ TaskExecuter \ TaskManagment \ TaskManager.cs: linia w TaskExecuter.Terminal.Program.Main (String [] args) w d: \ users \ peter \ documents \ visual studio 2010 \ Projects \ TaskExecuter \ TaskExecuter.Terminal \ Program .cs: ​​linia 16 w System.AppDomain._nExecuteAssembly (montaż RuntimeAssembly, łańcuchowe [] arg) w System.AppDomain.ExecuteAssembly (string assemblyFile, Evidence assemblySecurity, String [] args) pod Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() w System.Threading.ThreadHelper.ThreadStart_Context (Przedmiot stan) w System.Threading.ExecutionContext.Run (ExecutionContext executionContext, ContextCallback zwrotna, stanu obiektu, logiczna ignoreSyncCtx) w System.Threading.ExecutionContext.Run (ExecutionContext executionContext, ContextCallback zwrotna, obiekt stan) na System.Threading.ThreadHelper.ThreadStart()
InnerException:

Answer 1

udało mi się odzyskać związana blogu używając archive.org a także pochodzić z roztworu roboczego.

Moim celem było dynamiczne skompilowanie pliku exe do tymczasowej lokalizacji, a następnie załadowanie tego exe shadowa do wszystkich głównych bibliotek dll w domenie podrzędnej, aby główna aplikacja, która zainicjowała plik exe, mogła być z łatwością aktualizowana. Podstawowym podejściem jest użycie childAppDomain.CreateInstanceFrom w celu utworzenia typu, który w konstruktorze instaluje procedurę obsługi zdarzenia assembly assembly. Mój kod wyglądało

var exportAppDomain = AppDomain.CreateDomain(
    runnerName, 
    null, 
    appDomainSetup, 
    new PermissionSet(PermissionState.Unrestricted)); 

exportAppDomain.CreateInstanceFrom(
    Assembly.GetExecutingAssembly().Location, 
    "ExportLauncher.AppDomainResolver", 
    true, 
    BindingFlags.Public | BindingFlags.Instance, 
    null, 
    new object[] { Assembly.GetExecutingAssembly().Location }, 
    null, 
    null); 

i rodzaju, który tworzy potrzebne obsługi AssemblyResolve (poniżej blogu opisuje dlaczego potrzebujesz innego typu)

class AppDomainResolver 
{ 
    string _sourceExeLocation; 

    public AppDomainResolver(string sourceExeLocation) 
    { 
     _sourceExeLocation = sourceExeLocation; 
     AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve; 
    } 

    Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args) 
    { 
     if (args.Name.Contains("exporterLauncher")) // why does it not already know it has this assembly loaded? the seems to be required 
      return typeof(AppDomainResolver).Assembly; 
     else 
      return null; 
    } 
} 

Oto oryginalny blogu:

Application Domains jest trudny ...

Czy kiedykolwiek pracowałeś z Application Domain w .NET ?, na początku nie wydaje Ci się to takie trudne, bu Dzięki nim poznajesz wszystkie małe trudności.

Wszystko działa dobrze, o ile nie zostanie przeniesiony poza katalog Host AppDomains.BaseDirectory, ale w naszym przypadku chcieliśmy zainstalować wtyczki, np. Lokalizacja "C: \ My Plug-ins", podczas gdy aplikacja hosta byłby uruchomiony w "C: \ Program Files \ Moja aplikacja", ponieważ możemy natknąć się na zależności od AppDomain do niektórych problemów Zespołów hostów najwyraźniej nieuniknione.

Klasyczny Oto prosty kod i nasza pierwsza próba.

1: string applicationBase = Path.GetDirectoryName(interOperabilityPackageType.AssemblyDescription.AssemblyPath); 
    2: AppDomainSetup setup = new AppDomainSetup 
    3: { 
    4:  ApplicationName = name, 
    5:  ApplicationBase = applicationBase, 
    6:  PrivateBinPath = AppDomain.CurrentDomain.BaseDirectory, 
    7:  PrivateBinPathProbe = AppDomain.CurrentDomain.BaseDirectory, 
    8:  ConfigurationFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile 
    9: }; 
    10: 
    11: Evidence evidence = new Evidence(AppDomain.CurrentDomain.Evidence); 
    12: AppDomain domain = AppDomain.CreateDomain(name, evidence, setup); 

wydaje się bardzo proste, ale ponieważ „ApplicationBase” różni się od „AppDomain.CurrentDomain.BaseDirectory” wpadliśmy na to, co wydaje się być bardzo dobrze znać wyjątkiem.

System.IO.FileNotFoundException: Nie można załadować pliku lub zestawu 'Host.Services, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null' lub jednej z jego zależności. System nie może odnaleźć określonego pliku.

Jeśli pracowałeś z jakimkolwiek dynamicznym ładowaniem złożeń, jestem pewien, że jest ci dobrze znany. Problem polega na tym, że "Host.Services" był znany w Host Application Domain, ponieważ jest przechowywany w "C: \ Program Files \ Moja aplikacja", a Domain Application szukając go szuka w "C: \ My Plug- ins ".

Cóż, myśleliśmy, że poleciliśmy, aby również wyglądał w "AppDomain.CurrentDomain.BaseDirectory", który byłby "C: \ Program Files \ Moja aplikacja", ale tak nie było.

AppDomain.AssemblyResolve na ratunek? Ok, więc pracowaliśmy z tymi dziwactwami wcześniej, więc wiedzieliśmy, jak możemy użyć "AppDomain.AssemblyResolve ", aby ręcznie rozwiązać wszystkie zespoły, których nie może obsłużyć AppDomain to self.

1: string applicationBase = Path.GetDirectoryName(interOperabilityPackageType.AssemblyDescription.AssemblyPath); 
    2: AppDomainSetup setup = new AppDomainSetup 
    3: { 
    4:  ApplicationName = name, 
    5:  ApplicationBase = applicationBase, 
    6:  PrivateBinPath = AppDomain.CurrentDomain.BaseDirectory, 
    7:  PrivateBinPathProbe = AppDomain.CurrentDomain.BaseDirectory, 
    8:  ConfigurationFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile 
    9: }; 
    10: 
    11: Evidence evidence = new Evidence(AppDomain.CurrentDomain.Evidence); 
    12: AppDomain domain = AppDomain.CreateDomain(name, evidence, setup); 
    13: domain.AssemblyResolve += Resolve; 

To powinno działać w porządku, dobrze myśleliśmy więc i te znowu myliliśmy się, co dzieje się teraz jest to, że zamiast rzeczywiście coraz miarę inicjalizacji aplikacji domeny, a korzystanie z niego, zamiast to nie tam, gdzie mamy podpięty do obsługi zdarzeń dla rozwiązywania złożeń.

Ponownie wyjątek wygląda bardzo podobnie do poprzedniego, ale tym razem nie może znaleźć zestawu zawierającego typ, który ma procedurę "Rozwiąż", którą ustawiliśmy w ostatniej linii w powyższym fragmencie.

AppDomain.Load then! OK, więc oczywiście podczas podłączania obsługi zdarzeń, Domena Aplikacji musi znać Typ obiektu obsługującego to zdarzenie, co jest całkiem zrozumiałe, gdy się nad tym zastanowić, więc jeśli Domena Aplikacji nie może nawet znaleźć tego i ładunek, którego tak naprawdę nie możemy obsłużyć.

Co dalej? Naszym zamysłem było ręczne polecenie Domain Application załadowania płytkiego zespołu, który nie miał żadnych innych zależności, które można znaleźć w GAC, i zawiesić procedurę obsługi zdarzeń.

1: string applicationBase = Path.GetDirectoryName(interOperabilityPackageType.AssemblyDescription.AssemblyPath); 
    2: AppDomainSetup setup = new AppDomainSetup 
    3: { 
    4:  ApplicationName = name, 
    5:  ApplicationBase = applicationBase, 
    6:  PrivateBinPath = AppDomain.CurrentDomain.BaseDirectory, 
    7:  PrivateBinPathProbe = AppDomain.CurrentDomain.BaseDirectory, 
    8:  ConfigurationFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile 
    9: }; 
    10: 
    11: Evidence evidence = new Evidence(AppDomain.CurrentDomain.Evidence); 
    12: AppDomain domain = AppDomain.CreateDomain(name, evidence, setup); 
    13: domain.Load(File.ReadAllBytes(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Host.AssemblyLoader.dll"))); 
    14: domain.AssemblyResolve += new AssemblyLoader(AppDomain.CurrentDomain.BaseDirectory).Handle; 

Korzystanie z bardzo prostej, niewielkiej klasy, takiej jak poniższa, i nie zwracaj uwagi na dziwne zachowanie w trybie rozwiązywania.

1: [Serializable] 
    2: public class AssemblyLoader 
    3: { 
    4:  private string ApplicationBase { get; set; } 
    5: 
    6:  public AssemblyLoader(string applicationBase) 
    7:  { 
    8:   ApplicationBase = applicationBase; 
    9:  } 
    10: 
    11:  public Assembly Resolve(object sender, ResolveEventArgs args) 
    12:  { 
    13:   AssemblyName assemblyName = new AssemblyName(args.Name); 
    14:   string fileName = string.Format("{0}.dll", assemblyName.Name); 
    15:   return Assembly.LoadFile(Path.Combine(ApplicationBase, fileName)); 
    16:  } 
    17: } 

Tak tak czy nie? ... NIE! ... wciąż ten sam problem.

Rzeczy są o wiele prostsze! W końcu sprawy stały się o wiele prostsze, gdy udało nam się je uruchomić.

Nie mogę powiedzieć, jak dokładnie zespół .NET przewidział, że to powinno działać, nie mogliśmy znaleźć żadnych użytecznych rzeczy, do których użyto "PrivateBinPath" i "PrivateBinPathProbe". Używamy ich teraz i sprawiliśmy, że działają tak, jak się spodziewaliśmy!

więc zmieniliśmy klasę „AssemblyLoader”, aby wyglądać tak zamiast:

1: [Serializable] 
    2: public class AssemblyLoader : MarshalByRefObject 
    3: { 
    4:  private string ApplicationBase { get; set; } 
    5: 
    6:  public AssemblyLoader() 
    7:  { 
    8:   ApplicationBase = AppDomain.CurrentDomain.SetupInformation.PrivateBinPath; 
    9:   AppDomain.CurrentDomain.AssemblyResolve += Resolve; 
    10:  } 
    11: 
    12:  private Assembly Resolve(object sender, ResolveEventArgs args) 
    13:  { 
    14:   AssemblyName assemblyName = new AssemblyName(args.Name); 
    15:   string fileName = string.Format("{0}.dll", assemblyName.Name); 
    16:   return Assembly.LoadFile(Path.Combine(ApplicationBase, fileName)); 
    17:  } 
    18: } 

Więc zamiast podpinania zdarzenie gdzie stworzyliśmy aplikację domenę, możemy pozwolić klasa zrobić to przez to samo, i zamiast "CurrentDomain".

OK, czekaj, czy nie powoduje to problemu podczas tworzenia w fabryce, ponieważ trwa ładowanie w niewłaściwej domenie? Na szczęście jesteś w stanie tworzyć obiekty w domenach z zewnątrz.

Więc tworzenia domena jest teraz odbywa się następująco:

1: string applicationBase = Path.GetDirectoryName(interOperabilityPackageType.AssemblyDescription.AssemblyPath); 
    2: AppDomainSetup setup = new AppDomainSetup 
    3: { 
    4:  ApplicationName = name, 
    5:  ApplicationBase = applicationBase, 
    6:  PrivateBinPath = AppDomain.CurrentDomain.BaseDirectory, 
    7:  PrivateBinPathProbe = AppDomain.CurrentDomain.BaseDirectory, 
    8:  ConfigurationFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile 
    9: }; 
    10: 
    11: Evidence evidence = new Evidence(AppDomain.CurrentDomain.Evidence); 
    12: AppDomain domain = AppDomain.CreateDomain(name, evidence, setup); 
    13: domain.CreateInstanceFrom(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Host.AssemblyLoader.dll"),"Host.AssemblyLoader"); 

My nawet nie dbają o utrzymanie odniesienia do „AssemblyLoader”, ponieważ powinien on być dość dużo utrzymywane przy życiu przez zahaczenie to samo aż do wydarzenie.

Mam nadzieję, że pomoże to niektórym, którzy natknęli się na ten sam problem, widzę wiele obejść, w których ludzie po prostu pozwalają zainstalować wtyczki w tym samym katalogu hosta, mając wszystkie niezbędne zależności wdrożone wraz z wtyczką nawet choć nie jest to coś, o czym wtyczka wie, że jest zależna i tak dalej.

Powyższe umożliwia przynajmniej instalację wtyczek z naszej bazy aplikacji, co moim zdaniem jest miłe.

Jeśli ktoś rozwiązał to inaczej, to proszę o odpowiedź, może uda nam się znaleźć plusy i minusy w dowolny sposób lub po prostu odkryjemy lepsze rozwiązanie.

Jeśli masz jakieś pytania lub nie możesz uzyskać powyższych informacji, zadzwoń.

autor: Jens Melgaard | wysłano @ czwartek, 1 lipca 2010 r. 15:08 | Feedback (0)

Answer 2

Czy jest jakiś powód, dla którego nie należy używać oryginalnych zespołów?

Jeśli twoja zagraniczna aplikacja nie używa poświadczeń uniemożliwiających jej dostęp do oryginalnych zestawów, może to zrobić metoda AppDomain.CreateInstanceFromAndUnwrap.

Proponuję odizolować swoją zdalnie wykonywany kod w klasie MarshalByRefObject, przy użyciu klasy tak:

public class MyRemoteClass : MarshalByRefObject 
{ 
    public void SetupLogging() 
    { 
     // ... 
    } 
} 

i używać go tak:

var assemblyPath = new Uri(typeof(MyRemoteClass).Assembly.CodeBase).LocalPath; 
var remote = (MyRemoteClass)domain.CreateInstanceFromAndUnwrap(assemblyPath, "NameSpace.MyRemoteClass"); 

remote.SetupLogging(); 

To pozwoli uniknąć niepotrzebnych kłopotów z przekazywanie wartości zwracanych przez stan appdomain, ponieważ DoCallBack nie zwraca wartości. Pozwoli to również uniknąć mieszania kodu instalacyjnego AppDomain z logiką aplikacji.

Wreszcie, być może trzeba przechwycić AppDomain.AssemblyResolve w MyRemoteClass, aby inne zależności ładowały się poprawnie.

Answer 3

Jeśli chcesz załadować zespół samodzielnie, unikaj ładowania z bajtów ... Zalecam użycie co najmniej ładowania przez pełną ścieżkę montażu.

Ogólnie rzecz biorąc, aby zbadać problemy z ładowaniem złożeń, serach dla "przeglądarki dziennika fuzyjnego" (http://www.bing.com/search?q=fussion+log+viewer) i użyć narzędzia, aby zobaczyć, gdzie kod próbuje załadować złoŜenia.

Answer 4

Według http://msdn.microsoft.com/en-us/library/aehss7y0.aspx zachowanie AppDomain.CreateDomain zmieniła się z .NET4 i należy użyć http://msdn.microsoft.com/en-us/library/ms130766.aspx i konfiguracji Evidence i grants „ręcznie” ...

Answer 5

znalazł rozwiązanie po załadowaniu zespół od ustalania .GetName bajt () .CodeBase na zero rozwiązało problem ...

Po rozejrzeniu się znalazłem stronę this i ma ona lepsze rozwiązanie niż moja!

Answer 6

Moja wykształcony Domyślam się, że brakowało ważną część komunikatu o błędzie:

System.IO.FileNotFoundException był nieobsługiwany Message = Nie można załadować pliku lub zestawu „TaskExecuter, Version = 1.0.4244.31921, Culture = neutralny, PublicKeyToken = null ' lub jedna z jego zależności. System nie może odnaleźć określonego pliku. Źródło = mscorlib

Oprócz tego, że nie można załadować zestawu z innego miejsca niż w ramach aplikacji, prawdopodobnie brakuje jakiegoś modułu zależności, skąd można go rozwiązać i załadować.

Nawiasem mówiąc, jeśli zaczniesz ładować z bajtów, powinieneś rzucić okiem na zespoły załadowane do twojej domeny.Zestaw zależności może być już załadowany, ale zależności nie można rozwiązać automatycznie. Jeśli ten sam zespół zostanie załadowany dwa razy, jego typy będą niezgodne. Dostaniesz śmieszne CastExceptions mówiąc, że obiekt YourClass nie może być rzutowany na YourClass.

Możesz spróbować zarejestrować program obsługi zdarzeń AssemblyResolve w swojej domenie, ale dzięki temu łatwo możesz skończyć z czarną magią wyczarowując rzeczy z piekła .dll. Jeśli wszystko inne zawiedzie i pójdziesz do piekła .dll siebie, spotykają mnie tutaj: Need to hookup AssemblyResolve event when DisallowApplicationBaseProbing = true