맨위로가기

사이드 바이 사이드 어셈블리

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

사이드 바이 사이드 어셈블리(SxS)는 윈도우에서 여러 애플리케이션이 동일한 DLL의 다른 버전을 공유하거나 사용할 수 있도록 하는 기술이다. 응용 프로그램은 매니페스트를 사용하여 필요한 DLL 버전을 지정하며, 매니페스트는 실행 파일에 포함되거나 외부 파일로 존재할 수 있다. SxS는 공유 어셈블리와 개인 어셈블리를 지원하며, 공유 어셈블리는 WinSxS 폴더에 설치되고 디지털 서명과 Windows Installer를 사용하며, 개인 어셈블리는 애플리케이션과 함께 배포되어 설치가 필요 없다. SxS는 애플리케이션 간의 DLL 충돌을 방지하고, 개발자가 종속성을 쉽게 확인할 수 있게 하지만, 윈도우 XP에서 버그로 인한 문제와, winsxs 디렉터리의 디스크 공간 사용량 증가와 같은 단점도 존재한다.

더 읽어볼만한 페이지

  • 코드 예시에 관한 문서 - 순서도
    순서도는 컴퓨터 알고리즘이나 프로세스를 시각적으로 표현하는 도구로, 흐름 공정 차트에서 기원하여 컴퓨터 프로그래밍 분야에서 알고리즘을 설명하는 데 사용되며, 다양한 종류와 소프트웨어 도구가 존재한다.
  • 코드 예시에 관한 문서 - 람다 대수
    람다 대수는 알론조 처치가 수학기초론 연구를 위해 도입한 형식 체계로, 초기 체계의 모순 수정 후 유형 없는 람다 대수와 단순 유형 람다 대수가 발표되었으며, 프로그래밍 언어와의 관계가 명확해지면서 컴퓨터 과학과 언어학에서 중요한 위치를 차지하며 함수형 프로그래밍 언어의 기반이 되었고, 튜링 완전성을 가지는 등 다양한 분야에 응용된다.
  • 윈도우 관리 - 블루스크린
    블루스크린은 윈도우 운영체제에서 발생하는 치명적인 오류로, 컴퓨터 작동을 멈추고 파란색 화면에 오류 메시지를 표시하며, 하드웨어 또는 소프트웨어 문제로 인해 발생하고, 시스템 복원, 안전 모드 부팅 등의 방법으로 대처한다.
  • 윈도우 관리 - 파워셸
    파워셸은 마이크로소프트에서 개발한 작업 자동화 솔루션으로, 명령줄 셸과 스크립트 언어의 기능을 결합하여 윈도우 시스템 관리를 위해 설계되었으며, .NET 프레임워크 기반의 객체 지향적 특징을 갖고 다양한 플랫폼에서 자동화 스크립트 작성 및 실행, 시스템 구성 관리 등에 활용된다.
사이드 바이 사이드 어셈블리
개요
이름Side-by-side 어셈블리
설명윈도우 XP 이상에서 실행 파일에 사용되는 표준 형식임.
응용 프로그램 및 DLL이 동일 시스템에서 충돌 없이 여러 버전의 동일한 DLL을 사용할 수 있도록 하는 기술임.
역사
도입 시기윈도우 XP
목적DLL Hell 문제 해결
기술적 세부 사항
핵심 원리응용 프로그램과 DLL을 "어셈블리"라는 단위로 묶어 관리함.
각 어셈블리는 자체 버전 정보를 포함하고, 특정 폴더에 저장됨.
윈도우는 응용 프로그램 실행 시 필요한 어셈블리를 해당 폴더에서 찾아 로드함.
구성 요소어셈블리 매니페스트: 어셈블리에 대한 메타데이터 (이름, 버전, 종속성 등)를 포함하는 XML 파일.
어셈블리 DLL: 실제 코드를 포함하는 DLL 파일.
구성 파일: 어셈블리의 동작을 제어하는 XML 파일 (선택 사항).
매니페스트 파일응용 프로그램 매니페스트: 실행 파일과 함께 배포되며, 응용 프로그램이 필요로 하는 어셈블리 목록을 포함함.
어셈블리 매니페스트: 어셈블리에 대한 정보를 포함함.
장점DLL Hell 문제 해결: 여러 버전의 DLL이 충돌하는 문제를 방지함.
응용 프로그램 격리: 응용 프로그램이 시스템에 미치는 영향을 최소화함.
더 나은 배포 및 설치: 응용 프로그램과 필요한 DLL을 함께 배포하여 설치 과정을 단순화함.
단점디스크 공간 소비 증가: 여러 버전의 DLL을 저장해야 하므로 디스크 공간 사용량이 증가할 수 있음.
복잡성 증가: 어셈블리 관리 및 배포 과정이 복잡해질 수 있음.
활용 예시
예시닷넷 프레임워크: 여러 버전의 닷넷 프레임워크를 동시에 설치하여 사용할 수 있도록 함.
Visual C++ 런타임 라이브러리: 여러 버전의 Visual C++ 런타임 라이브러리를 동시에 설치하여 사용할 수 있도록 함.
관련 용어
관련 용어어셈블리(Assembly)
DLL Hell
매니페스트(Manifest)

