Как отлаживать мой пакет nuget, развернутый из TeamCity?
Я поместил библиотеку, которую моя команда использует в пакет nuget, который развертывается из TeamCity в сетевой папке. Однако я не могу отлаживать этот код! SymbolSource - это одно из решений, о котором я читал, но я бы скорее нашел способ получить доступ к файлам .pdb/source непосредственно из Teamcity. Кто-нибудь знает как это сделать?
Изменить. Когда я проверяю 'Include Symbols and Source'
в шаге сборки Nuget Pack, TeamCity создает .Symbol.nupkg в дополнение к файлу .nupkg в сетевой папке. Файл .Symbol.nupkg содержит файл src и .pdb.
Изменить. Я снял флажок 'Include Symbols and Source'
в TeamCity и добавил в свой файл nuspec следующее:
<files>
<file src="..\MyLibrary\bin\release\MyLibrary.dll" target="lib\net40" />
<file src="..\MyLibrary\bin\release\MyLibrary.pdb" target="lib\net40" />
<file src="..\MyLibrary\*.cs" target="src" />
<file src="..\MyLibrary\**\*.cs" target="src" />
</files>
Это добавило dll, pdb и исходные файлы для моей библиотеки в пакете nuget и не создала файл .Symbols, который, как мне кажется, нужен только для серверов символов.
Ответы
Ответ 1
Надежное облегченное решение
- Поместите pdb в пакет NuGet вместе с dll.
- Добавьте исходный код в исходные файлы Debug для решения, которое ссылается на пакет.
Это означает, что вы сможете пройти через код и просмотреть исключения, но вам, возможно, придется найти файл на диске и открыть его, прежде чем вы сможете установить точку останова. Очевидно, что вам нужно быть осторожным, чтобы источник находился в правильной редакции.
Подробнее о шаге 1
Если вы в настоящее время упаковываете без Nuspec, вам нужно создать Nuspec, а затем добавить pdb в список файлов в папке lib "Спецификация NuGet" может быть полезной командой для генерации начальной спецификации как определенном в Документация NuGet. Затем убедитесь, что шаг Team City Nuget Pack ссылается на ваш новый nuspec.
Подробнее о шаге 2
Когда у вас открыто решение, щелкните правой кнопкой мыши Solution, выберите Properties... Common Properties... Debug Source Files и добавьте корневой каталог источника для соответствующей бинарной ссылки. Или посмотрите MSDN.
Обратите внимание: вы не можете открыть свойства решения во время отладки.
В будущем - вставка источника
Из Visual Studio 2017 15.5 preview2 вы можете добавить что-то вроде этого в свой файл проекта:
<PropertyGroup>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<IncludeSymbolsInPackage>true</IncludeSymbolsInPackage>
<DebugSymbols>true</DebugSymbols>
<DebugType>portable</DebugType> <!-- Required for EmbedSources -->
<EmbedSources>true</EmbedSources>
</PropertyGroup>
<ItemGroup>
<!-- Does the equivalent of EmbedSources in MSBuild (hopefully won't be needed long term) -->
<Service Include="{508349b6-6b84-4df5-91f0-309beebad82d}" />
</ItemGroup>
См. нижнюю часть этот комментарий и соответствующее обсуждение, чтобы узнать больше
Ответ 2
Последняя версия dotPeek (бесплатно!) может действовать как сервер символов и генерировать файлы pdb на лету. Это позволило мне отладить в DLL, которые подаются через teamcity.
Загрузите его здесь:
http://blog.jetbrains.com/dotnet/2014/04/09/introducing-dotpeek-1-2-early-access-program/
Инструкции по настройке здесь.
https://web.archive.org/web/20160220163146/http://confluence.jetbrains.com/display/NETCOM/dotPeek+Symbol+Server+and+PDB+Generation
Ответ 3
Вы могли бы, конечно, настроить и настроить свой собственный сервер символов, но это, вероятно, проще всего...
- скачать и установить Inedo ProGet
- включить символ, обслуживающий целевой фид
- публиковать пакеты из TeamCity в фид ProGet
- используйте ProGet в качестве основного источника корма (поскольку он может агрегировать несколько каналов, включая nuget.org).
Все это можно сделать с помощью бесплатной версии ProGet.
отказ от ответственности - моя дневная работа - Inedo
Ответ 4
В вашем .nuspec
(прямо под <package>
):
<files>
<file src="bin\$configuration$\$id$.pdb" target="lib\net451\" />
</files>
(измените net451
на платформу, которую вы компилируете)
Ответ 5
Поскольку этот вопрос был первоначально опубликован, Jetbrains написали целую запись в блоге о том, как это сделать. Этапы можно суммировать как:
- Установите Инструменты отладки для Windows для агентов.
- Установите и включите плагин сервера Symbol.
- Добавить функцию создания индексирования файлов символов в конфигурацию сборки.
- Убедитесь, что файлы PDB выводятся как артефакт.
- Настройка Visual Studio для использования TeamCity в качестве исходного сервера.
Если вы используете шаги сборки Nuget Package, вы можете проверить "Include Symbols and Source", чтобы вывести .symbol.nupkg
, который содержит PDB. В зависимости от того, достаточно ли достаточно индексирования файлов символов для просмотра этого файла или нет, вам может потребоваться изменить расширение файла, чтобы все могло работать.
Подробная информация приведена здесь:
https://blog.jetbrains.com/teamcity/2015/02/setting-up-teamcity-as-symbol-and-source-server/
Ответ 6
Если у вас есть исходный код для пакета, то надежный (но, возможно, кропотливый) метод:
- Добавьте исходный код для пакета в ваше решение (щелкните правой кнопкой мыши Solution → Добавить существующий проект)
- Пройдите все ваши проекты в решении и удалите ссылку NuGet в библиотеку (т.е. откройте папку "Ссылки" в каждом проекте и удалите ссылку на пакет.) Затем добавьте ссылку на проект пакета NuGet в своем решение. (т.е. щелкните правой кнопкой мыши ссылку, добавьте ссылку, выберите "Проекты" и отметьте поле для проекта)
Мне приходилось делать это таким образом, когда метод, который я хотел отлаживать внутри пакета NuGet, вызывался каркасом, а не моим кодом, поэтому я не мог в него входить. (В моем случае этот метод был ASP.NET DelegatingHandler).
Как только вы закончите, вы захотите отменить все свои изменения с помощью элемента управления источника, чтобы правильно установить пакет NuGet.
Ответ 7
Это то, что я нашел для работы, но все шаги, вероятно, не требуются...
Примечание: это не позволяет вам отлаживать оба, только либо nuget пакет или решение, в котором оно установлено.
- Запустить Visual Studio как администратор
- Откройте и запустите приложение-хост (тот, в котором вы установили пакет Nuget) без отладки (Ctrl + F5)
- В решении пакета Nuget убедитесь, что
Tools > Options > Debugging > General > "Require source files to exactly match the original version"
отмечен НЕ.
- Убедитесь, что
"Enable just my code"
отмечен НЕ
- Добавить новую папку в
Tools > Options > Debugging > Symbols
, указывающую на исходный каталог пакета Nuget. (Вы буквально вводите путь к папке, см. Изображение ниже)
- Нажмите
Debug > Attach to Process...
- Найти
iisexpress
(может быть многократное, это не повредит всем)
![Снимок экрана с местоположениями с символами]()
Ответ 8
Я нашел супер простой способ сделать это, о котором я писал здесь:
https://mattfrear.com/2017/11/29/speed-up-development-in-a-nuget-package-centric-solution/
Это работает только в том случае, если вы используете новый .NET Core style.csproj с <PackageReference>
(на .NET Core или .NET Framework).
Это снова предполагает, что у вас есть доступ к исходному коду пакета NuGet.
- Скомпилируйте и скомпилируйте пакет NuGet на вашем локальном компьютере.
- Скопируйте файл .dll, который вы только что скомпилировали, в свою локальную папку локальных пакетов NuGet (на моей машине это
C:\Users\matt\.nuget\packages\
), перезаписав существующий пакет DLL NuGet.
Что это! Во время отладки вы должны войти в пакет. Не вмешиваться в .pdbs или исходные серверы. Это значительно ускорило мой цикл разработки.
Ответ 9
Если ваш код находится в общедоступном репозитории Git или, по крайней мере, в вашей сети, доступен без проверки подлинности, то GitLink будет вариантом:
https://github.com/GitTools/GitLink
GitLink делает серверы символов устаревшими, изменяя PDB, чтобы указать на сервер Git. Но, как было сказано ранее, это делает необходимым, чтобы репозиторий Git был общедоступным - до сих пор нет "правильного" способа аутентификации при доступе к частному репозиторию.