加载WinRT组件而不引用DLL /程序集

Question

我一直在C++中使用C#,C++/CX和WRL来试验WinRT组件.到目前为止,我设法做了我尝试过的所有事情,即使与COM相比,有些东西已经改变,要么让人感到困惑,要么令人沮丧.

我正在尝试的最后一件事,到目前为止,我做不到的是COM的基本架构模式.我只是想创建一个WRL组件的实例,而不是在使用该组件的项目中引用DLL.据我记得这是COM的基本行为,提供COM的CoClass的GUID,使用程序只知道接口,CoCreateInstance将动态加载COM并创建附加到您请求的接口的实例.

我无法找到如何用WRL做到这一点.我已经定义了一些简单的接口,我甚至无法在注册表中找到它们.但是,由于COM可以在没有注册表的情况下使用对象,并且现在存在窗口元数据,我认为这就是原因.

有人在那里知道这不是WinRT的限制(这会使它成为一个非常糟糕的架构......)或者如果有可能如何实现与WRL的后期绑定.

为了说清楚,在调用程序中我只想提供接口的信息(这可以是.h)然后我需要能够使用其GUID或名字对象名称创建WinRT组件的实例.这是我在C++/COM,C#和Java中使用的体系结构模式,因为您可以编写应用程序并支持新功能而无需触及应用程序的某一行,甚至无需重新编译它.

谢谢O. Rouit

Answer 1

到目前为止,还不清楚你究竟想做什么.WRL只是WinRT的C++帮助程序库,如果您使用的是C++(将其视为WRL-is-to-WinRT-as-ATL-is-to-COM).

我们采用C++,因为那是"最原始的",没有像C#或JS那样的虚拟机或运行时.您是否尝试实例化未链接的WinRT对象？如果是这样,那很简单 - ActivateInstance(activateableclassid).真正的问题是你想要实例化什么？如果它是第一方(收件箱/ Windows)组件,它应该工作.这非常像COM,其中ACID就像一个CLSID,ActivateInstance()就像CoCreateInstance().

如果你试图实例化第三方WinRT组件(不是用Windows发布),它会更简单一些.注册第三方WinRT组件的唯一方法是将它们包含在您的包中.包是彼此隔离的,所以你不能拥有,例如,AngryBirds提供一个FOO WinRT对象并在Scrabble包中的应用程序中使用它.与COM机器范围内的注册不同(或者甚至在HKCU下注册而不是HKLM,用户范围内),WinRT第三方(包装)WinRT对象仅注册供该包中的应用程序使用.(1)

(1)那是一个小小的谎言.从技术上讲,您的应用程序可以实例化随程序包图形中的程序包提供的Windows和WinRT组件提供的WinRT组件.您可以创建一个包含WinRT对象的Framework包,并让您的应用程序包依赖于它.Windows认为我们的软件包取决于框架,因此您的"软件包图"中包含2个软件包 - 您的应用程序包和框架包.但是您无法向商店提交Framework包.本地开发和企业/侧载部署可以执行此操作(它们不通过商店,因此不需要满足商店提交条件),但提交到商店的任何应用程序包只能依赖于Windows提供的框架(WinJS,VCLibs,PlayReady/DRM).这就是PlayReady的工作方式 - 它是一个包含(以及其他)一些WinRT对象的Framework包; 如果您的应用程序包声明了它,您的包图将包含2个包(您的应用程序包+ playready的包),ActivateInstance()可以解析包图中包的联合中的ACID.

应用程序模型中内置了很多保护措施.这是其中之一.这可以防止'COM地狱'和'DLL地狱' - 一切都很好,然后6个月后你安装应用程序Y并且没有明显的原因app X不再有效.新的appmodel旨在防止这种情况.

另一个保护是限制可以找到包装的WinRT对象.即使您将文件放在应用程序的本地文件夹中(例如ApplicationData.current.localFolder),ActivateInstance()也无法找到它.WinRT不会在AppData(或其他地方的oodles)下查看已注册的WinRT对象 - 仅包含在包图中的那些(以及随操作系统提供的第一方(Windows)组件,例如StorageFolder).

提供COM的CoClass的GUID,using程序只知道接口,CoCreateInstance将动态加载COM并创建一个附加到您请求的接口的实例.该WinRT的相当于是提供ACID的的runtimeclass的的WinRT的 [成分],使用该程序只知道有关接口和ActivateInstance()将动态加载的WinRT [成分],并创建连接到您请求的接口的实例.

需要注意的是,WinRT组件的实现必须在您的包图中注册,即必须列在应用程序包的AppXManifest.xml或依赖项的AppXManifest.xml中.

如果您直接在ABI级别处理WinRT,那么这是最原始的级别.C++投影是等价的,只是更方便的语法.CLR和JS运行时提供了自己的附加功能和执行变体(例如,搜索"windows 8 javascript local vs web compartment"),但它们只是进一步为行为着色.他们无法否决底层操作系统的基线行为.

达米尔指出

您将无法以任何其他方式将新文件放入安装文件夹,这是应用程序可以从中加载可执行代码的唯一位置."可执行代码"有不同的形式,具体取决于您的定义.

WinRT组件可以从其他地方加载(Windows提供的WinRT组件,依赖包,例如PlayReady框架包).

(非WinRT,非COM)"本机"DLL可以从其他位置(可执行文件的目录,System32等)加载.请参阅Windows商店应用的搜索顺序.

DLL中的.NET程序集有自己类似的限制,例如Assembly.Load().

有些人认为Javascript是"代码",并且整个本地与网络隔离的东西进一步着色,可以从中解析代码.

作为一般规则,您可以通过各种方式动态加载代码,但它需要是已知代码.没有支持的方法可以创建例如一个C++应用程序,它将加载在商店提交时未知的DLL(WinRT或非WinRT).您可以使用可选(有条件加载)代码编写应用程序,您可以使用"插件" - 但是当您提交到商店时,它们需要在您的包中.

您无法像今天一样构建Outlook,其中Outlook使用开放式插件模型提交到商店,稍后安装Outlook可以查找和使用的OutlookNiftyCalendar插件.不在Windows 8中.

(有一些方法可以通过网络空间在Javascript应用程序中稍微改变一下这个规则,但这本身就是一个复杂的主题,即使这样也会限制硬/软/政策.如果你不写,则无关紧要一个Javascript应用程序)