これまでのところ、実際に何をしようとしているのかは不明です。C++ を使用している場合、WRL は WinRT 用の単なる C++ ヘルパー ライブラリです (WRL-is-to-WinRT-as-ATL-is-to-COM と考えてください)。
C++ を見てみましょう。これは「最も生」であり、C# や JS のような vm やランタイムがないためです。リンクしていない WinRT オブジェクトをインスタンス化しようとしていますか? もしそうなら、それは簡単です - ActivateInstance(activateableclassid)。本当の問題は、何をインスタンス化しようとしているのかということです。ファースト パーティ (受信トレイ/Windows) コンポーネントの場合は、そのまま動作するはずです。これは、ACID が CLSID のようなもので、ActivateInstance() が CoCreateInstance() のような COM によく似ています。
サード パーティの WinRT コンポーネント (Windows には同梱されていません) をインスタンス化しようとしている場合は、もう少し簡単です。サード パーティの WinRT コンポーネントを登録する唯一の方法は、それらをパッケージに含めることです。パッケージは互いに分離されているため、たとえば AngryBirds が FOO WinRT オブジェクトを提供し、それを Scrabble パッケージのアプリで使用することはできません。登録がマシン全体で行われるCOM とは異なり(まれに、ユーザー全体で HKLM ではなく HKCU で登録することさえあります)、WinRT サード パーティ (パッケージ化された) WinRT オブジェクトは、そのパッケージ内のアプリで使用するためにのみ登録されます。(1)
(1) それはちょっとしたうそです。技術的には、アプリケーションは、Windows で提供される WinRT コンポーネントと、パッケージ グラフ内のパッケージによって提供される WinRT コンポーネントをインスタンス化できます。WinRT オブジェクトを含むフレームワーク パッケージを作成し、アプリケーションのパッケージをそれに依存させることができます。Windows は、パッケージがフレームワークに依存していると判断するため、「パッケージ グラフ」にはアプリのパッケージとフレームワーク パッケージの2 つのパッケージが含まれます。しかしフレームワーク パッケージをストアに提出することはできません。ローカル開発およびエンタープライズ/サイドローディング展開はこれを行うことができます (それらはストアを経由しないため、ストアの送信基準を満たす必要はありません)。ただし、ストアに送信されるアプリケーション パッケージは、Windows が提供するフレームワークにのみ依存できます。 (WinJS、VCLibs、PlayReady/DRM)。これが PlayReady の仕組みです。これは、(とりわけ) いくつかの WinRT オブジェクトを含むフレームワーク パッケージです。アプリケーションのパッケージが を宣言している場合、パッケージ グラフには 2 つのパッケージ (アプリのパッケージ + playready のパッケージ) が含まれ、ActivateInstance() はパッケージ グラフ内のパッケージの結合全体で ACID を解決できます。
アプリケーション モデルには多くの保護機能が組み込まれています。これはそれらの1つです。これにより、'COM Hell' と 'DLL Hell' が防止されます。すべて問題なく、6 か月後にアプリ Y をインストールすると、明確な理由もなくアプリ X が機能しなくなります。新しい appmodel は、そのシナリオを防ぐように設計されています。
もう 1 つの保護は、パッケージ化された WinRT オブジェクトが見つかる場所の制限です。アプリのローカル フォルダー (例: ApplicationData.current.localFolder) にファイルを配置しても、ActivateInstance() はそれを見つけられません。WinRT は、登録された WinRT オブジェクトの AppData (または他の場所の山) の下を調べません。パッケージ グラフ (および OS で提供されるファースト パーティ (Windows) コンポーネント (StorageFolder など)) 内のもののみです。
COM の CoClass の GUID を提供すると、使用するプログラムはインターフェイスのみを認識し、CoCreateInstance は動的に COM をロードし、要求しているインターフェイスにアタッチされたインスタンスを作成します。WinRT に相当するのは、WinRT [コンポーネント] のランタイム クラスの ACID を提供することです。使用するプログラムはインターフェイスについてのみ認識し、ActivateInstance ()はWinRT [コンポーネント]を動的に読み込み、要求しているインターフェイスにアタッチされたインスタンスを作成します。 .
注意点として、WinRT コンポーネントの実装はパッケージ グラフに登録する必要があります。つまり、アプリのパッケージの AppXManifest.xml または依存関係の AppXManifest.xml にリストする必要があります。
ABI レベルで WinRT を直接扱う場合、これは最も生のレベルです。C++ プロジェクションは同等で、より便利な構文です。CLR および JS ランタイムは、独自の追加および適用のバリエーションを提供します (たとえば、「windows 8 javascript ローカル vs Web コンパートメント」を検索します) が、動作をさらに色付けするだけです。基盤となる OS の基本動作を覆すことはできません。
ダミールが指摘したように
他の方法で新しいファイルをインストール フォルダーに配置することはできず、アプリが実行可能コードを読み込むことができる唯一の場所です。「実行可能コード」には、定義に応じてさまざまな形式があります。
WinRT コンポーネントは、他の場所 (Windows が提供する WinRT コンポーネント、PlayReady フレームワーク パッケージなどの依存パッケージ) から読み込むことができます。
(非 WinRT、非 COM) 'ネイティブ' DLL は、他の場所 (実行可能ファイルのディレクトリ、System32 など) から読み込むことができます。Windows ストア アプリの検索順序 を参照してください。
DLL 内の .NET アセンブリには、Assembly.Load() などの独自の同様の制限があります。
Javascript を「コード」と見なす人もいます。コードを解決できる場所をさらに色分けするために、ローカルと Web のコンパートメント全体が存在します。
原則として、さまざまな方法でコードを動的にロードできますが、それは既知のコードである必要があります。たとえば、ストアの送信時に不明な DLL (WinRT または非 WinRT) を読み込む C++ アプリを作成できるサポートされている方法はありません。オプションの (条件付きで読み込まれる) コードを使用してアプリを作成できます。「プラグイン」を使用することもできますが、ストアに送信するときにプラグインがパッケージに含まれている必要があります。
たとえば、Outlook が無制限のプラグイン モデルを使用して Store に送信され、後で Outlook が見つけて使用できる OutlookNiftyCalendar アドオンをインストールする現在の Outlook を構築することはできません。Windows 8 にはありません。
(Web コンパートメントを介して Javascript アプリでこのルールを少し曲げる方法はいくつかありますが、それ自体が複雑なトピックであり、ハードとソフト/ポリシーの両方に制限があります。書いていない場合は無関係です。 Javascript アプリケーション)