2. 작동 원리

SxS를 사용하는 응용 프로그램에는 매니페스트(manifest)가 있어야 한다. 매니페스트는 일반적으로 응용 프로그램의 실행 파일에 포함된 섹션이지만 외부 파일일 수도 있다. 운영 체제가 응용 프로그램을 로드하고 매니페스트가 있는지 감지하면, 운영 체제 DLL 로더는 매니페스트에 나열된 DLL 버전을 로드하도록 지시받는다. 매니페스트가 없으면 DLL 로더는 모든 DLL 종속성의 기본 버전을 로드한다. DLL이 COM 서버인 경우, 등록 없는 활성화를 성공시키려면 자체 매니페스트가 있어야 한다.

'''매니페스트'''는 분리 애플리케이션과 사이드 바이 사이드 어셈블리 모두 자신을 설명하는 XML 파일이며, 확장자는 `.manifest`이다. 분리 애플리케이션이 사용하는 것을 '''애플리케이션 매니페스트''', 사이드 바이 사이드 어셈블리가 사용하는 것을 '''어셈블리 매니페스트'''라고 부른다.

매니페스트는 "실행 파일명.manifest"라는 이름으로 실행 파일과 같은 폴더에 두거나, 빌드 시에 리소스로서 실행 파일에 포함시켜 기능하게 할 수 있다[31].

Microsoft Docs(구 MSDN 라이브러리)의 "Windows XP 비주얼 스타일 사용"[21]에 기재된 애플리케이션 매니페스트의 예는 다음과 같다.








version="1.0.0.0"

processorArchitecture="X86"

name="CompanyName.ProductName.YourApp"

type="win32"

/>

애플리케이션의 설명






type="win32"

name="Microsoft.Windows.Common-Controls"

version="6.0.0.0"

processorArchitecture="X86"

publicKeyToken="6595b64144ccf1df"

language="*"

/>









위 예시에서 `assemblyIdentity` 요소와 `description` 요소는 분리 애플리케이션 자체의 정보를 기술한다. `dependentAssembly` 요소는 이 애플리케이션이 참조하는 사이드 바이 사이드 어셈블리의 정보를 기재하며, 각 `assemblyIdentity` 요소가 하나의 어셈블리에 해당한다. 애플리케이션 매니페스트는 일반적으로 분리 애플리케이션 실행 시 읽히지만, 액티베이션 컨텍스트 API를 사용하여 더 세밀하게 제어할 수도 있다.

분리 애플리케이션과 사이드 바이 사이드 어셈블리 관련 항목 외에도, 애플리케이션 매니페스트에는 다음과 같은 항목도 포함될 수 있다.


  • 사용자 계정 컨트롤(UAC) 관련 설정 (Windows Vista부터)[28]
  • 고 DPI 대응 선언 (Windows Vista부터)[29]
  • Windows에 대한 호환성 표명 (Windows 7부터)[30] (Windows 7부터 탑재된 기능이지만, Windows Vista 호환성 선언 항목도 있음)


