KR20160002888A - 애플리케이션 내의 대역외 프레임워크 라이브러리 - Google Patents

Abstract

향상된 바인더는 로드할 소프트웨어 라이브러리의 버전을 선택하는 경우에 융통성 및 확실성을 제공하고, 향상된 로더는 보안 결함에 취약한 라이브러리 버전이 로드되는 것을 방지한다. 바인더는 통합, 묵시적 오버라이드 및/또는 재지향을 수행할 수 있다. 묵시적 오버라이드는 묵시적 버전을 찾아 어셈블리 특정 위치를 탐색하고, 묵시적 버전이 더 큰 경우에는 이전에 선택된 통합 또는 다른 버전을 묵시적 버전으로써 오버라이드한다. 통합 버전은 프레임워크로써 업데이트되는 반면, 묵시적 버전은 개별 어셈블리로써 업데이트된다. 재지향은 묵시적 버전을 오버라이드할 수 있다. 재지향과 달리, 묵시적 버전은 명시적 범위를 상술하지 않고 애플리케이션 구성 파일의 외부에서 발견된다. 묵시적 버전은 XML 선언 없이 어셈블리에 의해 묵시적으로 지정된다. 알려진 대역외 어셈블리의 리스트, 대역외 서비싱 속성 또는 커스텀 서비싱 라이브러리에 응답하여 배치된 대역외 메타데이터에 기반하여, 취약한 라이브러리는 로드되지 않는다.

Description

애플리케이션 내의 대역외 프레임워크 라이브러리{OUT-OF-BAND FRAMEWORK LIBRARIES WITHIN APPLICATIONS}

몇몇 디바이스는 어떠한 소프트웨어도 포함하지 않고, 몇몇은 설치된 후에 수정되는 일이 설사 있더라도 극히 드문 그저 단순한 임베드된 소프트웨어(embedded software)를 포함한다. 하지만 오늘날 사용되는 많은 각양각색의 디바이스 - 단지 몇 개만 말하자면, 스마트폰, 태블릿 컴퓨터, 랩톱 컴퓨터 및 최신 자동차와 같은 것 - 는 하나 이상의 애플리케이션(application)에 의해 사용되는 별개의 업데이트가능한 라이브러리를 포함하는 복합 소프트웨어(complex software)를 포함한다. 몇몇 소프트웨어 개발 환경에서, 이들 소프트웨어 라이브러리 중 몇몇 또는 전부는 프레임워크(framework)의 일부이다. 상업적으로 이용가능한 소프트웨어 프레임워크 중 몇몇은 Java® 및 JavaScript® 프레임워크(오라클 아메리카 사(Oracle America, Inc.)의 표장), Oracle® 애플리케이션 개발 프레임워크(Application Development Framework)(오라클 아메리카 사의 표장), 다양한 모델-뷰-제어기(Model-View-Controller: MVC) 프레임워크, 다양한 웹 애플리케이션 프레임워크, 그리고 널리 사용되는 Microsoft® .NET™ 프레임워크(마이크로소프트 사(Microsoft Corporation)의 표장)를 포함한다.

별개로 업데이트가능한 라이브러리를 사용하는 것은 코드(code)의 재사용을 증진시키고, 소스 코드가 변경되는 경우에 필요한 재컴파일(recompilation)을 제한하는 데에 도움이 되며, 대형 프로그램들을 개발하고 유지하기 더 쉽게 만드는 방식으로 그것들을 조직화하는(organize) 데에 도움이 된다. 하지만 애플리케이션이 호출되는(invoked) 경우에 라이브러리의 상이한 버전(version)들이 맞닥뜨리게 될 수 있다는 가능성은 또한 난제(challenge)들을 초래한다. 이 난제들은 프레임워크 라이브러리를 그룹(group)으로서 업데이트하는 확립된 관행에 의해, 그리고 애플리케이션 내에서 사용되는 상이한 라이브러리들이 흔히 상이한 벤더(vendor)들에 의해 제공 - 및 업데이트 - 된다는 사실에 의해 복잡하게 된다.

본 문서에 기술된 실시예 중 몇몇은 주어진 운영 콘텍스트(operating context) 내에서 애플리케이션을 지원하여 로드할(load) 소프트웨어 라이브러리의 버전을 선택하는 경우에 융통성(flexibility) 및 확실성(certainty) 양자 모두를 제공하는 기술적 문제에 지향됨을 컴퓨팅 업계의 숙련자는 이해할 것이다. 몇몇 실시예는 보안 결함(security flaw)에 취약한(vulnerable) 것으로 알려진 라이브러리 버전이 주어진 운영 콘텍스트 내에 로드된 적이 있는지를 효율적으로 그리고 정확하게 판정하는 기술적 문제에 지향됨이 또한 이해될 것이다. 본 문헌의 세심한 검토 후에, 당업계의 숙련자는 본 문서에 기술된 실시예가 하나 이상의 컴퓨팅 시스템 내의 계산적(computational) 컴포넌트로서, 즉 소프트웨어 명령어를 실행하는 것에 의해 존재하고 동작하도록 의도되고 제한된 것임을 또한 인지할 것이다. 이에 따라, 실시예는 사실상, 인간의 정신적 프로세스나, 순전한 추상화나, 전파되는 신호 그 자체와 같은 비계산적(non-computational) 아이템으로 대체될 수는 없다.

컴퓨팅 시스템에서, 애플리케이션 프로그램에 의해 소프트웨어 라이브러리에 대한 참조(reference)가 행해지는 경우, 애플리케이션을 지원하여 로드할 라이브러리의 버전을 바인더(binder)가 선택한다. 본 문서에 기술된 실시예 중 몇몇은 묵시적 오버라이드(implicit override) 부분을 포함하는 바인더를 제공한다. 묵시적 오버라이드는 때때로 본 문서에서 "앱 로컬"(app local), "애플리케이션 로컬"(application-local), 또는 "앱로컬"(AppLocal)로 지칭된다.

몇몇 실시예에서, 메모리는 프로세스(들)과 통신가능하고(operable communication), 메모리 내에 상주하는(residing) 바인더는 묵시적 오버라이드 코드(implicit override code)에 의해 향상된다. 바인더는 애플리케이션의 실행을 지원하도록 로딩(loading)하기 위해 참조된 어셈블리(referenced assembly)의 어느 버전이 로더(loader)에 식별될 것인지를 판정하기 위해 프로세서 및 메모리와 상호작용하도록 구성된다. "라이브러리"(library) 및 "어셈블리"(assembly)라는 용어는 개별적으로 버전화가능한(versionable) 계산적 컴포넌트들을 기술하기 위해 본 문서에서 교환가능하게 사용된다. 버전을 가지는 주어진 어셈블리는 자기 자신 각자의 버전을 갖는 다른 어셈블리로 구성되고/되거나 그렇지 않으면 이에 의존할 수 있다.

몇몇 실시예에서, 묵시적 오버라이드 코드는 적어도 하나의 어셈블리 특정 위치(assembly-specific location) 내에서 묵시적 버전(implicit_version)을 찾아 탐색하는 코드, 묵시적 버전이 발견된 후 묵시적 버전을 어떤 다른 버전과 비교하는 코드, 그리고 묵시적 버전이 그 다른 버전보다 더 큰 경우 묵시적 버전으로써 그 다른 버전을 조건부로(conditionally) 오버라이드하는 코드를 포함한다. 버전 번호는 전형적으로는 시간에 걸쳐 증가하여서, 어셈블리의 버전 X는 버전 X가 버전 Y보다 더 새로운 것인 경우 보통 어셈블리의 다른 버전 Y"보다 더 클" 것이다.

몇몇 실시예에서, 묵시적 오버라이드 중에 탐색되는 어셈블리 특정 위치 또는 위치들은 다음 중 적어도 하나를 포함한다: 어셈블리와 공통인 이름을 가지고 애플리케이션의 디렉토리(directory) 내에 위치된 파일(file), 탐색 규약(search convention)에 의해 지정된 애플리케이션의 서브디렉토리(subdirectory), 디렉토리 경로의 리스트(list) 내에 지정된 위치(그 리스트는 애플리케이션의 디렉토리 내에 위치됨), 파일 이름의 리스트 내에 지정된 위치(그 리스트는 애플리케이션의 디렉토리 내에 위치됨).

몇몇 실시예에서, 바인더는 프레임워크 통합(framework unification) 부분을 포함하는데, 이는 묵시적 오버라이드 부분 내에 들어간다. 프레임워크 통합 그 자체는 컴퓨팅 업계의 몇몇 숙련자들에게는 이미 친숙하다. 프레임워크 통합은 어셈블리의 상호 일관적(mutually-consistent) 세트가 로드되게끔 하는 것을 돕기 위해, 예컨대 Microsoft® .NET™ 프레임워크(마이크로소프트 사의 표장)와 함께 사용된다. 프레임워크 내의 어셈블리는 전형적으로 세트(set)로서 버전화되고(versioned) 릴리즈된다(released).

본 콘텍스트에서, 몇몇 실시예는 묵시적 오버라이드 코드를 가지며 또한 프레임워크 통합 코드를 포함하는 바인더를 제공한다. 프레임워크 통합 코드의 덕분으로, 바인더는 관리되는 런타임(runtime)에 커플링된 어셈블리들의 사전정의된 프레임워크 내에 어셈블리가 있는지 확인하도록 구성된다. 프레임워크 통합 코드는 요청된 버전(requested_version)을 통합 버전(unification_version)과 비교하고, 통합 버전이 요청된 버전보다 더 크고 어셈블리가 사전정의된 프레임워크 내에 있는 경우에는 요청된 버전을 통합 버전으로써 조건부로 오버라이드하는 코드를 포함한다. 향상된 바인더는 통합 단계 결과(unification phase result)를 획득하기 위해 프레임워크 통합 코드를 호출하고, 이후 묵시적 오버라이드 단계 결과(implicit override phase result)를 획득하기 위해 해당 통합 단계 결과로써 묵시적 오버라이드 코드를 호출하도록 구성된다.

몇몇 실시예에서, 바인더는 묵시적 오버라이드 부분에 의해 들어가게 되는 바인딩 재지향(binding redirection) 부분을 포함한다. 바인딩 재지향 그 자체는 컴퓨팅 업계의 몇몇 숙련자에게 이미 친숙하다. XML 바인딩 재지향 명령 및 발행자 정책 문장의 형태로 된 바인딩 재지향은 예컨대 Microsoft® .NET™ 프레임워크(마이크로소프트 사의 표장)를 사용하는 컴퓨팅 환경 내에서 찾아볼 수 있다. 친숙한 용도에서, 바인딩 재지향은 프레임워크 통합의 결과(들)를 수정하는 데에 사용된다. 다만, 본 문서에 기술된 몇몇 실시예에서, 바인딩 재지향은 묵시적 오버라이드 결과(들)를 수정한다. 즉, 묵시적 오버라이드 계산(implicit override computation)은 몇몇 실시예에서 프레임워크 통합 단계 및 바인딩 재지향 단계 사이에 주입된다.

몇몇 실시예에서, 묵시적 오버라이드 코드로써 향상된 바인더는 바인딩 재지향 명령에 대해 확인하도록 구성된 바인딩 재지향 코드를 또한 포함한다. 바인딩 재지향 코드는 바인딩 재지향 명령에 응답하여 묵시적 버전을 오버라이드하는 코드를 포함하고, 바인더는 묵시적 오버라이드 코드를 호출한 후 바인딩 재지향 코드를 호출하도록 구성된다. 몇몇 실시예에서, 묵시적 오버라이드 코드로써 향상된 바인더는 프레임워크 통합 코드 및 묵시적 오버라이드 코드 양자 모두를 또한 포함한다.

몇몇 실시예는 묵시적 오버라이드 및 바인딩 재지향 단계들 간의 하나 이상의 차이에 의해 특징지어진다(characterized). 몇몇에서, 바인딩 재지향은 만약 현재 선택된 버전이 X 내지 Y의 범위(range X-Y) 내에 있다면 대신에 버전 Z를 사용한다는 점을 상술하는(recite) 반면, 묵시적 버전은 명시적 범위(explicit range)를 상술하지 않는다. 몇몇에서, 묵시적 버전은 애플리케이션의 구성 파일(configuration file)의 외부에서 발견되나, 바인딩 재지향은 구성 파일의 내부에 지정된다. 몇몇에서, 바인딩 재지향은 XML 선언(declaration)에 의해 지정되는 반면, 묵시적 버전은 XML 선언을 요구하는 것 없이 어셈블리에 의해 묵시적으로 지정된다.

몇몇 실시예는 묵시적 오버라이드 및 프레임워크 통합 단계들 간의 차이에 의해 특징지어진다. 구체적으로, 통합 버전은 어셈블리들의 프레임워크로써 업데이트되어지는 반면, 묵시적 버전은 개별 어셈블리로써 업데이트되어진다. 어셈블리를 대역외(out-of-band) 어셈블리(프레임워크를 이용한 업데이트로 한정되지 않은 것)로 만드는 것은 어셈블리의 더욱 빈번한 업데이트를 허용한다. 프레임워크 업데이트는 개별 어셈블리의 개발자가 때때로 선호할 것보다는 상당히 더 긴 간격으로 일어나는 경향이 있으나, 이 불편함보다는 프레임워크 어셈블리의 대규모 호환가능성 시험(compatibility testing)과 같은 프레임워크 멤버십(membership)의 이득이 더 컸다.

앞서 밝혀진 향상된 바인더 변화는 주어진 운영 콘텍스트 내에서 애플리케이션을 지원하여 로드할 소프트웨어 라이브러리의 버전을 선택하는 경우에 융통성 및 확실성을 제공하는 데에 도움이 된다. 바인더는 운영 콘텍스트의 양상, 이를테면 운영 콘텍스트의 통합 버전(프레임워크 통합 레벨을 나타냄), 운영 콘텍스트의 앱 로컬 표시(어셈블리가 프레임워크에 대해 대역외로 취급되어야 한다는 것), 그리고 애플리케이션의 구성 파일, 머신 구성 및/또는 발행자 정책에서의 운영 콘텍스트의 "최종 발언"(final word) 바인딩 명령과 같은 것에 응답한다.

어느 어셈블리 버전을 로드할지 선택한 바인더는 흔히 어셈블리 코드의 선택된 버전을 위치파악하고(locate) 로드하는 로더와 긴밀히 공조한다. 특히, 로더는 바인더에 의해 선택된 어셈블리 버전이 로드되지 않아야 한다(어셈블리 코드의 해당 버전은 알려진 보안 취약점(security vulnerability)을 가지고 있기 때문임)고 로더가 판정할 수 있다. 문제의 어셈블리 버전이 이미 검사되었는지를 아는 것은 유익할 수 있다. 몇몇 실시예는 주어진 운영 콘텍스트 내에 어셈블리 버전이 이전에 로드되었다는 사실을 어셈블리 버전이 어떠한 알려진 보안 취약점도 갖지 않으며 따라서 안전하게 다시 로드될 수 있다 - 그것은 이전에 검사되었다 - 라는 표시(indication)로서 이용한다. 주어진 운영 콘텍스트는 소프트웨어 및 다른 데이터로써 구성된 주어진 머신 또는 머신의 주어진 세트를 포함한다.

몇몇 실시예에서, 어셈블리의 취약한 버전이 운영 콘텍스트 내에 로드되었던 적이 있는지를 판정하기 위해 업데이트 서비스(update service)에 의해 대역외 메타데이터 엔트리(out-of-band metadata entry)가 사용된다. 대역외 메타데이터 엔트리는 때때로 비공식적으로 본 문서에서 "브레드크럼"(breadcrumb)으로 지칭된다. 그 메타데이터 엔트리는 레지스트리 키(registry key), 파일 시스템 로그 엔트리(file system log entry) 또는 다른 로그 엔트리, 트리(tree) 또는 리스트 내의 구성요소로서, 그리고/또는 본 문서에 기술된 사용을 위해 적응된 다른 익숙한 메커니즘을 사용하여 구현될 수 있다.

앱 로컬 향상된(app-local-enhanced) 바인더를 이용한 몇몇 실시예는 어셈블리가 로드되는 경우에 어셈블리를 대역외 어셈블리로서 식별하는 브레드크럼을 또한 배치한다(place). 브레드크럼 배치는 예컨대 알려진 대역외 어셈블리의 리스트, 또는 어셈블리의 대역외 서비싱 속성(out-of-band-servicing attribute)에 기반할 수 있다. 몇몇 경우에, 서비싱 라이브러리(servicing library)는 브레드크럼을 배치한다. 몇몇 경우에, 애플리케이션 설치 패키지는 브레드크럼을 배치한다. 몇몇 실시예에서, 취약한 어셈블리 리스트 및 대역외 어셈블리 리스트 중 하나 또는 양자 모두는 서비싱(servicing)에 의해 패치될(patched) 수 있다.

