.NET 4.0에 새로운 GAC가 있습니다. 왜 그렇습니까?

%windir%\Microsoft.NET\assembly\새로운 GAC 입니다. 이제 두 개의 GAC를 관리해야합니까 (하나는 .NET 2.0-3.5 응용 프로그램 용, 다른 하나는 .NET 4.0 응용 프로그램 용)?

문제는 왜?

예. 2 개의 고유 한 GAC (Global Assembly Cache)가 있으므로 각각 개별적으로 관리해야합니다.

.NET Framework 4.0에서 GAC는 몇 가지 변경을 거쳤습니다. GAC는 각각의 CLR마다 하나씩 2 개로 분할되었다.

.NET Framework 2.0 및 .NET Framework 3.5 모두에 사용되는 CLR 버전은 CLR 2.0입니다. 이전 두 프레임 워크 릴리스에서는 GAC를 분할 할 필요가 없었습니다. Net Framework 4.0에서 이전 응용 프로그램을 손상시키는 문제.

CLR 2.0과 CLR 4.0 사이의 문제를 피하기 위해 GAC는 이제 각 런타임마다 개인 GAC로 분할됩니다. 주요 변경 사항은 이제 CLR v2.0 응용 프로그램이 GAC에서 CLR v4.0 어셈블리를 볼 수 없다는 것입니다.

출처

왜?

NET 4.0에서는 CLR이 변경되었지만 2.0에서 3.5는 변경되지 않았기 때문입니다. 1.1 ~ 2.0 CLR에서도 마찬가지입니다. GAC는 동일한 CLR에서 온다면 다른 버전의 어셈블리를 저장할 수있는 것으로 보입니다. 그들은 오래된 응용 프로그램을 중단하고 싶지 않습니다.

4.0의 GAC 변경 사항에 대해서는 MSDN 의 다음 정보를 참조하십시오 .

예를 들어 .NET 1.1과 .NET 2.0이 모두 동일한 GAC를 공유 한 경우이 공유 GAC에서 어셈블리를로드하는 .NET 1.1 응용 프로그램은 .NET 2.0 어셈블리를 가져 와서 .NET 1.1 응용 프로그램을 손상시킬 수 있습니다.

.NET Framework 2.0 및 .NET Framework 3.5 모두에 사용되는 CLR 버전은 CLR 2.0입니다. 그 결과 이전 두 프레임 워크 릴리스에서 GAC를 분할 할 필요가 없었습니다. CLR 4.0이 릴리스 된 Net Framework 4.0에서는 이전 (이 경우 .NET 2.0) 응용 프로그램을 깨뜨리는 문제가 다시 나타납니다. 따라서 CLR 2.0과 CLR 4.0 간의 간섭 문제를 피하기 위해 GAC는 이제 각 런타임마다 개인 GAC로 분할됩니다.

CLR이 이후 버전에서 업데이트됨에 따라 동일한 내용을 기대할 수 있습니다. 언어 만 변경되면 동일한 GAC를 사용할 수 있습니다.

나는 또한 왜이 GAC를 알고 싶어 다음과 같은 발견 마크 밀러 설명을 에 코멘트 섹션 의 .NET 4.0이이 전역 어셈블리 캐시 (GAC) :

마크 밀러는 말했다 ... 2010 년 6 월 28 일 오후 12:13

게시물 주셔서 감사합니다. "간섭 문제"는 의도적으로 모호했습니다. 글을 쓰는 시점에서 문제는 여전히 조사되고 있었지만 몇 가지 깨진 시나리오가 있음이 분명했습니다.

예를 들어 일부 응용 프로그램은 Assemby.LoadWithPartialName을 사용하여 가장 높은 버전의 어셈블리를로드합니다. 최고 버전이 v4로 컴파일 된 경우 v2 (3.0 또는 3.5) 앱이이를로드 할 수 없으며 작동했던 버전이 있어도 앱이 중단됩니다. 원래 GAC를 원래 위치에 분할했지만 Windows 업그레이드 시나리오에서 일부 문제가 발생했습니다. 이 두 가지 코드는 이미 배송 된 코드와 관련이 있으므로 버전 분할 된 GAC를 다른 곳으로 옮겼습니다.

이는 대부분의 응용 프로그램에 영향을 미치지 않으며 유지 관리 부담을 추가하지 않습니다. 두 위치 모두 기본 GAC API를 사용하여 액세스하거나 수정해야하며, 예상대로 파티션을 처리합니다. 이것이 나타나는 장소는 GetCachePath와 같은 GAC 경로를 노출하거나 관리 코드에로드 된 mscorlib 경로를 검사하는 API를 통해 이루어집니다.

v2를 출시 할 때와 어셈블리 ID의 일부로 아키텍처를 도입 할 때 GAC 위치를 수정했다는 점은 주목할 가치가 있습니다. 모두 여전히 % windir % \ assembly 아래에 있지만 GAC_MSIL, GAC_32 및 GAC_64를 추가했습니다. 안타깝게도이 릴리스에서는 옵션이 아니 었습니다.

미래 독자들에게 도움이 되길 바랍니다.

원래 GAC는 이미 다양한 버전의 어셈블리를 저장할 수있었습니다. 그리고 프로그램이 실수로 잘못된 어셈블리를 참조한다고 가정 할 이유가 거의 없습니다. 모든 .NET 4 어셈블리에는 [AssemblyVersion]이 4.0.0.0까지 올라갔습니다. 새로운 공정 내 병행 기능이이를 변경해서는 안됩니다.

내 생각에 : 이미 "GAC에서 직접 참조하지 않는"규칙을 위반 한 .NET 프로젝트가 너무 많습니다. 이 사이트에서 여러 번 수행 된 것을 보았습니다.

프로젝트를 중단하지 않으려면 GAC를 옮기십시오. 역전은 Microsoft에서 성스러운 것입니다.