Загрузка компонента WinRT без ссылки на DLL / сборку
Я экспериментировал с компонентами WinRT, используя C #, C ++ / CX и WRL в C ++. До сих пор мне удавалось делать все, что я пытался, даже если по сравнению с COM некоторые вещи изменились и либо сбивают с толку, либо расстраивают.
Последнее, что я пытаюсь и пока не могу сделать, — это базовый шаблон архитектуры COM. Я просто хочу создать экземпляр компонента WRL без ссылки на библиотеку DLL в проекте, который использует компонент. Насколько я помню, это базовое поведение COM, предоставьте GUID CoClass для COM, использующая программа знает только об интерфейсе, а CoCreateInstance динамически загрузит COM и создаст экземпляр, подключенный к запрашиваемому интерфейсу. ,
Я не могу найти, как это сделать с WRL. Я определил несколько простых интерфейсов, и я даже не могу найти их в реестре. Однако, так как это возможно с COM, чтобы использовать объект без реестра и что теперь есть метаданные окна, я предполагаю, что это является причиной.
Знает ли кто-то там, не является ли это ограничением WinRT (что сделало бы его очень плохой архитектурой …) или в случае, если возможно, как добиться позднего связывания с WRL.
Чтобы было понятно, в вызывающей программе я хотел бы предоставить только информацию об интерфейсе (это может быть .h), тогда мне нужно иметь возможность создать экземпляр компонента WinRT, используя его GUID или имя моникера. Это шаблон архитектуры, который я использовал в C ++ / COM, C # и Java, так как вы можете написать приложение и поддерживать новые функции, не затрагивая строку приложения, даже не перекомпилируя ее.
Спасибо
О. Руит
Решение
Пока неясно, что вы на самом деле пытаетесь сделать. WRL — это просто вспомогательная библиотека C ++ для WinRT, если вы используете C ++ (представьте, что это WRL-is-to-WinRT-as-ATL-is-to-COM).
Давайте возьмем C ++, так как это «самый сырой» и не имеет vm или времени выполнения, как C # или JS. Вы пытаетесь создать экземпляр объекта WinRT, с которым вы не связались? Если это так, то все просто — ActivateInstance (activableclassid). Настоящий вопрос что вы пытаетесь создать? Если это сторонний компонент (входящие / Windows), он должен просто работать. Это очень похоже на COM, где ACID похож на CLSID, а ActivateInstance () похож на CoCreateInstance ().
Если вы пытаетесь создать сторонний компонент WinRT (не поставляется с Windows), это немного проще. ТОЛЬКО Зарегистрировать сторонние компоненты WinRT можно, включив их в свой пакет. Пакеты изолированы друг от друга, поэтому вы не можете иметь, например, AngryBirds доставляет объект FOO WinRT и использует его в приложении из пакета Scrabble. В отличие от COM где регистрация распространяется на всю машину (или в редких случаях, даже если вы регистрируетесь в HKCU вместо HKLM для всего пользователя), WinRT-объекты WinRT третьей стороны (package’d) регистрируются только для использования приложениями в этом пакете. (1)
(1) Это маленькая белая ложь. Технически ваше приложение может создавать экземпляры компонентов WinRT, предоставляемых с компонентами Windows и WinRT, предоставляемыми пакетами. в графе вашего пакета. Вы Можно создайте пакет Framework, который включает в себя объекты WinRT, и от этого зависит пакет вашего приложения. Windows считает, что ваш пакет зависит от фреймворка, и поэтому ваш «пакетный график» имеет 2 пакеты в нем — пакет вашего приложения и пакет фреймворка. НО Вы не можете отправлять пакеты Framework в Магазин. Это могут сделать локальные разработки и корпоративные / боковые загрузки (они не проходят через Магазин и, следовательно, не должны соответствовать критериям отправки Магазина), но любой пакет приложений, представленный в Магазин, может зависеть только от предоставленных Windows платформ. (WinJS, VCLibs, PlayReady / DRM). Вот как работает PlayReady — это пакет Framework, содержащий (помимо прочего) некоторые объекты WinRT; если пакет вашего приложения объявляет a на нем, ваш граф пакетов будет содержать 2 пакета (пакет вашего приложения + пакет playready), и ActivateInstance () может разрешать ACID через объединение пакетов в вашем графе пакетов.
В модель приложения встроено множество средств защиты. Это одна из них. Это предотвращает «COM Hell» и «DLL Hell» — все хорошо, затем через 6 месяцев вы устанавливаете приложение Y и без видимой причины приложение X больше не работает. Новая appmodel предназначена для предотвращения этого сценария.
Другой защитой является ограничение того, где можно найти объекты WinRT в пакетном режиме. Даже если вы поместите файл в локальную папку вашего приложения (например, ApplicationData.current.localFolder), ActivateInstance () не найдет его. WinRT не просматривает AppData (или кучу других мест) для зарегистрированных объектов WinRT — только те, что находятся в графе вашего пакета (и компоненты сторонних производителей (Windows), предоставляемые вместе с ОС, например, StorageFolder).
укажите GUID класса CoClass COM, который знает использующая программа
только про интерфейс и CoCreateInstance будет динамически загружаться
COM и создать экземпляр, подключенный к интерфейсу, который вы
запрос.
Эквивалентом WinRT является предоставление ACID из runtimeclass из WinRT [компонент], использующая программа знает только об интерфейсе и ActivateInstance () будет динамически загружать WinRT [компонент] и создайте экземпляр, подключенный к запрашиваемому интерфейсу.
Предостережение заключается в том, что реализация компонента WinRT должна быть зарегистрирована в графе вашего пакета, т. Е. Должна быть указана в AppXManifest.xml пакета вашего приложения или в AppXManifest.xml зависимости.
Это на самом сыром уровне, если вы имеете дело непосредственно с WinRT на уровне ABI. C ++ проекции эквивалентны, просто более удобный синтаксис. Среды выполнения CLR и JS предоставляют свои собственные дополнения и варианты принудительного применения (например, поиск «локальный JavaScript 8 по сравнению с веб-отделом»), но они только дополнительно окрашивают поведение. Они не могут отменять базовое поведение базовой ОС.
Как отметил Дамир
Вы не сможете поместить новые файлы в папку установки другим способом и
это единственное место, откуда исполняемый код может быть загружен
приложение.
«Исполняемый код» может быть различной формы, в зависимости от вашего определения.
Компоненты WinRT могут быть загружены из других мест (предоставленные Windows компоненты WinRT, зависимые пакеты, например, пакет платформы PlayReady).
(Не WinRT, не COM) «родные» DLL могут быть загружены из других мест (каталог исполняемого файла, System32 и т. Д.). Увидеть Поиск заказа для приложений магазина Windows.
.Сборки NET в DLL имеют свои аналогичные ограничения, например Assembly.Load ().
Некоторые люди считают Javascript «кодом», и существует целый ряд локальных и веб-разделов, чтобы придать цвет, в котором можно найти код.
Как правило, вы можете динамически загружать код различными способами, но это необходимо известен код. Там нет поддерживаемого способа, которым вы можете создать, например. приложение C ++, которое будет загружать библиотеки DLL (WinRT или не-WinRT), которые не известны во время отправки в магазин. Вы Можно написать приложение, используя дополнительный (условно загруженный) код, вы Можно есть плагины — но они должны быть в вашем пакете, когда вы отправляете их в Магазин.
Вы не можете построить, например, Outlook в том виде, в каком он есть сегодня, где Outlook отправляется в Магазин с открытой моделью подключаемого модуля и через некоторое время устанавливает надстройку OutlookNiftyCalendar, которую Outlook может найти и использовать. Не в Windows 8.
(Есть несколько способов, которыми вы можете немного согнуть это правило в приложении Javascript через веб-отдел, но это сложная тема сама по себе, и даже она имеет ограничения, как жесткие, так и программные. Политика не имеет значения, если вы не пишете JavaScript-приложения)
Другие решения
Других решений пока нет …