1

つまり、基本的に、デバッガーに関する私の些細な調査で、元のプロセスの周りにラッパーを作成することでデバッガーが機能し、プロセスはラッパー内で実行されます(デバッガーが既に実行中のプロセスに接続されているシナリオではありません)。では、メトロアプリではどのように機能しますか?Metroアプリは、インストール時に割り当てられたアプリコンテナー内でのみ実行でき(実際には、Metroアプリは本当の意味でインストールされません)、アプリコンテナーとMetroアプリ間のマッピングはレジストリキーに記録されます。(すべて私の研究から、私が間違っている場合は私を修正してください)。では、デバッガーも同じアプリコンテナー内で実行されますか?

編集:私がこれを学びたかった理由についての短いメモ。私はこれで立ち往生しています。そのため、デスクトップアプリをデバッガーとして作成し(またはデバッガーを自動化すると、これはさらに不気味になります)、DebugBreakを使用してメトロアプリとデスクトップアプリ間の通信をシミュレートすることで、このIPCを実現できるかどうかを考えていました(メトロアプリ内から) )およびContinueステートメント(疑似デバッガーアプリから)

4

2 に答える 2

3

「ラッパー」のイメージは間違っています。デバッガーは、組み込みのWindowsサポートを使用してデバッグする別個のプロセスです。SE_DEBUG特権があり、通常のデスクトップアプリ特権を持つアプリによって開始されます。VisualStudioのように。したがって、AppContainer自体の内部では実行されません。

于 2012-06-22T06:24:06.553 に答える
1

ハンの答えは正しい。Metroスタイルアプリの場合、アプリを一時停止して起動できる新機能を導入し、コマンドラインオプションを使用して登録済みのデバッガーを起動し、接続するプロセスを指定します。この機能の詳細については、 IPackageDebugSettings APIを参照するか、使用例についてはhttp://winrt.codeplex.comプロジェクトを確認してください。確かではありませんが、このAPIには開発者ライセンスの制限がある可能性があります。

メトロスタイルアプリとデスクトップアプリの間でIPCをサポートするという当初の意図については、リンクされたスレッドが述べているように、これはサポートされていません。

于 2012-08-09T18:38:56.137 に答える