Есть приложение. Оно через AssemblyLoadFrom загружает две сборки. Сборки лежат в разных подпапках папки основного приложения. Вторая сборка имеет ссылку на первую.
Сборки успешно загружаются (классы из первой успешно создаются), но при попытки инициализации класса из второй сборки имеющего ссылку на классы из первой вылетает исключение, что невозможно загрузить первую сборку. Если положить сборки в одну подпапку, то все ок.

В чем проблема, не подскажите?
Спасибо!

Здравствуйте, Хэлкар.

Вот здесь Assembly.LoadFrom Method (String) есть описание контекстов загрузки сборки и в частности про load-from context (по-моему это как раз твой случай):

The load-from context allows an assembly to be loaded from a path not included in probing, and yet allows dependencies on that path to be found and loaded because the path information is maintained by the context.

Если не заморачиваться с механизмом probing path, то наверно самым простым решением проблемы будет событие AssemblyResolve:

It is the responsibility of ResolveEventHandler for this event to return the assembly that resolves the type, assembly, or resource. The assembly must be loaded into an execution context; if it is loaded into the reflection-only context, the load that caused this event to be raised fails.

Обе подпапки включены в probing.

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

Х>В чем проблема, не подскажите?
Х>Спасибо!
Если несколько разных сборок ссылаются на одну сборку и они находятся в разных местах, то может поместить ее в GAC?

А>Если несколько разных сборок ссылаются на одну сборку и они находятся в разных местах, то может поместить ее в GAC?

Возможно, но пока хочется понять в чем проблема.

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

Х>Есть приложение. Оно через AssemblyLoadFrom загружает две сборки. Сборки лежат в разных подпапках папки основного приложения. Вторая сборка имеет ссылку на первую.
Х>Сборки успешно загружаются (классы из первой успешно создаются), но при попытки инициализации класса из второй сборки имеющего ссылку на классы из первой вылетает исключение, что невозможно загрузить первую сборку. Если положить сборки в одну подпапку, то все ок.

Х>В чем проблема, не подскажите?
Х>Спасибо!

WPF?

C>WPF?
Да, основное приложение WPF, но библиотеки с UI никак не связаны.

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

C>>WPF?
Х>Да, основное приложение WPF, но библиотеки с UI никак не связаны.

Ну у меня были подобные чудеса, помнится. В AssemblyInfo проверьте, что звездочка в номере версии не стоит. Мне, помнится, помогло.

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

Х>Есть приложение. Оно через AssemblyLoadFrom загружает две сборки. Сборки лежат в разных подпапках папки основного приложения. Вторая сборка имеет ссылку на первую.
Х>Сборки успешно загружаются (классы из первой успешно создаются), но при попытки инициализации класса из второй сборки имеющего ссылку на классы из первой вылетает исключение, что невозможно загрузить первую сборку. Если положить сборки в одну подпапку, то все ок.

Х>В чем проблема, не подскажите?
Х>Спасибо!

Можно посмотреть fusion log. Запусти fuslogvw.exe и посмотри на лог загрузки сборки, там будет перечень путей, откуда CLR пробует загрузить сборку, вполне возможно там будет дополнительная информация о том, в чем проблема.

Подробности можно глянуть здесь.

ST>Можно посмотреть fusion log. Запусти fuslogvw.exe и посмотри на лог загрузки сборки, там будет перечень путей, откуда CLR пробует загрузить сборку, вполне возможно там будет дополнительная информация о том, в чем проблема.

ST>Подробности можно глянуть здесь.

Да, уже смотрел, там нет попытки загрузить эту сборку второй раз (а первый раз она удачно загружена)

C>Ну у меня были подобные чудеса, помнится. В AssemblyInfo проверьте, что звездочка в номере версии не стоит. Мне, помнится, помогло.

Нет, звездочек нет.

Не удается воспроизвести вашу проблему. Вам удается? Т.е. если создать тестовый проект с двумя простейшими тестовыми сборками.
И еще рег. стандарты у сборок одинаковые?

Нет, на чистой сборке не воспроизводится. В том то и проблема что я понимаю что проблема где-то у меня, но в чем она непонятно.