윈도우 비스타 이상에서는 ''sxstrace.exe'' 유틸리티를 사용하여 SxS 구성 오류로 인한 응용 프로그램 시작 실패를 진단할 수 있다. 사용자가 매니페스트에 지정된 어셈블리를 재정의하려는 경우(예: 라이브러리에 보안 패치가 적용된 경우), 게시자 구성 파일을 사용하여 어셈블리를 전역적으로 리디렉션할 수 있다. 디지털 서명은 이러한 리디렉션의 합법성을 보장하는 데 사용될 수 있다.

3. 매니페스트 포맷

애플리케이션 매니페스트는 내부적으로 XML로 표현된다. 사이드 바이 사이드 어셈블리(SxS) 매니페스트와 관련된 URN은 "urn:schemas-microsoft-com:asm.v1"이다. 클릭원스(ClickOnce)와 같은 일부 최신 마이크로소프트 기술들도 동일한 매니페스트 형식을 사용한다.

SxS를 사용하는 애플리케이션은 매니페스트 파일을 필요로 한다. 이 파일은 일반적으로 애플리케이션 실행 파일 내부에 포함된 섹션 형태이거나 외부 파일일 수도 있다. 운영체제가 애플리케이션을 로드할 때 매니페스트를 감지하면, 운영체제의 DLL 로더는 매니페스트에 명시된 DLL 버전을 사용하도록 지시받는다. 만약 매니페스트가 없다면, DLL 로더는 모든 DLL 의존성에 대해 기본 버전을 로드하게 된다. COM 서버 역할을 하는 DLL의 경우, 등록 없이 활성화되려면 자체 매니페스트가 반드시 필요하다.

윈도우 비스타 및 이후 버전에서는 sxstrace.exe 도구를 사용하여 SxS 구성 오류로 인한 애플리케이션 시작 실패 문제를 진단할 수 있다.

사용자가 매니페스트에 지정된 어셈블리를 재정의해야 하는 경우(예를 들어, 라이브러리에 보안 패치가 적용되었을 때), 게시자 구성 파일을 사용하여 어셈블리를 전역적으로 리디렉션할 수 있다. 디지털 서명은 이러한 리디렉션 과정의 합법성을 보장하는 데 사용될 수 있다.

3. 1. 예시 매니페스트























Microsoft Docs(구 MSDN 라이브러리)의 "Windows XP 비주얼 스타일 사용"[21] 문서에 기재된 애플리케이션 매니페스트의 예는 다음과 같다.








version="1.0.0.0"

processorArchitecture="X86"

name="CompanyName.ProductName.YourApp"

type="win32"

/>

애플리케이션의 설명






type="win32"

name="Microsoft.Windows.Common-Controls"

version="6.0.0.0"

processorArchitecture="X86"

publicKeyToken="6595b64144ccf1df"

language="*"

/>









위 예시에서 `assemblyIdentity` 요소와 `description` 요소는 분리 애플리케이션 자체의 정보를 기술한다. `dependentAssembly` 요소는 해당 애플리케이션이 참조하는 사이드 바이 사이드 어셈블리의 정보를 기재하며, `assemblyIdentity` 요소 하나가 어셈블리 하나에 대응한다.

애플리케이션 매니페스트는 일반적으로 분리 애플리케이션 실행 시 읽히지만, 액티베이션 컨텍스트 API를 사용하여 더 세밀하게 제어할 수도 있다.

또한, 분리 애플리케이션과 사이드 바이 사이드 어셈블리 관련 항목 외에도 애플리케이션 매니페스트에는 다음과 같은 항목이 포함될 수 있다.

  • 사용자 계정 컨트롤 관련 정보 (Windows Vista부터)[28]
  • 고 DPI 대응 선언 (Windows Vista부터)[29]
  • Windows에 대한 호환성 표명 (Windows 7부터)[30] (Windows 7부터 탑재된 기능이지만, Windows Vista 호환성 선언 항목도 존재한다.)


매니페스트는 "실행 파일명.manifest"라는 이름으로 실행 파일과 같은 폴더에 두거나, 빌드 시 리소스로서 실행 파일에 포함시켜 적용할 수 있다.[31]

3. 2. 활성화 컨텍스트

