Вы должны просто согласиться с тем, что ваш пользователь должен ссылаться на вашу сборку и вспомогательную сборку.
Да, вы, вероятно, можете заставить работать ilmerge, чтобы поддерживающая сборка целиком включалась в вашу собственную сборку. Но это полностью связывает график выпуска вашей сборки с графиком поддержки сборки. Не было бы никакой возможности обновить поддерживающую сборку для использования с вашей сборкой без повторного выпуска вашей собственной сборки.
Существует также вопрос об авторском праве и лицензировании. Если вы также написали вспомогательную сборку, я думаю, у вас не должно возникнуть никаких проблем. Но в противном случае слияние поддерживающей сборки с вашей собственной может, по крайней мере, не одобряться автором этой сборки, если не прямо запрещено.
Другим неприятным вариантом может быть возврат dynamic объектов из API вашей сборки вместо типов, объявленных в поддерживающей сборке. Это, конечно, может повлиять на производительность, а также свести на нет любую возможную безопасность типов во время компиляции, которая в противном случае была бы обычным преимуществом использования такого языка, как C#. Но это можно было сделать.
Если вы действительно не можете смириться с мыслью, что пользователь добавляет ссылку на вспомогательную библиотеку, разумным вариантом с точки зрения разработки программного обеспечения будет изменение API вашей сборки, чтобы он не возвращал типы из вспомогательной библиотеки. Им все равно понадобится эта сборка во время выполнения, если вы ее используете, но, по крайней мере, пользовательскому коду не потребуется явная ссылка. Вместо этого ваш API будет возвращать типы, которые объявляет ваша собственная сборка и которые обертывают типы поддерживающей сборки, возможно, изменяя интерфейсы этих типов (удаляя ненужные элементы, добавляя новые расширения и т. д.), чтобы лучше удовлетворить потребности ваших собственных пользователей. Таким образом, поддерживающие типы сборки скрыты от просмотра и поэтому не требуют явной ссылки со стороны ваших пользовательских сборок.
ИМХО, стоит принять к сведению, что ваш пользователь уже ссылается на множество других сборок, от которых зависит ваша сборка, то есть, если ничего другого, то, по крайней мере, различные сборки .NET. Конечно, многие из них необходимы для работы любого кода .NET, поэтому в пользовательских проектах уже есть эти ссылки, но они по-прежнему представляют собой дополнительные ссылки на сборки. Другие сборки .NET не по умолчанию могут потребоваться или не потребоваться, в зависимости от того, что еще ваша собственная сборка использует и возвращает в код пользователя. Тем не менее, такого рода вещи довольно распространены, и на самом деле не следует тратить значительное количество времени, пытаясь их избежать.
Опять же, дело в том, что поддерживающая сборка в любом случае потребуется во время выполнения. Таким образом, не кажется большой трудностью требовать, чтобы на эту сборку ссылались собственные проекты пользователя. Ссылки на сборки, которые объявляют типы, от которых зависит собственный код, — это как раз то, как работает .NET. Зачем с этим бороться? Что это за насущная проблема, которая могла бы побудить приложить какие-либо реальные усилия, чтобы избежать этой дополнительной ссылки в проектах пользователей?
person
Peter Duniho
schedule
14.04.2016
B(например, безопасным способом), то он на самом деле не нуждается в ссылкеExtLib- person Jcl schedule 13.04.2016B, но это неразумно, если цель состоит в том, чтобы избежать ссылки (ссылки, которые в любом случае есть в основной библиотеке). - person Jcl schedule 13.04.2016