더욱 정식으로, 몇몇 실시예는 주어진 운영 콘텍스트에서 이전에 적어도 1회 로드된 어셈블리를 포함한다. 대역외 메타데이터의 모음(collection)이 메모리 내에 상주한다. 대역외 메타데이터 모음은 이전에 로드된 어셈블리를 위한 엔트리를 포함한다. 메모리는 다음 중 적어도 하나를 또한 포함한다: (a) 어셈블리가 이전에 로드된 경우 어셈블리가 알려진 대역외 어셈블리의 리스트와 적어도 부분적으로 매칭되는 것에 응답하여 엔트리를 그 모음 내에 배치하도록 구성된 대역외 어셈블리 코드, (b) 이전에 로드된 어셈블리의 대역외 서비싱 속성. 몇몇 실시예에서, 메모리는 엔트리를 그 모음 내에 배치하도록 구성된 코드를 포함하는 서비싱 라이브러리를 포함한다.

절차적인 관점에서, 또는 구성된 저장 매체(configured storage medium)(이는 지적된 바와 같이 전파되는 신호 그 자체는 아님)의 관점에서, 몇몇 실시예는 요청된 어셈블리의 어느 버전이 애플리케이션의 실행을 지원하도록 로딩을 위해 로더에 식별될지를 판정하기 위한 기술적 프로세스의 계산적 수행을 야기한다. 몇몇에서, 그 프로세스는 어셈블리 특정 위치에서 묵시적 버전을 찾아내는 것, 묵시적 버전이 발견된 후 묵시적 버전을 다른 버전과 비교하는 것 및 묵시적 버전이 그 다른 버전보다 더 큰 경우 묵시적 버전으로써 그 다른 버전을 오버라이드하는 것을 포함한다.

몇몇 실시예에서, 그 프로세스는 요청된 어셈블리의 프레임워크 통합을 수행하는 것을 더 포함하고, 프레임워크 통합은 묵시적 버전과 비교되는 다른 버전을 산출한다. 몇몇에서, 그 프로세스는 요청된 어셈블리의 바인딩 재지향을 수행하는 것을 더 포함하고, 바인딩 재지향은 묵시적 버전을 오버라이드한다. 몇몇 실시예는 프레임워크 통합, 묵시적 오버라이드 및 바인딩 재지향을 포함한다.

몇몇 실시예는 대역외 메타데이터 엔트리를 배치하기 위한 하나 이상의 단계를 수행한다. 엔트리 배치는 데이터를 생성, 복사 또는 업데이트하는 것 및 데이터를 대역외 메타데이터 모음 내에 두는 것을 포함한다. 몇몇 실시예에서는, 어셈블리가 보안 결함에 취약한 것으로 블랙리스트에 올려진(black-listed) 경우에도 어셈블리 버전을 위한 대역외 메타데이터 엔트리가 배치된다. 어셈블리 버전을 위한 대역외 메타데이터 엔트리는 로드되는 버전, 즉 바인딩의 모든 단계가 완료된 후 선택된 버전을 위해 배치된다.

대역외 메타데이터 엔트리 배치는 어셈블리가 대역외 어셈블리라는 인식에 응답하여 발생한다. 그런 인식은 (a) 어셈블리를 알려진 대역외 어셈블리의 리스트에 적어도 부분적으로 매칭시키고, 대응하여 컴퓨터 시스템 상의 메타데이터 모음 내에 어셈블리를 위한 엔트리를 배치하는 것, (b) 어셈블리 내 대역외 서비싱 속성을 위치파악하고(locating), 대응하여 컴퓨터 시스템 상의 메타데이터 모음 내에 어셈블리를 위한 엔트리를 배치하는 것, 그리고/또는 (c) 컴퓨터 시스템에 서비스 패키지(service package)를 적용하고, 서비스 패키지를 적용하는 것의 일부로서 컴퓨터 시스템 상의 메타데이터 모음 내에 어셈블리를 위한 엔트리를 배치하는 것과 같은 다양한 방식으로 성취될 수 있다.

몇몇 실시예에서, 로더는 취약한 어셈블리 아이덴티티의 블록리스트(a blocklist of vulnerable assembly identities)를 살펴볼(consult) 것이고, 만약 로드된 어셈블리가 블록리스트 내의 엔트리와 매칭되는 경우 로드는 강제적으로 실패로 될 것이다. 더욱 정식으로, 몇몇 실시예에서, 로더 프로세스는 주어진 머신 상에 어셈블리가 이전에 로드되었다는 어떠한 표시도 못 찾아내고, 어셈블리가 보안 결함에 취약함을 판정하며, 해당 판정에 응답하여 어셈블리를 로드하는 데에 실패한다. 의도적으로 강제된 로드 실패의 부재 시에는, 로드가 정상적으로 성공하였을 것이다.

주어진 예들은 단지 예시적이다. 이 개요는 청구된 대상(claimed subject matter)의 중요 특징 또는 필수적 특징을 식별하고자 의도된 것이 아니고, 청구된 대상의 범주를 한정하기 위해 사용되도록 의도된 것도 아니다. 오히려, 이 개요는 상세한 설명에서 추가로 후술되는 몇몇 기술적 개념을 - 단순화된 형태로 - 소개하기 위해 제공된다. 혁신은 청구항으로써 정의되며, 이 개요가 청구항과 충돌하는 한, 청구항이 우선해야 한다.

첨부된 도면을 참조하여 더욱 자세한 설명이 주어질 것이다. 이들 도면은 선택된 양상을 예시할 뿐이며 따라서 포섭범위(coverage) 또는 범주(scope)를 완전히 정하지는 않는다.
도 1은 애플리케이션 프로그램의 어셈블리를 바인드하고 로드하기 위한 소프트웨어의 제어 하에 서로와 상호작용하는 적어도 하나의 프로세서 및 적어도 하나의 메모리를 가지는 컴퓨터 시스템, 그리고 다수의 네트워크 노드 상에 존재할 수 있는 운영 환경(operating environment) 내의 다른 아이템을 예시하고, (순전한 신호와 대조되는) 구성된 저장 매체 실시예를 또한 예시하는 블록도이고,
도 2는 예시적 아키텍처 내의 향상된 바인딩 및 대역외 어셈블리 관리의 양상을 예시하는 블록도이며,
도 3은 구성된 저장 매체 실시예 및 어떤 프로세스의 단계를 예시하는 흐름도이고,
도 4는 바인딩에 초점을 맞춰, 구성된 저장 매체 실시예 및 어떤 프로세스의 단계를 추가로 예시하는 흐름도이며,
도 5는 대역외 어셈블리 관리에 초점을 맞춰, 구성된 저장 매체 실시예 및 어떤 프로세스의 단계를 추가로 예시하는 흐름도이다.

개관

현재의 Microsoft® .NET™ 배포 모델(마이크로소프트 사의 표장)과 같은 몇몇 현재의 소프트웨어 배포 모델에서, 프레임워크 라이브러리는 중앙식으로(centrally) 설치되고 머신 범위로(machine wide) 공유된다. 어셈블리 바인더는 전역 어셈블리 캐시(Global Assembly Cache: GAC)와 같은 중앙 위치(central location)로부터 이들 프레임워크 어셈블리를 위치파악하기 위해 어떤 정책을 따른다. 이 배포 모델은 이점을 가지며 널리 사용되나, 그것은 또한 몇몇 난점을 제기한다. 개별적인 프레임워크 컴포넌트들은 그것들 자신의 더 빠른 진행속도(cadence)로 새로운 릴리즈를 발송하는(shipping) 것 대신에, 중앙 발송 매개체(central shipping vehicle)(가령, 재배포가능물(redistributable)들, 플랫폼 업데이트들)가 그것들의 새로운 기능을 릴리즈하기를 기다리도록 강제된다. 또한, 프레임워크 라이브러리에 대한 업데이트는 머신 상에 설치된 모든 애플리케이션에 영향을 미친다.

본 문서에 기술된 몇몇 실시예는 애플리케이션으로 하여금 프레임워크 라이브러리의 애플리케이션 로컬 버전을 지닐 수 있게 하는데, 이는 그것이 수취함내(in-box) 사본보다 더 큰 버전을 가지는 경우에 어셈블리 바인더가 선호할 것이다. 몇몇 실시예에서, 바인더 알고리즘은 여전히 호환가능성을 위해 프레임워크 어셈블리의 기존의 리스트(익숙하게는 "통합 리스트"로 알려짐)를 유지하나, (만약 존재하고 더 새롭다면) 애플리케이션 패키지 내에 포함된 라이브러리의 버전을 재배포가능물로부터의 것 대신에 선호한다. 몇몇 실시예에서, 바인더 알고리즘은 동일한 어셈블리의 다수의 버전의 로딩을 불허할 것이다. 몇몇 실시예에 있어서, 대역외 프레임워크 어셈블리는 프레임워크 릴리즈로써가 아니라 애플리케이션 패키지로써 발송되고/되거나 비치될(deployed) 것이다. 결과적으로, 개별 프레임워크 컴포넌트의 더 새로운 대역외 버전은 더 크고 덜 빈번하며 더 널리 영향력 있는 온전한 프레임워크 업데이트의 외부에서 애플리케이션 패키지로써 발송되어 비치될 수 있다. 또한, 애플리케이션 개발자는 프레임워크 컴포넌트의 새로운 기능을 사용하기 위해 새로운 프레임워크 버전을 재목표화하거나(retarget) 플랫폼 업데이트 전제조건을 시행하도록(enforce) 더 이상 강제되지 않을 것이다. 추가로, 프레임워크 컴포넌트의 대역외 버전을 쓰는(consuming) 것의 효과는 몇몇 실시예에서 단지 애플리케이션 자체로 한계 지어질(scoped) 것인데, 이는 원치 않는 머신 범위 행위 변화(machine wide behavior change)들을 가능한 대로 막는다.

본 문서에 기술된 몇몇 실시예는 더 폭넓은 콘텍스트에서 볼 수 있다. 예를 들면, 바인딩, 프레임워크, 로딩 및 버전과 같은 개념은 특정한 실시예와 관련될 수 있다. 다만, 폭넓은 콘텍스트의 이용가능성으로부터 본 문서에서 추상적 관념에 대해 배타적 권리를 구하고 있다는 결론이 나오는 것은 아니니, 그것은 아니다. 오히려, 본 개시는 기술적 효과가 특정한 기술적 문제를 전적으로 또는 부분적으로 해결하는 특정 실시예를 적절히 제공하는 것에 집중된다. 바인딩, 프레임워크, 로딩 및 버전을 수반하는 다른 매체, 시스템 및 방법은 본 범주의 외부에 있다. 이에 따라, 본 개시의 적절한 이해 하에서 모호성, 순전한 추상성, 기술적 특질의 흠결, 그리고 동반하는 검증 문제가 또한 방지된다.

본 문서에 기술된 실시예의 기술적 특질은 통상의 기술자에게 명백할 것이고, 또한 광범위한 주의 깊은 독자에게 여러 방식으로 명백할 것이다. 첫째, 몇몇 실시예는 바인드할(bind) 어셈블리 버전을 선택하는 것 또는 바인딩을 위해 선택된 어셈블리 버전이 또한 로드하기에 안전한지를 판정하는 것과 같은 기술적 문제를 다룬다. 둘째, 몇몇 실시예는 범용 컴퓨터(general purpose computer) 내의 전형적인 상호작용을 넘어서는 식으로 소프트웨어와 상호작용하는 컴퓨팅 하드웨어와 같은 기술적 컴포넌트를 포함한다. 예를 들어, 일반적으로 메모리 배분(memory allocation), 일반적으로 메모리 판독 및 기입, 일반적으로 명령어 실행, 그리고 어떤 종류의 I/O와 같은 통상적 상호작용에 더하여, 본 문서에 기술된 몇몇 실시예는 대역외 어셈블리 메타데이터 엔트리를 생성하고, 몇몇은 바인딩을 위한 버전을 선택하기 위해 애플리케이션 로컬 버전을 요청된 또는 통합된 버전과 비교한다. 셋째, 몇몇 실시예에 의해 제공되는 기술적 효과는 대역외 메타데이터 엔트리, 취약한 어셈블리의 강제된 로드 실패, 그리고 프레임워크 통합 버전 선택의 오버라이드를 포함한다. 넷째, 몇몇 실시예는 바인더에 대한 묵시적 오버라이드 향상, 그리고 로더 내의 대역외 어셈블리 지원과 같은 기술적 적응을 포함한다. 다섯째, 몇몇 실시예는 어셈블리 버전 및 메타데이터 엔트리와 같은 기술적 고려사항에 기반하여, 묵시적 오버라이드 기능에 의해 그리고/또는 대역외 어셈블리 검출 및 취급 기능에 의해 바인더 및/또는 로더의 기술적 기능을 수정한다. 여섯째, 몇몇 실시예의 기술적 이점은 프레임워크 어셈블리의 더욱 빈번한 업데이트, 바인드할 어셈블리 버전을 선택하기 위한 개선된 융통성, 그리고 대역외 어셈블리 내의 보안 결함에 대한 저하된 취약성을 포함한다.

도면 내에 예시된 것과 같은 예시적인 실시예에 대한 언급이 이제 행해질 것이며, 그것을 기술하기 위해 본 문서에서 특정한 말(language)이 사용될 것이다. 그러나 본 문서에 예시된 특징의 변경 및 추가적 수정, 그리고 본 문서 내의 특정한 실시예에 의해 예시된 추상적 원리의 추가적인 기술적 적용은, 관련 업계(들)에서 숙련되고 이 개시를 소유한 이에게 떠오를 것인데, 청구항의 범주 내에서 고려되어야 한다.

용어의 의미는 이 개시 내에서 해명되기에(clarified), 이 해명들에 대한 세심한 주의와 함께 청구항이 읽혀야 한다. 특정한 예가 주어지나, 관련 업계(들)의 숙련자는 사용되는 용어의 의미 내에, 그리고 하나 이상의 청구항의 범주 내에 다른 예가 속할 수도 있다는 점을 이해할 것이다. 용어는 그것이 일반적 용법(특히 비기술적 용법)이나 특정한 산업의 용법이나 특정한 사전 또는 사전의 집합에서 가지는 것과 동일한 의미를 여기에서 반드시 가지는 것은 아니다. 용어의 폭을 보이는 데에 도움이 되도록, 참조 번호가 다양한 어법(phrasing)들로써 사용될 수 있다. 텍스트의 주어진 부분에서의 참조 번호의 생략은 반드시 도면의 내용이 텍스트에 의해 논의되지 않고 있음을 의미하는 것은 아니다. 발명자들은 그들 자신의 사전편찬(lexicography)에 대한 그들의 권리를 주장하고 행사한다. 용어는 여기에서 상세한 설명 내에 그리고/또는 출원 파일 내 다른 곳에서, 명시적으로든 아니면 묵시적으로든, 정의될 수 있다.

본 문서에서 사용되는 바와 같이, "컴퓨터 시스템"은 예컨대 하나 이상의 서버, 마더보드(motherboard), 처리 노드(processing node), 개인용 컴퓨터(휴대가능하거나 그렇지 않음), 개인용 디지털 보조기기(personal digital assistant), 스마트폰(smartphone), 휴대폰 혹은 모바일 전화, 적어도 하나의 프로세서 및 메모리를 가지는 다른 모바일 디바이스, 그리고/또는 적어도 부분적으로는 명령어에 의해 제어되는 하나 이상의 프로세서를 제공하는 다른 디바이스(들)를 포함할 수 있다. 명령어는 메모리 및/또는 특화된 회로망(specialized circuitry) 내의 펌웨어 또는 다른 소프트웨어의 형태로 된 것일 수 있다. 특히, 비록 많은 실시예가 워크스테이션 또는 랩톱 컴퓨터 상에서 행해짐이 떠오를 수 있으나, 다른 컴퓨팅 디바이스 상에서 다른 실시예가 행해질 수 있고, 임의의 하나 이상의 그러한 디바이스는 주어진 실시예의 일부일 수 있다.

