Управління власними пакетами NuGet з доступом до вихідного коду

У нас є багато власних бібліотек, якими ми хотіли б поділитися між проектами всередині компанії. Ось деякі вимоги:

Бібліотечні джерела зберігаються у сховищах, відокремлених від кінцевих проектів
кінцеві проекти включають бібліотеки через NuGet
Потрібно мати можливість легко перевірити вихідний код для будь-якої бібліотеки під час роботи над кінцевим проектом

Налаштування нашого приватного сховища NuGet не є проблемою, але управління джерелами - це. Ми намагалися розкрити джерела через вихідний сервер, і це начебто працює, але не зовсім так: VS завантажує джерела під час налагодження зовнішнього коду, але не тоді, коли ви намагаєтесь перейти до визначення / реалізації. В основному, ви можете переходити до вихідного коду лише під час налагодження, що не зовсім те, що нам потрібно.

Отже, питання:

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

Використання ReSharper / інших надбудов - це можливість.

c# source-code closed-source nuget

— Диппл
джерело

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

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

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

— RubberDuck

У нас точно така ж настройка на моєму робочому місці. NuGet сервер (містить DLL без PDB) плюс сервер символів (містить DLL, PDB та джерела). У нас також є та сама проблема (джерела та PDB, отримані лише під час налагодження). @RobertHarvey: Менеджер пакетів NuGet - поганий клієнт NuGet. Він не розрізняє прямі та перехідні залежності і вимагає дурних "консолідаційних" дій. Ми перейшли на Paket і відтоді ніколи не озиралися. Це зробило управління пакетами розумним і переносимим, що межує з приємним.

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

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

— Мерф

@Murph - Я не ОП, але в моєму досвіді документація ніколи не фіксує потрібну мені деталь. Чи потрібно мені очищати цей стан, чи буде викликати виклик? Що саме це втеча? Чим відрізняються ці перевантаження? Чи підтримують ці суб'єкти рівності, і якщо так, то на основі чого? Яка приблизна складність цього дзвінка? Єдиною детальною документацією, яку варто мати, є (чисте) джерело, тому що завжди і зазвичай бувають речі, які документатор ніколи не вважав, але це важливо для вас. Гірше, що складна документація неминуче містить помилки і стає несвіжим.

— Еймон Нербонна

Відповіді:

Що має працювати - це просто перевірити вихідний код пакету 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
джерело