как приложение metro в windows 8 может взаимодействовать с бэкэнд-настольным приложением на том же компьютере?

<p>в ситуации, когда у вас есть пользовательский интерфейс, созданный с использованием нового стиля приложений metro для windows 8, и вы хотите, чтобы он взаимодействовал с приложением .net, работающим на рабочем столе на том же локальном компьютере (например, приложение службы windows).</p><p>какие формы межпроцессного взаимодействия доступны между приложением метро и настольным приложением?</p><p>спасибо павлу минаеву из команды visual studio, который предоставил некоторую начальную информацию здесь в комментарии, цитируя:</p><blockquote> <p>по словам мартина ловелла, для этого нет никакого преднамеренного механизма, и некоторые из них, которые могут быть использованы для него, намеренно ограничены. например, именованных каналов там нет, равно как и файлы с отображением в памяти. есть сокеты (включая сокеты сервера), но при подключении к localhost вы можете подключиться только к одному и тому же приложению. вы можете использовать обычные файлы в одной из общих "известных папок" ("документы", "изображения" и т.д.), но это довольно грубый взлом, который требует опроса и является видимым для пользователя. - <a href="https://stackoverflow.com/users/111335/pavel-minaev">павел минаев</a> комментируя <a href="https://stackoverflow.com/questions/7416826/how-does-the-new-windows-8-runtime-compare-to-silverlight-and-wpf">этот выпуск</a> </p> </blockquote><p>поэтому, отказываясь от нормальных подходов, я думал об использовании веб-сервисов или чтении/записи в базу данных для того, чтобы получить какую-то форму общения, оба из которых кажутся излишними, когда процессы работают на одной и той же машине.</p><p>имеет ли смысл то, что я пытаюсь здесь сделать? я вижу необходимость в приложении метро в качестве внешнего интерфейса для существующего сервиса, который работает на рабочем столе. или же лучше просто использовать wpf для интерфейса пользователя, работающего на рабочем столе (то есть, не в метро).</p>

<p>я портирую свой существующий проект на win8 прямо сейчас. он состоит из службы windows и приложения трей, которые общаются друг с другом через wcf namedpipes. как вы уже знаете, metro не поддерживает именованные каналы. я закончил тем, что использовал tcpbinding для полнодуплексного соединения.</p><p> <a href="http://blogs.msdn.com/b/piyushjo/archive/2011/10/19/wcf-for-metro-apps-supported-functionality.aspx">этот пост</a> описывает, какие функции поддерживаются.</p><p>пример моего wcf-сервера, который может использовать клиент metro, <strong> <a href="https://stackoverflow.com/questions/9372667/endpoint-is-not-compatible-with-version-1-of-windows-immersive-project">здесь</a> </strong>.</p><p>также имейте в виду, что вы не можете использовать синхронный wcf в metro. вам нужно будет использовать <a href="http://msdn.microsoft.com/en-us/library/system.threading.tasks.task.aspx">task</a> - обертку на основе, которая является только асинхронной.</p><p>и спасибо за ваш вопрос. я был хорошей отправной точкой для меня :)</p>

<p>в конце собрания, которое я посетил, было несколько таких вопросов. алеш голечек, исполнительный директор, который сделал одну из самых больших картинных сессий, вышел из зала, чтобы справиться с ними. даже если вы не являетесь разработчиком c++, скачайте этот сеанс и посмотрите q & a. <a href="http://channel9.msdn.com/events/build/build2011/tool-789c">http://channel9.msdn.com/events/build/build2011/tool-789c</a> </p><p>приложения metro не могут рассчитывать на настольные приложения или службы, установленные на компьютере. а настольные приложения не могут рассчитывать на запущенные приложения metro, поскольку их можно в любой момент приостановить. вы должны начать думать по-другому. послушай алеша об этом.</p>

<p>обратите внимание, что в windows 8.1 update связь между приложениями магазина windows и компонентами рабочего стола, написанными на c # для .net 4.5+, теперь официально поддерживается для приложений с боковой загрузкой в сценариях enterprise:</p><p> <a href="http://msdn.microsoft.com/en-us/library/windows/apps/dn630195.aspx">посреднические компоненты среды выполнения windows для загруженных приложений магазина windows</a> </p><p>цитировать:</p><blockquote> <p>признавая, что критически важные бизнес-функции и правила воплощены в существующих программных активах и что предприятия имеют широкий спектр сценариев, для которых новый стиль приложения будет высокопроизводительным, обновление windows 8.1 включает новую функцию под названием brokered windows runtime components для боковой загрузки. приложения. мы используем термин ipc (межпроцессное взаимодействие) для описания возможности запуска существующих программных активов настольных компьютеров в одном процессе (компонент рабочего стола) при взаимодействии с этим кодом в приложении магазина windows. это знакомая модель для корпоративных разработчиков, так как приложения базы данных и приложения, использующие службы nt в windows, имеют схожую многопроцессорную архитектуру.</p> </blockquote><p>хотя реализация этого подхода поначалу немного сложна, она допускает глубокую интеграцию между компонентами магазина windows и компонентов рабочего стола. просто помните, что пока он не пройдет публичную сертификацию windows store.</p>