"멀티쓰레딩된"(multithreaded) 컴퓨터 시스템은 다수의 실행 쓰레드를 지원하는 컴퓨터 시스템이다. "쓰레드"(thread)라는 용어는 스케줄링(scheduling)(그리고 가능하게는 동기화)가 가능하거나 이의 대상이 되는 임의의 코드를 포함하는 것으로 이해되어야 하며, 예컨대 "태스크"(task), "프로세스"(process) 또는 "코루틴"(coroutine)과 같은 다른 이름으로 알려질 수도 있다. 쓰레드는 병렬로, 순차로, 또는 병렬 실행(가령, 다중처리(multiprocessing)) 및 순차적 실행(가령, 시배분됨(time-sliced))의 조합으로 구동될(run) 수 있다. 멀티쓰레딩된 환경은 다양한 구성으로 설계되었다. 실행 쓰레드가 병렬로 구동될 수 있거나, 쓰레드가 병렬 실행을 위해 조직화되나 실제로는 순차로 실행하는 것을 교대로 할 수 있다. 멀티쓰레딩(multithreading)은 예컨대 다중처리 환경 내의 상이한 코어들 상에서 상이한 쓰레드들을 구동하는 것에 의해, 단일 프로세서 코어 상에서 상이한 쓰레드들을 시배분하는 것(time-slicing)에 의해, 또는 시배분 및 다중프로세서(multi-processor) 쓰레딩의 어떤 조합에 의해 구현될 수 있다. 쓰레드 콘텍스트 스위치는 예컨대 커널(kernel)의 쓰레드 스케줄러(thread scheduler)에 의해, 사용자 공간(user-space) 신호에 의해, 또는 사용자 공간 및 커널 동작의 조합에 의해 개시될 수 있다. 예를 들어, 쓰레드는 공유된 데이터에 대해 동작하는 것을 교대로 할 수 있거나, 각 쓰레드는 그 자신의 데이터에 대해 동작할 수 있다.

"논리적 프로세서"(logical processor) 또는 "프로세서"는 동시 멀티쓰레딩 구현 내의 코어와 같은 단일의 독립적인 하드웨어 쓰레드 처리 유닛(hardware thread-processing unit)이다. 다른 예로서, 코어당(per core) 두 개의 쓰레드를 구동하는 하이퍼쓰레딩된 쿼드 코어 칩(hyperthreaded quad core chip)은 8개의 논리적 프로세서를 가진다. 논리적 프로세서는 하드웨어를 포함한다. "논리적"이라는 용어는 주어진 칩이 기껏해야 하나의 프로세서를 가진다는 오판된 결론을 막기 위해 사용되는데, "논리적 프로세서" 및 "프로세서"는 분 문서에서 교환가능하게 사용된다. 프로세서는 범용일 수 있거나, 그것은 그래픽 처리(graphics processing), 신호 처리(signal processing), 부동 소수점 산술 처리(floating-point arithmetic processing), 암호화(encryption), I/O 처리 및 기타 등등과 같은 특정한 사용을 위해 맞춰질 수 있다.

"멀티프로세서" 컴퓨터 시스템은 다수의 논리적 프로세서를 가지는 컴퓨터 시스템이다. 멀티프로세서 환경은 다양한 구성에서 생긴다. 주어진 구성에서, 프로세서들 전부는 기능적으로 동일할 수 있으나, 다른 구성에서 몇몇 프로세서는 상이한 하드웨어 능력, 상이한 소프트웨어 할당, 또는 양자 모두를 가지기 때문에 다른 프로세서와 상이할 수 있다. 구성에 따라, 프로세서는 단일 버스 상에서 서로에게 밀접하게 커플링될(coupled) 수 있거나, 그것은 느슨하게 커플링될 수 있다. 몇몇 구성에서 프로세서는 중앙 메모리를 공유하고, 몇몇에서 그것은 각각 자기 자신의 로컬 메모리를 가지며, 몇몇 구성에서는 공유된 메모리와 로컬 메모리 양자 모두가 존재한다.

"커널"은 운영 체제, 하이퍼바이저, 가상 머신, BIOS 코드 및 유사한 하드웨어 인터페이스 소프트웨어를 포함한다.

"코드"는 프로세서 명령어, (상수, 변수 및 데이터 구조를 포함하는) 데이터, 또는 명령어 및 데이터 양자 모두를 의미한다.

"프로그램"은 애플리케이션, 커널, 드라이버, 인터럽트 핸들러, 라이브러리, 그리고 프로그래머(개발자로도 지칭됨)에 의해 쓰인(written) 다른 코드를 포함하도록 본 문서에서 광범위하게 사용된다.

"벤더"는 상업적 또는 비상업적 조직, 개인, 또는 코드의 내용 및/또는 배포를 제어하는 다른 개체(entity)를 의미한다.

본 문서에서 사용되는 바와 같이, 달리 언급되지 않으면 "포함한다"(include)는 추가적인 구성요소를 허용한다(즉, 포함한다(includes)는 포함한다(comprises)를 의미한다). "이루어진다"(consists of)는 필수적으로 이루어진다(consists essentially of), 또는 전적으로 이루어진다(consists entirely of)를 의미한다. X의 Y 아닌 부분(non-Y part)이 만약 있더라도 이것이 문제 청구항(claim in question)에 관한 한 청구된 실시예의 기능을 변경하지 않고 자유롭게 변경, 제거 및/또는 추가되는 경우에 X는 필수적으로 Y로 이루어진다.

"프로세스"는 컴퓨팅 과학 기술의 용어로서 본 문서에서 때때로 사용되고, 해당 기술적 의미에서는 예컨대 리소스 유저, 즉 코루틴, 쓰레드, 태스크, 인터럽트 핸들러, 애플리케이션 프로세스, 커널 프로세스, 프로시저 및 오브젝트 메쏘드를 망라한다. "프로세스"는 특허법 전문용어(patent law term of art)로서, 가령 시스템 청구항 또는 제조 물품(article of manufacture)(구성된 저장 매체) 청구항과 대조되는 프로세스 청구항을 기술하는 데에서, 본 문서에서 또한 사용된다. 유사하게, "방법"(method)은 컴퓨팅 과학 기술에서의 기술적 용어("루틴"과 같은 것)로서 그리고 특허법 전문용어("프로세스")로서도 종종 본 문서에서 사용된다. 숙련자는 특정한 사례에서 어느 의미가 의도되고 있는지 이해할 것이고, (특허법 의미에서) 주어진 청구된 프로세스 또는 방법이 때때로 (컴퓨팅 과학 의미에서) 하나 이상의 프로세스 또는 방법을 사용하여 구현될 수 있음을 또한 이해할 것이다.

"자동으로"(automatically)는 자동화(automation) 없음이 아니라, 자동화의 사용(가령, 본 문서에서 논의된 특정 동작 및 기술적 효과를 위해 소프트웨어에 의해 구성된 범용 컴퓨팅 하드웨어)에 의해서임을 의미한다. 특히, "자동으로" 수행되는 단계는, 비록 그것이 인간에 의해 개시되거나 인간에 의해 상호작용적으로 유도될 수 있기는 하지만, 종이 위에 손으로 또는 사람의 마음 속에서 수행되지 않는다. 기술적 상호작용 없이 실현되어 제공되지는 않을 하나 이상의 기술적 효과를 획득하기 위해서 머신으로써 자동적(automatic) 단계가 수행된다.

숙련자는 기술적 효과가 기술적 실시예의 추정적 목적임을 이해한다. 예를 들어, 어떤 실시예에 계산이 수반되고, 몇몇 계산은 기술적 컴포넌트 없이(가령, 종이와 연필에 의해, 또는 심지어는 정신적 단계로서) 수행될 수도 있다는 단순한 사실이 기술적 효과의 존재를 제거하거나 실시예의 실체적이고 기술적인 본질을 바꾸지는 않는다. 예를 들어, 어떤 친숙한 디바이스는 그것의 균형을 유지하기 위해 균형 계산을 수행하는데, 몇몇 예는 모바일 로봇 및 SEGWAY® 바퀴형(wheeled) 개인용 이동성 디바이스(세그웨이 사(Segway, Inc.)의 표장)를 포함한다. 이들 디바이스는 본 문서에 기술된 실시예의 일부는 아니지만 그것은 기술적 효과가 순전한 정신적 단계에 의해서가 아니라 기술적 컴포넌트에 의해 제공된다는 점을 보여준다. 균형 계산은 단순히, 많은 모바일 로봇 또는 바퀴형 개인용 이동성 디바이스 내에 존재하는 균형을 제공하기 위해, 정신적 단계에 의해 또는 종이와 연필에 의해 충분히 빠르게 수행될 수는 없다. 그러므로 동적으로 균형 잡히는 디바이스를 갖는 것의 기술적 효과는 균형 제어 소프트웨어와 상호작용하는 프로세서 및 메모리를 포함하는 기술적 컴포넌트에 의해 제공된다.

"계산적으로"(computationally)는 마찬가지로 컴퓨팅 디바이스(적어도, 프로세서에 메모리가 덧붙여짐)가 사용되고 있음을 의미하며, 순전한 인간의 생각(thought) 또는 순전한 인간의 행동(action)만에 의해 결과를 획득하는 것을 배제한다. 예를 들어, 종이와 연필로써 산술을 행하는 것은 본 문서에서 이해되는 바와 같이 계산적으로 산술을 행하는 것이 아니다. 계산적 결과는 더욱 신속한 것, 더욱 광범위한 것, 더욱 심도 있는 것, 더욱 정확한 것, 더욱 일관적인 것, 더욱 포괄적인 것, 그리고/또는 아니면 인간의 수행만의 범주를 넘어서는 기술적 효과를 제공하는 것이다. "계산적 단계"는 계산적으로 수행되는 단계이다. "자동으로"나 "계산적으로" 중 어느 것도 반드시 "즉각적으로"(immediately)를 의미하는 것은 아니다. "계산적으로" 및 "자동으로"는 본 문서에서 교환가능하게 사용된다.

"선조치적으로"(proactively)는 사용자로부터의 직접적인 요청 없음을 의미한다. 사실, 사용자는 심지어 실시예에 의한 선조치적 단계(proactive step)가 가능했다는 것을 그 단계의 결과가 사용자에게 제시될 때까지 알아차리지도 못할 수 있다. 달리 언급되는 경우 외에, 본 문서에 기술된 임의의 계산적 및/또는 자동적 단계는 선조치적으로 행해질 수도 있다.

이 문헌을 통틀어, 선택적인 복수형 "(들)"((s) 또는 (es) 또는 (ies))의 사용은 표시된 특징이 하나 이상 존재함을 의미한다. 예를 들어, "프로세서(들)"은 "하나 이상의 프로세서" 또는 동등하게 "적어도 하나의 프로세서"를 의미한다.

이 문헌을 통틀어, 달리 명시적으로 언급되지 않은 경우 프로세스 내의 단계에 대한 임의의 언급은 그 단계가 이해관계 측(party of interest)에 의해 직접적으로 수행되고/되거나 중개 메커니즘 및/또는 중개 개체를 통해 그 측에 의해 간접적으로 수행될 수 있다고 상정하며, 여전히 그 단계의 범주 내에 있다. 즉, 직접적인 수행이 명시적으로 언급된 요구사항이 아닌 한 이해관계 측에 의한 그 단계의 직접적인 수행은 요구되지 않는다. 예를 들어, 목표(destination) 또는 다른 대상체(subject)에 대해 적용하기, 바인드하기, 특징짓기, 확인하기, 비교하기, 구성하기, 판정하기, 실행하기, 실패하기, 찾아내기, 강제하기, 식별하기, 포함하기, 호출하기, 로드하기, 위치파악하기, 매칭하기, 획득하기, 오버라이드하기, 수행하기, 배치하기, 재지향하기, 요구하기, 상주하기, 탐색하기, 서비스하기, 지원하기, 업데이트하기 (그리고 적용하다, 적용되다, 바인드하다, 바인드되다, 찾아내다, 발견되다, 강제하다, 강제되다 등등)과 같은 이해관계 측에 의한 행동을 수반하는 단계는 어떤 다른 측에 의한 전달하기(forwarding), 복사하기(copying), 업로드하기(uploading), 다운로드하기(downloading), 부호화하기(encoding), 복호화하기(decoding), 압축하기(compressing), 압축해제하기(decompressing), 암호화하기(encrypting), 해독하기(decrypting), 인증하기(authenticating), 호출하기(invoking) 및 기타 등등과 같은 중개 행위를 수반할 수 있지만, 이해관계 측에 의해 직접적으로 수행되는 것으로 여전히 이해될 수 있다.

데이터 또는 명령어에 대한 언급이 행해질 때마다, 이 아이템들은 컴퓨터 판독가능(computer-readable) 메모리 및/또는 컴퓨터 판독가능 저장 매체를 구성하여, 이로써 그것을, 예컨대 종이 위에, 사람의 마음 속에, 또는 전선 상에서 전파되는 순전한 신호로서 단지 존재하는 것과는 대조되는 구체적인 물품(article)으로 변형시킨다는 점이 이해된다. 청구항 내에서 달리 명시적으로 언급되지 않는 한, 청구항은 신호 그 자체를 포섭하지 않는다. 이 명세서는 메모리 또는 다른 컴퓨터 판독가능 저장 매체가 Nuijten 사건의 미국 특허상표청(United States Patent and Trademark Office: USPTO) 해석 하에서 특허가능한 대상(patentable subject matter)의 범주 바깥에 있는 전파 신호(propagating signal) 또는 반송파(carrier wave)가 아니라고 상정한다.

더욱이, 본 문서 내의 다른 곳에 명백히 반하는 어떠한 것에도 불구하고, (a) 한편으로는 컴퓨터 판독가능 저장 매체 및 컴퓨터 판독가능 메모리, 그리고 (b) 다른 한편으로는 신호 매체로도 지칭되는 송신 매체 간의 명백한 구분이 이해될 것이다. 송신 매체는 전파 신호 또는 반송파 컴퓨터 판독가능 매체이다. 대조적으로, 컴퓨터 판독가능 저장 매체 및 컴퓨터 판독가능 메모리는 전파 신호나 반송파 컴퓨터 판독가능 매체가 아니다. 달리 명시적으로 언급되지 않는 한, "컴퓨터 판독가능 매체"는 전파 신호 그 자체가 아니라, 컴퓨터 판독가능 저장 매체를 의미한다.

운영 환경

도 1을 참조하면, 일 실시예를 위한 운영 환경(100)은 컴퓨터 시스템(102)을 포함할 수 있다. 컴퓨터 시스템(102)은 멀티프로세서 컴퓨터 시스템이거나 그렇지 않을 수 있다. 운영 환경은 주어진 컴퓨터 시스템 내에 하나 이상의 머신을 포함할 수 있는데, 이는 클러스터링된(clustered) 것, 클라이언트-서버 네트워킹된(client-server networked) 것 및/또는 피어-투-피어 네트워킹된(peer-to-peer networked) 것일 수 있다. 개별적인 머신은 컴퓨터 시스템이고, 협력하는(cooperating) 머신의 그룹도 컴퓨터 시스템이다. 주어진 컴퓨터 시스템(102)은 최종 사용자를 위해, 가령 애플리케이션으로써, 관리자를 위해, 서버로서, 분산 처리 노드(distributed processing node)로서, 그리고/또는 다른 방식으로 구성될 수 있다.

인간 사용자(104)는 타이핑된 텍스트(typed text), 터치(touch), 음성(voice), 움직임(movement), 컴퓨터 비전(computer vision), 제스처(gestures) 및/또는 다른 형태의 I/O를 통하여, 디스플레이, 키보드 및 다른 주변장치(106)를 사용함으로써 컴퓨터 시스템(102)과 상호작용할 수 있다. 사용자 인터페이스(user interface)는 실시예 및 하나 이상의 인간 사용자 간의 상호작용을 지원할 수 있다. 사용자 인터페이스는 명령 라인 인터페이스(command line interface), 그래픽 사용자 인터페이스(Graphical User Interface: GUI), 자연적 사용자 인터페이스(Natural User Interface: NUI), 음성 명령 인터페이스(voice command interface) 및/또는 다른 인터페이스 제시를 포함할 수 있다. 사용자 인터페이스는 예컨대 로컬 데스크톱 컴퓨터 상에, 또는 스마트폰 상에 생성될 수 있거나, 그것은 웹 서버로부터 생성되어 클라이언트에 발신될 수 있다. 사용자 인터페이스는 서비스의 일부로서 생성될 수 있고 그것은 소셜 네트워킹 서비스와 같은 다른 서비스와 접목될 수 있다. 주어진 운영 환경은 이들 상이한 사용자 인터페이스 생성 옵션 및 사용을 지원하는 디바이스 및 인프라스트럭처(infrastructure)를 포함한다.