SxS 로더는 매니페스트를 활성화 컨텍스트로 구문 분석한다. 각 스레드 또는 파이버에는 활성화 컨텍스트 스택이 있다. API를 통해 이러한 컨텍스트를 프로그래밍 방식으로 조작할 수 있다. 라이브러리(DLL)가 자체적으로 호출자의 활성화 컨텍스트를 사용하는 대신 다른 라이브러리의 특정 버전을 필요로 하는 경우와 같이 활성화 컨텍스트를 변경해야 할 수 있다. 이러한 유형의 문제를 때때로 (활성화 컨텍스트) 오염이라고 한다.[4] 활성화 컨텍스트를 오염시키는 것을 방지하기 위해 DLL은 리소스로 내장된 매니페스트를 가질 수 있으며, DLL이 로드될 때 구문 분석된다. 로더가 찾을 수 있도록 이 매니페스트는 이미지 파일의 리소스 ID 2에 있어야 한다.[5]

4. WinSxS (윈도우 컴포넌트 스토어)

비스타 이후 버전의 윈도우 운영 체제는 핵심 구성 요소를 관리하기 위해 WinSxS(Windows Side-by-Side), 즉 '윈도우 컴포넌트 스토어'를 사용한다. `'winsxs'` 디렉터리에 저장된 운영 체제 파일들은 실제 사용되는 위치(예: `'System32'` 디렉터리나 응용 프로그램 디렉터리)에서 하드 링크 방식으로 연결된다. 이 때문에 파일 탐색기와 같은 도구는 종종 이러한 파일들이 차지하는 디스크 공간을 실제보다 크게, 즉 이중으로 계산하여 보여주기도 한다.[36][6] 이는 `fsutil` 명령 줄 유틸리티를 사용하거나[37][7] 파일의 링크 수를 표시해주는 일부 서드파티 탐색기 확장 기능을 통해 확인할 수 있다.

그러나 `'winsxs'` 디렉터리의 모든 파일이 항상 시스템에서 활발하게 사용되는 것은 아니다. 예를 들어, 윈도우 업데이트를 설치하면 이전 버전의 파일들은 실제 시스템 폴더와의 연결은 끊어지지만, `'winsxs'` 디렉터리 내에는 그대로 보존된다. 이는 사용자가 필요할 경우 해당 업데이트를 안전하게 제거하고 이전 상태로 되돌릴 수 있도록 하기 위함이다.[38][8]

WinSxS 디렉터리는 시스템 운영에 매우 중요한 파일들을 담고 있기 때문에, 비스타 이후부터는 'TrustedInstaller'라는 특별한 시스템 서비스 계정(SID)이 소유권을 가진다. 이로 인해 기본적으로 관리자 권한을 가진 사용자라도 해당 디렉터리의 내용을 임의로 수정하거나 삭제할 수 없다(소유권을 먼저 획득하지 않는 한).[9] 또한, 응용 프로그램을 제거해도 관련된 파일들이 `'winsxs'` 디렉터리에서 즉시 삭제되지 않으며, 더 이상 사용되지 않는 어셈블리(파일 묶음)들은 시스템의 'Installer' 서비스에 의해 시간이 지나면서 점진적으로 정리(가비지 컬렉션)되어 공간을 확보하게 된다.[9]

`'winsxs'` 디렉터리 내의 하위 디렉터리 이름이 생성되는 방식은 공식적으로 문서화되어 있지는 않지만, MSDN의 마이크로소프트 직원 블로그를 통해 그 알고리즘이 공개된 바 있다. 이 이름 생성 방식은 윈도우 XP에서 비스타로 넘어가면서 변경되었다.[10]

윈도우 버전이 올라가면서 WinSxS 디렉터리를 관리하고 디스크 공간을 효율적으로 사용하기 위한 여러 도구와 기능들이 도입되었다. 예를 들어 윈도우 7에서는 배포 이미지 서비스 및 관리(DISM) 도구를 통해 사용하지 않는 업데이트 파일을 제거할 수 있게 되었고,[11] 이후 버전에서는 디스크 정리 도구나[12] 자동 정리 기능[15] 등이 추가되었다. 이러한 기능들에 대한 자세한 내용은 디스크 공간 관리 섹션에서 다룬다.

4. 1. 구성 파일

