Хм. Интересно. А где можно поподробнее посмотреть как это можно использовать у себя? А то на сайте mono нашёл только два страничке посвященные песочнице Mono.
Спасибо за ещё одно направление в котором нужно подумать. До этого так нормально и не знал для чего предназначен DLR. Сейчас посмотрел его поверхностно — позже посмотрю поподробнее. Однако мне кажется что любой подход имеет право на существование — в качестве плюсов к моему методу могу сказать что у меня уже сразу используется готовый язык. В случае DLR же, если я правильно понял, надо ещё описать синтаксис языка, и что во что компилируется.
1. Во первых класс «плагина» должен реализовывать ранее продуманный интерфейс. И этот класс должен предусматривать некий «менеджер» который будет отвечать за доступ к важным данным и функциям основного приложения.
Как раз такого подхода я и хочу добиться. Здесь проблема в том, что надо запретить в коде сточки вида System.IO.FileStream file = new System.IO.FileStream(«путь_до_важного_файла_с_паролями»);
2. Доступ к файлику с паролями стоит ограничить. Как минимум приложение может его просто блокировать в начале работы и разблокировать после выгрузки «плагинов» (вариант грубый но простой)
В статье я имел в виду файлы паролей не только самого приложения. Например — файл %APPDATA%/Opera/Opera/wand.dat. Не очень хорошо будет если такой файл попадёт не в те руки.
4. Ну и еще есть вариант подписи плагинов — то есть прежде чем плагин выпустить в свободное плавание — его исходный код изучает специалист и проверяет на потенциально опасный код. Такая система например с приложения в App Store от Apple. (Хотя опять же зависит от конкретной ситуации — подходит такой вариант, или нет)
1. Во первых класс «плагина» должен реализовывать ранее продуманный интерфейс. И этот класс должен предусматривать некий «менеджер» который будет отвечать за доступ к важным данным и функциям основного приложения.
2. Доступ к файлику с паролями стоит ограничить. Как минимум приложение может его просто блокировать в начале работы и разблокировать после выгрузки «плагинов» (вариант грубый но простой)
Об этом как раз сказано в заключении. Там же есть и решение — правильно настраивать уровни видимости — то, что к чему нельзя подпускать делаем internal. Правда защита такого плана обходится при помощи рефлексии. Сейчас как раз ищу способы защиты от такого.
Как раз такого подхода я и хочу добиться. Здесь проблема в том, что надо запретить в коде сточки вида System.IO.FileStream file = new System.IO.FileStream(«путь_до_важного_файла_с_паролями»);
В статье я имел в виду файлы паролей не только самого приложения. Например — файл %APPDATA%/Opera/Opera/wand.dat. Не очень хорошо будет если такой файл попадёт не в те руки.
К сожалению в моём случае не подходит.