자연적 사용자 인터페이스(Natural User Interface: NUI) 동작은 예컨대 발화 인식(speech recognition), 터치 및 스타일러스 인식, 제스처 인식(스크린 상에서도 그리고 스크린에 인접하여서도), 공기 제스처, 머리 및 눈 추적(head and eye tracking), 음성 및 발화, 비전, 터치, 제스처 및/또는 머신 지능(machine intelligence)을 사용할 수 있다. NUI 기술의 몇몇 예는 터치 감응 디스플레이, 음성 및 발화 인식, 의도 및 목적 이해, (입체 카메라 시스템, 적외선 카메라 시스템, RGB 카메라 시스템 및 이들의 조합과 같은) 깊이 카메라를 사용한 모션 제스처 검출, 가속도계/자이로스코프를 사용한 모션 제스처 검출, 얼굴 인식, 3D 디스플레이, 머리, 눈 및 깜박임 추적, 실감형 증강 현실 및 가상 현실 시스템을 포함하는데, 이들 전부는 더욱 자연스러운 인터페이스는 물론, 전계 감지 전극을 사용하여 뇌 활동을 감지하기 위한 기술(뇌파계(electroencephalograph) 및 관련된 도구)을 제공한다.

숙련자는 전술한 양상 및 "운영 환경" 밑에서 본 문서에 제시된 다른 양상이 주어진 실시예의 일부를 형성할 수도 있음을 인식할 것이다. 이 문헌의 표제들은 실시예 및 비실시예 특징 부류로의 특징의 엄격한 분류를 제공하고자 의도된 것은 아니다.

다른 예로서, 게임 애플리케이션이 Microsoft XBOX Live® 서버(마이크로소프트 사의 표장) 상에 상주할 수 있다. 게임은 콘솔(console)로부터 구매될 수 있고 그것은 서버, 콘솔 또는 양자 모두 상에서 전체적으로 또는 부분적으로 실행될 수 있다. 표준 제어기, 공기 제스처, 음성을 사용하거나 스마트폰 또는 태블릿과 같은 휴대 디바이스(companion device)를 사용하여 다수의 사용자가 게임과 상호작용할 수 있다. 주어진 운영 환경은 이들 상이한 사용 시나리오를 지원하는 디바이스 및 인프라스트럭처를 포함한다.

시스템 관리자, 개발자, 엔지니어 및 최종 사용자는 각각 특정한 유형의 사용자(104)이다. 하나 이상의 사람을 대신하여 작용하는 자동화된 에이전트, 스크립트, 플레이백(playback) 소프트웨어 및 유사한 것은 사용자(104)일 수도 있다. 저장 디바이스 및/또는 네트워킹 디바이스는 몇몇 실시예에서 주변 장비로 간주될 수 있다. 도 1에 도시되지 않은 다른 컴퓨터 시스템은 예컨대 네트워크 인터페이스 장비를 통하여 네트워크(108)로의 하나 이상의 연결을 사용하여 컴퓨터 시스템(102)과 또는 다른 시스템 실시예와 기술적인 방식으로 상호작용할 수 있다.

컴퓨터 시스템(102)은 적어도 하나의 논리적 프로세서(110)을 포함한다. 다른 적합한 시스템과 같이, 컴퓨터 시스템(102)은 하나 이상의 컴퓨터 판독가능 저장 매체(112)를 또한 포함한다. 매체(112)는 상이한 물리적 유형의 것일 수 있다. 매체(112)는 휘발성(volatile) 메모리, 비휘발성(non-volatile) 메모리, 제자리에 고정된(fixed in place) 매체, 탈착가능(removable) 매체, 자기 매체, 광학 매체, 그리고/또는 물리적 지속가능 저장 매체의 다른 유형의 것(전파되는 신호에 불과한 것과는 대조적임)일 수 있다. 특히, CD, DVD, 메모리 스틱(memory stick), 또는 다른 탈착가능한 비휘발성 메모리 매체와 같은 구성된 매체(114)는 삽입되거나 그렇지 않으면 설치되는 경우에 기능적으로 컴퓨터 시스템의 기술적인 일부가 될 수 있으니, 그것의 내용을 프로세서(110)와의 상호작용 및 프로세서(110)에 의한 사용을 위해 액세스가능하게 만든다. 탈착가능한 구성된 매체(114)는 컴퓨터 판독가능 저장 매체(112)의 한 예이다. 컴퓨터 판독가능 저장 매체(112)의 몇몇 다른 예는 내장된(built-in) RAM, ROM, 하드 디스크, 그리고 사용자(104)에 의해 손쉽게 탈착가능하지 않은 다른 메모리 저장 디바이스를 포함한다. 컴퓨터 판독가능 매체나 컴퓨터 판독가능 메모리 어느 것도 신호 그 자체를 포함하지 않는다.

매체(114)는 프로세서(110)에 의해 실행가능한(executable) 명령어(116)로써 구성되는데, "실행가능"은 예컨대 머신 코드, 해석가능한(interpretable) 코드, 바이트코드(bytecode), 그리고/또는 가상 머신(virtual machine) 상에서 구동되는 코드를 포함하도록 본 문서에서 광범위한 의미로 사용된다. 매체(114)는 명령어(116)의 실행에 의한 기술적 효과를 위해 생성되고/되거나 수정되고/되거나 참조되고/되거나 그렇지 않으면 사용되는 데이터(118)로써 또한 구성된다. 명령어(116) 및 데이터(118)는 메모리 또는 다른 저장 매체(114)(이 안에 그것들이 상주함)를 구성하는데, 그런 메모리 또는 다른 컴퓨터 판독가능 저장 매체가 주어진 컴퓨터 시스템의 기능적 일부인 경우, 명령어(116) 및 데이터(118)는 해당 컴퓨터 시스템을 또한 구성한다. 몇몇 실시예에서, 데이터(118)의 일부분은 제품 특성, 물품 목록, 물리적 측정, 설정, 이미지, 판독, 타겟, 볼륨 및 기타 등등과 같은 실세계 아이템을 나타내는 것이다. 그러한 데이터는 또한 백업(backup), 복원(restore), 커밋(commits), 중단(aborts), 재포맷화(reformatting) 및/또는 다른 기술적 동작에 의해 변형된다.

비록 실시예가 컴퓨팅 디바이스(가령, 범용 컴퓨터, 스마트 폰, 또는 게이밍 콘솔(gaming console)) 내의 하나 이상의 프로세서에 의해 실행되는 소프트웨어 명령어로서 구현되는 것으로 기술될 수 있으나, 그러한 설명은 모든 가능한 실시예를 철저히 다루고자 의도된 것은 아니다. 숙련자는 동일하거나 유사한 기술적 효과를 제공하기 위해, 동일하거나 유사한 기능이 흔히 전체적으로 또는 부분적으로, 직접적으로 하드웨어 논리로 구현될 수 있음을 이해할 것이다. 대안적으로, 또는 소프트웨어 구현에 더하여, 본 문서에 기술된 기술적 기능은 적어도 부분적으로는, 하나 이상의 하드웨어 논리 컴포넌트에 의해 수행될 수 있다. 예를 들어, 그리고 다른 구현을 배제하지 않고, 일 실시예는 필드 프로그램가능 게이트 어레이(Field-Programmable Gate Array: FPGA), 애플리케이션 특정 집적 회로(Application-Specific Integrated Circuit: ASIC), 애플리케이션 특정 표준 제품(Application-Specific Standard Product: ASSP), 시스템 온 칩 컴포넌트(System-on-a-Chip component: SOC), 복합 프로그램가능 논리 디바이스(Complex Programmable Logic Device: CPLD) 및 유사한 컴포넌트와 같은 하드웨어 논리 컴포넌트를 포함할 수 있다. 일 실시예의 컴포넌트는 예컨대 그것의 입력, 출력 및/또는 그것의 기술적 효과에 기반하여 상호작용하는 기능적 모듈로 그룹화될(grouped) 수 있다.

예시된 환경(100)에서, 하나 이상의 애플리케이션(122)과 더불어 코드(120) 베이스는 각자의 버전(126)을 가지는 어셈블리(124)(가령, DLL 파일 및 다른 라이브러리)를 포함한다. "DLL"은 "동적 링크 라이브러리"(dynamic-link library)("동적으로 로드되는 라이브러리"(dynamically loaded library)로도 알려짐)를 나타낸다. 어셈블리(124)는 다수의 벤더로부터의 다수의 애플리케이션(122)을 지원하기 위해 내부적으로 호환가능한 그룹으로서 릴리즈된 어셈블리의 세트인 프레임워크(142)의 일부일 수 있다. 프레임워크 어셈블리는 흔히 주어진 시스템(102)에서 구동되는 애플리케이션 중 전부는 아니더라도 대부분에 의해 사용되는 서비스를 제공하는 애플리케이션 런타임(application runtime)(144)의 일부이다.

컴파일러(130), 디버거(132), 바인더(134) 및 로더(136)와 같은 소프트웨어 개발 도구(128)는 프로세서(들)(110)에 의한 실행을 위한 코드(120)를 산출하고/하거나 변형함으로써 소프트웨어 개발을 돕는다. 도면에 도시되고/되거나 텍스트에서 논의되는 코드(120), 도구(128) 및 다른 아이템은 각각 하나 이상의 하드웨어 저장 매체(112) 내에 부분적으로 또는 전체적으로 상주하여, 이로써 모든 하드웨어 - 소프트웨어 협력적 동작에 내재된 "통상적인" (즉, 최소 공통 분모) 상호작용을 넘어서는 기술적 효과를 위해 해당 매체를 구성할 수 있다.

프로세서(110)(CPU, ALU, FPU, 및/또는 GPU), 메모리/저장 매체(112), 디스플레이(들)(140) 및 배터리(들)에 더하여, 운영 환경은 예를 들면 버스, 전력 공급부, 유선 및 무선 네트워크 인터페이스 카드, 그리고 가속기와 같은 다른 하드웨어(그것의 각자의 동작은 숙련자에게 이미 명백하지 않은 한 본 문서에서 기술됨)를 또한 포함할 수 있다. CPU는 중앙 처리 유닛(central processing unit)이고, ALU는 산술 및 논리 유닛(arithmetic and logic unit)이며, FPU는 부동 소수점 처리 유닛(floating point processing unit)이고, GPU는 그래픽 처리 유닛(graphical processing unit)이다.

주어진 운영 환경(100)은 개발자에게 컴파일러, 소스 코드 편집기, 프로파일러, 디버거 및 기타 등등과 같은 코디네이트된(coordinated) 소프트웨어 개발 도구(128)의 세트를 제공하는 통합 개발 환경(Integrated Development Environment: IDE)을 포함할 수 있다. 특히, 몇몇 실시예를 위한 적합한 운영 환경 중 몇몇은 프로그램 개발을 지원하도록 구성된 Microsoft® Visual Studio® 개발 환경(마이크로소프트 사의 표장)을 포함하거나 이를 생성하는 것을 돕는다. 몇몇 적합한 운영 환경은 Java® 환경(오라클 아메리카 사의 표장)을 포함하고, 몇몇은 C++ 또는 C#("C 샤프"(C-Sharp))와 같은 언어를 활용하는 환경을 포함하나, 본 문서 내의 교시는 매우 다양한 프로그래밍 언어, 프로그래밍 모델 및 프로그램은 물론 소프트웨어 개발 그 자체의 분야의 외부에서의 기술적 노력과 함께 적용가능하다.

하나 이상의 아이템이 도 1에서 요점 형태로 보여지니 그것이 반드시 예시된 운영 환경의 일부인 것은 아니나, 본 문서에서 논의된 바와 같은 운영 환경 내의 아이템과 상호동작할(interoperate) 수 있음을 강조한다. 어떤 도면에서도 또는 어떤 실시예에서도, 요점 형태로 되지 않은 아이템이 반드시 요구된다는 결론은 나오지 않는다.

시스템

도 2는 몇몇 실시예와의 사용에 적합한 아키텍처의 양상을 예시한다. 추가적인 콘텍스트로서, 애플리케이션(122)이 호출된 후 몇몇 환경(100)에서, 애플리케이션에 의해 사용되는 어셈블리(124)는 필요에 따라 하는 방식의(on an as-needed basis) 실행을 위해 메모리(112) 내에 로드된다. 이는 때때로 어셈블리의 "지연 로딩"(delay-loading) 또는 "느긋한 로딩"(lazy loading)으로 불린다. 실행 중에 어느 어셈블리가 실제로 필요한지는 애플리케이션 및 그것의 로드된 어셈블리의 실행 중에 애플리케이션 코드를 통해 어느 경로가 취해지는지에 부분적으로 달려 있다. 지연 로딩이 사용되는 경우, 필요하지 않은 어셈블리는 반드시 로드되는 것은 아니다.

실행 중에, 애플리케이션(122)은 어셈블리(124), 가령 foo.dll을 요청한다. 요청은 애플리케이션에 의해 직접 행해질 수 있거나, 그것은 다른 어셈블리 또는 런타임(144)과 같은, 그 애플리케이션을 대신하여 구동되는 코드에 의해 행해질 수 있다. 요청은 선조치적(proactive)일 수 있거나(가령, 애플리케이션은 실행 중에 이후에 지연을 방지하기 위해 어떤 어셈블리를 사전로드할(pre-load) 수 있음), 요청은 실행 중에 어셈블리를 참조하기 위해 시도가 행해지는 경우에 발생하는 예외(exception) 또는 다른 이벤트에 응답하여 행해질 수 있다. 많은 (그러나 전부는 아닌) 경우에, 어셈블리를 사용하기 위한 요청은 어셈블리의 특정한 버전, 가령 foo.dll 버전 2를 지정할 것이다. 이 논의에서, 어셈블리의 요청된 버전은 요청된 버전(requested_version)이라 불리고 참조 번호 202에 의해 표기된다.

어셈블리가 요청된 후, 바인더(134)는 어셈블리의 어느 버전이 로드될 것인지 판정하고, 이후 로더(126)는 어셈블리 코드가 실행될 수 있도록 그것을 메모리 내에 로드한다. 바인더는 어셈블리의 어느 버전(126, 204)을 사용할 것인지를 판정하는 것을 책임진다. 몇몇 환경에서, 바인더는 파일 시스템 또는 다른 스토리지(storage) 내에서 해당 버전을 위치파악하는 것을 또한 책임지나, 다른 환경에서는 로드할 파일을 위치파악하는 것은 로더의 책임이다. 로더(136)는 전형적으로는 메모리(112)를 배분하는 것, 어셈블리 코드를 메모리 내에 복사하는 것 및 복사된 코드의 메모리 주소에 기반하여 코드 내의 포인터를 조절하는 것을 책임진다. 바인더(134) 및 로더(136)는 본 문서에서 논의되지 않은 다른 책임을 가질 수도 있다.

몇몇 실시예에 대해, 한 가지 독자에게 흥미로운 점은 바인더가 애플리케이션을 위한 어셈블리 버전을 어떻게 그리고 언제 선택하느냐일 것이다. 언제냐에 대하여, 어셈블리 버전의 선택은 해당 어셈블리를 위한 애플리케이션의 "바인드 시간"(bind-time) 중에 행해진다. 어셈블리를 위한 바인드 시간은 어셈블리에 대한 요청이 행해지는 때에, 애플리케이션에 의해 또는 애플리케이션을 대신하여 구동되는 코드에 의해 시작한다. 어셈블리를 위한 바인드 시간은 어셈블리의 어느 버전을 사용할지를 바인더가 판정한 때에 종료한다.

어떻게 버전이 선택되느냐에 대하여, 바인딩은 여기에서 프레임워크 통합, 묵시적 오버라이드 및 바인딩 재지향으로 지칭되는 세 개의 주된 단계를 포함하는 것으로 본 문서에 기술된 바와 같이 향상될 수 있다. 그 단계들을 그런 순서로 나타난다. 그러나 몇몇 흥미로운 상황에서는, 어떠한 바인딩 재지향도 일어나지 않아서, 바인딩은 묵시적 오버라이드 단계가 뒤따르는 프레임워크 통합 단계만을 포함한다. 다른 흥미로운 상황에서, 바인딩은 묵시적 오버라이드 및 바인딩 재지향 단계만을 포함한다. 또 다른 흥미로운 상황에서는, 단지 묵시적 오버라이드 단계가 일어난다.

프레임워크 통합 단계는 때때로 단순히 "통합"으로 불린다. 묵시적 오버라이드 단계는 때때로 "앱 로컬" 또는 "앱로컬" 단계로 불린다. 바인딩 재지향 단계는 때때로 앱 구성(app configuration) 또는 발행자 정책(publisher policy)과 같은, 바인딩 재지향을 위한 특정한 메커니즘을 사용하는 것을 참조하게 된다.

향상된 바인더(206)를 포함하는 몇몇 실시예에서, 프레임워크 통합 절차 또는 다른 통합 코드(208)는 통합 버전(unification_version)(210)과 대비해 어셈블리의 요청된 버전(202)을 확인한다. 어셈블리를 위한 통합 버전은 애플리케이션의 바인드 시간 전에 프레임워크(142) 내에 지정되었다. 만약 요청된 버전이 통합 버전 이하인 경우, 프레임워크 통합 코드(208)는 통합 버전을 반환한다(return). 즉, 향상된 바인딩의 프레임워크 통합 단계는 그것의 결과(212)로서 통합 버전을 산출한다. 만약 요청된 버전이 통합 버전보다 큰 경우, 프레임워크 통합은 실패한다. 만약 프레임워크 통합이 실패하는 경우 (a) (몇몇 구현에서는) 바인딩이 실패하거나, 아니면 (b) (다른 구현에서는) 바인딩이 묵시적 오버라이드 단계로 넘어간다.

