Как загрузить блок, не используя блок. Загрузка?

Насколько я понимаю, вы хотите сделать следующее:

1. Загрузить сборку с диска в память, чтобы использовать в ней данные, или вызвать в ней код
2. Возможность выгрузить сборку позже
3. Избегайте блокировки сборки на диске, чтобы вы могли изменить ее, не выходя из приложения (или сначала выгрузив сборку)

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

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

Вот запрос Google , который должен предоставить вам несколько начальных статей.

Во-вторых, Чтобы избежать блокировки сборки на диске, это просто, просто сделайте сначала ее копию и загрузите копию вместо оригинала. Конечно, вы заблокируете копию, но копия - это просто временный файл для вашего приложения, поэтому никого не должно интересовать изменение этого файла. Это оставляет исходный файл разблокированным и изменяемым.

Вы должны попытаться использовать теневое копирование вместо использования перегрузок Assembly.Load , которые могут загружать сборки из байтового массива, если у вас более одной сборки который будет загружен и заменен.

Например, если ваша сборка подключаемого модуля A.dll использует вторую сборку B.dll, и вы используете трюк с байтовым массивом для загрузки A.dll в память перед вызовом Assembly.Load, вам нужно либо обрабатывать вызовы разрешения сборки в вашем домене приложения (вы можете получать уведомления, когда сборка должна быть загружена, и «помогать» процессу загрузки), либо вам нужно убедиться, что B.dll загружается первым таким же образом A .dll загружается, иначе загрузка A.dll из памяти автоматически загрузит B.dll с диска.

Вот еще некоторая информация об использовании отдельных доменов приложений.

Когда вы создаете другой домен приложения, используя AppDomain в .NET, вы создаете отдельный отсек в памяти, где вы можете запускать код. Он действительно отделен от вашего основного домена приложения и имеет только небольшое отверстие в стене, которое разделяет их.

Через это отверстие вы можете передавать сообщения, такие как вызовы методов и данные.

После создания нового домена приложения, вы загружаете в него одну или несколько сборок. Обычно вы загружаете 1, если сборка, которую вы хотите загрузить в нее, была создана для этого типа загрузки, или 2, если нет (подробнее об этом ниже).

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

В основном происходит следующее. Внутри этого другого домена приложения создается объект типа, загруженного в этот домен приложения. Этот тип происходит от MarshalByRefObject . Запрос на создание этого объекта пришел из первого домена приложения, и внутри этого домена приложения создается прокси-объект, который выглядит, но не является тем же объектом, который был создан в этом другом домене приложения. Прокси-сервер общается с этим другим объектом через эту дыру.

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

С этой настройкой позже вы сможете может разорвать соединение между объектами, а затем выгрузить этот другой домен приложения, что в основном разрушает этот отсек. Затем, если вы хотите, вы можете создать новый второй домен приложения и начать заново, фактически перезагружая сборки с диска еще раз.

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

Итак. убедитесь, что вы этого не делаете, передавайте собственные типы или типы, определенные вне сборок, которые вы хотите заменить.

Я упоминал, что вы можете захотеть загрузить как минимум две сборки. Причина этого заключается в том, что если тип, который вы хотите создать объект, тип, объявленный в этой сборке, которую вы хотите загрузить, не происходит от MarshalByRefObject , тогда проблема передачи типов через эту дыра снова появляется, и вы также загрузите сборку в свой основной домен. Типичный способ справиться с этим - иметь какой-то класс диспетчера подключаемых модулей, который происходит от MarshalByRefObject , и этот менеджер находится в этом другом домене и разговаривает с этими другими типами. Это позволяет избежать проблемы пропускания типов через эту дыру.

Я здесь уже некоторое время бредил, поэтому оставлю это как есть, но с этой информацией вы сможете понять и использовать найденные статьи с помощью этого запроса Google немного проще.

If you compile the DLLs on fly from the sources, you don't necessarily even have to make a copy, instead the re-compile process should be as following:

1) Destroy the application domain that has the assemblies loaded, effectively unlocking the DLLs.

2) Re-compile the scripts.

3) Re-create the application domain for plugins, and load the new assemblies in it.

Вы можете создать временную копию сборки и загрузить эту копию с помощью Assembly.Load. Поместите файловый монитор на оригинал и выгрузите / повторно загрузите временную копию обновленной сборки, когда файловый монитор обнаружит изменение.