사이드 바이 사이드(SxS) 기술을 사용하는 응용 프로그램은 매니페스트 파일을 필요로 한다. 이 매니페스트는 일반적으로 응용 프로그램의 실행 파일 내부에 포함된 섹션 형태이지만, 별도의 외부 파일로 존재할 수도 있다. 운영 체제가 응용 프로그램을 로드할 때 매니페스트의 존재를 감지하면, 운영 체제의 DLL 로더는 매니페스트에 명시된 특정 버전의 DLL을 사용하도록 지시받는다. 만약 매니페스트가 없다면, DLL 로더는 모든 DLL 의존성에 대해 기본 버전을 로드하게 된다. COM 서버 역할을 하는 DLL의 경우, 레지스트리 등록 없이 활성화되려면 자체적인 매니페스트를 가지고 있어야 한다.

사용자가 매니페스트에 지정된 어셈블리를 재정의해야 하는 상황(예를 들어, 라이브러리에 보안 패치가 적용된 경우)이 발생하면, 게시자 구성 파일을 사용하여 어셈블리 사용을 전역적으로 다른 버전으로 리디렉션할 수 있다. 이러한 리디렉션 과정의 정당성은 디지털 서명을 통해 보장될 수 있다. 게시자 구성 파일은 어셈블리가 배포된 이후에도 사용 중인 어셈블리를 변경할 수 있는 메커니즘을 제공한다.

예를 들어, 특정 어셈블리에서 보안 문제가 발견되었을 경우, 게시자(Publisher)가 제공하는 구성 파일을 WinSxS 폴더에 설치하면, 기존에 특정 버전의 개인 어셈블리를 사용하도록 설정된 응용 프로그램이라도 해당 보안 패치가 적용된 새로운 버전의 공유 어셈블리가 시스템에 존재한다면 이를 우선적으로 사용하도록 강제할 수 있다.

윈도우 비스타 및 그 이후 버전의 윈도우에서는 `sxstrace.exe` 유틸리티를 사용하여 SxS 구성 오류로 인해 응용 프로그램 시작이 실패하는 문제를 진단할 수 있다.

4. 2. 디스크 공간 관리

비스타 이후 윈도우 운영 체제는 핵심 구성 요소를 관리하기 위해 WinSxS(Windows 구성 요소 저장소)라는 특별한 디렉터리를 사용한다. `'winsxs'` 디렉터리에 있는 운영 체제 파일들은 실제로 사용되는 위치, 예를 들어 `'System32'` 디렉터리 같은 곳에서 하드 링크 방식으로 연결되어 있다. 이러한 구조 때문에 파일 탐색기와 같은 일반적인 파일 관리 도구는 `'winsxs'` 디렉터리의 크기를 실제 사용량보다 훨씬 크게 표시하는 경우가 많다. 이는 하드 링크로 연결된 동일한 파일을 여러 위치에서 각각 계산하여 중복으로 합산하기 때문이다.[36][6][19] 파일 시스템 유틸리티인 `fsutil` 명령 줄 프로그램[37][7]이나 파일의 링크 수를 보여주는 일부 서드파티 탐색기 확장 기능을 사용하면 실제 디스크 점유 공간을 좀 더 정확하게 확인할 수 있다.

`'winsxs'` 디렉터리에 있는 모든 파일이 항상 시스템에서 활발하게 사용되는 것은 아니다. 예를 들어, 윈도우 업데이트를 통해 새로운 버전의 파일이 설치되면, 이전 버전의 파일들은 시스템 폴더와의 연결(하드 링크)은 끊어지지만 `'winsxs'` 디렉터리 내에는 한동안 보존된다. 이는 사용자가 원할 경우 해당 업데이트를 안전하게 제거하고 이전 상태로 되돌릴 수 있도록 지원하기 위함이다.[38][8]

`'winsxs'` 디렉터리는 시스템 운영에 필수적인 파일들을 포함하고 있어 매우 중요하게 다뤄진다. 비스타 이후부터 이 디렉터리의 소유권은 'TrustedInstaller'라는 특수한 시스템 서비스 계정에 있으며, 기본적으로 관리자 권한을 가진 사용자라 할지라도 임의로 내용을 수정하거나 삭제할 수 없다.[9] 응용 프로그램을 제거하더라도 관련 파일들이 `'winsxs'` 디렉터리에서 즉시 사라지지는 않는다. 더 이상 사용되지 않는 파일(어셈블리)들은 시스템의 'Installer' 서비스에 의해 시간이 지남에 따라 자동으로 정리되는 과정(가비지 컬렉션)을 거쳐 공간을 확보하게 된다.[9]

