다양한 SharePoint 패키지를 통해 공통 어셈블리의 고유 버전을 배포 하시겠습니까?

Question

하나의 SharePoint 인스턴스에서 사용하는 동일한 GAC에 배포되는 두 개의 SharePoint 패키지 (훨씬 이상)가 공유/사용하는 Common.dll이 있습니다. 공유 어셈블리는 제품 배포에서 제품 배포로 발전하며 자체 제품으로 취급되지 않습니다. 그것은 공개되지 않습니다. 이는 다른 SharePoint 제품/패키지의 컨텍스트에서만 전개됩니다.

공통 어셈블리는 주로 재사용 가능한 코드의 저장소입니다. 그것은 내부 개발자 팀에 의해서만 사용됩니다.

분기/병합은 개발자에 맞는마다 다양한 제품이 Common.dll의 최신 버전에 걸릴 수 있습니다. 각 제품의 개발 노력으로 새 버전의 Common.dll을 사용할 위험이 있습니다.

저의 어셈블리는 SharePoint 패키지에서 SharePoint 패키지까지 제품에서 제품으로 분리되어 작동해야합니다.

하지만 그런 일은 일어나지 않습니다. 대신, 배포 할 때마다 Common.dll이 GAC에서 덮어 써서 모든 제품에서 가장 최근 버전의 Common.dll의 동작을 수신합니다. 해당 동작이 무엇인지에 따라 얼마 동안 배포되지 않은 제품이 손상 될 수 있습니다.

나는 그 배치를 "놀람!" 잠재적 인 승/O를주의 깊게 변경 사항을 깨는 것을 피하기 위해 공공 제품처럼 Common.dll을 치료해야만하는 등. 하나의 셰어 인스턴스의 GAC에 다양한 셰어 패키지를 배포 할 때

어떤 기술을 사용하면 일반적인 어셈블리의 서로 다른 버전을 유지하기 위해 사용합니까?

Answer 1

우리는 일반적인 어셈블리의 비주얼 스튜디오 프로젝트의 빌드 전 이벤트에서이 명령을 사용 :이 사전 빌드 명령은 일반적인 어셈블리가 다양한 제품이 소비됩니다으로 변경하지 않는

if not "$(SolutionName)" == "ABC" if not "$(TargetFileName)" == "$(ProjectName).$(SolutionName).dll" exit 1 

. 당신이 일반적인 조립의 솔루션 파일의 이름으로 "ABC"를 교체 할 때, 그것은 다음과 같이 읽습니다

우리가 자체 솔루션의 일반적인 어셈블리를 컴파일하는 경우 (드물지만 발생) , 거기에 아무 것도 고려해야 - 멀리 컴파일! 그렇지 않으면 누군가가 에 소모품의 Visual Studio 솔루션 파일 이름별로 공용 어셈블리의 이름을 바꾸지 않는 한 빌드를 실패합니다.

빌드 실패를 방지하기 위해 공용 어셈블리 프로젝트의 속성 페이지를 통해 소비 제품의 코드베이스로 분기 한 후에 공용 어셈블리의 이름을 바꿉니다. 공용 어셈블리의 프로젝트 은 이 아니며 솔루션 탐색기에서이 아니거나 속성 페이지에서 기본 네임 스페이스가 변경되지 않았습니다. "어셈블리 이름"만 변경됩니다. 따라서 제품 별 변경 사항을 제외하고는 공통 코드를 유지 관리하고 사용하는 것이 항상 익숙합니다. 솔루션 탐색기와 네임 스페이스는 개발중인 제품에 관계없이 동일하게 유지됩니다.

이름 바꾸기는 공용 어셈블리의 프로젝트 파일에서 한 줄을 변경합니다. 트렁크에 을 다시 병합 할 때 트렁크에 다시 병합 할 때 마찰이 발생합니다.이 다른 제품에 병합됩니다.여전히 ProductA에 대한 어셈블리를 명명하는 동안 일반적인 프로젝트 파일 ProductB의 코드베이스에 길을 만드는 경우

그 빌드 전 명령이 개발자가 쉽게 "어셈블리 이름"을 변경할 수 있습니다 ProductB에서 컴파일을 방지 할 수 있습니다 컴파일을 허용합니다. 이 마찰 기회는 합병할수록 더 커집니다.

공용 어셈블리는 새 SharePoint 제품이 GAC에 도착할 때마다 GAC에서 고유 한 이름 (및 인스턴스)을 가져옵니다. 다양한 제품은 배포 할 때 갑자기 다른 제품/패키지를 깨뜨릴 염려가 없으면 공통 어셈블리를 사용, 개발 및 배포 할 수 있습니다.

Answer 2

버전 관리 및 binding redirects이 여기에서 도움이 될 수 있습니다. 근본적인 문제는 Visual Studio에서 강력한 이름의 일관된 토큰 화가 부족한 것 같습니다. 소스 제어와 관련된 정교한 해결 방법을 만드는 것보다 주어진 프로젝트 파일에서 모든 공통 어셈블리 참조를 업데이트 할 수있는 간단한 도구를 만드는 것이 더 좋습니다. 이것은 다른 불필요한 비용을 발생시키지 않고 근본 문제를 해결합니다.