Управление собственными пакетами NuGet с доступом к исходному коду

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

исходники библиотеки хранятся в репозиториях, отделенных от конечных проектов
конечные проекты включают библиотеки через NuGet
должна быть возможность легко проверить исходный код любой данной библиотеки во время работы над конечным проектом

Настройка нашего частного репозитория NuGet не проблема, но управление источниками есть. Мы попытались раскрыть источники через исходный сервер, и это вроде работает, но не совсем: VS загружает исходные коды при отладке внешнего кода, но не при попытке перейти к определению / реализации. По сути, вы можете перейти к исходному коду только при отладке, что не совсем то, что нам нужно.

Итак, вопросы:

какие существуют способы предоставления доступа к исходному коду внутренних библиотек без необходимости иметь код в том же репо / решении
Есть ли способ настроить комбо-сервер Symbol Server / NuGet, чтобы VS использовал символы для навигации, а не только для отладки?

Использование ReSharper / других надстроек является опцией.

c# source-code closed-source nuget

— Dyppl
источник

Мы обнаружили, что использование Nuget для управления внутренними проектами неоптимально; в конечном итоге мы разорвали его в пользу ссылок на проект и DLL. Я хотел бы услышать от кого-то, кто смог сделать эту работу.

— Роберт Харви

Вы также настроили сервер символов для файлов pdb, которые соответствуют dll, которые содержатся в ваших пакетах NuGet?

— RubberDuck

У нас точно такая же настройка на моем текущем рабочем месте. Сервер NuGet (содержит библиотеки DLL без PDB) и сервер символов (содержит библиотеки DLL, PDB и источники). У нас также есть та же проблема (источники и PDB извлекаются только при отладке). @RobertHarvey: Менеджер пакетов NuGet - плохой клиент NuGet. Он не различает прямые и временные зависимости и требует глупых «консолидирующих» действий. Мы перешли на Пакет и с тех пор никогда не оглядывались назад. Это сделало управление пакетами вменяемым и терпимым, граничащим с приятным.

— Аллон Гуралнек

Я должен спросить - хотя я не думаю, что это необоснованное требование - почему вы должны иметь возможность просматривать общие / общие пакеты? По крайней мере, по идее, это должны быть документированные черные ящики, и необходимость заглянуть внутрь следует скорее в исключение, чем в норму. В любом случае они доступны в вашем репо-источнике, и поэтому должно быть сносно тривиально загрузить решение для проверки. Я вижу множество причин, по которым это или его части могут быть не совсем правильными, но все же стоит спросить.

— Мерф

@Murph - я не OP, но в моем опыте документация никогда не фиксирует детали, которые я хочу. Нужно ли убирать это состояние или будет вызываемый? Что именно это ускользает? Как эти перегрузки отличаются? Поддерживают ли эти организации равенство, и если да, то на основании чего? Какова примерная сложность этого звонка? Единственная подробная документация стоит иметь это (чистый) источник, потому что всегда и обычно собирается быть вещи Архивариус никогда не считали , но что это важно для вас. Хуже того, сложная документация неизбежно содержит ошибки и становится устаревшей.

— Имон Нербонн

Ответы:

Что должно сработать, так это просто проверить исходный код пакета NuGet и открыть решение в отдельном экземпляре Visual Studio.

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

Основная проблема, с которой вы сталкиваетесь, заключается в том, чтобы проверенный код для зависимого пакета представлял ту же версию, что и ваша ссылка NuGet в основном проекте. Не проблема, если вы следуете политике всегда использовать самую последнюю версию вашего пакета.

Еще одним преимуществом этого подхода является то, что если пакет необходимо изменить, вы можете внести изменения тут же.

— Стюарт Ричи
источник

Можете ли вы предоставить некоторые дополнительные сведения о том, как заставить это работать? Это не работает так, как вы описали для меня. Вам нужно включить PDB в пакет? Какие-нибудь дополнительные уловки?

— Dyppl

-1

Может быть, вы можете использовать https://github.com/GitTools/GitLink . Он добавляет в файл pdb ссылку, указывающую на хранилище, так что Visual Studio будет извлекать исходный код оттуда, а затем вам просто нужно включить файл pdb в ваш пакет nuspec, и ему не понадобится исходный сервер.

— Джеспер Балле
источник

Это работает вне отладки все же? Это не похоже на это.

— Dyppl

-1

Так что это не идеальное решение, но вы упоминаете, что вы можете использовать Resharper; с помощью dotPeek и resharper вы можете перейти к разборке исходного кода, это то, что я использую на работе, где у нас есть настройки, аналогичные вашей.

Я нахожу комбинацию сервера символов, которую вы упомянули, и просмотра разборки обычно достаточно, чтобы выяснить, что происходит.

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

Изменить: Перечитав ваш вопрос, я понимаю, что вы специально просите, чтобы иметь возможность просматривать исходный код, который не является. Тем не менее, надеюсь, это будет кому-то полезно.

— BaronVonDrew
источник