Как сделать тип известным в одном домене приложений, но неизвестным в другом? - PullRequest
0 голосов
/ 18 декабря 2009

Мой вопрос прост. Для целей модульного тестирования мне нужен статически скомпилированный тип, производный от типа Exception, который известен в одном домене приложений, но неизвестен в другом.

Простое решение будет:

  1. Для создания подпапки в каталоге исполняемого файла приложения.
  2. Поместите туда сборку с некоторым производным типом Exception.
  3. Обновите файл app.config, добавив эту папку в путь поиска.
  4. Создайте новый AppDomain, но с немного другим app.config - без элемента.

Теперь основной домен приложения может легко загружать тип, поскольку его местоположение находится на пути поиска, а второй домен приложения не может - миссия выполнена.

Но этот метод требует:

  • дополнительная папка
  • Макетная сборка
  • Файл конфигурации приложения-пустышки

Мне интересно, смогу ли я достичь своей цели проще, но без Reflection.Emit.

Спасибо.

EDIT:

Подойдет любой производный от исключения тип.

Мотивация:

У нас есть распределенное приложение, состоящее из клиентов, сервера и агентов. Есть сборки, найденные исключительно на агентах, а некоторые найдены исключительно на сервере. Сервер и агенты могут быть расширены после развертывания с новыми функциями. Дело в том, что возможно, что какое-то действие завершится неудачей с исключением, тип которого неизвестен на принимающей стороне. Я разрабатываю средство, чтобы справиться с этой ситуацией, и хочу сейчас провести его модульное тестирование. Для этого мне нужно смоделировать ситуацию, когда исключение, вызванное на удаленном сайте, имеет тип, неизвестный на принимающей стороне.

Ответы [ 2 ]

1 голос
/ 18 декабря 2009

AppDomain.CreateDomain имеет перегрузки, которые принимают AppDomainSetup. Многие из свойств этого класса соответствуют соответствующей записи в файле .config. Включая PrivateBinPath. ApplicationBase устанавливает домашний каталог, в котором CLR начинает поиск.

1 голос
/ 18 декабря 2009

Прежде всего, я не знаю ни одного способа предотвратить загрузку типа из загруженной сборки. Это означает, что нам нужно говорить о собраниях, а не о типах. Даже если определенный тип не инициализируется до тех пор, пока к нему не обращаются в первый раз, если он будет доступен, если загружена сборка с вашим типом, вы не сможете заставить CLR отучить его.

Другими словами, у вас должен быть отдельный dll с защищенным типом. Остальная часть может быть решена несколькими способами, то есть вместо игры с appconfig вы можете загрузить сборку с Assembly.LoadFrom в домене приложения, где вам это нужно.

Насколько это лучше, решать вам в зависимости от того, что именно вы пытаетесь сделать здесь.

...