GAC 설치를 다시 방문하십시오

Question

이 중 하나가 돌아가지만 나는 만족스러운 응답을 찾을 수 없습니다.

조립품을 GAC에 넣어야합니까? 이 질문들 : when-and-when-not-to-install-into-the-gac 및 What are the advantages and disadvantages of using the GAC은 정확하게 주소를 지정하지만 대답은 "~을 권장합니다 ..."또는 "~해야만합니다 ..."입니다. 왜???

.Net의 스타가 시작될 때 GAC naysaying 블로그의 상당수는 5/6 년 전과 같이 보입니다. 우리는 여전히 지금 거기에 있습니까? 확실하게 DLL-Hell은 GAC가 서로 다른 버전의 "동일한"어셈블리를 나란히 설치할 수있게 해주는 과거의 일입니다.

내 관심사를 강조하겠습니다. 우리는 점점 더 많은 웹 애플리케이션 제품군을 보유하고 있습니다 (지금까지 5 개). 이들은 API 호출 및 데이터베이스 확장을 통해 제 3 자 응용 프로그램을 핵심으로 확장합니다. 따라서 모든 앱은 공통된 많은 코드를 공유하며, 우리는 품질, 유지 보수성 등을 향상시키기 위해 새로운 핵심 공유 라이브러리 세트를 개발하고 있습니다.

확실히이 공유 기능을 한 번 설치하고 공유하고 싶습니다. 유지 보수 악몽을 여는 것에 대한 모든 주장은 가난한 징계의 일부 세계를 기반으로합니다. ABI를 깨면 AssemblyVersion을 부딪 치면 기존 앱을 계속 작동시킬 수 있습니다.

참으로 GAC는 의심의 여지가없는 꿀 함정입니까? 나는 순진한가? 게으른 징징 대는 것으로 'XCopy'설치의 손실을 언급하면서 논쟁을 기각 할 때 나는 불필요하게 가혹한가? 아니면 조금 "종교적"이되어 가고있는 것일뿐입니다.

빛을 볼 수 있도록 도와 주셔서 감사합니다.

단

Answer 1

저는 개인적으로 GAC에 직접 어셈블리를 설치 한 적이 없습니다 (순수한 학술적 연구는 제외). 몇 가지 응용 프로그램에서 액세스되는 중앙 위치에서 어셈블리를 사용하는 것에 대한 논쟁을 전에 들었습니다. 그리고 그것은 다소 매력적인 것으로 보이지만, 개인적으로는 내 시간 가치가 없습니다. 요즘 컴퓨터는 320GB의 하드 디스크 공간이 있습니다 ... 내 평범한 160K 조립품은 5 번 복사 되더라도 그 안에 함몰을 만들지 않을 것입니다. (물론, 어떤 사람들은 "커먼즈 문제"에 대해 논쟁 할 수 있습니다. "모든 개발자가 그런 식으로 생각한다면 ....", 그러나 나는 빗나간 다.) 내가 이것을 선택하지 않는 주된 이유는 하나의 특정 응용 프로그램이 한 방법으로 어셈블리에 의존 할 수 있고 또 다른 특정 응용 프로그램이 다른 방법으로 어셈블리에 의존 할 수 있기 때문입니다. 이상적인 세계에서이 어셈블리에 대한 업데이트는이 어셈블리에 의존하는 응용 프로그램에 영향을주지 않아야합니다. 실제로는 종종 그렇습니다. 특정 응용 프로그램에 문제가있어 어셈블리 문제를 해결할 경우 해당 어셈블리에 의존하는 다른 응용 프로그램에 무의식적으로 영향을줍니다. 다른 한편으로, 이런 상황이 우리를 더 나은 프로그래머로 만들고 GAC-Shared 어셈블리를 더욱 강력하게 만든다고 주장 할 수도 있습니다. 훌륭합니다.하지만 프로그래머로서의 일은 주로 더 나은 프로그래머가되도록하는 것이 아니라, 작동하는 프로그램을 작성하는 것입니다. 그렇게함으로써 나는 더 나은 프로그래머가 될 것입니다.

내 투표는 무엇입니까? GAC에 가까이 가지 마십시오. 각 응용 프로그램은 의존 할 수 있도록 제작 된 어셈블리 버전을 사용합니다.한 응용 프로그램에서 해당 어셈블리에 노출 된 버그는 어셈블리를 다르게 사용하기 때문에 절대로 다른 응용 프로그램에 나타나지 않을 수 있습니다. 따라서 공유 DLL이 패치 될 때마다 회귀 테스트를 수행 할 필요가 없습니다. .

Answer 2

다음과 같은 약한 전략을 사용합니다.
다른 프로그램에서 공유 어셈블리 + 버전 관리를 사용하는 경우 GAC을 사용하십시오.
항상 GAC을 사용하지 마십시오.

의견을 환영합니다.