Как выполнить отладку в моем пакете 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, который, я думаю, нужен только для символьных серверов.
9 ответов
Надежное легкое решение
- Поместите pdb в пакет NuGet вместе с dll.
- Добавьте исходный код в исходные файлы отладки для решения, которое ссылается на пакет.
Это означает, что вы сможете просматривать код и просматривать исключения, но вам, возможно, придется найти файл на диске и открыть его, прежде чем вы сможете установить точку останова. Очевидно, вы должны быть осторожны, чтобы источник был в правильной редакции.
Подробнее на шаге 1
Если в настоящее время вы упаковываете без Nuspec, вам нужно создать Nuspec, а затем добавить pdb в список файлов в папке lib. "NuGet spec" может быть полезной командой для генерации начальной спецификации, как определено в 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>
Для этого метода еще рано, и, возможно, есть несколько предостережений по его использованию, чтобы узнать больше, ознакомьтесь с нижней частью этого комментария и соответствующей дискуссией.
Последняя версия dotPeek (бесплатная!) Может выступать в роли сервера символов и генерировать файлы pdb на лету. Это позволило мне отладить в dll, которые обслуживаются через teamcity.
Загрузите это здесь:
http://blog.jetbrains.com/dotnet/2014/04/09/introducing-dotpeek-1-2-early-access-program/
Инструкции по настройке здесь.
Конечно, вы можете установить и настроить свой собственный сервер символов, но, вероятно, проще всего...
- скачать и установить Inedo's ProGet
- включить подачу символов на целевой канал
- публиковать пакеты из TeamCity в канал ProGet
- используйте ProGet в качестве основного источника каналов (так как он может объединять несколько каналов, включая nuget.org)
Все это можно сделать с помощью бесплатной версии ProGet.
В вашем .nuspec (прямо под <package>):
<files>
<file src="bin\$configuration$\$id$.pdb" target="lib\net451\" />
</files>
(менять net451 на платформу, для которой вы компилируете)
Если у вас есть исходный код для пакета, то надежный (но, возможно, трудоемкий) метод:
- Добавьте исходный код пакета в свое решение (щелкните правой кнопкой мыши Solution -> Add Existing Project)
- Просмотрите все свои проекты в решении и удалите ссылку NuGet на библиотеку (т. Е. Откройте папку "Ссылки" в каждом проекте и удалите ссылку на пакет.) Затем добавьте ссылку на проект пакета NuGet в свое решение. (т.е. щелкните правой кнопкой мыши на References, добавьте Reference, выберите Projects и установите флажок для проекта)
Я должен был сделать это таким образом, когда метод, который я хотел отладить внутри пакета NuGet, был вызван фреймворком, а не моим кодом, поэтому я не мог войти в него. (В моем случае этот метод был ASP.NET DelegatingHandler).
Как только вы закончите, вы захотите отменить все ваши изменения через систему контроля версий, чтобы на пакет NuGet ссылались правильно.
Я нашел супер простой способ сделать это, о котором я написал здесь:
https://mattfrear.com/2017/11/29/speed-up-development-in-a-nuget-package-centric-solution/
Это работает, только если вы используете новый.NET Core стиль.csproj с <PackageReference> (в.NET Core или.NET Framework).
Это снова предполагает, что у вас есть доступ к исходному коду пакета NuGet.
- Соберите и скомпилируйте пакет NuGet на вашем локальном компьютере.
- Скопируйте.dll, которую вы только что скомпилировали, в локальную папку фида пакетов NuGet (на моем компьютере это
C:\Users\matt\.nuget\packages\), перезаписывая существующий пакет NuGet.dll.
Это оно! Вы должны быть в состоянии войти в пакет во время отладки. Не возиться с.pd bs или исходными серверами. Это значительно ускорило мой цикл разработки.
Это то, что я нашел для работы, но все шаги, вероятно, не требуются...
Примечание: это не позволяет вам отлаживать оба, только пакет 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(их может быть несколько, это не принесет вреда всем)
Поскольку этот вопрос был первоначально опубликован, Jetbrains написали целый пост в блоге о том, как этого добиться. Шаги можно суммировать как:
- Установите средства отладки для Windows на агентах.
- Установите и активируйте плагин SymbolServer.
- Добавьте функцию сборки индексатора файлов символов в свои конфигурации сборки.
- Убедитесь, что файлы PDB выводятся как артефакт.
- Настройте Visual Studio для использования TeamCity в качестве исходного сервера.
Если вы используете шаги сборки пакета Nuget, вы можете выбрать "Включить символы и источник" для вывода .symbol.nupkg который содержит PDB. В зависимости от того, достаточно ли умен Индексатор файлов символов, чтобы заглянуть внутрь этого файла или нет, вам может потребоваться изменить расширение файла, чтобы все работало.
Полная информация приведена здесь: https://blog.jetbrains.com/teamcity/2015/02/setting-up-teamcity-as-symbol-and-source-server/
Если ваш код находится в общедоступном Git-репозитории или, по крайней мере, в вашей сети, доступен без аутентификации, то GitLink будет вариант:
https://github.com/GitTools/GitLink
GitLink делает серверы символов устаревшими, изменяя PDB так, чтобы он указывал на сервер Git. Но, как уже было сказано, это делает общедоступным репозиторий Git - до сих пор не существует "правильного" способа аутентификации при доступе к частному репозиторию.
Теперь Microsoft интегрировала пакет SourceLink NuGet по адресу https://github.com/dotnet/sourcelink/, который позволяет загружать исходный код по запросу во время отладки, если издатель пакета NuGet настроил его.