.NET 4.0에는 새로운 GAC가 있습니다. 이유는 무엇입니까?
%windir%\Microsoft.NET\assembly\새로운 GAC입니다.이제 .NET 2.0-3.5 애플리케이션용 GAC와 .NET 4.0 애플리케이션용 GAC 두 개를 관리해야 합니까?
문제는, 왜?
예. GAC(Global Assembly Cache)가 2개 있기 때문에 각 GAC를 개별적으로 관리해야 합니다.
.NET Framework 4.0에서 GAC는 몇 가지 변경을 거쳤습니다.GAC는 CLR별로 하나씩 두 개로 분할되었습니다.
.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를 사용할 수 있습니다.
또한 2GAC를 사용하는 이유를 알고 싶었으며 .NET 4.0에는 2GAC(Global Assembly Cache)가 포함되어 있습니다.
마크 밀러가 말하길... 2010년 6월 28일 오후 12:13
게시물 감사합니다."간섭 문제"는 의도적으로 모호했습니다.글을 쓸 당시에도 여전히 문제가 조사되고 있었지만, 여러 개의 깨진 시나리오가 있는 것은 분명했습니다.
예를 들어 일부 응용 프로그램은 어셈블리를 사용합니다.LoadWithPartialName은 어셈블리의 가장 높은 버전을 로드합니다.가장 높은 버전이 v4로 컴파일된 경우 v2(3.0 또는 3.5) 앱을 로드할 수 없고 작동하는 버전이 있더라도 앱이 충돌합니다.원래 GAC를 원래 위치로 분할했지만, 이로 인해 Windows 업그레이드 시나리오에 문제가 발생했습니다.이 두 가지 모두 이미 출하된 코드가 포함되어 있었기 때문에 (버전 분할 GAC를) 다른 곳으로 이동했습니다.
이는 대부분의 애플리케이션에 영향을 미치지 않으며 유지 관리 부담을 가중시키지 않습니다.두 위치 모두 예상대로 파티셔닝을 처리하는 네이티브 GAC API를 사용하여 액세스하거나 수정해야 합니다.GetCachePath와 같은 GAC의 경로를 노출하거나 관리되는 코드에 로드된 mscorlib의 경로를 검사하는 API를 통해 이러한 위치가 표시됩니다.
어셈블리 ID의 일부로 아키텍처를 도입할 때도 v2를 릴리스할 때 GAC 위치를 수정했습니다.GAC_MSIL, GAC_32 및 GAC_64가 추가되었지만 모두 %windir%\assembly 미만입니다.안타깝게도 이 릴리스에서는 이 옵션을 선택할 수 없었습니다.
그것이 미래의 독자들에게 도움이 되기를 바랍니다.
말이 되지 않습니다. 원래 GAC는 이미 여러 버전의 어셈블리를 저장할 수 있었습니다.그리고 프로그램이 실수로 잘못된 어셈블리를 참조할 것이라고 가정할 이유가 거의 없습니다. 모든 .NET 4 어셈블리는 [AssemblyVersion]을 4.0.0.0으로 업그레이드했습니다.진행 중인 새로운 기능이 이를 변경해서는 안 됩니다.
제 생각에는 "GAC의 어떤 것도 직접 참조하지 않음" 규칙을 어긴 .NET 프로젝트가 이미 너무 많은 것 같습니다.저는 이 사이트에서 그것을 하는 것을 여러 번 보았습니다.
이러한 프로젝트를 중단하지 않는 유일한 방법은 GAC를 이동하는 것입니다.마이크로소프트에서는 백-호환을 사용할 수 없습니다.
.NET Framework 4.0에서 GAC는 몇 가지 변경을 거쳤습니다.GAC는 CLR별로 하나씩 두 개로 분할되었습니다.
.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 어셈블리를 볼 수 없다는 것입니다.
언급URL : https://stackoverflow.com/questions/2660355/net-4-0-has-a-new-gac-why
'programing' 카테고리의 다른 글
| 부분적으로 깃과 약속을 선택하는 것. (0) | 2023.05.22 |
|---|---|
| Xaml Value 필드에서 사용자 지정 색상 값을 설정하려면 어떻게 해야 합니까? (0) | 2023.05.17 |
| Python 패키지를 설치할 때 "오류: Microsoft Visual C++ 14.0 이상이 필요합니다"를 해결하는 방법은 무엇입니까? (0) | 2023.05.17 |
| 루비의 배열에 값이 있는지 확인하는 방법 (0) | 2023.05.17 |
| jQuery를 사용하여 한 요소를 다른 요소에 상대적으로 배치하는 방법은 무엇입니까? (0) | 2023.05.17 |