현재, 공식 빌드 용 Nuget을 사용하여 릴리스 빌드를 nuget.org로 패키징하지만 기호 소스 푸시를 위해 Nuget을 사용하여 디버그 빌드를 symbolsource.org로 패키징합니다.
편집 : (Jon Skeet, Noda Time 개발의 편견)
NuGet은 이제 문서화 된대로 NuGet 갤러리 및 symbolsource.org (또는 유사한 서버)에 대한 푸시를 지원합니다 . 불행히도 여기에는 두 가지 모순되는 요구 사항이 있습니다.
- 단지 때 사용하는 디버깅을위한 필요없이 도서관을, 당신은 정말 릴리스 빌드를 원한다. 그것이 릴리스 빌드의 목적입니다.
- 진단 목적으로 라이브러리로 디버깅 할 때 모든 적절한 최적화가 비활성화 된 디버그 빌드를 원합니다. 이것이 바로 디버그 빌드의 목적입니다.
괜찮겠지 만 NuGet은 릴리스 및 디버그 빌드가 동일한 패키지에 유용한 방식으로 게시되도록 허용하지 않습니다.
따라서 선택 사항은 다음과 같습니다.
- 모든 사람에게 디버그 빌드를 배포하고 (문서의 예에 표시된대로) 모든 크기 및 성능 적중률을 유지합니다.
- 릴리스 빌드를 모든 사람에게 배포하고 약간 손상된 디버그 환경을 유지합니다.
- 정말 복잡한 배포 정책을 따르십시오. 잠재적으로 별도의 릴리스 및 디버그 패키지를 제공합니다.
처음 두 가지는 디버그와 릴리스 빌드 간의 차이의 영향으로 요약됩니다 … 일부 동작을 확인하고 싶어하기 때문에 라이브러리 코드에 들어가기를 원하는 것과 원하는 것 사이에 큰 차이가 있다는 점도 주목할 가치가 있습니다. 버그를 발견했다고 믿기 때문에 라이브러리의 코드를 디버깅합니다. 두 번째 경우에는 라이브러리 코드를 Visual Studio 솔루션으로 가져 와서 그런 방식으로 디버그하는 것이 더 낫기 때문에 그 상황에 너무 많은주의를 기울이지 않습니다.
내 유혹은 릴리스 빌드를 유지하는 것입니다. 상대적으로 적은 수의 사용자가 디버그해야하고, 그렇게하는 사용자는 릴리스 빌드의 최적화에 크게 영향을받지 않을 것이라는 기대를 가지고 있습니다 . (JIT 컴파일러는 어쨌든 대부분의 최적화를 수행합니다.)
그래서 우리가 고려하지 않은 다른 옵션이 있습니까? 균형을 맞추는 다른 고려 사항이 있습니까? NuGet 패키지를 SymbolSource에 푸시하여 “모범 사례”가 실제로 확립되지 않았습니까?
답변
SymbolSource에 대해 말하면 모범 사례는 다음과 같습니다.
- 릴리스 바이너리 + 콘텐츠 패키지를 nuget.org에만 (또는 기타 프로덕션 피드) 푸시
- 디버그 바이너리 + 콘텐츠 패키지를 개발 피드로 푸시합니다.
- 전제에
- myget.org에서
- nuget.org에서 시험판 패키지로.
- 릴리스 및 디버그 바이너리 + 심볼 패키지를 symbolsource.org 또는 다른 기호 저장소로 푸시합니다.
.NET의 릴리스 및 디버그 빌드가 실제로 많이 다르다는 것은 일반적인 오해이지만 Debug와 같이 두 빌드에 포함되거나 포함되지 않을 수있는 다양한 코드로 인해 차이점이 여기에 있다고 가정합니다. .Asserts.
즉, 프로덕션 코드를 디버깅해야 할 때를 알 수 없기 때문에 두 구성을 모두 SymbolSource에 푸시 할 가치가 있습니다. 더 어렵게 만들기 위해 프로덕션에서 원격으로. 그럴 때 툴링에서 얻을 수있는 도움이 필요할 것입니다. 나는 분명히 누구에게도 바라지 않습니다.
버전 관리와 관련하여 여전히 고려해야 할 사항이 있습니다. 2 개의 서로 다른 패키지 (디버그 및 릴리스에서 빌드)가 하나의 버전 번호를 공유하는 것이 맞습니까? SymbolSource는 패키지를 추출하고 바이너리를 별도의 빌드 모드 분기에 저장하므로 NuGet 만 그에 따라 패키지에 태그를 지정할 수있는 경우이를 허용합니다. 현재로서는 패키지가 디버그 모드인지 릴리스 모드인지 확인할 방법이 없습니다.
답변
귀하의 결론에 전적으로 동의합니다. 디버그가있는 RELEASE 및 SymbolSource가있는 NuGet 패키지. 패키지로 직접 들어가는 것은 매우 드물고 최적화가 활성화 된 상태에서 가끔 디버그 실수가 허용 될 수 있습니다.
정말 문제가 있었다면 NuGet이 지원하는 것이 이상적인 솔루션이라고 생각합니다. 예를 들어 디버깅 할 때 릴리스 DLL을 SymbolSource 패키지에 포함 된 DLL로 바꿀 수 있다고 상상해보십시오.
이상적으로 nuget pack SomePackage -Symbols는 릴리스 버전에 대해 릴리스 너겟 패키지가 생성되지만 디버그 기호 패키지는 생성됩니다. 그리고 VS 플러그인은 디버거에서 실행할 때 연결을 확인하고 디버그 어셈블리를 가져와 대신로드 할 수있을만큼 스마트하게 업데이트됩니다. 다소 미쳤지 만 흥미로울 것입니다.
하지만 지금 당장은 그럴만 한 가치가 있다고 불평하는 사람들이 많지 않습니다.
NuGet 팀은 풀 요청을 수락합니다. 🙂
답변
OP가 포스트 한 지 8 년이 되었으니 요즘 사용하는 걸로 크랙을 드리겠습니다.
NuGet 패키지 를 ” 스테핑 “하는 방법에는 두 가지가 있습니다 .
1. PDB 배포
.symbols.nupkg심볼 패키지는 레거시 로 간주되며 Symbol Server에.snupkg 게시되는 패키지 로 대체되었습니다 . NuGet.org, Azure DevOps ( 덜 부드럽 지만) 등과 같은 모든 주요 공급 업체에서 지원합니다 .
다음은 공식 지침 입니다. 다음 두 줄을 csproj 파일에 추가하기 만하면됩니다.
<PropertyGroup>
<IncludeSymbols>true</IncludeSymbols>
<SymbolPackageFormat>snupkg</SymbolPackageFormat>
</PropertyGroup>
소비자 측에서는 디버깅 할 때 패키지 코드 를 실행할 수 있도록 IDE가 NuGet.org (또는 Azure 등) 기호 서버에 대해 구성되어 있는지 확인합니다 .
2. 소스 링크. 실제 코드 연결
경우에 따라 PDB는 MSIL / JIT 최적화로 인해 소스 코드의 일부 세부 사항을 숨길 수 있습니다. 따라서 디버깅하는 동안 NuGet의 실제 소스에 ” 단계적 으로” 들어가는 방법이 있습니다. 그것은라고 원본 링크를 닷넷 재단 – ” 소스 바이너리에 대한 경험을 디버깅을 제공하는 language- 및 소스 제어 불가지론 시스템 “.
Visual Studio 15.3 이상 및 모든 주요 공급 업체에서 지원합니다 (개인 리포지토리도 지원).
설정하는 것은 간단합니다 ( 공식 문서 ) – 일부 플래그와 함께 프로젝트 파일에 개발 종속성을 추가합니다 (repo 유형에 따라 다름).
<PropertyGroup>
<PublishRepositoryUrl>true</PublishRepositoryUrl>
<EmbedUntrackedSources>true</EmbedUntrackedSources>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.0.0" PrivateAssets="All" />
</ItemGroup>
” NuGet 패키지를 개선하기위한 5 단계 “에서이 주제에 대해 자세히 알아보십시오 .
답변
심볼 패키지 생성 및 게시 의 예제 는 디버그 디렉토리의 파일을 dll 및 pdb 파일의 소스로 참조합니다.
심볼 패키지 내용 지정
기호 패키지는 규칙에 따라 이전 섹션에서 설명한 방식으로 구조화 된 폴더에서 빌드하거나 파일 섹션을 사용하여 그 내용을 지정할 수 있습니다. 이전에 설명한 예제 패키지를 빌드하려면 다음을 nuspec 파일에 넣을 수 있습니다.
<files>
<file src="Full\bin\Debug\*.dll" target="lib\net40" />
<file src="Full\bin\Debug\*.pdb" target="lib\net40" />
<file src="Silverlight\bin\Debug\*.dll" target="lib\sl40" />
<file src="Silverlight\bin\Debug\*.pdb" target="lib\sl40" />
<file src="**\*.cs" target="src" />
</files>
기호를 게시하는 목적은 디버깅 할 때 다른 사용자가 코드를 단계별로 실행할 수 있도록하는 것이므로 코드 단계별 실행에 영향을 줄 수있는 최적화없이 디버깅 용 코드 버전을 게시하는 것이 가장 현명 해 보입니다.
답변
