Добрый день увыжаемые коллеги, снова меня мучает архитектурный вопрос.
Представьте, что у вас есть библиотека с api, которая работает с другой библиотекой из опенсорса.
Вы хотите что бы пользователь, который будет использовать ваше апи не интересовался ее зависимостями, что бы он просто подключал вашу библиотеку и все.
Как это сделать правильно? Скорее всего такое сделать невозможно, если не брать исходники самой библиотеки и не включать их в свою реализацию, но это немного не то.
Подскажите пожалуйста.
Здравствуйте, -n1l-, Вы писали:
N>Вот в с++ есть статическая линковка, то что нужно было бы.
Посмотри
ILMerge... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Здравствуйте, rameel, Вы писали:
R>Здравствуйте, -n1l-, Вы писали:
N>>Вот в с++ есть статическая линковка, то что нужно было бы.
R>Посмотри ILMerge
Или можно заморочиться по другому, встроить нужную библиотеку в ресурсы и подгружать ее подписавшись на AssemblyResolve текущего AppDomain. Кода там на пару строчек.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Здравствуйте, rameel, Вы писали:
R>>Посмотри ILMerge
R>Или можно заморочиться по другому, встроить нужную библиотеку в ресурсы и подгружать ее подписавшись на AssemblyResolve текущего AppDomain. Кода там на пару строчек.
Это не решение. Во-первых, возможное нарушение лицензии (с LGPL могут быть проблемы).
Во-вторых, грабли с load context/ресурсными сборками.
В-третьих, вспомогательная библиотека, завязанная на AssemblyResolve… вам точно хочется таких приключений?
Правильный ответ — использовать nuget (можно свой хост) и не мучаться. Его именно для этого и сделали.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, rameel, Вы писали:
R>>>Посмотри ILMerge
R>>Или можно заморочиться по другому, встроить нужную библиотеку в ресурсы и подгружать ее подписавшись на AssemblyResolve текущего AppDomain. Кода там на пару строчек.
S>Это не решение. Во-первых, возможное нарушение лицензии (с LGPL могут быть проблемы).
Это понятно, только вопрос лицензии — это уже отдельный вопрос.
S>Во-вторых, грабли с load context/ресурсными сборками.
S>В-третьих, вспомогательная библиотека, завязанная на AssemblyResolve… вам точно хочется таких приключений?
Ага, есть проблема с ресурсными сборками, об этом надо знать. Но если их нет, то и проблем с ними тоже нет
— Кеп. А грабли с контекстом могут возникнуть только если грузить через Assembly.Load(byte[]), да и то в простых случаях на эти грабли тяжело наступить.
S>Правильный ответ — использовать nuget (можно свой хост) и не мучаться. Его именно для этого и сделали.
Полностью согласен. Изначально я отвечал на вопрос о технической возможности внедрения сборки, глаз зацепился за статическую линковку, отсюда и ответ. Сейчас посмотрел главный вопрос топикстартера, и да, ответ — использовать nuget.
ЗЫ. Вообще, у нас в проекте есть несколько самописных утилиток, некоторые из них используют нашу же вспомогательную сборку. Для удобства мы когда-то очень давно воспользовались ilmerge, чтобы эти утилиты были представлены в виде отдельных самодостаточных файлов. А так как ресурсных сборок они не содержат, то и проблем с ними нет, плюс маааааленькая плюшка в виде наличия только одного файлика вместо 2-3.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