디스크 공간을 효율적으로 관리하기 위해 윈도우 버전별로 다음과 같은 기능들이 도입되었다.

  • 윈도우 7: Windows AIK에 포함된 배포 이미지 서비스 및 관리(DISM) 도구를 통해, 시스템 재부팅 없이도 더 이상 필요 없는 오래된 업데이트 파일들을 제거할 수 있게 되었다.[11] 서비스 팩 1(SP1) 이후에는 디스크 정리 도구(`'cleanmgr.exe'`)[12]와 시스템 업데이트 준비 도구(CheckSUR)[13]에 윈도우 업데이트 정리 기능이 추가되었다. 이 도구들은 구성 요소 저장소의 오류를 찾아 복구하거나, 손상되거나 누락된 시스템 파일을 정상적인 파일로 대체하는 역할도 수행한다.
  • 윈도우 8: DISM 도구의 기능이 더욱 향상되어, 윈도우 업데이트 서버나 오프라인 WIM 이미지 파일로부터 직접 필요한 파일을 가져와 시스템을 복구하는 기능이 추가되었다. 또한, 구성 요소 저장소를 정리하여 최신 버전의 구성 요소 파일만 남도록 재설정하는 기능도 제공한다.[14]
  • 윈도우 8.1: DISM 도구에 구성 요소 저장소의 실제 크기를 분석하여 보고하는 기능이 추가되어, 사용자가 디스크 공간 사용 현황을 더 정확히 파악할 수 있게 되었다.[20]
  • 윈도우 10: 운영 체제가 자동으로 구성 요소 저장소를 정리하는 작업을 주기적으로 실행하여 디스크 공간을 효율적으로 관리한다.[15]


결론적으로 `'winsxs'` 디렉터리는 많은 파일과 여러 버전의 파일을 포함하고 있어 겉보기에는 디스크 공간을 많이 차지하는 것처럼 보일 수 있지만, 하드 링크 기술을 통해 실제 사용되는 파일들과 연결되어 관리되므로 파일 탐색기 등에서 보이는 크기가 실제 디스크 점유 공간을 정확히 반영하는 것은 아니다.[17][18]

5. 분리 애플리케이션

분리 애플리케이션은 애플리케이션 매니페스트에 자신이 사용하는 컴포넌트(사이드 바이 사이드 어셈블리)를 기술한 애플리케이션이다. 분리 애플리케이션 실행 시, Win32 시스템은 애플리케이션 매니페스트를 보고 읽어들여야 할 어셈블리 (DLL/EXE)의 버전을 결정한다. 어셈블리는 자신 전용의 프라이빗 어셈블리 또는 여러 버전이 공존하는 공유 어셈블리로 존재하기 때문에, 다른 애플리케이션에 의한 어셈블리의 추가, 삭제, 업데이트 등의 영향을 받지 않는다.

6. Side-by-Side 어셈블리

Side-by-Side 어셈블리란 DLL, 윈도우 클래스, COM 서버, 타입 라이브러리, COM 인터페이스 등의 집합을 매니페스트에 기재한 것이다.

어셈블리는 자신을 식별하기 위해 다음과 같은 정보를 가지며[25], 이 정보들을 통해 구별된다.

정보 종류설명
종류win32 등 어셈블리의 유형
이름어셈블리의 고유한 이름
언어어셈블리가 지원하는 언어
프로세서 아키텍처어셈블리가 호환되는 프로세서 구조 (예: x86, amd64)
버전어셈블리의 버전 정보 (예: 1.0.0.0)
공개 키 토큰어셈블리의 고유성을 보장하는 공개 키의 해시값



이 중에서 최소한 종류, 이름, 버전 정보는 필수적으로 포함되어야 한다.

어셈블리는 사용 범위에 따라 공유 어셈블리와 개인 어셈블리(프라이빗 어셈블리)로 나뉜다.

6. 1. 공유 어셈블리

