회사 내부의 프로젝트간에 공유하려는 사내 라이브러리가 많이 있습니다. 다음은 몇 가지 요구 사항입니다.
- 라이브러리 소스는 최종 프로젝트와 분리 된 저장소에 저장됩니다.
- 최종 프로젝트에는 NuGet을 통한 라이브러리가 포함됩니다.
- 최종 프로젝트에서 작업하는 동안 주어진 라이브러리에 대한 소스 코드를 쉽게 검사 할 수 있어야합니다.
비공개 NuGet 리포지토리 설정은 문제가되지 않지만 소스 관리는 문제가됩니다. 소스 서버를 통해 소스를 공개하려고 시도했지만 다소 효과가 있습니다 .VS 는 외부 코드를 디버깅하는 동안 소스를 다운로드하지만 정의 / 구현을 탐색하려고 할 때는 소스를 다운로드하지 않습니다. 기본적으로 디버깅 할 때만 소스 코드로 이동할 수 있습니다.
따라서 질문은 다음과 같습니다.
- 동일한 리포지토리 / 솔루션에 코드를 만들 필요없이 내부 라이브러리의 소스 코드에 액세스 할 수있는 방법
- VS가 디버깅뿐만 아니라 탐색에 기호를 사용하도록 Symbol 서버 / NuGet 피드 콤보를 설정하는 방법이 있습니까?
ReSharper / 기타 애드 인 사용은 옵션입니다.
2
내부 프로젝트 관리에 최적이 아닌 Nuget 사용이 발견되었습니다. 결국 프로젝트 및 DLL 참조를 위해이를 제거했습니다. 이 일을 할 수 있었던 누군가의 의견을 듣고 싶습니다.
—
Robert Harvey
NuGet 패키지에 포함 된 dll에 해당하는 pdb 파일에 대한 심볼 서버도 설정 했습니까?
—
RubberDuck
우리는 현재 직장에서 똑같은 설정을 가지고 있습니다. NuGet 서버 ( PDB가 없는 DLL 포함 )와 기호 서버 (DLL, PDB 및 소스 포함). 또한 동일한 문제가 있습니다 (소스 및 PDB는 디버깅 할 때만 검색). @RobertHarvey : NuGet 패키지 관리자는 NuGet 클라이언트가 좋지 않습니다. 직접 및 일시적 종속성을 구분하지 않으며 어리석은 "통합"조치가 필요합니다. 우리는 Paket으로 전환했으며 그 이후로 되돌아 보지 않았습니다. 패키지 관리를 깔끔하고 견딜 수있게 만들었습니다.
—
Allon Guralnek
나는 이것이 불합리한 요구 사항이라고 생각하지 않지만 왜 공유 / 공통 패키지를 볼 수 있어야합니까? 원칙적으로 적어도 이것들은 블랙 박스에 문서화되어야하며 표준보다는 예외를 들여다 볼 필요가 있습니다. 어쨌든 소스 리포지토리에서 사용할 수 있으므로 검사 할 솔루션을 다운로드하는 것이 용납 될 수 있습니다. 나는 이것 또는 이것의 일부가 전적으로 그렇지는 않지만 여전히 가치가있는 이유를 알 수 있습니다.
—
Murph
@ 머프-나는 OP가 아니지만 내 경험에 따르면 문서가 내가 원하는 세부 사항을 포착하지 못합니다. 이 상태를 정리해야합니까, 아니면 수신자가합니까? 이 탈출은 정확히 무엇입니까? 이 과부하는 어떻게 다릅니 까? 이러한 실체가 평등을 지원합니까? 그렇다면 무엇을 기반으로합니까? 이 통화의 대략적인 복잡성은 무엇입니까? 유일한 설명 문서의 가치를 가진이 있기 때문에 항상하고 일반적으로 문서 기록기는 고려하지 않을 일이 될 것하지만은 (청소) 소스 입니다 당신에게 중요합니다. 더 나쁘고 복잡한 문서는 필연적으로 오류를 포함하고 부실합니다.
—
Eamon Nerbonne