Натолкнулся на странность.
Есть .exe, к нему подключена .dll, которая использует иные .dll. Весь комплект библиотек лежит в поддиректории, которая приписана в probing секцию .exe.config. Библиотеки подключены как reference. FW 3.5, пробовали и 4.0.
Все прекрасно работает локально на Win 2003 x86 и x64, Win 2008 x64.
Если директория с .exe размещается в сети, то на Win 2003 x86 работает, на x64 — нет. Ошибка безопасности. Если навалить .dll в директорию с .exe — все работает.
Что такое, почему и как с этим бороться ?
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Что такое, почему и как с этим бороться ?
Я бы проверил текст и стек исключения +лог fuslogvw. И убедился бы, что права на папку с dll правильно прописаны.
Если с этим всё ок — похоже на что-то типа http://support.microsoft.com/kb/2580188/en-us
А крайний случай: проверьте политику через caspol, вот пример.
Re[2]: Странности с правами при загрузки .dll по сети в х64 среде.
Здравствуйте, Sinix, Вы писали:
S>А крайний случай: проверьте политику через caspol, вот пример.
Спасибо, оно. Permission Set для х86 и х64 — разный. Был задан для х86. На самом деле путаница была больше — .dll на 4.0 вызывала .dll на 2.0, для первой были х64 права, для второй — только х86.
P.S. А есть ли какой удобный способ смотреть и\или назначать эти permission ? Очень неудобно вызывать почти десяток caspol при настройке системы. Мы то еще ладно, а вот клиентам это объяснить
Re[3]: Странности с правами при загрузки .dll по сети в х64 среде.
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Спасибо, оно. Permission Set для х86 и х64 — разный. Был задан для х86. На самом деле путаница была больше — .dll на 4.0 вызывала .dll на 2.0, для первой были х64 права, для второй — только х86.
Эт как? Один же рантайм, .net 4. Чтобы политики работали, надо явно <legacyCasPolicy> прописать, вот тут написано подробнее.
N_P>P.S. А есть ли какой удобный способ смотреть и\или назначать эти permission ? Очень неудобно вызывать почти десяток caspol при настройке системы. Мы то еще ладно, а вот клиентам это объяснить
0. Перейти на .net 4.
1. Не вызывать код из сетевой папки.
2. Написать bat-файл, который будет править политики.
3. Enterprise-level policy.
Re[3]: Странности с правами при загрузки .dll по сети в х64 среде.
Здравствуйте, pugv, Вы писали:
N_P>>P.S. А есть ли какой удобный способ смотреть и\или назначать эти permission? Очень неудобно вызывать почти десяток caspol
P>Есть оснастка mscorcfg.msc из SDK, если Вы про ГУИ.
А его нет для 4.0
Вообще — лучшим вариантом был-бы код. Позволяющий из приложения получать и устанавливать безопасность для любого FrameWork.
Re[5]: Странности с правами при загрузки .dll по сети в х64 среде.
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Вообще — лучшим вариантом был-бы код. Позволяющий из приложения получать и устанавливать безопасность для любого FrameWork.
А, код... Ну вообще это всё в System.Security. Вот тут есть кусок кода, создающий кастомный Permission Set.
Re[6]: Странности с правами при загрузки .dll по сети в х64 среде.
Здравствуйте, pugv, Вы писали:
P>Вот тут есть кусок кода, создающий кастомный Permission Set.
Маааленькая проблема: чтобы раздать права нужны права раздать права. Как-то вот так получается
Re[7]: Странности с правами при загрузки .dll по сети в х64 среде.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, pugv, Вы писали:
P>>Вот тут есть кусок кода, создающий кастомный Permission Set. S>Маааленькая проблема: чтобы раздать права нужны права раздать права. Как-то вот так получается
Приложение под админом локально мы запустим. Сложностей нет. Сейчас основная трудность в неочевидности и разбросанности всех этих настроек.
Re[8]: Странности с правами при загрузки .dll по сети в х64 среде.
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Приложение под админом локально мы запустим. Сложностей нет. Сейчас основная трудность в неочевидности и разбросанности всех этих настроек.
Да, неочевидно — это мягко сказано
Такой вопрос: а как у вас получилось вот так сделать:
Спасибо, оно. Permission Set для х86 и х64 — разный. Был задан для х86. На самом деле путаница была больше — .dll на 4.0 вызывала .dll на 2.0, для первой были х64 права, для второй — только х86.
?
Или я ничего не понимаю, или dll, написанная под 2.0 должна нормально работать под clr4, без приседаний с политикой.
Re[9]: Странности с правами при загрузки .dll по сети в х64 среде.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Nikolay_P_I, Вы писали:
N_P>>Приложение под админом локально мы запустим. Сложностей нет. Сейчас основная трудность в неочевидности и разбросанности всех этих настроек. S>Да, неочевидно — это мягко сказано
S>Такой вопрос: а как у вас получилось вот так сделать: S>
S>Спасибо, оно. Permission Set для х86 и х64 — разный. Был задан для х86. На самом деле путаница была больше — .dll на 4.0 вызывала .dll на 2.0, для первой были х64 права, для второй — только х86.
S>?
S>Или я ничего не понимаю, или dll, написанная под 2.0 должна нормально работать под clr4, без приседаний с политикой.
Так, вроде — 2.0 хостится под 4.0. В отличие от того, что 2.0 исполняется под 3.5 ?
В любом случае — это только предположение. Дело в том, что caspol 4.0 на х64 мы пускали, не помогло. Запуск caspol 2.0 на х64 — помог.
Re[10]: Странности с правами при загрузки .dll по сети в х64 среде.
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>В любом случае — это только предположение. Дело в том, что caspol 4.0 на х64 мы пускали, не помогло. Запуск caspol 2.0 на х64 — помог.
Нет, она используется как обычная библиотека, скомпилированная под .net4. И в теории проблем с безопасностью быть не должно.
Один же рантайм, .net 4. Чтобы политики работали, надо явно <legacyCasPolicy> прописать, вот тут написано подробнее.