공유 어셈블리는 다양한 애플리케이션에서 사용되는 어셈블리로, WinSxS 폴더에 설치된다. 설치에는 디지털 서명과 Windows Installer의 사용이 요구된다.[26] 예를 들어, 같은 이름의 파일이라도 다른 어셈블리에 속해 있다면, 다른 하위 디렉토리에 저장되며 덮어쓰기되지 않는다.

6. 2. 프라이빗 어셈블리

프라이빗 어셈블리는 공유되지 않고 특정 애플리케이션에서만 개별적으로 사용하는 어셈블리이다. 공유 어셈블리와는 다르게 별도의 설치 과정이 필요 없다. 애플리케이션 실행 파일이 있는 디렉터리 또는 그 하위 디렉터리에 배치된다. 이러한 특징 때문에 공유 어셈블리를 사용하지 않는 애플리케이션의 경우, 설치 관리자를 통하지 않고 간단한 파일 복사만으로도 배포하고 사용할 수 있다는 장점이 있다.

일반적으로 COM 구성 요소는 사용하기 전에 Windows 시스템 레지스트리에 미리 등록해야 하며, 이 등록 과정에는 관리자 권한이 필요하다. 하지만 SxS 프라이빗 어셈블리 메커니즘을 활용하면, 이러한 레지스트리 등록 절차 없이도 COM 구성 요소를 만들고 사용할 수 있다.

7. 장점


  • 사이드 바이 사이드(SxS) 방식으로 빌드된 애플리케이션은 동일한 DLL의 서로 다른 버전을 필요로 하는 여러 프로그램이 충돌 없이 공존할 수 있게 한다. 이는 과거 공유 시스템 폴더에 있는 특정 버전의 DLL 파일이 다른 프로그램을 설치할 때 덮어씌워져 기존 프로그램이 오작동하는 문제(이른바 'DLL Hell')를 해결하는 중요한 장점이다.
  • 애플리케이션의 종속성 정보를 담고 있는 매니페스트 파일이 XML 형식으로 작성되어 사람이 읽고 이해하기 쉽다. 덕분에 개발자는 애플리케이션이 어떤 라이브러리의 어떤 버전에 의존하는지 쉽게 파악하고 관리할 수 있다.

8. 단점


  • 윈도우 XP에서는 'sxs.dll' 파일의 버그로 인해 힙 손상이 발생하여 응용 프로그램이 갑자기 종료되는 문제가 있다. 이 문제는 윈도우 XP 서비스 팩으로 해결되지 않으므로, 사용자가 직접 관련 업데이트를 설치해야 한다.[16]
  • 'winsxs' 폴더 안의 파일 대부분은 실제로는 다른 위치에 있는 파일들을 가리키는 하드 링크이지만, 파일 탐색기 등에서는 각 링크를 별도의 파일로 계산하기 때문에 디스크 용량이 실제보다 많이 사용되는 것처럼 보일 수 있다.[36]
  • 보안 업데이트가 계속 설치되면서 중요한 시스템 파일의 여러 버전이 'winsxs' 폴더에 누적되기 때문에, 'winsxs' 폴더와 윈도우 업데이트 로그 파일의 크기가 점점 커지면서 손상될 위험이 있다. 특히 윈도우 비스타에서는 'winsxs' 폴더의 크기를 안전하게 줄일 수 있는 공식적인 방법이 없다.[8]

9. 사용 예시

참조

