Как получить доступ к пространствам имен в DLL через другую DLL?

У меня есть несколько библиотек DLL (управляемых мной или не управляемых мной), которые я хотел бы включить в CoreLib.dll, чтобы мне не приходилось включать (возможно) сотни библиотек DLL в каждое приложение, которое использует эти библиотеки DLL. Я включаю DLL со ссылкой непосредственно на DLL.

Поэтому я также хотел бы создать экземпляры классов, объявленных в этих DLL, в приложении, которое я создаю. Я не могу сделать то, что изображено в проекте MyApp.exe, хотя я хотел бы. В CoreLib нет ссылки на A, B или C.

Как я могу выполнить то, что я хочу?

РЕДАКТИРОВАТЬ Я использовал Facade Pattern, как предложено, однако я получаю ошибку компиляции. Я должен включить A.dll в проект MyApp. Зачем? Это то, чего я хотел избежать. Есть ли способ обойти это?

 Josh C.10 окт. 2012 г., 20:48
Как вы планируете узнать типы в этих различных DLL?
 Tizz10 окт. 2012 г., 22:52
Я могу получить типы, доступные в моих библиотеках A, B, C, зная пространство имен и позволяя автозаполнению сообщать мне, что доступно. Я не хочу плагин архитектуры, хотя. Я просто не хочу иметь сотни DLL-библиотек, я хотел бы объединить в одну DLL и не использовать ILMerge, который объединит библиотеки DLL и EXE в один EXE-файл. Я хочу иметь возможность повторно использовать dll CoreLib и, возможно, передать dll другим людям, чтобы они тоже могли ее использовать.
 Alex11 окт. 2012 г., 09:33
@Tizz ILMerge может объединить DLL в другую DLL! Вы просто говорите ему, чтобы вывести dll - смотрите мой обновленный ответ.
 rene10 окт. 2012 г., 20:45
Не уверен, что это дубликат, но он может вас куда-нибудь ...stackoverflow.com/questions/12307602/...
 Josh C.10 окт. 2012 г., 20:54
Возможно, вы пытаетесь подключить архитектуру:stackoverflow.com/questions/1071265/...

Ответы на вопрос(3)

ILMerge объединить сборки в одну.

Затем вы можете использовать все классы в этой сборке так, как вы хотите.

Вот'Вот пример того, как объединить несколько сборок (dll) в одну сборку (dll):http://www.fishofprey.com/2011/01/ilmerge-to-combine-multiple-dlls.html

По сути, вы просто делаете

ILMerge.exe /out:CoreLib.dll A.dll B.dll C.dll
 Alexei Levenkov10 окт. 2012 г., 22:11
+1, тоже не очень хороший стартовый вариант ...
Решение Вопроса

что это возможно. Добавление ссылки на библиотеки DLL A, B и C в CorLib будет означать только то, что CorLib ссылается на эти библиотеки DLL (таблица метаданных AssemblyRef будет иметь одну запись для каждой сборки). Это не означает, что CorLib переопределяет сборки и любые типы ссылочных сборок. в MyApp.exe вам нужно будет ссылаться на сборки A, B и C.

Альтернативным решением было бы определить класс Facade в CorLib и перенаправить вызовы в A, B и C DLL. В MyApp.exe вы будете использовать класс Facade.

 jags11 окт. 2012 г., 20:47
Вы можете переопределить методы в классе Facade, а затем делегировать вызов оригинальному методу \ классу. Метод Static \ Instance не будет иметь никакого значения.
 Tizz11 окт. 2012 г., 20:34
Мне нравится идея использования класса Facade, однако, что если у меня есть статические методы в классах? Я не могу перенести статический метод (или статические классы в этом отношении).
 jags13 окт. 2012 г., 07:03
Я думаю, что клиент должен будет ссылаться на библиотеки A и B. Но клиенту не нужно будет обращаться к какому-либо классу из библиотек A или B. Клиенту нужно будет только взаимодействовать с вашим классом Facade. Это похоже на блоки обработки исключений и ведения журнала Enterprise Library. При регистрации некоторой информации или обработке некоторого исключения с использованием блоков приложения Enterprise Library клиенту нужно будет взаимодействовать только с классом Facade (например, Logger), но клиент должен ссылаться на все библиотеки DLL, используемые блоком.
 Tizz12 окт. 2012 г., 22:25
Поэтому я сделал все это (что заняло некоторое время, потому что есть много методов, классов и переменных, и теперь говорится, что проекты MyApp.exe должны ссылаться на A.dll. Это то, чего я пытался избежать в первую очередь. Есть идеи, что я сделал не так? Или не сделал? Я обновил свой вопрос выше.

что вы путаете DLL (которая в собственном управляемом мире содержит фактическую реализацию) с файлами LIB / OBJ, которые содержат что-то, что будет объединено в EXE / DLL во время сборки для включения реализации в соответствующий EXE / DLL.

У вас есть по существу 2 варианта:

нести все библиотеки DLL с вашим приложением (нормальный подход, следует использовать, если у вас нет странных требований). Вы можете ссылаться на сборки непосредственно из основного приложения и создавать классы или создавать какие-то фабрики в вашей сборке CoreLib, которые будут создавать классы по требованию. В более позднем случае вам может не понадобиться добавлять ссылки на все сборки A..C (если вы не используете классы напрямую, а через некоторые общие интерфейсы / базовые классы), но вам все равно придется их переносить.своего рода объединение сборок в одну (т.е. ILMerge, как предложено @Alex). Этот подход потребует лучшего понимания CLR, чем первый, и может оказаться невозможным, если участвуют сторонние сборки (из-за лицензирования).

Ваш ответ на вопрос