Доброго времени суток всем читателям.
Вот с такой проблемой я столкнулся и никак не могу разобраться как с ней бороться при использовании вышеперечисленных методов загрузки сборок.

Итак, поехали. Есть папка и в ней три сборки:

plugins/myplugin/Main.dll
plugins/myplugin/A.dll
plugins/myplugin/B.dll

Сборки зависят друг от друга так:

A используется в B
A и B использует в Main

Сборка Main лежит в зашифрованном виде, поэтому в методе загрузки сборок я пишу такой код:

Byte[] assemblyBytes = CryptoManager.Unpack(AssemblyPath, AssemblyName);
Assembly plugInAssembly = Assembly.Load(assemblyBytes);                
foreach (var refAssembly in plugInAssembly.GetReferencedAssemblies())
{
    Assembly.LoadFrom(AssemblyPath + refAssembly.Name);
}

После этого в списке загруженных модулей появляются следующие записи:
<...>
MainApplication
Main
A
B
<...>

НО при попытке создать класс из Main, который ссылается на класс из A вываливается исключение: сборка A не найдена... Хотя она поидее загружена в домен! Как такое может быть?

Естественно, если написать такой код, вместо предыдущего:

Byte[] assemblyBytes = CryptoManager.Unpack(AssemblyName);
File.WriteAllBytes(AssemblyName + ".pack", assemblyBytes);
Assembly plugInAssembly = Assembly.LoadFrom(AssemblyName + ".pack");

То все заработает. Но мне не хочется сохранять расшифрованную сборку на системном диске...

Здравствуйте, DragonFire, Вы писали:

DF>НО при попытке создать класс из Main, который ссылается на класс из A вываливается исключение: сборка A не найдена... Хотя она поидее загружена в домен! Как такое может быть?

1) Для отладки таких проблем используйте утиллиту fuslogvw (входит в SDK)
2) Для указания локальных путей поиска сборок используйте privatePath

Здравствуйте, DragonFire, Вы писали:

DF>НО при попытке создать класс из Main, который ссылается на класс из A вываливается исключение: сборка A не найдена... Хотя она поидее загружена в домен! Как такое может быть?

У вас сборки загрузились в разные контексты, вот и начались проблемы. Использование бинарного образа приводит к тому, что сборка загружается "без контекста". В этом случае все ее зависитмости нужно разруливать вручную — в событии AppDomain.AssemblyResolve.

Здравствуйте, DragonFire, Вы писали:

DF>Сборка Main лежит в зашифрованном виде

Шифруете для защиты от декомпиляции? А как-то боритесь с тем что, ИМХО, можно относительно легко расшифровать, если заглянуть в программу?

Cпрашиваю, потому что мне идея нравиться, не кажеться достаточно надежной.

Здравствуйте, vf, Вы писали:

vf>Здравствуйте, DragonFire, Вы писали:

DF>>Сборка Main лежит в зашифрованном виде

vf>Шифруете для защиты от декомпиляции? А как-то боритесь с тем что, ИМХО, можно относительно легко расшифровать, если заглянуть в программу?

vf>Cпрашиваю, потому что мне идея нравиться, не кажеться достаточно надежной.

Да, шифруем =) Активационным ключом на основе серийного номера и некоторых данных с машины пользователя (например ID процессора, но мы его не используем)...

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, DragonFire, Вы писали:

DF>>НО при попытке создать класс из Main, который ссылается на класс из A вываливается исключение: сборка A не найдена... Хотя она поидее загружена в домен! Как такое может быть?

H>У вас сборки загрузились в разные контексты, вот и начались проблемы. Использование бинарного образа приводит к тому, что сборка загружается "без контекста". В этом случае все ее зависитмости нужно разруливать вручную — в событии AppDomain.AssemblyResolve.

Пытался в домен загрузить текущий — не получается...

Здравствуйте, DragonFire, Вы писали:

DF>Да, шифруем =) Активационным ключом на основе серийного номера и некоторых данных с машины пользователя (например ID процессора, но мы его не используем)...

Боюсь, вот это вас сильно разочарует Поэтому или не заморачивайтесь с уберзащитой, или переходите на обфускаторы с генерацией нативного кода. Правда, там грабли c рефлексией/биндингом/etc будут ещё серьёзнее.

Здравствуйте, DragonFire, Вы писали:

DF><skipped>
[offtop]
Ох, уж эти доморощенные защиты...
[/offtop]