[1] 문서 Visual C++ Libraries https://msdn.microso[...] Breaking Changes in Visual C++ 2010-09-10
[2] 문서 Differences between Visual C++ 2008 and Visual C++ 2010 https://msdn.microso[...] Deployment in Visual C++ 2010 2010-09-10
[3] 문서 Publisher Configuration (Windows) https://msdn.microso[...]
[4] 웹사이트 Fixing Activation Context Pollution https://docs.microso[...] Microsoft 2006-01-07
[5] 웹사이트 DLLs and resource ID 2 manifests https://docs.microso[...] Microsoft 2006-01-17
[6] 웹사이트 KB 2592038: How to Alleviate Disk Space Pressure Caused By a Large Windows Component Store (WinSxS) Directory http://support.micro[...]
[7] 웹사이트 Should you delete files in the \WinSXS directory? And what's the deal with VSS? https://docs.microso[...] 2010-08-06
[8] 웹사이트 What is the WINSXS directory in Windows 2008 and Windows Vista and why is it so large? https://docs.microso[...] Microsoft Corporation 2011-03-15
[9] 웹사이트 Deleting from the WinSxS Directory https://docs.microso[...] Microsoft 2007-01-02
[10] 웹사이트 What's that Awful Directory Name Under Windows\WinSxS? https://docs.microso[...] Microsoft 2005-12-28
[11] 문서 Microsoft TechNet: What Is Deployment Image Servicing and Management? https://technet.micr[...]
[12] 웹사이트 Breaking News! Reduce the size of the WinSxS Directory and Free up Disk Space with a New Update for Windows 7 SP1 Clients https://techcommunit[...] Microsoft 2013-10-08
[13] 문서 Microsoft TechNet: Advanced guidelines for diagnosing and fixing servicing corruption https://technet.micr[...]
[14] 웹사이트 DISM – Repair a Windows Image https://technet.micr[...] Microsoft
[15] 웹사이트 Clean Up the WinSxS Folder https://docs.microso[...] 2017-05-02
[16] 웹사이트 KB 943232: An application that uses the Sxs.dll file crashes when you run the application on a Windows XP-based computer http://support.micro[...]
[17] 웹사이트 Manage the Component Store https://technet.micr[...] Microsoft
[18] 웹사이트 How hard links work https://docs.microso[...] 2011-01-06
[19] 웹사이트 Disk Space https://docs.microso[...] Microsoft 2008-11-19
[20] 웹사이트 Determine the Actual Size of the WinSxS Folder https://technet.micr[...] Microsoft
[21] 웹사이트 Windows XP ビジュアル スタイルの使用 https://docs.microso[...] マイクロソフト 2022-01-06
[22] 문서 DLL Hellを解消する新しいWindowsインストーラとアセンブリ(7/7) - @IT https://atmarkit.itm[...]
[23] 웹사이트 C/C++ 分離アプリケーションおよび side-by-side アセンブリのビルド http://msdn.microsof[...] マイクロソフト 2008-11-08
[24] 문서 Concepts of Isolated Applications and Side-by-side Assemblies | Microsoft Docs https://docs.microso[...]
[25] 웹사이트 Assembly Manifests http://msdn.microsof[...] マイクロソフト 2008-11-08
[26] 웹사이트 Installing Side-by-side Assemblies as Shared Assemblies http://msdn.microsof[...] マイクロソフト 2008-11-08
[27] 문서 Creating Registration-Free COM Objects - Win32 apps | Microsoft Docs https://docs.microso[...]
[28] 웹사이트 Step 6: Create and Embed an Application Manifest (UAC) http://msdn.microsof[...] マイクロソフト 2008-11-08
[29] 웹사이트 高 DPI 対応の Win32 アプリケーションを記述する http://msdn.microsof[...] マイクロソフト 2010-12-29
[30] 웹사이트 Application Manifest - Win32 apps https://docs.microso[...] マイクロソフト 2022-01-06
[31] 웹사이트 Using Side-by-Side Assemblies as a Resource http://msdn.microsof[...] マイクロソフト 2008-11-08
[32] 문서 アプリケーションで共有する Side-by-Side コンポーネントの実装 (拡張) | Microsoft Docs https://docs.microso[...]
[33] 문서 DLL Hellを解消する新しいWindowsインストーラとアセンブリ(5/7) - @IT https://atmarkit.itm[...]
[34] 문서 Visual C++ Libraries https://msdn.microso[...] Breaking Changes in Visual C++ 2010-09-10
[35] 문서 Differences between Visual C++ 2008 and Visual C++ 2010 https://msdn.microso[...] Deployment in Visual C++ 2010 2010-09-10
[36] 웹인용 KB 2592038: How to Alleviate Disk Space Pressure Caused By a Large Windows Component Store (WinSxS) Directory http://support.micro[...]
[37] 웹인용 Should you delete files in the \WinSXS directory? And what’s the deal with VSS? https://web.archive.[...] 2019-03-03
[38] 웹인용 What is the WINSXS directory in Windows 2008 and Windows Vista and why is it so large? http://blogs.technet[...] Microsoft Corporation 2011-03-15



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com