Начало банально: в exe есть ссылка на dll, создается экземпляр класса, определенного в dll. Сама dll лежит рядом с exe.

Далее интересней. Если exe запускается с локального диска, то все работает. Если же с UNC, то Unhandled Exception: System.Security.Policy.PolicyException: Required permissions cannot be acquired.

Да, это лечится заведением зоны в .NET Configuration и прописыванием там доступа на UNC, но черт возьми, почему exe с UNC запустить можно, а загрузить dll из того же UNC — нельзя?


(у меня куча клиентов пускают exe c сервера. Оч-чень хотелось бы сделать приклад zero-administrative)

Здравствуйте, <Аноним>, Вы писали:

А>Да, это лечится заведением зоны в .NET Configuration и прописыванием там доступа на UNC, но черт возьми, почему exe с UNC запустить можно, а загрузить dll из того же UNC — нельзя?

И запустить можно, и загрузить, но при том нельзя нарушать соотв. полиси.

А>(у меня куча клиентов пускают exe c сервера. Оч-чень хотелось бы сделать приклад zero-administrative)

Не используй никаких операций, запрещенных для Intranet зоны.

Hello,
> Далее интересней. Если exe запускается с локального диска, то все работает. Если же с UNC, то Unhandled Exception: System.Security.Policy.PolicyException: Required permissions cannot be acquired.
>
> Да, это лечится заведением зоны в .NET Configuration и прописыванием там доступа на UNC, но черт возьми, почему exe с UNC запустить можно, а загрузить dll из того же UNC — нельзя?
>
> (у меня куча клиентов пускают exe c сервера. Оч-чень хотелось бы сделать приклад zero-administrative)

Подписывай все свои сборки публичным ключом, а для данного ключа можно в домене распространить политику полного доверия.

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

AVK>И запустить можно, и загрузить, но при том нельзя нарушать соотв. полиси.

Вот мне и непоятно, что же за полиси я нарушаю, который разрешает запускать программу, а потом ЭТОЙ ЖЕ программе не разрешает загрузить dll из ТОГО ЖЕ места... (Activator.CreateInstanceFrom валится точно так же)

AVK>Не используй никаких операций, запрещенных для Intranet зоны.

Беру .NET Configuration, в группе LocalIntranet_Zone в табе Permission Set вместо нынешнего LocalIntranet ставлю FullTrust и... результат тот же. Где еще указаны запрещения для Intranet зоны?

Здравствуйте, <Аноним>, Вы писали:

AVK>>И запустить можно, и загрузить, но при том нельзя нарушать соотв. полиси.

А>Вот мне и непоятно, что же за полиси я нарушаю, который разрешает запускать программу, а потом ЭТОЙ ЖЕ программе не разрешает загрузить dll из ТОГО ЖЕ места... (Activator.CreateInstanceFrom валится точно так же)

Еще раз — исключение возникает не из за того что ты загружаешь вобще, а из-за того что данная конкретная загружаемая dll требует какое то разрешение, которое данной зоне не доступно.

AVK>>Не используй никаких операций, запрещенных для Intranet зоны.

А>Беру .NET Configuration, в группе LocalIntranet_Zone в табе Permission Set вместо нынешнего LocalIntranet ставлю FullTrust и... результат тот же. Где еще указаны запрещения для Intranet зоны?

Там и указаны. Должно все работать.

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

TK>Подписывай все свои сборки публичным ключом, а для данного ключа можно в домене распространить политику полного доверия.

Возможно к этому все и придет...

Я нашел статью с примером, все похоже на мою ситуацию (только там возня с реестром). НО! У меня пример не заработал , поэтому очень прошу запустить этот пример у себя (он мелкий, компилится все сразу и без ошибок) и сказать о результатах. (там две проги, одна в середине статьи, другая дальше)

Заранее благодарен.

Hello, "Andrbig"
>
> Я нашел статью с примером, все похоже на мою ситуацию (только там возня с реестром).

Тут на сайте тоже подобная статья была...

НО! У меня пример не заработал , поэтому очень прошу запустить этот пример у себя (он мелкий, компилится все сразу и без ошибок) и сказать о результатах. (там две проги, одна в середине статьи, другая дальше)
>
Насколько я понимаю — раз у твоего приложения изначально ограничены права, то никакие манипуляции с настройками на уровне AppDomain отсутствующих полномочий не добавят.

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

TK>Насколько я понимаю — раз у твоего приложения изначально ограничены права, то никакие манипуляции с настройками на уровне AppDomain отсутствующих полномочий не добавят.

Похоже на то.

Но решение все же есть! Нормальные герои всегда идут в обход :
1. долбаная dll копируется в temp
2. ловится AssemblyResolve у домена и подсовывается эта dll (она уже на локальном диске )


Попутно. Извиняюсь за возможный RTFM, но не подскажет ли кто адрес примера по просмотру (определению) текущих разрешений? В хелпе что-то не могу найти ничего подходящего...

Hello, "Andrbig"

>
> Попутно. Извиняюсь за возможный RTFM, но не подскажет ли кто адрес примера по просмотру (определению) текущих разрешений? В хелпе что-то не могу найти ничего подходящего...

Программно это можно делать через класс System.Security.SecurityManager, а административно — через остнастку Microsoft .NET Framework Configuration

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

Это не самому себе письмо , это маленькое дополнение.

A>1. долбаная dll копируется в temp
A>2. ловится AssemblyResolve у домена и подсовывается эта dll (она уже на локальном диске )

Все это надо делать в другом домене, который потом выгрузить. Иначе dll не выгрузить и файл соответственно не удалить. А так все работает — проверил на собственной шкуре, т.е. программе.