몇몇 실시예에서, 프레임워크(142)는 관리되는 런타임(144)에 커플링된 어셈블리(124)의 모음을 포함한다. 프레임워크의 통합 절차는 통합 버전을 위해 보수적인 값(conservative value)을 사용한다. 즉, 어셈블리의 통합 버전은 프레임워크 내의 다른 모든 어셈블리와 적절하게 작동하는 것으로 알려져 있다. 다시 말해, 통합에 의해 지정된 어셈블리 버전들은 그것들이 서로와 올바르게 상호동작하게끔 하는 데에 도움이 되도록 서로에 대해 시험되었다.

몇몇 실시예에서, 만약 요청된 어셈블리 버전이 통합 버전 이하인 주요(major) 부분 및 부차적(minor) 부분을 가지는 경우, 통합 결과는 통합 버전일 것이다. 예를 들어, 만약 4.0.0.0으로 통합되는 경우, 2.0.0.0 또는 4.0.1.0은 4.0.0.0으로 재목표화될 것이나, 4.5.0.0 및 5.0.0.0은 그렇지 않을 것이다. 주요 및 부차적 부분은 상이한 벤더들에 의해 상이하게 정의될 수 있으나, 일반적으로 첫 번째(제일 왼쪽의) 소수점의 왼쪽의 숫자는 주요 부분이고 부차적 부분은 적어도 그런 첫 번째 소수점의 우측의 숫자를 포함한다. 부차적 부분의 오른쪽의 다른 숫자(만약 있다면)는 예컨대 빌드(build) 또는 개정(revision) 번호일 수 있다.

몇몇 실시예에서, 묵시적 오버라이드 단계를 구현하는 코드(238)는 묵시적 버전(216) 값을 위해 하나 이상의 어셈블리 특정 위치(214)를 확인한다. 예컨대, 어셈블리 foo.dll에 대해, 묵시적 오버라이드 단계는, 가령 애플리케이션의 디렉토리 내의 foo_versions 파일과 같은, 지정된 위치(214) 내에 있는, 파일 이름 및/또는 디렉토리 경로의 리스트에 의해 또는 관례에 의해 지정된 서브디렉토리 내의 또는 애플리케이션의 디렉토리 내의 foo.dll 파일을 열 수 있다. 몇몇 실시예에서, 묵시적 오버라이드 단계는 어느 위치가 확인되었는지 및 어느 순서로 그랬는지에 관하여 로더 조사 단계(loader probing phase)를 병행한다. 만약 묵시적 버전 값이 발견되고 통합 버전보다 더 큰 경우, 향상된 바인더(206)는 어셈블리의 묵시적 버전을 선택할 것이다. 그렇지 않은 경우, 향상된 바인더(206)는 통합 버전을 오버라이드하기 위해 묵시적 버전 값을 사용하지 않는다.

몇몇 실시예에서, 바인딩 재지향 단계를 구현하는 코드(236)는 앱 구성 파일(218) 또는 발행자 정책(220) 내의 어셈블리 바인딩 재지향 명령(240)을 찾는다. 바인딩 재지향 명령은 다음 형태를 가진다: 만약 현재 선택된 버전이 X 내지 Y 범위 내에 있는 경우 대신에 버전 Z를 사용한다. 애플리케이션의 앱 구성 파일 내의 어셈블리의 바인딩 재지향 명령은 어셈블리가 해당 애플리케이션에 바인드되고 있는 경우 해당 어셈블리에 적용된다. 발행자 정책 내의 어셈블리의 바인딩 재지향 명령은 어셈블리가 발행자 정책의 범주 (즉, 주어진 머신) 내의 임의의 애플리케이션에 바인드되고 있는 경우 해당 어셈블리에 적용된다. 몇몇 실시예에서, 바인딩 재지향은 로드할 어셈블리의 버전을 낮출 수 있으나(가령, 버전 2.0.0.0을 1.0.0.0으로 재지향), 통합 및 묵시적 오버라이드는 버전 번호를 낮출 수 없다.

묵시적 오버라이드 단계는 프레임 통합 단계와 상이하다. 첫째, 묵시적 오버라이드 단계의 결과는 부분적으로 프레임워크 통합 단계의 결과에 달려 있는데, 묵시적 버전이 통합 버전과 비교되기 때문이다. 둘째, 묵시적 버전은 개별 어셈블리로써 업데이트되는 반면, 통합 버전은 프레임워크로써 (즉, 어셈블리의 모음으로써) 업데이트된다.

통합에 관하여, 숙련자는 프레임워크(142)의 일부로서 통합의 대상인 어셈블리를 로드하는 것을 수반하는 경우 및 프레임워크의 일부가 아니기 때문에 통합되지 않은 어셈블리를 로드하는 것을 수반하는 경우 양자 모두에서 앱 로컬 바인딩 단계가 유용함에 유의할 수 있다. 통합이 행해지지 않은 경우라도, 앱 로컬 바인딩은 그것이 애플리케이션(122)에 의해 사용되는 상이한 모듈들 전부로 하여금 운영 콘텍스트가 애플리케이션 모듈당 런타임에서 오직 하나의 버전을 로드하는 경우에 어셈블리의 상이한 버전들을 참조하게 하기 때문에 가치 있다. 예를 들어, msbuild는 최신의 종속체(dependency)를 로컬로(locally) 놓을 것이다. 앱 로컬은 또한 구성 XML 명령을 작성하는(authoring) 더욱 복잡한 단계에 의해서가 아니라, 단지 파일을 복사, 기입 또는 삭제하는 것에 의해 사용자가 버전을 지정하는 것을 허용한다.

묵시적 오버라이드 단계는 또한 바인딩 재지향 단계와 상이하다. 첫째, 묵시적 버전은 바인딩 재지향 명령에 의해 오버라이드될 수 있어서, 묵시적 단계의 추가는 바인딩 재지향 단계의 기존 기능을 보존하면서 새로운 기능을 추가한다. 둘째, 묵시적 버전은 명시적 범위를 상술하지 않는데, 다음을 상술하는 바인딩 재지향의 형태와는 대조적이다: 만약 현재 선택된 버전이 X 내지 Y 범위 내에 있는 경우 대신에 버전 Z를 사용한다. 바인딩 재지향으로부터 묵시적 오버라이드 단계를 r구별하는 두 가지 추가 사항은: (1) 버전이 로컬 어셈블리에 의해 묵시적으로 지정되어서, 모듈 벤더는 애플리케이션의 구성 파일에 대한 액세스를 필요로 하지 않고 그들이 목표로 삼고자 바라는 어셈블리를 포함할 수 있다는 것 및 (2) 버전이 로컬 어셈블리에 의해 묵시적으로 지정되어서, 개발자는 복잡하고 오류 발생이 쉬울 수 있는 프로세스인 바인딩 재지향의 XML 선언을 쓸 필요가 없다는 것이다.

도 1 및 도 2에 의해 예시된 몇몇 실시예는 적어도 부분적으로는 이하의 의사코드(pseudocode) 내에 기술된 바와 같이 동작한다. 숙련자는 명료성을 위해, 어떤 바인더 복잡성이 이 의사코드에서 생략됨을 이해할 것이다. 예를 들어, 바인딩 재지향은 만약 출력이 통합된 값보다 더 클 경우 사전통합(pre-unification) 버전에 작용할 수도 있다.

(향상된 바인더(206)일 수 있는) 바인더(134)가 어느 어셈블리 버전이 로드되어야 하는지를 판정한 후, 로더(136)는 어셈블리의 해당 버전을 포함하는 파일을 위치파악한다. 로더(136)는, 가령 로더 캐시(loader cache)를 확인함으로써, 주어진 프로세스(해당 용어의 컴퓨터 과학 의미에서)를 위해 어셈블리의 해당 버전이 이전에 로드되었는지를 판정하는 향상된 로더(222)일 수 있다. 향상된 로더(222)는 보안 결함에 취약한 것으로 알려진 어셈블리의 리스트(224)를 확인한다. 만약 이 어셈블리 버전이 취약한 것으로 알려진 경우, 로더는 로드 실패(load failure)를 강제한다. 최적화로서, 몇몇 실시예는 단지 각 프로세스(해당 용어의 컴퓨터 과학 의미에서) 상의 첫 번째 로드 중에 리스트(224)를 확인하고, 리스트(224) 검색(lookup)의 결과를 캐시한다(cache). 몇몇 향상된 로더는 대역외 메타데이터 엔트리(228)("브레드크럼")의 모음(226)을 확인하여 이것이 대역외 어셈블리인지 판정한다. 만약 이 어셈블리가 대역외 어셈블리인 경우, 로더는 어셈블리 버전이 취약한지를 확인한다. 그렇지 않으면, 만약 어셈블리 버전이 이전에 로드되었고 대역외가 아닌 경우, 또는 만약 어셈블리 버전이 이전에 로드되지 않았으나 취약하지 않은 경우, 어셈블리의 로딩은 허용된다.

몇몇 실시예에서, 대역외 메타데이터 엔트리(228)의 모음(226)은 (a) 어셈블리가 대역외 서비싱 속성(230)을 가지는 경우, (b) 서비싱 라이브러리(232)가 적용되는 경우 및/또는 (c) 어셈블리가 대역외 어셈블리의 리스트(234) 상에서 발견되는 경우(이 리스트는 가령 프레임워크 설정(Framework Setup)에 의해 또는 다른 프레임워크(142) 초기화 절차에 의해 유지됨)에 만들어지는 엔트리를 포함한다. 그러므로, 몇몇 실시예에서, 몇몇 브레드크럼은 이하의 단락 내에 기술된 바와 같이, 로더에 의해 기입되고 업데이트 서비스에 의해 판독되는 반면, 다른 것은 대역외 어셈블리의 리스트(234)의 일부이다.

몇몇 실시예에서, 주어진 머신 또는 머신의 주어진 세트 상에 라이브러리의 취약한 버전이 로드된 적이 있는지를 판정하기 위해, 대역외 메타데이터 엔트리(228)는 Microsoft® Windows® Update 서비스 또는 Microsoft® Windows Server® Update 서비스(마이크로소프트 사의 표장)와 같은 업데이트 서비스에 의해 판독된다. 즉, 브레드크럼(228)은 머신과 같은 주어진 운영 콘텍스트 내의 DLL 파일 또는 다른 라이브러리의 버전의 존재의 지시자(indicator)이다.

몇몇 실시예에서, 향상된 로더(222)는 적어도 부분적으로는 아래의 의사코드에 따라 동작한다. 이 의사코드에서, Is_OOB_assembly는 대역외 서비싱 속성(230)을 표현하고, BreadcrumbNotExist는 로드되는 어셈블리 버전을 위한 대역외 메타데이터 엔트리(228)가 발견되었는지를 나타내며, Is_Vulnerable은 해당 어셈블리 버전이 보안 결함에 취약한 것으로 알려졌는지를 나타낸다:

전부는 아니더라도 대부분의 실시예에서, 어셈블리(124)가 애플리케이션의 주어진 모듈을 위해 애플리케이션의 일생(lifetime)에서 오직 한 번 로드됨이 이해될 것이다. 일단 로드가 발생하면, 로더 및/또는 바인더는 해당 상태를 보존하여, 어셈블리가 이전에 로드되었음을 그것들이 효과적으로 알게 한다. 그러므로, 몇몇 실시예에서, 만약 어셈블리 버전을 로드하려는 시도가 이 시스템 상에서 어셈블리의 이 버전에 대한 첫 번째 로드 시도가 아닌 경우, 로더는 어셈블리 메타데이터 엔트리의 모음을 확인한다. 어셈블리는 그것을 대역외 어셈블리로서 식별하는 메타데이터(속성(230))를 지닌다. 브레드크럼(228) 엔트리는 이 어셈블리의 로드를 나타내기 위해 스토리지(112)에 기입된다.

도 1 및 도 2를 참조하면, 몇몇 실시예는 본 문서에 기술된 기술적 효과를 제공하도록 회로망, 펌웨어 및/또는 소프트웨어에 의해 구성된 논리적 프로세서(110) 및 메모리 매체(112)를 컴퓨터 시스템(102)에 제공한다.

몇몇 실시예에서 인간 사용자 I/O 디바이스(스크린, 키보드, 마우스, 태블릿, 마이크, 스피커, 모션 센서(motion sensor) 등등)와 같은 주변장치(106)가 하나 이상의 프로세서(110) 및 메모리와 통신가능하게 존재할 것이다. 그러나, 일 실시예는 어떠한 인간 사용자(104)도 그 실시예와 직접 상호작용하지 않도록 기술적 시스템 내에 깊숙이 임베드될 수도 있다. 소프트웨어 프로세스가 사용자(104)일 수 있다.

몇몇 실시예에서, 시스템은 네트워크에 의해 연결된 다수의 컴퓨터를 포함한다. 네트워킹 인터페이스 장비(networking interface equipment)는 주어진 컴퓨터 시스템 내에 존재할 수 있는, 예컨대 패킷 교환 네트워크 인터페이스 카드(packet-switched network interface card), 무선 송수신기(wireless transceiver), 또는 전화 네트워크 인터페이스(telephone network interface)와 같은 아이템을 사용하여, 네트워크(108)로의 액세스를 제공할 수 있다. 그러나, 일 실시예는 직접적 메모리 액세스(direct memory access), 탈착가능한 비휘발성 매체, 또는 다른 정보 저장색출(storage-retrieve) 및/또는 송신 접근법을 통해 기술적 데이터 및/또는 기술적 명령어를 통신할 수도 있거나, 컴퓨터 시스템 내의 일 실시예는 다른 컴퓨터 시스템과 통신하지 않고 동작할 수 있다.

몇몇 실시예는 "클라우드" 컴퓨팅 환경 및/또는 "클라우드" 저장 환경(컴퓨팅 서비스가 소유되지는 않지만 주문식으로(on demand) 제공됨)에서 동작한다. 예를 들어, 어셈블리(124)는 네트워킹된 클라우드 내의 다수의 디바이스/시스템(102) 상에 있을 수 있고, 어셈블리를 요청하는 애플리케이션(122)은 클라우드 내의 또 다른 디바이스 상에 저장될 수 있고, 향상된 바인더(206) 및/또는 향상된 로더(222)는 또 다른 클라우드 디바이스(들)/시스템(들)(102) 상의 메모리(112)를 구성할 수 있다.

프로세스

도 3 내지 도 5는 몇몇 프로세스 실시예를 예시하는데, 이들은 흐름도(300) 내에 집합적으로 표현되고, 각각 도 4 및 도 5의 흐름도(400 및 500) 내에 추가로 상술된다. 그 도면들 내에 도시되거나 그렇지 않으면 개시된 기술적 프로세스는 몇몇 실시예에서 자동으로, 가령 스크립트의 제어 하의 또는 그렇지 않으면 동시기의 미가공 사용자 입력(contemporaneous live user input)을 거의 또는 전혀 요구하지 않는 향상된 바인더(206) 및 향상된 로더(222)에 의해 수행될 수 있다. 달리 표시되지 않는 한 프로세스는 부분적으로는 자동으로 그리고 부분적으로는 수동으로 수행될 수도 있다. 어떤 주어진 실시예에서, 프로세스의 0개 이상의 예시된 단계는 아마도 상이한 파라미터 또는 데이터(이에 대해 동작하는 것임)와 함께 반복될 수 있다. 일 실시예 내의 단계들은 도 3에 펼쳐진 위에서 아래로의 순서와는 상이한 순서로 행해질 수도 있다. 단계들은 연속적으로, 부분적으로는 중첩하는 방식으로, 또는 온전히 병렬로 수행될 수 있다. 프로세스 중에 수행되는 단계들을 나타내기 위해 흐름도(300)가 지나가는 순서는 프로세스의 하나의 수행에서 프로세스의 다른 수행까지 다양할 수 있다. 흐름도 횡단 순서는 또한 하나의 프로세스 실시예에서 다른 프로세스 실시예까지 다양할 수 있다. 수행되는 프로세스가 운영가능하고 적어도 하나의 청구항에 따른다면, 단계들은 생략되거나, 조합되거나, 재명명되거나, 재그룹화되거나 그렇지 않으면 예시된 흐름에서 벗어날 수도 있다.

