Странное поведение NuGet (работает в некоторых файлах .csproj, но не в других) - PullRequest
0 голосов
/ 02 мая 2018

Итак, мы широко используем NuGet, и, прежде чем вы скажете мне, что это безумие, я уже знаю о большинстве идиосинкразий NuGet и по большей части он делает то, что мы хотим с ним. Поэтому, пожалуйста, не говорите «прекратите использовать NuGet в качестве решения»!

Так вот в чем проблема. Мы генерируем две версии каждого пакета NuGet - версию Debug, которая включает в себя файл .pbd, чтобы мы могли отследить в программе во время отладки, и версию Release, в которой нет .pbd, который мы переключаем на ближайшую версию. Так что я просто сделал массовое изменение во всех файлах .csproj с Release back до Debug, и некоторые из моих проектов правильно используют отладочную версию, но некоторые все еще указывают на версию выпуска. Я закрыл проект (и Visual Studio), заново открыл и заново собрал все, а также очистил папки .obj и bin, и все же, когда я смотрю на свойства некоторых пакетов, они все еще указывают на Release. Вы можете видеть на рисунке ниже. Первый (верхний файл) GEARVIEW QC.csproj указывает на Debug как в файлах .csproj, так и в packages.config, и свойства правильно показывают версию Debug, но с другими (в данном случае QCImage) ссылки неверны. Какого черта здесь происходит? Есть идеи?

enter image description here

1 Ответ

0 голосов
/ 04 мая 2018

Странное поведение NuGet (работает в некоторых файлах .csproj, но не в других)

Это действительно очень странное поведение. Я создал два пакета (Debug, Release), но не воспроизвел эту проблему. Чтобы устранить эту проблему, попробуйте выполнить следующие действия:

  • Сначала проверьте, нет ли ошибки сборки или желтого маркера на узле ссылки.
  • Во-вторых, убедитесь, что путь в свойствах указан для ссылки Pacsgear.Debug.DICOMLIB, а не Pacsgear.Release.DICOMLIB.
  • Попробуйте удалить пакет nuget и переустановить его, проверьте, работает ли он для вас.

Надеюсь, это поможет.

...