Side-by-Side 어셈블리에 대한 DLL 작성

사용자 고유의 side-by-side 어셈블리를 만들 때는 다음 지침에 따라 Side-by-side 어셈블리 만들기 지침을 따르고 어셈블리에서 사용되는 모든 DLL을 작성합니다.

  • 여러 버전이 서로 방해하지 않고 동시에 동일한 프로세스에서 실행될 수 있도록 DLL을 디자인해야 합니다. 예를 들어 많은 애플리케이션은 각각 다른 버전의 구성 요소가 필요한 여러 플러그 인을 호스트합니다. 개발자는 동일한 프로세스에서 동시에 실행될 때 여러 버전의 구성 요소가 제대로 작동하는지 확인하기 위해 side-by-side 어셈블리를 디자인하고 테스트해야 합니다.

  • Windows XP 이전의 시스템에서 구성 요소를 공유 구성 요소로 제공하려는 경우 이러한 시스템에 구성 요소를 단일 인스턴스 공유 구성 요소로 계속 설치해야 합니다. 이 경우 구성 요소가 이전 버전과 호환되는지 확인해야 합니다.

  • 시스템에서 어셈블리 버전이 두 개 이상 실행되면 개체 사용을 평가합니다. 서로 다른 버전의 어셈블리에 메모리 매핑된 파일, 명명된 파이프, 등록된 Windows 메시지 및 클래스, 공유 메모리, 세마포, 뮤텍스 및 하드웨어 드라이버와 같은 별도의 데이터 구조가 필요한지 여부를 확인합니다. 어셈블리 버전에서 사용되는 모든 데이터 구조는 이전 버전과 호환되어야 합니다. 버전 간에 사용할 수 있는 데이터 구조와 버전에 대해 프라이빗이어야 하는 데이터 구조를 결정합니다. 공유 데이터 구조에 세마포 및 뮤텍스와 같은 별도의 동기화 개체가 필요한지 여부를 확인합니다.

  • 창 클래스 및 Atoms와 같은 일부 개체는 각 프로세스에 대해 고유하게 이름이 지정됩니다. 창 클래스와 같은 개체는 매니페스트를 사용하여 각 어셈블리에 대해 버전이 정해져야 합니다. Atoms와 같은 개체의 경우 버전 간에 공유하려는 경우가 아니면 버전별 식별자를 사용합니다. 버전별 식별자를 사용하는 경우 네 부분으로 구성된 버전 번호를 사용합니다.

  • DLL에 자체 등록 코드를 포함하지 않습니다. side-by-side 어셈블리의 DLL은 자체 등록할 수 없습니다.

  • define 문을 사용하여 DLL의 모든 버전별 이름을 # 정의합니다. 이렇게 하면 모든 레지스트리 키를 한 위치에서 변경할 수 있습니다. 새 버전의 어셈블리를 릴리스하는 경우 이 define 문만 변경하면 # 됩니다. 예를 들면 다음과 같습니다.

    #define MyRegistryKey "MyAssembly1.0.0.0"

  • 비영구 데이터를 Temp 디렉터리에 저장합니다.

  • 사용자 데이터를 전역 위치에 배치하지 마십시오. 애플리케이션 데이터를 사용자 데이터와 별도로 유지합니다.

  • 모든 공유 파일에 애플리케이션의 이름에 따라 달라지는 파일 버전을 할당합니다.

  • 프로세스 간에 사용되는 모든 메시지 및 데이터 구조를 버전에 할당하여 의도하지 않은 프로세스 간 공유를 방지합니다.

  • DLL은 다른 버전의 어셈블리에서 공유되지 않는 공유 메모리 섹션과 같이 존재하지 않을 수 있는 버전 간에 공유에 의존해서는 안 됩니다.

  • 원래 DLL의 이진 인터페이스 호환성 계약을 따르지 않는 새 기능을 추가하는 경우 새 CLSID, ProgId 및 파일 이름을 할당해야 합니다. 그런 다음 이 CLSID, ProgId 및 파일 이름을 사용하려면 이후 버전의 side-by-side 어셈블리가 필요합니다. 이렇게 하면 나란히 있지 않은 DLL 버전이 side-by-side 버전을 통해 등록될 때 충돌을 방지할 수 있습니다.

  • 동일한 CLSID 또는 ProgId를 다시 사용할 경우 어셈블리가 이전 버전과 호환되는지 테스트합니다.

  • 어셈블리 코드에서 어셈블리의 기본 설정을 초기화하고 설정합니다. 레지스트리에 기본값 설정을 저장하지 마십시오.

  • 모든 데이터 구조에 버전을 할당합니다.

  • DLL은 Side-by-Side 어셈블리에 대한 Authoring State Storage 설명한 대로 side-by-side 어셈블리의 상태를저장해야 합니다.