기술의 양상을 예시하는 데에 도움이 되도록 예들이 본 문서에 제공되나, 이 문헌 내에 주어진 예들은 모든 가능한 실시예를 기술하지는 않는다. 실시예는 본 문서에서 제공된 특정 구현, 배열, 디스플레이, 특징, 접근법 또는 시나리오에 한정되지 않는다. 주어진 실시예는 예를 들면 추가적인 또는 상이한 기술적 특징, 메커니즘 및/또는 데이터 구조를 포함할 수 있고, 그렇지 않으면 본 문서에 제공된 예에서 벗어날 수 있다.

도 1 및 도 2에 예시된 시스템 실시예는 도 3 내지 도 5에 예시된 프로세스 실시예의 적어도 몇몇 양상과 부합하는(consistent) 방식으로 동작한다. 예를 들어, 몇몇 실시예는 적어도 하나의 어셈블리 특정 위치 내의 묵시적 버전을 탐색하여 찾아내고(302), 묵시적 버전이 발견된 후 묵시적 버전을 어떤 다른 버전과 비교하며(304), 묵시적 버전이 그 다른 버전보다 더 큰 경우 묵시적 버전으로써 그 다른 버전을 조건부로 오버라이드한다(306).

몇몇 실시예에서, 향상된 바인더(206)는 묵시적 오버라이드 부분 내에 들어가는 프레임워크 통합 부분을 포함한다. 바인더(206)는, 가령 프레임워크의 벤더에 의해 유지되는 리스트를 확인함으로써, 어셈블리가 프레임워크(142) 내에 있는지를 확인한다. 프레임워크 통합을 수행하기(308) 위하여, 몇몇 실시예는 요청된 버전을 통합 버전과 비교하고(304) 통합 버전이 요청된 버전보다 더 크고 어셈블리가 프레임워크 내에 있는 경우 요청된 버전을 통합 버전으로써 조건부로 오버라이드한다(306). 향상된 바인더는 통합 단계 결과(212)를 획득하기(336) 위해 프레임워크 통합 코드를 호출하고, 이후에는 묵시적 오버라이드 단계 결과(212)를 획득하기 위해 해당 통합 단계 결과로써 묵시적 오버라이드 코드를 호출한다. 몇몇 실시예에서, 묵시적 버전은 개별 어셈블리로써 업데이트되는(328) 반면, 통합 버전은 어셈블리의 프레임워크(142)로써 업데이트된다(330).

몇몇 실시예에서, 바인더(206)는 바인딩 재지향 부분을 포함하는데, 이는 묵시적 오버라이드 부분에 의해 들어가게 된다. 바인딩 재지향이 수행되어(310), 묵시적 오버라이드 결과(들)(212)를 수정한다. 바인딩 재지향 코드는 바인딩 재지향 명령(240)에 응답하여 묵시적 버전을 오버라이드(306)하는 코드를 포함하는데, 향상된 바인더(206)는 묵시적 오버라이드 코드를 호출한 후 바인딩 재지향 코드를 호출한다.

찾아내기(302), 비교하기(304), 오버라이드하기(206), 통합 수행하기(308), 재지향 수행하기(310), 그리고 지정된 작동(act) 또는 본 문서에 기술된 작동의 세트를 수행하는(312) 다른 단계는, 기술된 컴퓨팅 시스템 기능을 제공하도록 특별히 설계된 소프트웨어를 실행함(314)으로써 몇몇 실시예에서 공동으로 또는 각기 수행될 수 있다. 그러한 소프트웨어의 예는, 가령 향상된 바인더(206) 및 그것의 구성적 코드(208, 236, 238), 향상된 로더(222), 그리고 본 문서에서 제공된 의사코드를 구현하는 코드를 포함한다.

몇몇 실시예에서, 대역외 메타데이터 엔트리(228)(브레드크럼으로도 알려짐)는 어셈블리(124)의 취약한 버전이 주어진 운영 콘텍스트 내에 로드되었던 적이 있는지를 판정하기 위해 업데이트 서비스에 의해 사용된다. 몇몇 실시예는 어셈블리가 로드되는 경우에 어셈블리를 대역외 어셈블리로서 식별하는 브레드크럼을 배치한다(322). 브레드크럼 배치는 예컨대 어셈블리를 알려진 대역외 어셈블리의 리스트(234)에 매칭시키는 것(316)에 기반하거나, 어셈블리의 대역외 서비싱 속성(230)을 위치시키는 것(318)에 기반할 수 있다. 몇몇 경우에, 서비싱 라이브러리(232)는 서비싱 라이브러리가 적용되는(320) 경우에 브레드크럼을 배치한다(322). 몇몇 실시예는 어셈블리가 로드되는 경우에 로더에 의해 업데이트되는 상태 정보를 사용하여, 어셈블리가 주어진 운영 콘텍스트 내에 이전에 적어도 한 번 로드되었는지를 확인한다(324).

절차적 관점에서, 또는 (지적된 바와 같이 전파되는 신호 그 자체는 아닌) 구성된 저장 매체의 관점에서, 몇몇 실시예는 요청된 어셈블리(참조된(402) 어셈블리라고도 알려짐)의 어느 버전이 애플리케이션의 실행을 지원하도록 로딩을 위한 로더에 식별될지(406)를 판정하기(332) 위한 기술적 프로세스의 계산적 수행을 야기한다. 몇몇에서, 프로세스는 묵시적 버전에 대해 확인하는 것(404)을, 그리고 몇몇 경우에는 어셈블리 특정 위치(214) 내의 묵시적 버전을 찾아내는 것(302), 묵시적 버전이 발견된 후 묵시적 버전을 다른 버전과 비교하는 것(304), 그리고 묵시적 버전이 그 다른 버전보다 더 큰 경우 묵시적 버전으로써 그 다른 버전을 오버라이드하는 것(306)을 포함한다.

몇몇 실시예에서, 프로세스는 요청된 어셈블리의 프레임워크 통합을 수행하는 것(308)을 더 포함하고, 프레임워크 통합은 묵시적 버전과 비교되는 다른 버전을 산출한다. 몇몇에서, 프로세스는 애플리케이션 바인딩 재지향, 발행자 정책(220), 머신 바인딩 재지향 및/또는 다른 바인딩 재지향 명령(240)을 위해 애플리케이션 구성 파일 또는 머신 구성 파일 또는 전역 어셈블리 캐시(또는 다른 위치)를 확인하는 것(338)을, 그리고 그러한 명령이 발견되는 경우에는 요청된 어셈블리의 바인딩 재지향을 수행하는 것(310)을 더 포함한다. 본 문서에서 사용되는 바와 같이, "바인딩 재지향 명령"(binding redirect command)은 어셈블리 바인딩을 지정하는 애플리케이션 구성, 머신 구성, 발행자 정책 또는 다른 형태 내의 문장(statement), 정책(policy) 또는 다른 명령을 의미한다. 바인딩 재지향은 묵시적 버전을 오버라이드한다. 몇몇 실시예는 프레임워크 통합, 묵시적 오버라이드 및 바인딩 재지향을 포함한다.

몇몇 실시예는 만약 엔트리가 아직 존재하지(508) 않는 경우 대역외 메타데이터 엔트리를 배치하는(332) 하나 이상의 단계를 수행한다. 엔트리 배치(332)는 데이터를 생성, 복사 또는 업데이트하는 것 및 대역외 메타데이터 모음(226) 내에 데이터를 두는 것을 포함한다. 몇몇 실시예에서, 어셈블리 버전을 위한 대역외 메타데이터 엔트리는 어셈블리가 보안 결함에 취약한 것으로 블랙리스트에 올려진 경우에도 배치된다(322). 대역외 메타데이터 엔트리 배치는 어셈블리가 대역외 어셈블리라는 인식(502)에 응답하여 일어난다. 그런 인식은 (a) 어셈블리를 알려진 대역외 어셈블리의 리스트와 적어도 부분적으로 매칭시키는 것(316), (b) 어셈블리 내의 대역외 서비싱 속성을 위치파악하는 것(318) 및/또는 (c) 서비스 패키지를 컴퓨터 시스템에 적용하는 것(320)과 같은 다양한 방식으로 완수될 수 있다.

몇몇 실시예에서, 어셈블리가 시스템(102) 상에 이전에 로드되지 않았음을 확인한(324) 후, 로더는 어셈블리가 취약한지 판정하기(326) 위해 취약한 어셈블리 아이덴티티의 블록리스트를 살펴볼 것이다. 만약 로드된 어셈블리가 블록리스트 내의 엔트리와 매칭되는 경우 그 로드는 강제로 실패로 될(504) 것이고, 만약 어떠한 매치(match)도 발견되지 않으면 로드는 허용될(506) 것이다.

몇몇 실시예는 컴퓨팅 시스템이 컴퓨팅 시스템 내의 애플리케이션의 실행을 지원하도록 로딩을 위해 로더에 식별된 요청된 어셈블리의 버전을 로드할지를 자동으로 판정하는 기술적 프로세스를 제공한다. 프로세스는 컴퓨팅 시스템 내의 대역외 메타데이터 모음(226)을 위치파악하고, (a) 요청된 어셈블리가 알려진 대역외 어셈블리의 리스트 내의 엔트리와 매칭됨(316), (b) 요청된 어셈블리가 대역외 서비싱 속성을 포함함(318)이라는 대역외 어셈블리 조건 중 적어도 하나가 만족됨을 판정하며, 대역외 어셈블리 조건 중 적어도 하나가 만족됨을 판정하는 것에 응답하여 컴퓨터 시스템 상의 대역외 메타데이터 모음 내에 요청된 어셈블리를 위한 엔트리를 배치하는(322), 컴퓨팅 시스템 내의 소프트웨어 명령어를 실행하는 계산적 단계를 포함한다.

몇몇 실시예에서, 기술적은 요청된 어셈블리가 보안 결함에 취약함을 판정하는 것(326) 및 해당 판정에 응답하여 요청된 어셈블리를 로드하는 데에 실패하는 것을 더 포함한다. 몇몇에서, 프로세스는 요청된 어셈블리가 보안 결함에 취약한 것으로 알려지지 않았음을 판정하고(326) 해당 판정에 응답하여 로더가 요청된 어셈블리를 로드하도록 허용한다(506). 몇몇 실시예는 대역외 메타데이터 모음 내에서 요청된 어셈블리를 위한 엔트리를 판독함으로써 요청된 어셈블리가 대역외 어셈블리임을 판정한다(502).

(전부는 아니나) 몇몇 실시예는 대역외 메타데이터 모음(226)의 사용을 앱 로컬 통합의 사용과 조합한다. 이에 따라, 몇몇 실시예에서 앞서 기술된 대역외 메타데이터 모음 기술적 프로세스 중 하나는 컴퓨팅 시스템 내의 소프트웨어 명령어(어셈블리 특정 위치 내의 묵시적 버전을 찾아냄)를 실행하는 것 및 컴퓨팅 시스템 내의 소프트웨어 명령어(묵시적 버전이 발견된 후 묵시적 버전을 다른 버전과 비교함)를 실행하는 것과 같은 앱 로컬 통합 단계를 또한 포함한다.

구성된 매체

몇몇 실시예는 구성된 컴퓨터 판독가능 저장 매체(112)를 포함한다. 매체(112)는 특히 (순전한 전파되는 신호와 대조되는) 컴퓨터 판독가능 매체를 포함하여, 디스크(자기, 광학, 또는 그밖의 것), RAM, EEPROMS 또는 다른 ROM, 그리고/또는 다른 구성가능한 메모리를 포함할 수 있다. 구성된 것인 저장 매체는 특히 탈착가능 저장 매체(114), 이를테면 CD, DVD 또는 플래시 메모리(flash memory)와 같은 것일 수 있다. 구성된 매체를 형성하기 위해, 탈착가능 매체(114) 및/또는 네트워크 연결과 같은 다른 소스로부터 판독되는 데이터(118) 및 명령어(116)의 형태로 된, 향상된 바인더(206), 묵시적 오버라이드 코드(238), 향상된 로더(222), 메타데이터 엔트리(228)의 모음(226), 대역외 서비싱 속성(230), 그리고 어셈블리 특정 위치(214)의 리스트와 같은 아이템을 사용하는 일 실시예로 범용 메모리(탈착가능하거나 그렇지 않을 수 있고, 휘발성이거나 그렇지 않을 수 있음)가 구성될 수 있다. 구성된 매체(112)는 컴퓨터 시스템으로 하여금 본 문서에서 개시된 바인딩 및 로딩을 위한 기술적 프로세스 단계를 수행하게 하는 것이 가능하다. 그러므로 도 1 내지 도 5는 시스템 및 프로세스 실시예뿐만 아니라 구성된 저장 매체 실시예 및 프로세스 실시예를 보여주는 데에 도움이 된다. 특히, 도 3 내지 도 5에 예시되거나 그렇지 않으면 본 문서에서 교시된 프로세스 단계 중 임의의 것은 구성된 매체 실시예를 형성하도록 저장 매체를 구성하는 데에 도움이 되기 위해 사용될 수 있다.

추가적인 예

추가적인 세부사항 및 설계 고려사항이 아래에서 제공된다. 본 문서 내의 다른 예도 그러하겠지만, 기술된 특징은 주어진 실시예에서 개별적으로 및/또는 조합하여 사용되거나, 전혀 사용되지 않을 수 있다.

구현 세부사항은 특정 API 및 특정 샘플 프로그램과 같은 특정 코드에 관한 것일 수 있고, 그래서 모든 실시예에서 나타날 필요는 없음을 숙련자는 이해할 것이다. 세부사항을 논의하는 데에서 사용되는 프로그램 식별자 및 몇몇 다른 용어는 구현 특정적이고 그래서 모든 실시예에 관한 것일 필요는 없음을 숙련자는 또한 이해할 것이다. 그래도, 비록 여기서는 그것들이 존재할 것이 반드시 요구되는 것은 아니지만, 이들 세부사항이 제공되는데 그것들이 콘텍스트를 제공하는 것에 의해 몇몇 독자를 도울 수 있고/있거나 본 문서에서 논의된 기술의 많은 가능한 구현 중 약간을 예시할 수 있기 때문이다.

이하의 논의는 앱 로컬 통합(App-Local Unification: ALU) 문서로부터 도출된다. ALU는 마이크로소프트 사에 의해 원형이 만들어진(prototyped) 소프트웨어를 명기한다. ALU 프로그램 및/또는 문서의 양상은 본 문서에 기술된 실시예의 양상과 부합하거나 그렇지 않으면 이를 보여준다. 그러나, ALU 문서 및/또는 구현 선택은 반드시 그러한 실시예의 범주를 제한하는 것은 아니고, 마찬가지로 ALU 및/또는 그것의 문서는 그러한 실시예의 범주의 외부에 있는 특징을 포함할 가능성도 상당함이 이해될 것이다. 아래의 논의는 부분적으로는 반드시 통상의 기술자인 것은 아닌 독자에 대한 지원으로서 제공되고, 그래서 아래에서의 설명이 본 개시를 지원할 것이 엄격히 요구되지는 않는 세부사항을 포함하고/하거나 생략할 수 있음이 또한 이해될 것이다.

Dot Net™ 프레임워크(.Net™ 프레임워크로도 알려짐, 마이크로소프트 사의 표장임)는 개발자가 애플리케이션을 빌드할(build) 수 있는 안정적이고 안전한 플랫폼을 제공한다. 프레임워크의 현재 모델에서는 라이브러리가 중앙식으로 설치되고 머신 범위로 공유된다. 그러나 이 중앙화(centralization)는 몇몇 난제를 제기한다. 개별 프레임워크 컴포넌트들은 그것들의 기능을 끌어내기 위해서 중앙식 발송 매개체(centralized shipping vehicle)를 기다리는데, 이는 그렇지 않다면 어떤 컴포넌트가 혁신할(innovate) 속도(rate)를 저해할 수 있다. 프레임워크 릴리즈의 대기(latency)의 결과로서, 프레임워크 컴포넌트는 또한 원하는 만큼 빨리 고객 피드백(customer feedback)에 반응하지 못하게 된다. 결국, 프레임워크의 중앙식 성질 때문에, 단일 업데이트가 머신 범위로 애플리케이션들에 영향을 줄 것인데, 이는 차질을 초래할 수 있다.

본 문서에 기술된 몇몇 실시예는 기존의 중앙의 공유된 위치 외에도, 버전 선행(version precedence)에 기반하여 애플리케이션 로컬 위치로부터 라이브러리를 로드하는 것을 허용하도록, 라이브러리를 로드하기 위해 프레임워크에 의해 사용되는 메커니즘을 바꾼다. 이 변경은 프레임워크 라이브러리로 하여금 그것 자신의 진행속도로 독립적인 컴포넌트로서 발송되게 하고 고객 피드백에 대한 그것의 반응을 빠르게 하는 데에 도움이 된다.

몇몇 실시예에서, 이들 라이브러리를 위한 배포 메커니즘은 NuGet 패키지 관리기를 포함하는데, 이는 애플리케이션 로컬 경로 내에 놓여진 DLL 파일의 zip 아카이브(archive)이다. 라이브러리의 이 로컬화(localization)는 프레임워크의 중앙식 서비싱(centralized servicing)의 종래의 접근법이 붕괴하게 할 것으로 보일 수 있다. 그러나, 몇몇 실시예는 업데이트 서비스가 애플리케이션에 대해 로컬로 발송되는 프레임워크 라이브러리를 신뢰성 있게 검출하고 업데이트하는 용이한 방식을 허용한다. 몇몇 실시예는 또한 서비스되지 않는(unserviced) 라이브러리가 로드되는 것을 방지하고 시스템으로부터 유휴 비트(dead bit)들을 청소하는(scavenge) 메커니즘을 제공한다. 몇몇 실시예에서는, 취약한 DLL을 라이브러리의 서비스되는 버전(serviced version)으로 앞으로 돌리기 위해 발행자 정책(220)을 설치하되, 기존의 비치(deployment) 기술을 사용하여, 기존의 업데이트 메커니즘을 통하여 수정본(fix)들이 발송될 것이다.

배경으로서, Microsoft® Update 및 Windows® Update 서비스(마이크로소프트 사의 표장)는 중앙식으로 설치되는 컴포넌트를 서비스하기(servicing) 위한 중앙식 메커니즘을 제공한다. 그러나, 그것들은 비중앙식(non-centralized) 컴포넌트에 대해 여기서 기술된 실시예와 같이 작동하지 않는데 이들 업데이트 서비스가 시스템에 대한 스캔을 행할 수 없기(서비싱을 행하기 위해서 특정한 머신 범위의 알려진 위치를 볼 수 있을 뿐임) 때문이다.

추가적인 배경으로서, 몇몇 Microsoft® SQL Server® Compact(마이크로소프트 사의 표장) 환경에서는 상이한 접근법이 취해진다. 그것들은 몇몇 로컬 라이브러리를 추적하나, 그것들이 대역외 방식으로 업데이트되게 허용하기 위해서 제품의 일부인 라이브러리의 알려진 세트를 목록화하는 것(cataloging)에 그것들이 의존한다는 점에서 한정된다. 그것들은 또한 추적 코드(tracking code)가 애플리케이션 내에 남아 있다는 점에서 한정된다.

추가적인 배경으로서, Windows® Graphics Device Interface(GDI+, 마이크로소프트 사의 표장) 보안 이슈는 몇몇 애플리케이션 로컬 고려사항을 다루었으나, 전체 시스템의 스캔에 기반하여 그렇게 하였는데, 이는 매우 고비용이다. 다른 배경 예는 Microsoft® C Runtime(CRT), 즉 Visual C++® 런타임이다(마이크로소프트 사의 표장). 이 런타임은 애플리케이션 내에 로컬 링크되게 또는 중앙식으로 로드하는 것을 허용한다(중앙식으로 서비스되는 유일한 모드는 중앙식으로 로드되는 모드임).

본 문서에 기술된 몇몇 실시예는 프레임워크 라이브러리가 애플리케이션 내에 발송되게 하도록 바인더를 변경하고 애플리케이션과 함께 발송될 프레임워크 라이브러리를 서비스하는 데에 사용될 메커니즘을 변경한다. 몇몇 실시예의 하나의 양상은 Dot Net™ 프레임워크 바인더(마이크로소프트 사의 표장)를 일반화하는 것이다. 현재의 프레임워크는 엄격한 바인딩 모델을 가지는데, 이는 그것이 공유가능한 라이브러리를 어디에서 찾을 수 있는지를 지시한다(dictate). 몇몇 변경은 위치(공유가능한 라이브러리가 이로부터 로드될 수 있음)의 리스트를 확대하기 위해 바인딩 알고리즘을 일반화하는 것, 그리고 애플리케이션 로컬 위치로부터 공유가능한 라이브러리의 최신 버전을 로드하는 데에 버전 선행을 사용하기 위해 바인딩 알고리즘을 변경하는 것을 포함한다. 이 혁신들은 공유가능한 라이브러리가 해당 박스(즉, 해당 머신) 상에 있을 수 있는 해당 라이브러리의 다른 버전에 상관 없이 발송되어 애플리케이션에 의해 사용될 수 있게 할 것이다.

몇몇 변경은 공유가능한 라이브러리를 중앙식으로 서비스가능(serviceable)하게 하는 것을 수반한다. 애플리케이션 로컬 모델로 나아가는 것은 공유가능한 라이브러리를 훨씬 더 서비스하기 힘들게 할 수 있다. 하지만 몇몇 실시예는 라이브러리를 애플리케이션 로컬 프레임워크 라이브러리로서 식별하는 모델, 이 애플리케이션 로컬 라이브러리들의 로드를 목록화하고 확인하는(324) 모델, 향후의 청소를 위해 이 라이브러리들의 위치를 추적하는 모델, 릴리즈된 프레임워크 라이브러리가 또한 서비스되게(320) 하는 메커니즘, 그리고 보안 취약 라이브러리를 첫 번째 로드 시에 실패하게(504) 하는 메커니즘을 정의한다.

서비싱에 대한 전통적인 접근법은 라이브러리가 설치되었다는 지시자를 갖는 중앙 위치에 의존한다. 어떤 설정 구축(setup authoring)은 어셈블리/라이브러리를 중앙 위치에 두거나 아니면 메타데이터/레지스트리 키를 알려진 위치에 기입하는 능력을 가진다. 그러나 애플리케이션 로컬 라이브러리가 있는 몇몇 실시예는 그러한 비치 고려사항을 부과하지 않는다. 몇몇은 애플리케이션과, 더불어 그것의 라이브러리가 클라이언트 머신에 단순히 복사될 것이라고 가정한다. 그러한 환경에서 어느 하나는 알려진 위치에 애플리케이션 라이브러리를 복사하거나 레지스트리 키/메타 데이터를 알려진 위치에 기입하는 어떠한 메커니즘도 갖지 않는다. 대신, 런타임 내의 메커니즘은 어셈블리 로드 시에 이 정보를 수집한다.

예를 들어, 적어도 한 번 로드되었던 "System.Foo.dll"이라 명명된 라이브러리를 고려하자. 몇몇 실시예에서, 만약 System.Foo.dll이 어셈블리 메타데이터 속성 Servicing("true") 설정을 가지는 경우 어셈블리의 로드 중에, 이하의 형태 또는 기능적으로 유사한 형태의 브레드크럼이 생성될 것이다.

C:＼ProgramData＼Microsoft＼NetFramework＼System.Foo, version 1.0.0.0, culture neutral, abbcdaccl23.txt

여기서 보여진 포맷은 단지 비한정적 예임이 숙련자에 의해 이해될 것이다. 또한, 몇몇 실시예에서는 어셈블리 아이덴티티의 모든 부분이 없는(가령, 버전 번호가 없는) 브레드크럼이 자동으로 생성되어, 어셈블리 이름의 더욱 애매한(fuzzy) 매칭을 허용한다. 몇몇 실시예에서, 브레드크럼은 레지스트리 내에, 또는 어떤 다른 위치 내에 저장될 수 있다.

몇몇 실시예에서, 만약 System.Foo.dll이 알려진 레지스트리 키 하이브(registry key hive) 내의 엔트리를 가지는 경우, 어셈블리의 로드 중에, 이하의 형태 또는 기능적으로 유사한 형태가 생성될 것이다.

HKLM＼Software＼Microsoft＼NetFramework＼System.Foo, version 1.0.0.0, culture neutral, abbcdaccl23.txt

몇몇 실시예에서, 만약 System.Foo.dll이 Microsoft.Servicing.dll 상의 종속체(dependency)를 취하는 경우, 어셈블리의 로드 중에, Microsoft.Servicing은 Microsoft.Servicing 및 System.Foo 내에 코딩된 행위(behavior) 때문에 호출되고 이하의 형태 또는 기능적으로 유사한 형태의 브레드크럼이 생성될 것이다.

C:＼ProgramData＼Microsoft＼NetFramework＼System.Foo, version 1.0.0.0, culture neutral, abbcdaccl23.txt

이 접근법들 중 어느 것도 애플리케이션 내의 System.Foo.dll을 쓰고 있었던 애플리케이션 개발자에 의해 임의의 특별한 단계가 취해지는 것에 달려 있지 않다. 그것들은 애플리케이션 로컬 라이브러리가 클라이언트 머신 상에 상주하는 때를 판정하는 기술적 문제를 해결하는 데에 사용될 수 있는 접근법의 예이다. 보여진 브레드크럼 포맷은 단지 예인데, 다른 실시예에서는 다른 포맷이 사용될 수 있다.

취약한 코드가 구동되는 것을 방지하는 기술적 문제를 이제 고려하자(이는 여기서는 취약한 코드가 로드되는 것을 방지하는 기술적 문제로 변환됨). 몇몇 실시예는 라이브러리 메타데이터를 분석함으로써 라이브러리가 대역외 라이브러리임을 라이브러리의 첫 번째 로드 시에 판정한다. 라이브러리 메타데이터의 알려진 부분의 존재 시에, 어셈블리 아이덴티티 정보를 머신 범위 위치에 기입하기 위해 런타임에서 논리가 트리거된다(triggered). 라이브러리 어셈블리의 첫 번째 로드 시에 몇몇 실시예는 알려진 데이터스토어(data-store) 내의 어셈블리 아이덴티티의 포함에 의해 라이브러리가 대역외 라이브러리임을 판정한다. 이는 어셈블리로 하여금 소급적으로 서비싱에 참여하기로 되게 한다. 데이터 스토어 내의 어셈블리 아이덴티티의 존재 시에, 어셈블리 아이덴티티 정보를 머신 범위 위치에 기입하기 위해 런타임에서 논리가 트리거된다.

서비싱에 참여하기로 하는 것(opting in to servicing)과 관련하여 여러 관측이 행해질 수 있다. 몇몇 실시예에서, 프레임워크 라이브러리가 서비스가능하기 위해서, 그것은 어떤 정책을 준수한다. 새로운 대역외 라이브러리를 식별하는 것을 지원하기 위하여, 서비스될 모든 프레임워크 라이브러리는 공통 언어 런타임(Common Language Runtime: CLR) 로더가 점검하는 어셈블리 레벨 속성 AssemblyServicable("true")를 선언한다. 대안적인 옵션은 어셈블리 헤더 내에 플래그(flag)를 설정하는 의사 커스텀 속성(pseudo custom attribute)을 사용한다. 다른 옵션은 AssemblyMetadata 속성을 사용하며 메타데이터를 어셈블리 내에 추가하여 서비싱에 참여하기로 하는 것인데, 문제의 실마리는 "서비싱"일 수 있고 그 값은 참(true) 또는 거짓(false)일 수 있다. 그러나, 만약 사용되는 접근법이 강하게 박힌(typed) 것이 아닌 경우, 어떠한 설계 시간 시행 또는 오류 확인도 없다. 다른 옵션은 로드 위치가 비-GAC 위치로부터인지 및 로드할 어셈블리 내의 아이덴티티가 프레임워크 어셈블리의 해당 아이덴티티와 매칭되는 공용 키(public key)를 가지는지에 기반하여, 대역외 라이브러리를 자가식별하는(auto-identify) 것이다. 이 옵션의 이점은 라이브러리가 프레임워크 키로써 서명되어야 한다는 것 이외에 개발자에게 어떠한 제한도 그것이 부과하지 않는다는 것이다.

이전에 릴리즈된 대역외 라이브러리를 식별하는 기술적 문제로 또한 주의가 돌려진다. 이 속성(230) 없이 이미 릴리즈된 대역외 라이브러리에 대해, 몇몇 실시예는 레지스트리 또는 파일 시스템에 설치될 옵트인 리스트(opt-in list)(234)를 생성한다. 이 리스트는 이미 대역외로서 취급되었거나 그렇지 않으면 특징지어지고 혹자가 서비스할 수 있기를 바라는 모든 라이브러리를 포함할 것이다. 그 리스트는 오직 관리자가 그것을 변경할 수 있도록 (가령, 액세스 제어 리스트(Access Control List) 또는 다른 메커니즘을 사용하여) 지켜질 수 있다. 이 리스트를 위한 레지스트리 키는, 예컨대 HKEY_LOCAL_MACHINE＼SOFTWARE＼Microsoft＼NET Framework Setup＼NDP＼Servicing＼<AssemblyIdentity>(값으로서의 것)(만약 관측되는 경우 바인더 또는 로더가 이를 위해 브레드크럼을 기입하여야 함)에 위치될 수 있다.

대역외 라이브러리를 쓰는 경우에 서비스가능하도록 애플리케이션이 참여하기로 하는 것에 관하여, 몇몇 실시예에서는 만약 애플리케이션이 묵시적 오버라이드 바인딩 모델에 참여하기로 하는 경우, 애플리케이션은 향상된 로더(222) 서비싱 모델에 자동으로 참여하기로 된다. 이 접근법은 애플리케이션으로 하여금 그것이 서비스되어야 하는지 여부의 결정을 행하게 하지 않는다. 서비싱 업데이트를 취하는 옵션은 친숙한 업데이트 서비스 메커니즘(들)을 통하여, 영향을 받거나 그렇지 않을 수 있는 모든 애플리케이션을 위한 수정본을 다운로드하기 위해서도, 머신의 관리자에게 맡겨진다.

서비싱에 참여하기로 하는 것의 영향에 관하여, CLR 바인더가 어셈블리 상의 이 속성(230)을 보거나 서비스 리스트(234) 상의 어셈블리 이름을 보는 것의 한 가지 영향은 향상된 로더(222)에게 서비싱에 참여하기로 한 대역외 어셈블리를 그것이 로드하고 있음을 나타내는 것이다. 이에 주석을 달기 위하여, CLR 바인더는 브레드크럼을 디렉토리 엔트리의 형태로, 많은 가능한 예들 중 두 개를 들자면, 가령 C:＼ProgramData＼Microsoft＼CLR＼<AssemblyName>_<PublicKeyToken>_<Major>_<Minor>_<Buid>_<Revision>＼<UserNameHash>＼BC.txt 또는 C:＼ProgramData＼Microsoft＼NetFramework＼<AssemblyName>_<PublicKeyToken>_<Major>_<Minor>_<Buid>_<Revision>＼<UserNameHash>＼BC.txt과 같은 위치에 기입하여야 한다.

레지스트리에 대해 구조는 다음과 같이 보일 것이다:

HKEY_LOCAL_MACHINE＼SOFTWARE＼Microsoft＼NET Framework Setup＼NDP＼OOBServicing＼<AssemblyName>_<PublicKeyToken>_<Major>_<Minor>_< Buid>_<Revision>

<UserNameHash>＼BC.txt에 선행하는 디렉토리 엔트리의 부분, 또는 OOBServicing에 후속하는 레지스트리 엔트리 키의 부분의 존재는 이 어셈블리의 특정 버전이 실제로 로드되었음을 업데이트 서비스 검출 논리에 나타낼 것이다. BC.txt의 내용은 위치(들)(이로부터 DLL이 로드되었음)을 포함할 것이다.

몇몇 실시예에서 디렉토리 및/또는 레지스트리를 위한 ACL에 관하여, 디렉토리를 생성한 사용자 계정(user account)은 그것을 삭제하는 것이 가능하지 않을 것인데, 오직 관리자가 브레드크럼을 삭제할 수 있다. 하나의 사용자는 다른 사용자의 브레드크럼 정보를 볼 수 없다. 사용자는 자기 자신의 브레드크럼을 삭제할 수 없다. 만약 프라이버시(privacy)가 걱정인 경우, 경로를 부호화하기 위해 일 구현은 UserName 대신에 UserNameHash를 사용할 수 있다. 브레드크럼이 기입되지 않은 경우에는, 예컨대 디스크 공간 이슈 또는 ACL 이슈로 인해, 바인더는 어셈블리를 계속해서 로드하고 바인딩 실패를 야기하지 않으며, 이에 따라 진단 로그 엔트리(diagnostic log entry)가 만들어질 수 있다.

대역외 라이브러리를 식별하는 몇몇 실시예는 이하를 행한다. 첫 번째 로드 시에, 어떤 서비싱 라이브러리(232)의 포함에 의해 라이브러리가 대역외 라이브러리임을 판정한다. 이 서비싱 라이브러리가 로드되는 경우, 그것은 그것을 포함했던 어셈블리에 관한 어셈블리 아이덴티티 정보를 머신 범위 위치에 기입한다. 몇몇 실시예에서, 이 접근법은 서비싱 라이브러리(서비스될 필요가 있는 임의의 다른 프레임워크 라이브러리가 이에 대한 의존성을 취함)를 빌드하는 것을 수반한다. 그 메커니즘은 브레드크럼을 기입하는 패키지를 호출하기 위해 초기화기(initializer), 즉 어셈블리 로드 시에 언제나 콜되는(called) 메쏘드를 사용한다. 이 메커니즘은 대역외 라이브러리의 식별을 라이브러리 개발자의 묵시적 행동으로 만들며 따라서 그런 목적을 위해 속성(230)의 사용을 대체할 수 있다. 그러나, 이 접근법에서의 이슈는 그것이 서비싱 라이브러리를 서비스될 메커니즘이 전혀 없게 놔두는 것인데, 이는 그것을 친숙한 Microsoft® .NET™ 프레임워크(마이크로소프트 사의 표장)를 포함하는 몇몇 프레임워크를 위해 구현할 더 높은 위험 특징으로 만든다. 그럼에도 불구하고 그것은 어떤 업데이트 서비스 배포 메커니즘이 존재할 때에 이 기능을 빌드하고 싶어하는 제3자(third party) 어셈블리를 위한 실현가능한(viable) 옵션일 수 있다.

몇몇 실시예는 취약한 라이브러리가 처음으로 로드되는 것을 방지한다. 첫 번째 로드 시에 런타임은 알려진 취약한 라이브러리의 리스트(224)를 위해 데이터 스토어를 확인한다. 만약 로드되는 라이브러리가 취약한 라이브러리의 아이덴티티과 매칭되는 경우, 그 로드는 실패로 되고(504), 어셈블리 아이덴티티 정보를 머신 범위 위치에 기입하기 위해 런타임에서 논리가 트리거되며, 그 이슈를 해결하는 링크(link)와 함께 오류 메시지가 사용자가 행동을 취하도록 로그된다(logged). 특히, 로더(222)가 식별된 대역외 라이브러리를 로드하기 전에 몇몇 실시예에서, 로더는 HKEY_LOCAL_MACHINE＼SOFTWARE＼Microsoft＼NET Framework Setup＼NDP＼OOBBlocklist＼<AssemblyIdentity Value> 하이브 내에서 값 이름(value name)(로드되는 Assembly Identity와 매칭됨)에 대해 확인한다. 만약 매치가 발견되는 경우 로더(222)는 (가령, 친숙한 킬비트(killbit) 메커니즘을 사용하여) 어셈블리를 로드하는 데에 실패하고 FileLoadException을 쓰로우하기(throw) 위해 상응하는 데이터를 사용한다. 그 데이터는 제안된 수정본의 웹사이트 주소 또는 다른 URL(Uniform Resource Locator)를 가리키는데, 이는 예외 메시지 내에 포함될 수 있다. 쓰로우된 예외는 SecurityException일 수 있는데, 이는 이미 Assembly.Load()에 의해 쓰로우된 예외 중 하나이되, 메타데이터가 그것에 추가되어 있다. 몇몇 실시예는 내부의 SecurityException과 함께, FileLoadException을 쓰로우한다.

처음으로 구동되는 경우에 로드된 적이 없는 라이브러리에 대해, 몇몇 실시예는 서비싱 이벤트가 발생하였음을 알 것이며 어셈블리를 로드하는 데에 실패할 것인 바인더에 내장된 특징을 가진다. 이 실패 시에, 그것은 알려진 위치에 브레드크럼을 기입하고 업데이트 메커니즘을 행할 장소를 가리킬 것인데, 이후에 이는 혹자가 브레드크럼 기반 접근법으로써 행할 것과 동일한 방식으로 라이브러리를 업데이트해 버릴 것이다.

몇몇 실시예에서, 어셈블리 아이덴티티는

System.Composition.AttributedModel, Version= 1.0.16.0, Culture=neutral, PublicKeyToken=b03f5f7flld50a3a 처럼 보인다.

다른 실시예에서, 어셈블리 아이덴티티는 예컨대 전역적 고유 식별자(Globally Unique Identifier: GUID), 또는 단지 어셈블리의 파일 이름, 또는 파일 이름 및 파일 버전의 조합일 수 있다. 어셈블리 아이덴티티는 어셈블리의 주어진 버전을 고유하게 식별하는 방식이다.

결론

비록 특정한 실시예가 본 문서에서 프로세스로서, 구성된 매체로서, 또는 시스템으로서 명시적으로 예시되고 기술되나, 하나의 유형의 실시예의 논의는 또한 다른 실시예 유형으로 일반적으로 확장됨이 인식될 것이다. 예를 들면, 도 3 내지 도 5와 관련한 프로세스의 설명은 또한 구성된 매체를 기술하는 데에 도움이 되고, 다른 도면과 관련하여 논의된 것과 같은 시스템 및 제품의 기술적 효과 및 동작을 기술하는 데에 도움이 된다. 하나의 실시예로부터의 한정이 반드시 다른 것 내로 읽힌다는 결론이 나오는 것은 아니다. 특히, 프로세스는 시스템 또는 제품, 이를테면 구성된 메모리를 논의하면서 제시된 데이터 구조 및 배열에 반드시 한정되지는 않는다.

어떤 특징 X를 가지는 일 실시예에 대한 본 문서 내의 언급 및 어떤 특징 Y를 갖는 일 실시예에 대한 본 문서의 다른 곳에서의 언급은 특징 X 및 특징 Y 양자 모두를 가지는 실시예를 이 개시로부터 배제하는 것은 (그러한 배제가 본 문서에서 명시적으로 언급되지 않는 한) 아니다. "실시예"라는 용어는 "적용가능한 법과 부합하는 방식으로 적용되는 것과 같은 본 문서 내의 교시의 프로세스, 시스템, 제조 물품, 구성된 컴퓨터 판독가능 매체 및/또는 다른 예"의 더욱 편리한 형태로서 본 문서에서 사용된 것뿐이다. 따라서, 주어진 "실시예"는 그 실시예가 적어도 하나의 청구항과 부합한다면, 본 문서에 개시된 특징의 임의의 조합을 포함할 수 있다.

도면에 도시된 모든 아이템이 모든 실시예에 존재할 필요가 있는 것은 아니다. 역으로, 일 실시예는 도면에 명시적으로 도시되지 않은 아이템(들)을 포함할 수 있다. 비록 여기서 텍스트 및 도면 내에 특정 예에 의해 몇몇 가능성이 예시되나, 실시예들은 이 예들로부터 벗어날 수 있다. 예를 들면, 한 예의 특정 기술적 효과 또는 기술적 특징은 생략되거나, 재명명되거나, 따로 그룹화되거나, 반복되거나, 따로 하드웨어 및/또는 소프트웨어 내에 인스턴스화되거나(instantiated), 예들 중 둘 이상에 나타나는 효과 또는 특징의 혼합일 수 있다. 하나의 위치에서 보여진 기능은 몇몇 실시예에서 상이한 위치에서 제공될 수도 있는데, 전체로서 간주되는 상호작용하는 모듈의 모음으로부터 원하는 기술적 효과를 반드시 생략하는 것 없이 주어진 구현에서 다양한 방식으로 기능 모듈이 정의될 수 있음을 숙련자는 인지한다.

참조 번호에 의해 쭉 도면에 대한 언급이 행해졌다. 주어진 참조 번호와 연관된 어법 내, 도면 내 또는 텍스트 내의 임의의 명백한 모순은 단지 해당 번호에 의해 참조되는 것의 범주를 넓히는 것으로서 이해되어야 한다. 주어진 참조 번호의 상이한 인스턴스들은 설사 동일한 참조 번호가 사용되더라도 상이한 실시예를 나타낼 수 있다.

본 문서에서 사용되는 바와 같이, "일" 및 "그"와 같은 용어는 표시된 아이템 또는 단계가 하나 이상임을 포함하는 것이다. 특히, 청구항에서 한 아이템에 대한 언급은 적어도 하나의 그러한 아이템이 일반적으로 존재함을 의미하고 한 단계에 대한 언급은 그 단계의 적어도 하나의 인스턴스가 수행됨을 의미한다.

표제는 단지 편의를 위한 것인데, 주어진 주제에 대한 정보는 표제가 해당 주제를 나타내는 부문 밖에서 발견될 수 있다.

제출된 바와 같은 모든 청구항 및 요약은 명세서의 일부이다.

예시적인 실시예가 도면에서 도시되고 앞서 기술되었으나, 청구항에 개진된 원리 및 개념을 벗어나지 않고 많은 수정이 행해질 수 있다는 점 및 그러한 수정이 전체적인 추상적 개념을 망라할 필요는 없다는 점은 통상의 기술자에게 명백할 것이다. 비록 대상(subject matter)이 구조적 특징 및/또는 절차적 작용에 특정한 말로 기술되었으나, 부기된 청구항 내에 정의된 대상은 반드시 청구항 위에서 기술된 특정한 기술적 특징 또는 작용에 한정되지는 않는다는 점이 이해되어야 한다. 주어진 정의 또는 예에서 식별된 모든 수단 또는 양상 또는 기술적 효과가 모든 실시예에서 존재하거나 활용될 필요는 없다. 오히려, 기술된 특정한 특징과 작용과 효과는 청구항을 구현하는 경우 고려를 위한 예로서 개시된다.

전체적인 추상적 관념을 아우르는 것에 미치지 못하나 청구항의 균등성의 의미 및 범위 내에 드는 모든 변경은 법에 의해 허용되는 전체 범위까지 그것의 범주 내에 포괄되어야 한다.

Claims (10)

1. 컴퓨터 시스템으로서,
   적어도 하나의 프로세서와,
   상기 프로세서와 통신가능한 메모리와,
   상기 메모리 내에 상주하고(residing) 묵시적 오버라이더 코드(implicit override code)를 가지는 바인더(binder)를 포함하되, 상기 바인더는 애플리케이션의 실행을 지원하도록 로딩하기 위해 요청된 어셈블리의 어느 버전이 로더(loader)에 식별될지를 판정하기 위해 상기 프로세서 및 메모리와 상호작용하도록 구성되고,
   상기 묵시적 오버라이드 코드는 적어도 하나의 어셈블리 특정 위치(assembly-specific location)에서 묵시적 버전을 찾아 탐색하는 코드를 포함하고, 상기 묵시적 오버라이드 코드는 또한 상기 묵시적 버전이 발견된 후 상기 묵시적 버전을 다른 버전과 비교하는 코드를 포함하며, 상기 묵시적 오버라이드 코드는 또한 상기 묵시적 버전이 상기 다른 버전보다 더 큰 경우 상기 묵시적 버전으로써 상기 다른 버전을 조건부로 오버라이드하는 코드를 포함하는
   시스템.
   
2. 제1항에 있어서,
   상기 바인더는 또한 바인딩 재지향 명령에 대해 확인하도록 구성된 바인딩 재지향 코드(binding redirection code)를 포함하되, 상기 바인딩 재지향 코드는 바인딩 재지향 명령에 응답하여 상기 묵시적 버전을 오버라이드하는 코드를 포함하고, 상기 바인더는 상기 묵시적 오버라이드 코드를 호출한 후 상기 바인딩 재지향 코드를 호출하도록 구성된
   시스템.
   
3. 제1항에 있어서,
   상기 시스템은 상기 시스템 상에 이전에 적어도 1회 로드된 어셈블리를 더 포함하고, 대역외 메타데이터(out-of-band metadata)의 모음(collection)이 상기 메모리 내에 상주하되, 상기 대역외 메타데이터 모음은 상기 이전에 로드된 어셈블리를 위한 엔트리(entry)를 포함하고, 상기 시스템 메모리는 또한 (a) 상기 어셈블리가 이전에 로드된 경우 상기 어셈블리가 알려진 대역외 어셈블리의 리스트와 적어도 부분적으로는 매칭되는 것에 대응하여 상기 엔트리를 상기 모음 내에 배치하도록 구성된 대역외 어셈블리 코드, (b) 상기 이전에 로드된 어셈블리의 대역외 서비싱 속성(out-of-band-servicing attribute) 중 적어도 하나를 포함하는
   시스템.
   
4. 데이터로써 그리고 적어도 하나의 프로세서에 의해 실행되는 경우 상기 프로세서로 하여금 애플리케이션의 실행을 지원하도록 로딩하기 위해 요청된 어셈블리의 어느 버전이 로더에 식별될지를 판정하는 기술적 프로세스를 수행하게 하는 명령어로써 구성된 컴퓨터 판독가능 저장 매체로서, 상기 프로세스는
   어셈블리 특정 위치에서 묵시적 버전을 찾아내는 단계와,
   상기 묵시적 버전이 발견된 후 상기 묵시적 버전을 다른 버전과 비교하는 단계와,
   상기 묵시적 버전이 상기 다른 버전보다 더 큰 경우 상기 묵시적 버전으로써 상기 다른 버전을 오버라이드하는 단계를 포함하는
   컴퓨터 판독가능 저장 매체.
   
5. 제4항에 있어서,
   상기 프로세스는 상기 요청된 어셈블리의 프레임워크 통합(framework unification)을 수행하는 단계를 더 포함하고, 상기 프레임워크 통합은 상기 묵시적 버전과 비교되는 상기 다른 버전을 산출하는
   컴퓨터 판독가능 저장 매체.
   
6. 제4항에 있어서,
   상기 프로세스는 컴퓨터 시스템 상에서 일어나고, 상기 프로세스는
   (a) 상기 어셈블리를 알려진 대역외 어셈블리의 리스트에 적어도 부분적으로 매칭시키고, 이에 대응하여 상기 컴퓨터 시스템 상의 메타데이터 모음 내에 상기 어셈블리를 위한 엔트리를 배치하는 단계,
   (b) 상기 어셈블리 내의 대역외 서비싱 속성을 위치파악하고(locating), 이에 대응하여 상기 컴퓨터 시스템 상의 메타데이터 모음 내에 상기 어셈블리를 위한 엔트리를 배치하는 단계,
   (c) 상기 컴퓨터 시스템에 서비스 패키지(service package)를 적용하고, 상기 서비스 패키지를 적용하는 것의 일부로서 상기 컴퓨터 시스템 상의 메타데이터 모음 내에 상기 어셈블리를 위한 엔트리를 배치하는 단계
   중 적어도 하나를 더 포함하는
   컴퓨터 판독가능 저장 매체.
   
7. 제4항에 있어서,
   상기 프로세스는 상기 어셈블리가 보안 결함(security flaw)에 취약함(vulnerable)을 판정하는 단계를 더 포함하고 해당 판정에 응답하여 상기 어셈블리를 로드하는 데에 실패하는
   컴퓨터 판독가능 저장 매체.
   
8. 제4항에 있어서,
   상기 찾아내는 단계는
   상기 어셈블리와 공통인 이름을 가지고 상기 애플리케이션의 디렉토리 내에 위치된 파일,
   탐색 규약(search convention)에 의해 지정된 상기 애플리케이션의 서브디렉토리,
   상기 애플리케이션의 디렉토리 내에 위치된, 디렉토리 경로의 리스트 내에 지정된 위치,
   상기 애플리케이션의 디렉토리 내에 위치된, 파일 이름의 리스트 내에 지정된 위치
   중 적어도 하나인 어셈블리 특정 위치에서 상기 묵시적 버전을 찾아내는
   컴퓨터 판독가능 저장 매체.
   
9. 제4항에 있어서,
   상기 프로세스는 상기 요청된 어셈블리의 바인딩 재지향을 수행하는 단계를 포함하고, 상기 프로세스는
   상기 묵시적 버전은 명시적 범위를 상술하지(recite) 않고, 상기 바인딩 재지향은 만약 현재 선택된 버전이 X 내지 Y 범위(range X-Y) 내에 있다면 대신에 버전 Z를 사용함을 상술하는 방식,
   상기 묵시적 버전은 상기 애플리케이션의 구성 파일의 외부에서 발견되고, 상기 바인딩 재지향은 상기 구성 파일의 내부에 지정되는 방식,
   XML 선언을 요구하지 않고 상기 어셈블리에 의해 상기 묵시적 버전은 묵시적으로 지정되고, 상기 바인딩 재지향은 XML 선언에 의해 지정되는 방식
   중 적어도 하나로 또한 특징지어지는
   컴퓨터 판독가능 저장 매체.
   
10. 제4항에 있어서,
    상기 어셈블리는 어셈블리들의 프레임워크에 속하고, 상기 프로세스는 상기 요청된 어셈블리의 프레임워크 통합을 수행하는 단계를 포함하며, 통합 버전은 어셈블리들의 상기 프레임워크로써 업데이트되는 반면, 상기 묵시적 버전은 개별 어셈블리로써 업데이트되는 것으로 상기 프로세스는 또한 특징지어지는
    컴퓨터 판독가능 저장 매체.

Images