MSBuild & NuGet: распространение свойства проекта на косвенную зависимость - PullRequest
Новая
       25

MSBuild & NuGet: распространение свойства проекта на косвенную зависимость

0 голосов
/ 07 декабря 2018

Введение

У меня есть решение VS2017 с несколькими проектами, все в .NET.Существует проект C # A , приложение .NET с зависимостью B , который является другим проектом Visual C ++, просто оболочкой для собственных библиотек.Они хранятся в пакете NuGet, который B ссылается как на зависимость C .

. Иллюстративно: A → B → C

C содержит 2 DLL (и некоторые другие не относящиеся к делу вещи).Они практически идентичны, только 1 функция реализована по-разному (была причина отделить ее).В некоторых случаях требуется одна из DLL, в некоторых - другая.Они имеют одно и то же имя (неизменяемое), поэтому их нельзя скопировать в выходной каталог.

Для контроля над тем, какая библиотека DLL выбрана, пакет NuGet C содержит некоторую логику вего .targets файл.Он в основном выбирает соответствующую DLL на основе свойства (например, свойство NativeDllType с допустимыми значениями TypeOne и TypeTwo).Это свойство должно быть определено в ссылочном проекте, поэтому оно видно в файле .targets.

Проблема

Я обнаружил, что только B , какпроект, непосредственно ссылающийся на C , может установить это свойство для фактического управления выбором.Если я установлю свойство на A , его область действия не достигнет C , оно просто не будет иметь никакого эффекта.(Я удалил свойство из B в первую очередь, чтобы предотвратить перезапись)

Вопросы

  • Есть ли способ получить егоРабота;передать свойство в пакет NuGet C для управления вводом?
  • Или области остаются строго разделенными, чтобы избежать некоторых проблем, связанных с тем, что свойство имеет большее влияние в других местах?
  • Во втором случае, есть ли другой способ управления вводом в косвенных зависимостях?

Частичное решение (в обход проблемы)

B не требуется C для сборки, только для времени выполнения.Поскольку B является просто оболочкой, проект не является исполняемым, на него всегда будут ссылаться в других местах, таких как A (фактическое приложение, которое будет запущено).Это означает, что C может потребоваться для ссылки не в B , а в A , что делает его прямой зависимостью A . A затем может установить свойство проекта для распространения на C , и оно будет работать просто отлично.Тем не менее, я бы хотел, чтобы ссылки на библиотеки были в их оболочке, если это возможно.

...