Как упаковать и развернуть пакет NuGet с символами и исходным кодом, чтобы отладчик мог использовать ЭТО исходный код?

2

Я создал очень простой пакет NuGet из проекта .NET Framework Visual Library, где исходный код библиотеки классов находится на С#.

Я использовал эту команду для создания пакета nuget:

nuget pack MyProject.csproj -symbols -Properties "Configuration=Debug" -suffix debug

Который создает, как я ожидаю, два файла пакета nuget, а именно:

  • MyProject.1.0.0-debug.symbols.nupkg
  • MyProject.1.0.0-debug.nupkg

Эти пакеты в основном идентичны, за исключением того, что пакет с "символами" включает файлы pdb в иерархии lib и исходные файлы в папке src.

Учитывая дублирование, я переименую файл MyProject.1.0.0-debug.symbols.nupkg в MyProject.1.0.0-debug.symbols.nupkg MyProject.1.0.0-debug.nupkg, который перезаписывает один из файлов, и в этом нет ничего сложного. Теперь у меня есть условно названный пакет с PDB и исходными файлами.

Я развернул это на внутреннем фиде общего ресурса с:

nuget add MyProject.1.0.0-debug.nupkg \\InternalShare\FeedFolder

В совершенно другом проекте и другом решении я теперь использую этот пакет NuGet в Visual Studio с помощью диспетчера пакетов NuGet. Все отлично работает. И код тоже работает отлично, в моем случае я сделал простое консольное приложение, которое использует пару классов в пакете, и я продемонстрировал, что оно использует их правильно и без инцидентов.

Все идет нормально.

Теперь я устанавливаю точку останова в потребляющем коде и пытаюсь войти в исходный код для отладки пакета. Кажется, он работает нормально, но на самом деле он не входит в исходный код, который был распространен вместе с пакетом. Фактически он входит в ОРИГИНАЛЬНЫЙ источник от создания пакета, в совершенно другой и не связанной иерархии папок на моем компьютере.

ХОРОШО. Поэтому теперь я воссоздаю свое простое консольное приложение на отдельном компьютере, который не имеет ОРИГИНАЛЬНОГО источника. И на этом отдельном компьютере, который находится во внутренней сети и, следовательно, имеет доступ к общей папке, я использую пакет NuGet и снова все компилируется и работает нормально.

Однако когда я пытаюсь войти в исходный код пакета в отладчике Visual Studio, он просто не работает. Отладчик не может найти исходный код, даже если он находится прямо в папке пакета. (Отладчик предлагает разобрать код - не очень полезно).

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

Различные варианты вещей:

  • Visual Studio: Профессиональная 2017 15.9.11
  • NuGet Package Manager установлен в VS: 4.6.0
  • Версия CLI NuGet: 4.8.1.5435
  • Целевой .NET Framework для моего примера кода: 4.6.1

В чем моя ошибка?

Спасибо заранее.

================== ДОБАВЛЕННАЯ ИНФОРМАЦИЯ 17.04.2017, 15:30 Pacific Pacific ==================== ===

Это не так плохо, как я думал. Когда я пытаюсь зайти в код и сказать, что он не может его найти, мне предоставляется возможность просмотреть код, чтобы я мог перейти к пакету (при условии, что я знаю, где он находится!) И освободить отладчик и все отлично работает Приятно то, что Visual Studio, похоже, запоминает, где я находился, и знает, где искать в следующий раз. Не уверен в этом механизме.

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

Тем не менее, было бы замечательно не прыгать через такие обручи, поэтому я буду благодарен за любые дальнейшие идеи.

  • 0
    Я не понимаю, почему вы пытаетесь сделать это с помощью пакета Nuget. Не могли бы вы просто клонировать исходный репо в ваш рабочий проект?
  • 0
    Похоже, вам нужна функциональность сервера символов. Если вы не можете опубликовать свои пакеты на внешнем фиде (nuget.org), существуют предпосылки, такие как proget, которые можно бесплатно использовать (на определенный момент). Если вы используете git для управления исходным кодом, ссылка на источник также может помочь
Показать ещё 2 комментария
Теги:
visual-studio
nuget
visual-studio-2017
visual-studio-debugging

2 ответа

1

Некоторые основы:

  • отладчику нужны PDB для включения отладки
  • пакет символов должен содержать PDB (это не просто пакет с другим расширением)
  • этот пакет символов должен быть опубликован в хранилище символов, из которого отладчик Visual Studio может запрашивать символы

Следующий:

  1. Посмотрите этот документ для создания и публикации пакета символов на nuget.org(.snupkg)
  2. Затем посмотрите этот документ для настройки Visual Studio для использования NuGet.org в качестве источника символов (используйте это значение при добавлении сервера символов https://symbols.nuget.org/download/symbols)
  • 0
    Я ценю ответ, но на самом деле он не отвечает на мой вопрос. Пакет, который я публикую (внутри), включает в себя как файлы PDB, так и исходные файлы. И когда этот пакет используется (опять же внутри), если вы переходите вниз по иерархии файлов пакетов на машине-потребителе, вы можете видеть, что там находятся исходный файл и файлы PDB. Nuget используется для упаковки пакета nuget. Кажется, это может? Легко? убедитесь, что файлы PDB в пакете указывают относительно упакованных исходных файлов. Ты говоришь, что этого не происходит? И мне интересно, почему?
  • 0
    Спасибо @karann. Теперь возникает вопрос, почему NuGet, когда он делает упаковку по умолчанию с -Symbols, не помещает эти файлы в правильное место? Есть ли веская причина для такого несоответствия? (Я понимаю, что могу адаптировать файл .nuspec для каждого проекта, но так приятно, что нет необходимости ...) - К вашему сведению, если я не отвечу на дальнейшие комментарии сразу, я буду самоволкой в течение пары дней - обратно в понедельник.
Показать ещё 4 комментария
0

Некоторая информация о пути записана в вашем .nupkg, поэтому проект, который использует пакет, всегда будет искать исходный путь.

Я воспроизвожу вашу проблему, выполнив ваши действия. (Спасибо за ваши подробности, поскольку на самом деле я не знаком с тем, как создавать пакеты nuget раньше).

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

The debugger could not locate the source file 'C:\Users\localmachine\source\repos\LibraryForNuget\LibraryForNuget\TestNuget.cs'.

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

Решение Go (где находится консольное приложение) → Свойства → Отладка исходных файлов, затем добавьте каталог, в котором находится файл xx.cs, в "Каталоги, содержащие исходный код".

Я имею в виду каталог, похожий на C:\remoteMachine\xxx\source\repos\CurrentSolutionDir\packages\LibraryForNuget.1.0.0-debug\src.

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню