基于应用程序执行上下文选择性地展示基类库的制作方法

文档序号:6426860阅读:349来源:国知局
专利名称:基于应用程序执行上下文选择性地展示基类库的制作方法
技术领域
本发明涉及基于应用程序执行上下文选择性地展示基类库的技术。
背景技术
计算机和计算系统已经影响了现代生活的几乎每个方面。计算机通常在工作、消遣、保健、运输、娱乐、家政管理等中都有涉猎。通常,需要为不同的平台展示不同的应用程序编程接口(API)功能,诸如托管代码平台或应用程序模型。托管代码是需要且仅在公共语言运行时(CLR)虚拟机的“托管”下执行的计算机程序代码。在该同一上下文中,程序员还将不依赖于公共语言运行时的代码称作非托管代码。通常不同的应用程序模型提供不同的功能集并且因而使用不同的基类库,尽管这些基类库具有较大部分的公共代码。然而,在部署不同的应用程序模型时,可能需要的是节省存储空间而不是具有其中每个具有大部分重叠代码的两个不同的运行时。例如,诸如蜂窝电话、个人数字助理等的移动设备的存储空间可比其它较不便携或较大的设备小。应当对安装在移动设备上的事物进行详细审查,并且应当努力优化存储空间。在此要求保护的主题不限于解决任何缺点或仅在诸如上述环境中操作的各个实施例。相反,提供该背景仅用以示出在其中可实践在此描述的部分实施例的一个示例性技术领域。

发明内容
此处示出的一个实施例涉及一种在计算环境中实施的方法。该方法包括用于基于应用程序上下文允许访问API的动作。该方法包括为应用程序确定应用程序上下文。为基类库(base class library)确定层。基类库的层由与API相关联的一个或多个开发者定义的属性来定义,其中API被包括在基类库中。基于开发者定义的属性将基类库分成层。该一个或多个属性定义哪个应用程序上下文可访问API。如果层与应用程序上下文匹配,则允许应用程序对API的访问。提供本概述以便以简化形式介绍将在以下的具体实施方式
中进一步描述的概念精选。本概述并非旨在标识所要求保护的主题的关键特征或必要特征,也不旨在用于帮助确定所要求保护的主题的范围。另外的特征和优点将在以下的描述中阐述,并且部分可从该描述中显而易见,或者可以从此处的教示实践中习得。本发明的特征和优点可以通过在所附权利要求中特别指出的手段和组合来实现并获取。本发明的特征将从以下描述和所附权利要求书中变得完全显而易见,或者可通过如下所述对本发明的实践而获知。


为了描述能够获得上述和其他优点和特征的方式,将通过参考附图中示出的各具体实施例来呈现对以上简述的主题的更为具体的描述。应该理解,这些附图仅描绘了各典型实施例,因此其不应被认为是对范围的限制,各实施例将通过使用附图用附加附加特征和细节来描述并解释,在附图中图1是示出不同代码等级的图表;以及图2示出基于应用程序上下文允许访问API的方法。
具体实施例方式此处描述的实施例允许使用单个运行时,其中运行时内的类利用指示用于展示应用程序编程接口(API)的应用程序上下文的信息来注释。这允许选择性地展示API以用于不同的应用程序模块。以下示出非常具体的示例,但是所示出的概念可通用地应用于基类库。示出一个示例,移动Silverlight (SLM)将.Net. 压缩框架(NETCF)(两者均可从美国华盛顿州雷蒙德市的微软公司获得)作为基运行时。这是旨在诸如例如在存储空间和不移动或非移动设备相比较小的空间受限移动设备上重用(resue)单个运行时和基类库(BCL)的单个集, 而不是在其上部署并行运行时。如此,NETCF运行时包括对不同的应用程序模型——传统 NETCF和SLM应用程序模型的支持。现有NETCF API支持比SLM应用程序所可用的要丰富。因此,各实施例可仅向SLM 应用程序展示可用API表面的子集。也可期望由于安全原因限制API表面区域。各实施例可通过将BCL分成三个层来实现上述内容。基于从用户代码以及在这些层自身内对这些层的不同级别的可访问性来确定向在不同上下文下运行的应用程序(规则NETCF或SLM)展示的BCL表面区域。对层的可访问性由BCL代码形式的自定义属性注释来确定。特别地,每个类或方法可具有指示应当将类向哪些应用程序上下文展示的属性。 一些类或方法可具体地排除某属性,其中该属性的缺少是关于应用程序上下文和层可访问性的指示符。这可用于本质上创建相同物理类库的逻辑视图。因此,各实施例可便于运行时的重用同一 BCL以支持不止一个应用程序模型的能力。这可有助于大大减少运行时和工作集大小。特别地,不同应用程序中的类似功能所需要的公共代码不需要被多次复制,对于每个应用程序上下文复制一次。相反,各实施例可使用代码注释来确定API在特定应用程序上下文中的展示。各实施例可包括静态地验证BCL 层划分的正确性的功能。以下示出各实施例。现在参见图1,示出了示出一个实施例的基类库的图表100。基类库被分成层
(在图 1 中示出三层)-NETCF 内部(NETCFInternalNETCFInternal) 102、SLM 内部
(SLMInternalSLMInternal) 104 以及 SLM 公共(SLMPublicSLMPublie) 106。这通过在类和 / 或成员级别注释代码来完成。可注释类型和/或方法。特别地,类和成员可包括一个或多个属性,这些属性定义类或成员向哪个(哪些)划分展示功能。在运行时间,公共语言运行时(CLR)读取类或成员上的属性并确定基于应用程序上下文的应用程序是否能访问该属性。在所示出的示例中,当在规则NETCF上下文下执行代码时没有限制被展示。即,当在如108所示的NETCF上下文中执行时,用户应用程序被允许访问102所示的完整BCL。
然而,当在移动Silverlight 上下文中运行时,应用程序可仅仅访问SLM公共 106API。在所示出的实施例中,SLM公共106和SLM内部104层可相互访问。NETCF内部 102层是自包含的,并且在SLM上下文中运行的任何代码,如110所示,不被允许对其进行访问。图1所示的本实现涉及支持两个不同的应用程序模型。然而,各实施例可通过使用附加层扩展到两个以上应用程序模型。各实施例也可扩展到透明度类模型。透明度是帮助开发者编写向部分可信的代码展示功能的更安全的框架库的特征。整个汇编件、汇编件中的某些类、或者类中的某些方法可被标记为安全透明的。安全透明的代码不能提高特权。在.Net, 框架中,该限制具有三个具体的分支(1)安全透明的代码不能执行断言。(2)将可由安全透明的代码满足的任何链接需求变成完全需求。(3)必须以安全透明的代码执行的任何不安全(不可验证)代码引起对跳过验证安全许可的完全需求。类似地,具有CoreCLR的Silverlight⑧具有不实现需求的透明度的简化模型。各实施例可通过使用上述注释概念来实施透明度类功能。然而,与透明度不同,各实施例可用于完全阻挡API的一部分——而透明度准许以不同的特权访问整个(full)API。尽管前述示例是在.Net压缩框架和移动应用程序模型的新Silverlight @的上下文中示出,但是各实施例足够灵活以为其它应用程序提供支持。以下讨论示出代码注释可被如何执行。在一个实施例中,代码注释在类型和方法级别完成。代码注释可用于定义类型或方法在什么层。在图1示出的示例中,利用压缩框架内部属性(CompactFrameworldnternalAttribute)来注释NETCF内部层中的类型和方法。 利用Silverlight内部属性(SilverlightInternalAttribute)来注释SLM内部层中的公共代码。该层中的任何内部和专用代码被置为未注释的,因为根据定义该代码不能由用户应用程序访问。在所示出的实施例中,SLM公共层被置为完全未注释的。在包含类型级别的注释应用于全部所包含的成员。如果公共类型没有注释,则在本示例中,它在SLM公共层中。然而,注释仍然可在个体方法级别上完成。如上所述,在前述示例中,在类型和方法级别上注释代码。在所示出的实施例中, 任何枚举器(enumerator)或字段不被明确地注释。这是因为对于某些实施例它们可被认为是无威胁性的。特别地,枚举器映射到无害的整数值。原语类型的或者引用可访问层的对象的任何字段也被认为是安全的。引用不可访问层的对象的任何字段由于其类型的不可访问性而不能被访问,因此被置为未注释的。一些实施例可使用基于RCop的工具(可从微软公司获得的静态代码分析工具) 来标识在运行时间的不同的层。特别地,基于i^xCop的工具可用于标识注释进而标识不同的层。一旦注释已被标识,进而层被标识,上述基于应用程序上下文的限制就可应用于不同的层。以下讨论现在涉及多种方法以及可以执行的方法动作。虽然用特定次序讨论或用以特定次序发生的流程图示出了各个方法动作,但除非明确规定否则不需要特定次序,或因为一动作依赖于另一动作在执行该动作之前完成而需要特定次序。现在参考图2,示出了方法200。该方法可在计算环境中实施,并且包括用于基于应用程序上下文允许访问API的动作,该方法包括为应用程序确定应用程序上下文(动作202)。在先前示出的示例中,各实施例确定应用程序是否在全部.Net 压缩框架或移动 Silverlight 中运行。然而,也可实现其它实施例。在执行该动作时,应用程序上下文可涉及共享某些但不是全部的功能的应用程序上下文。例如,不同的应用程序模型提供具有大部分公共代码的不同的功能集。方法200还包括确定基类库的一层(动作204)。基类库的层(多层)由与API相关联的一个或多个开发者定义的属性来定义。API被包括在基类库中。基于开发者定义的属性将基类库分成多层。在一些实施例中,方法200可在利用开发者定义的属性注释基类库的各部分的情况下实施。该一个或多个属性定义哪些应用程序上下文可访问API。例如, 如图1和相关描述所示,属性可用于定义SLM内部层104、SLM公共层106和NETCF内部层 102。将基类库分成层可创建同一基类库的多个逻辑视图,使得基类库被用于支持多个应用程序模型。各实施例可在至少一个层被置为完全未利用开发者定义的属性注释的情况下实施。在该实施例中,注释的缺少定义该至少一个层。这样的一个示例在上面示出,其中SLM 公共层被置为完全未注释的。各实施例可在注释在类型和方法级别上执行的情况下实施。在一些实施例中,在包含类型(containing type)级别上的注释应用于全部所包含的成员。方法200还包括如果层与应用程序上下文匹配则允许应用程序访问API (动作 206)。特别地,应用程序将被允许访问适于给定应用程序上下文的层。在一些实施例中,方法200可在基类库是托管代码基类库(其需要且仅在公共语言运行时虚拟机的托管下执行的)的情况下实施。在一些实施例中,方法200可实施为,该方法还包括通过基于一个或多个应用程序的一个或多个应用程序上下文不允许该一个或多个应用程序访问API来实施安全限制。 在一个特定示例中,如先前在上面所解释的,在一个实施例中,透明度类限制可通过使用一些实施例的特征来完成。此外,该方法可以由包括一个或多个处理器和诸如计算机存储器等计算机可读介质的计算机系统来实施。具体而言,计算机存储器可以存储计算机可执行指令,计算机可执行指令在由一个或多个处理器执行时使得执行各种功能,如在各实施方式中所述的那些动作。本发明的各实施例可以包括或利用包含计算机硬件的专用或通用计算机,这将在下文中更详细地讨论。本发明范围内的各实施例还包括用于承载或存储计算机可执行指令和/或数据结构的物理和其他计算机可读介质。这样的计算机可读介质可以是可由通用或专用计算机系统访问的任何可用介质。存储计算机可执行指令的计算机可读介质是物理存储介质。承载计算机可执行指令的计算机可读介质是传输介质。由此,作为示例而非限制, 本发明的各实施例可包括至少两种完全不同的计算机可读介质物理计算机可读存储介质和传输计算机可读介质。物理计算机存储介质包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储(如CD、DVD
等)、磁盘存储或其他磁存储设备、或可用于存储计算机可执行指令或数据结构形式的所需程序代码装置且可由通用或专用计算机访问的任何其他介质。“网络”被定义为允许在计算机系统和/或模块和/或其他电子设备之间传输电子数据的一个或多个数据链路。当信息通过网络或另一通信连接(硬连线、无线、或硬连线或无线的组合)传输或提供给计算机时,该计算机将该连接适当地视为传输介质。传输介质可包括可用于承载计算机可执行指令或数据结构形式的所需程序代码装置并可由通用或专用计算机访问的网络和/或数据链路。以上介质的组合也被包括在计算机可读介质的范围内。此外,在到达各种计算机系统组件之后,计算机可执行指令或数据结构形式的程序代码装置可从传输计算机可读介质自动转移到物理计算机可读存储介质(或者相反)。 例如,通过网络或数据链路接收到的计算机可执行指令或数据结构可被缓存在网络接口模块(例如,“NIC”)内的RAM中,然后最终被传送到计算机系统RAM和/或计算机系统处的较不易失性的计算机可读物理存储介质。因此,计算机可读物理存储介质可被包括在同样 (或甚至主要)利用传输介质的计算机系统组件中。计算机可执行指令例如包括,使通用计算机、专用计算机、或专用处理设备执行某一功能或某组功能的指令和数据。计算机可执行指令可以是例如二进制代码、诸如汇编语言等中间格式指令、或甚至源代码。尽管用结构特征和/或方法动作专用的语言描述了本主题,但可以理解的是,所附权利要求书中定义的主题不必限于上述特征或动作。相反,上述特征和动作是作为实现权利要求的示例形式而公开的。本领域的技术人员将理解,本发明可以在具有许多类型的计算机系统配置的网络计算环境中实践,这些计算机系统配置包括个人计算机、台式计算机、膝上型计算机、消息处理器、手持式设备、多处理器系统、基于微处理器的或可编程消费电子设备、网络PC、小型计算机、大型计算机、移动电话、PDA、寻呼机、路由器、交换机等等。本发明也可以在其中通过网络链接(或者通过硬连线数据链路、无线数据链路,或者通过硬连线和无线数据链路的组合)的本地和远程计算机系统两者都执行任务的分布式系统环境中实践。在分布式系统环境中,程序模块可以位于本地和远程存储器存储设备中。本发明可具体化为其他具体形式而不背离其精神或特征。所描述的实施例在所有方面都应被认为仅是说明性而非限制性的。从而,本发明的范围由所附权利要求书而非前述描述指示。落入权利要求书的等效方案的含义和范围内的所有改变被权利要求书的范围所涵盖。
权利要求
1.在计算环境中,一种基于应用程序上下文允许访问API的方法,所述方法包括确定应用程序O02)的应用程序上下文;确定基类库O04)的层,所述基类库的所述层由与API相关联的一个或多个开发者定义的属性所定义,所述API被包括在所述基类库中,其中所述基类库基于所述开发者定义的属性被分成多层,其中所述一个或多个属性定义哪些应用程序上下文可访问所述API ; 以及如果所述层与所述应用程序上下文匹配,则允许所述应用程序访问所述API (206)。
2.如权利要求1所述的方法,其特征在于,所述基类库是需要且仅在公共语言运行时虚拟机的托管下执行的托管代码基类库。
3.如权利要求1所述的方法,其特征在于,所述方法还包括通过基于一个或多个应用程序的一个或多个应用程序上下文不允许所述一个或多个应用程序访问所述API来实施安全限制。
4.如权利要求1所述的方法,其特征在于,还包括将所述基类库安装在移动设备上。
5.如权利要求1所述的方法,其特征在于,执行所述方法创建同一基类库的多个逻辑视图,使得所述基类库被用于支持多个应用程序模型。
6.如权利要求1所述的方法,其特征在于,利用所述开发者定义的属性注释所述基类库的各部分。
7.如权利要求6所述的方法,其特征在于,至少一个层被置为完全未利用开发者定义的属性来注释,使得注释的缺少定义所述至少一个层。
8.如权利要求6所述的方法,其特征在于,在类型和方法级别上执行注释。
9.如权利要求6所述的方法,其特征在于,在包含类型级别上的注释应用于全部所包含的成员。
10.在计算环境中,一种基于应用程序上下文定义对API的所允许的访问的方法,所述方法包括确定应用程序O02)的应用程序上下文;确定应当对应用程序(204)可用的基类库中的一个或多个API ;以及将所述一个或多个API添加到所述基类库的层,所述基类库的所述层是所述应用程序可访问的层,其中将所述一个或多个API添加到所述层包括定义与所述API相关联的一个或多个开发者定义的属性,其中所述基类库基于所述开发者定义的属性被分成多层,其中所述一个或多个属性定义哪些应用程序上下文可访问所述API。
11.如权利要求10所述的方法,其特征在于,所述基类库是需要且仅在公共语言运行时虚拟机的托管下执行的托管代码基类库。
12.如权利要求10所述的方法,其特征在于,所述方法还包括通过基于一个或多个应用程序的一个或多个应用程序上下文不允许所述一个或多个应用程序访问所述API来基于所述开发者定义的属性定义安全限制。
13.如权利要求10所述的方法,其特征在于,还包括将所述基类库安装在移动设备上。
14.如权利要求10所述的方法,其特征在于,执行所述方法创建同一基类库的多个逻辑视图,使得所述基类库被用于支持多个应用程序模型。
15.如权利要求14所述的方法,其特征在于,利用所述开发者定义的属性注释所述基类库的各部分。
全文摘要
公开了基于应用程序执行上下文选择性地展示基类库的技术,该技术可基于应用程序上下文允许访问API。一种方法包括为应用程序确定应用程序上下文。确定基类库的层。基类库的层由与API相关联的一个或多个开发者定义的属性来定义,其中API被包括在基类库中。基于开发者定义的属性将基类库分成层。该一个或多个属性定义哪些应用程序上下文可访问API。如果层与应用程序上下文匹配,则允许应用程序对API的访问。
文档编号G06F9/445GK102279761SQ20111017084
公开日2011年12月14日 申请日期2011年6月13日 优先权日2010年6月14日
发明者S·纳迪姆帕利, S·齐达毕, Y·辛格 申请人:微软公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1