공용/유틸리티 라이브러리 작업

Question

제가 일하는 회사에는 우리가 구축한 거의 모든 애플리케이션에서 참조되는 "유틸리티" 프로젝트가 있습니다.NullHelpers, ConfigSettingHelpers, Common ExtensionMethods 등과 같은 많은 것들이 있습니다.

우리가 작업하는 방식은 새 프로젝트를 만들 때 소스 제어에서 프로젝트의 최신 버전을 가져와서 솔루션에 추가한 다음 솔루션에 추가되는 새 프로젝트에서 프로젝트를 참조하는 것입니다.

이것은 괜찮게 작동했습니다. 그러나 사람들이 공통 프로젝트에 "획기적인 변경"을 가한 경우가 두어 번 있었는데, 이는 그들에게는 작동하지만 다른 사람들에게는 작동하지 않습니다.

나는 공통 라이브러리를 프로젝트 참조로 추가하는 대신 독립 실행형 DLL로 공통 라이브러리 개발을 시작하고 다른 버전을 게시하고 특정 프로젝트에 대한 특정 버전을 대상으로 지정하여 위험 없이 변경이 이루어질 수 있도록 해야 한다고 생각했습니다. 공용 라이브러리를 사용하여 다른 프로젝트에.

다른 사람들이 공통 라이브러리를 어떻게 참조하고 사용하는지 알고 싶습니다.

Answer 1

그것이 바로 우리가 하고 있는 일입니다.우리는 프로젝트에 특정한 유용한 기능이 아닌 유틸리티 프로젝트를 가지고 있습니다.버전을 수동으로(마이너) 높이고, 릴리스 버전에서 프로젝트를 빌드하고, 서명한 후 공유 위치에 넣습니다.

그런 다음 사람들은 특정 버전의 도서관.

일부 유용한 메서드가 기본 유틸리티 프로젝트에 포함될 수 있는 일부 특정 프로젝트에 구현된 경우 해당 메서드를 프로젝트의 특수 도우미 클래스에 배치하고 이를 가능한 유틸리티 후보로 표시합니다(간단한 //TODO).프로젝트가 끝나면 후보를 검토하고 후보가 유지되면 메인으로 이동합니다. 도서관.

주요 변경 사항은 절대 허용되지 않으며 필요한 경우 메서드와 클래스를 [사용되지 않음]으로 표시합니다.

하지만 게시할 때마다 버전을 늘리기 때문에 별 문제가 되지 않습니다.

도움이 되었기를 바랍니다.

Answer 2

우리는 소스 제어에서 분기를 사용합니다.모두가 릴리스를 할 때까지 헤드 브랜치를 사용합니다.릴리스를 분기하면 공통 유틸리티 프로젝트도 분기됩니다.

또한 우리 유틸리티 프로젝트에는 자체 단위 테스트가 있습니다.이렇게 하면 다른 팀이 다른 팀의 빌드를 손상시킬 수 있는지 알 수 있습니다.

물론, 당신이 가끔 언급하는 것처럼 여전히 문제가 있습니다.그러나 한 팀이 다른 팀의 빌드를 중단시키는 변경 사항을 체크인하면 일반적으로 해당 메서드/객체에 대한 계약이 어딘가에서 중단되었음을 의미합니다.우리는 이를 공공 유틸리티 프로젝트의 설계를 개선할 수 있는 기회로 봅니다...아니면 적어도 더 많은 단위 테스트를 작성하려면 :/

Answer 3

나는 그것을 가지고 있었다 정확한 같은 문제!

나는 프로젝트 참조를 사용하곤 했지만, 당신이 말했듯이 그것을 참조하는 프로젝트가 많으면 모든 것이 나빠지는 것 같습니다.

이제 DLL로 컴파일하고 첫 번째 빌드 후에 DLL 참조에 대한 CopyLocal 속성을 false로 설정합니다. 그렇지 않으면 하위 프로젝트를 재정의하여 엉망이 될 수 있습니다.

이론적으로는 아마도 GAC가 적용되어야 할 것 같지만, 문제가 많이 변하는 경우(나처럼) 문제가 될 수 있습니다.