TeamCity에서 배포 한 내 nuget 패키지로 디버그하는 방법은 무엇입니까?
팀에서 사용하는 라이브러리를 TeamCity에서 네트워크 폴더로 배포하는 너겟 패키지에 넣었습니다. 그래도이 코드로 디버깅 할 수 없습니다! SymbolSource는 내가 읽은 솔루션 중 하나이지만 Teamcity에서 직접 .pdb / source 파일에 액세스 할 수있는 방법을 찾고 싶습니다. 누구든지 이것을하는 방법을 알고 있습니까?
편집하다. 'Include Symbols and Source'Nuget Pack 빌드 단계를 체크인하면 TeamCity가 네트워크 폴더의 .nupkg 파일 외에 .Symbol.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>
이것은 nuget 패키지에 내 라이브러리의 dll, pdb 및 소스 파일을 추가했으며 기호 서버에만 필요하다고 생각하는 .Symbols 파일을 생성하지 않았습니다.
신뢰할 수있는 경량 솔루션
- dll과 함께 NuGet 패키지에 pdb를 넣습니다.
- 패키지를 참조하는 솔루션의 소스 코드를 디버그 소스 파일에 추가합니다.
즉, 코드를 단계별로 실행하고 예외를 볼 수 있지만 중단 점을 설정하기 전에 디스크에서 파일을 찾아 열어야 할 수 있습니다. 분명히 소스가 올바른 개정판에 있는지주의해야합니다.
1 단계에 대한 자세한 내용
당신이 현재 Nuspec없이 포장하는 경우, 당신은 다음의 lib 폴더에있는 파일 목록에 PDB를 추가합니다 Nuspec을 만들어야합니다 "NuGet 스펙"에 정의 된 초기 사양을 생성하는 유용한 명령 할 수있다 NuGet docs . 그런 다음 Team City Nuget Pack 단계가 새 nuspec을 참조하는지 확인합니다.
2 단계에 대한 자세한 내용
솔루션이 열려 있으면 솔루션을 마우스 오른쪽 단추로 클릭하고 속성 ... 공통 속성 ... 디버그 소스 파일을 선택한 다음 관련 이진 참조에 대한 루트 소스 디렉터리를 추가합니다. 또는 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 파일을 생성 할 수 있습니다. 이를 통해 teamcity를 통해 제공되는 dll을 디버깅 할 수있었습니다.
여기에서 다운로드하십시오:
http://blog.jetbrains.com/dotnet/2014/04/09/introducing-dotpeek-1-2-early-access-program/
여기에서 설정 방법에 대한 지침.
물론 자신의 심볼 서버를 설정하고 구성 할 수 있지만, 아마도 가장 쉬운 방법은 ...
- Inedo의 ProGet 다운로드 및 설치
- 대상 피드에서 기호 제공 활성화
- TeamCity에서 ProGet 피드로 패키지 게시
- ProGet을 기본 피드 소스로 사용 (nuget.org를 포함한 여러 피드를 집계 할 수 있음)
이 모든 작업은 ProGet의 무료 버전으로 수행 할 수 있습니다.
면책 조항-내 일은 Inedo에 있습니다.
내 .nuspec(바로 아래 <package>) :
<files>
<file src="bin\$configuration$\$id$.pdb" target="lib\net451\" />
</files>
( net451컴파일하려는 플랫폼으로 변경 )
이 작업을 수행하는 매우 간단한 방법을 찾았으며 여기에 대해 블로그를 게시했습니다.
https://mattfrear.com/2017/11/29/speed-up-development-in-a-nuget-package-centric-solution/
이는 <PackageReference>.NET Core 또는 .NET Framework 에서 새로운 .NET Core 스타일 .csproj를 사용하는 경우에만 작동합니다 .
여기에서도 NuGet 패키지의 소스 코드에 액세스 할 수 있다고 가정합니다.
- Build and compile the NuGet package on your local machine
- Copy the .dll you've just compiled into your local NuGet packages feed folder (On my machine, this is
C:\Users\matt\.nuget\packages\), overwriting the existing NuGet package .dll.
That's it! You should be able to step into the package while debugging. No messing around with .pdbs or source servers. This has greatly sped up my development cycle.
Since this question was originally posted, Jetbrains have written an entire blog post on how to accomplish this. The steps can be summarised as:
- Install Debugging Tools for Windows on the agents.
- Install & Enable the Symbol Server plugin.
- Add Symbol Files Indexer build feature to your build configurations.
- Ensure PDB files are output as an artefact.
- Configure Visual Studio to use TeamCity as source server.
If you are using Nuget Package build steps, you can check 'Include Symbols and Source' to output a .symbol.nupkg which contains the PDBs. Depending on whether the Symbol Files Indexer is smart enough to look inside this file or not, you may need to change the file extension for things to work.
The full details are given here: https://blog.jetbrains.com/teamcity/2015/02/setting-up-teamcity-as-symbol-and-source-server/
This is what I have found to work, but all the steps are probably not required...
Note: this doesn't allow you to debug both, only either the nuget package or the solution in which it is installed.
- Run Visual Studio as Administrator
- Open and Start the host application (the one in which you installed the Nuget package) without debugging (Ctrl + F5)
- In the Nuget package solution, ensure that
Tools > Options > Debugging > General > "Require source files to exactly match the original version"is NOT checked. - Ensure that
"Enable just my code"is NOT checked - Add a new folder in
Tools > Options > Debugging > Symbolspointing to the source directory of the Nuget package. (You literally enter the folder path , see image below) - Click
Debug > Attach to Process... - Find
iisexpress(there may be multiple, it won't do any harm attaching to all)
If you have the source code for the package, then the foolproof (but possibly laborious) method is:
- Add the source code for the package to your solution (right click Solution -> Add Existing Project)
- Go through all of your projects in the solution and remove the NuGet reference to the library (i.e. open the References folder under each project and delete the reference to the package.) Then, add a reference to the NuGet package project in your solution. (i.e. Right click References, add Reference, choose Projects and tick the box for the project)
I had to do it this way when I the method I wanted to debug inside the NuGet package was called by the framework and not by my code, thus I couldn't step into it. (In my case, the method was an ASP.NET DelegatingHandler).
Once you're done you'll want to undo all your changes via source control so that the NuGet package is referenced correctly.
If your code is in a public Git repository, or, at least in your network, is accessible without authentication, then GitLink would be an option:
https://github.com/GitTools/GitLink
GitLink makes symbol servers obsolete by changing the PDB to point to the Git server. But, as said before, this makes it necessary for the Git repository to be public - until now there's no "proper" way to authenticate when accessing a private repository.
'program story' 카테고리의 다른 글
| GitHub 위키에서 어떤 종류의 목차를 어떻게 만듭니 까? (0) | 2020.11.11 |
|---|---|
| Bootstrap 3에서 기둥을 쌓을 때 수직 공간 (0) | 2020.11.11 |
| NumPy 배열에서 특정 행과 열 선택 (0) | 2020.11.11 |
| PowerShell에서 CMD 명령 실행 (0) | 2020.11.11 |
| 오류 : ggplot2 및 data.table에 대한 패키지 또는 네임 스페이스로드 실패 (0) | 2020.11.11 |