<p>существует <a href="http://www.infoq.com/news/2011/09/metro-protocols">статья</a> on <a href="http://www.infoq.com">infoq</a> о том, как создавать слабосвязанные приложения metro с обработчиками протоколов. это то, что долгое время поддерживалось windows, и можно было ожидать, что настольное приложение зарегистрирует себя в качестве обработчика протокола, и, возможно, приложение metro сможет обмениваться данными через этот механизм.</p><p>я понятия не имею, если это возможно, но это может быть интересно проверить.</p>

<p>если вы считаете, что можете выполнить дополнительную ручную операцию cmd, вы можете попробовать:</p><pre><code>x:/> checknetisolation.exe loopbackexempt –a –n=<packageid>; </code></pre><p>checknetisolation.exe включен в установку winrt, поэтому не нужно устанавливать ничего лишнего.</p><p>я попробовал: работает даже после обновления пакета.</p><p>как показано на: <a href="http://msdn.microsoft.com/en-us/library/windows/apps/hh780593.aspx">http://msdn.microsoft.com/en-us/library/windows/apps/hh780593.aspx</a> </p><p>здесь объясняется, как узнать идентификатор пакета для вашего приложения: <a href="http://social.msdn.microsoft.com/forums/windowsdesktop/en-us/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get-the-appid-of-a-metro-style-app-">http://social.msdn.microsoft.com/forums/windowsdesktop/en-us/82bad7d4-d52b-4731-a396-13ab9004c1cc/how- в-получить заместитель appid-оф-а-метро-стиль-приложение -</a> </p>

<p>кристоф насарре <a href="http://iinspectable.wordpress.com/2013/06/04/inter-process-silent-communication-in-winrt-part-4/">опубликовал в блоге</a> довольно хакерский способ сделать это, используя локальные файлы. в результате происходит обмен данными между настольным приложением/приложением магазина windows (в блоге называется da/wsa) без необходимости переключения между пользовательским интерфейсом двух приложений. он также написал в блоге об еще одной менее хакерской технике, связанной с обработчиками протоколов.</p><p>обратите внимание, что наличие wsa, который взаимодействует с da, <em> явно запрещено </em> магазином <a href="http://msdn.microsoft.com/en-us/library/windows/apps/hh694083.aspx">требования к сертификации приложения</a> </p><blockquote> <p>приложения магазина windows не должны связываться с локальными настольными приложениями или службами через локальные механизмы, в том числе через файлы и ключи реестра.</p> </blockquote><p>... но это ограничивает только "локальные механизмы". поэтому я думаю, что можно построить веб-сервис для маршрутизации сообщений.</p>

<p>на одной машине можно общаться из приложения metro с настольным приложением, используя локальный сервис. некоторое время назад я реализовал простое "доказательство концепции", как обойти песочницу winrt с помощью локального сервиса. для установки службы по-прежнему нужна какая-то "социальная инженерия" или прямое руководство, но в любом случае это возможно.<br> однако я не уверен насчет правил сертификации связи "локальный сервис" при добавлении такого приложения в магазин windows.</p><p> <a href="http://suchan.cz/wp7/outofsandboxsample.7z">образец здесь</a> </p><blockquote> <p>по своему дизайну приложение metro не может напрямую обращаться к базовому пк, только используя winrt api и доступные возможности но когда вы создаете бэк-сервис для доступа к пк и всем данным на нем, он больше не работает в песочнице.</p> <p>единственная "проблема" состоит в том, что пользователь должен вручную установить эту серверную службу, но это не будет проблемой при использовании некоторой "социальной инженерии": пользователь загружает приложение metro для браузера пк, пользователь может просматривать все изображения, музыку и видео , используя winrt api, но приложение также отображает сообщение внизу: "загрузите наш браузер для пк и просмотрите весь компьютер бесплатно"</p> <p>пользователь перенаправляется на веб-страницу, откуда пользователь может загрузить классический установщик рабочего стола, содержащий серверную службу "пк-браузер" для доступа к файлам на всем пк пользователя. как только эта служба рабочего стола установлена, приложение metro может обнаружить ее и использовать для просмотра всего пк. пользователь доволен, но песочница winrt взломана.</p> <p>конечно, это не будет работать на планшетах с windows 8 arm. используя этот обходной путь, можно даже создать клиенты приложений metro для классических настольных приложений, таких как антивирусы, клиенты torrent/p2p и т.д.</p> </blockquote>

<p>может быть, я упустил момент, но при активации возможности частных сетей я могу подключиться к локальному работающему (http) серверу, используя локальный ip-адрес (не localhost). это включает мой сценарий, когда приложение winrt связывается с настольным приложением wpf</p>