Слияние DLL и изменение управляющих пространств имен

Question

Я хочу создать сингл dll, слитый с сторонним dll. Это означает, что конечным потребителям придется иметь дело только с 1 dll вместо 2.

Ради увеличения скажем, что сторонняя dll - это nLog. Как мне поступить со случаями, когда у потребителя объединенной DLL уже есть ссылка NLog в их проекте?

В идеале, я хотел бы иметь возможность изменить пространство имен NLog в моем проекте на «XyzNLog», что означает, что пользователю не нужно будет делать псевдонимы ... Есть идеи, как я могу это сделать?

Теперь я знаю, что могу добавить псевдонимы в свой проект для NLog, чтобы мне называть его XyzNLog, но я хочу, чтобы то же самое можно было перенести на потребителей объединенной библиотеки DLL, чтобы никогда не возникало конфликтов.

ОБНОВЛЕНИЕ - Решение

http://blog.mattbrailsford.com/2010/12/10/avoiding-dependency-conflicts-using-ilmerge/

Бинго! Таким образом, используя ILMerge, он становится возможно объединение стороннего библиотеки DLL в с поставщиками собственная DLL, то есть у нас будет только одна DLL для развертывания. Но это еще не все, мы на самом деле может пойти еще дальше, и скажите ILMerge интернализировать все Зависимости . Что это делает конвертирует все сторонние классы быть объявленным внутренним, что означает они могут быть использованы только изнутри финальная DLL. Woo Hoo! проблема решена =)

Учитывая это, проблема, при которой у потребителя моей dll также может быть NLog, исчезает ... поскольку мой ссылочный NLog переходит во внутреннее состояние! Это именно то, что я хочу.

У кого-нибудь есть отзывы или мысли по этому поводу?

Answer 1

Я согласен с Гансом, я бы настоятельно рекомендовал отказаться от регистрации DLL отдельно.

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

Затем вы можете придуматьнекоторые умные методы развертывания для определения, если DLL уже зарегистрирована и т. д.

Answer 2

Я должен согласиться с @Hans Passant (и вот некоторая информация об часто обсуждаемом аде DLL), но так как вы задали вопрос, я постараюсь ответить на него.

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

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

Например, вы можете предоставить доступ к методу NLog Log(), используя статический метод в вашем классе, скажем XyzNLog.Logger.Log(), заботясь об инициализации и обо всем остальном внутри,внутри вашего кода (статический конструктор или что-то еще, что вам нравится).Поскольку вы загружаете сборку NLog, используя метод, описанный выше, вы будете единственным, кто имеет доступ к встроенной сборке NLog напрямую, и пользователь не сможет получить к ней доступ.Теперь вы не получаете преимущества автоматической экспозиции всех классов из NLog, вам все равно придется выставлять их вручную в этом случае.

РЕДАКТИРОВАТЬ : Другой подход - попытаться использоватьILMerge с / внутренним флагом , как описано здесь .Возможно, вы не сможете полностью решить проблему, но посмотрите на эту статью , чтобы узнать, сможете ли вы избежать ловушек, описанных автором.Оповещение о спойлере: на этом тоже не все peaches'n'cream, но это может сработать, если приложить дополнительные усилия.