Microsoft-ui-xaml: 👩‍💻📞WinUIコミュニティコール（2020年2月19日）

Windows10Xの開発について質問があります。 そのために開発するには、エミュレータが必要ですが、AMDプロセッサ（ネストされた仮想化）はいつサポートされますか？ Windows 10 2003バージョンを信頼できますか？

＃1958に基づくWinUIに関連して、ライブタイルの将来はどうなりますか？

AMD Ryzenのサポートにより、エミュレーターの実行が妨げられているため、いつ修正されるかについての情報を聞くとよいでしょう。

@ jp-weber @mdtauk

これは公式の文言です（https://docs.microsoft.com/en-us/dual-screen/windows/get-dev-tools）：

現時点では、AMDプロセッサはサポートされていません。 エミュレータでWindows10Xを実行するには、ネストされた仮想化が必要ですが、WindowsはAMDプロセッサでこれをまだサポートしていません。 乞うご期待！

詳細情報が必要な場合は、 dualscreendev @ microsoft.comに連絡する必要があります

@ Felix-Devに感謝します-その通りです。ドキュメントは10Xエミュレーターの最新のステータスを取得するのに最適な場所であり、その電子メールアドレスはWinUIに固有ではない他の10Xの質問の最良の連絡先です。

十分に公平なことですが、Microsoftがそれについて話す準備ができるまで待たなければなりません。

Windows 10Xを見ると、Win32アプリはVEILコンテナーで実行されます。 WinUI 3.0以外のUWPアプリはどうですか？

ネイティブUWPアプリが10Xで実行するのと同じように実行されるように見えますか？

@mdtauk WinUIデスクトップアプリはネイティブのUWPアプリではないため、UWPコンテナーで実行されるとは思いません。 Win32アプリの（すべての）機能を備えているため、前述のWin32コンテナーで実行されると思います。

また、今後のWinUIアプリの分離の計画についても知りたいと思います。 企業の観点からは、分離/サンドボックス化と機能制御（ユーザーのオプトインではない）が必要です。 だから、これをミゲルのトピックとしてそこに出す。

@mdtauk WinUIデスクトップアプリはネイティブのUWPアプリではないため、UWPコンテナーで実行されるとは思いません。 Win32アプリの（すべての）機能を備えているため、前述のWin32コンテナーで実行されると思います。

これは少し残念です。 Win32アプリは、異なるウィンドウ動作を示し、フォアグラウンドにあるときに画面を暗くするように見えます。 そのため、切り替えの動作も異なります。

Xaml UIを使用することで、WinUIデスクトップアプリが、少なくともユーザーにとっては、両方の世界のシナリオの中で最良のものになることを期待しています。

@mdtauk現在リリースされている10Xエミュレーターイメージはまだ非常に早いので、あなたが気付いた問題/動作（私もテストで行いました）はリリースまで対処/変更されると確信しています（つまり、Win32アプリもあります。今すぐロードに失敗します）。

そうは言っても、10XのWinUIデスクトップアプリコンテナで修正されることを嬉しく思います。 私の現在の考えは、これまでにWinUIデスクトップ（Win32アプリモデル）、10XプレゼンテーションHow Windows 10X runs UWP and Win32 apps 、およびデスクトップブリッジテストアプリについて話されたことに基づいています。 残念ながら、私のXAML Islandテストアプリは現在エミュレーターにロードできないため（ App Launch Initializedステージでスタックしている）、使用するコンテナーを確認できません。 Win32コンテナではないので、まだWin32アプリなので驚かれることでしょう。 そのすべてが、WinUIデスクトップアプリが10XのWin32コンテナーで実行されると私に信じさせます。

チームに尋ねることは確かに良い質問です！

@ Felix-Devは、20：18分にあなたが言及した同じビデオ（Windows 10XがUWPおよびWin32アプリを実行する方法）によると、ハイブリッドアプリ（Win32 / UWP）は（まだ？）サポートされていないと言っています。 XAMLアイランドを使用するハイブリッドアプリです。

Q1）SwapchainPanelはいつWinUIで利用可能になりますか？ これは私や他の多くの人がすることにとって絶対に不可欠です。

Q2）SharpDXは作成者によってサポートされなくなったため、Microsoftはステップアップして、SharpDXとWinUIのハードウェアレンダリングサーフェス間の互換性を提供しますか？ MSは、SharpDXを使用せずにC＃を使用したハードウェアレンダリングのストーリーを見ていますか？ そして、私はUnityを気にしません。つまり、C＃で独自のグラフィックツール、エンジン、およびUnity以外のゲームを作成するための、制限のない自由形式のグラフィック開発を意味します。 また、Win2dを意味するのではなく、完全なハードウェアレンダリング機能（DirectX）が必要です。

Q3）アプリケーションには、マウスを画面の上端と下端に移動したときにTaskBarとTitleBarのポップアップをオフにする機能がありません。 これは、カメラのパンやポップアップなどの独自のUIで画面の端を利用する多くのゲーム（および場合によっては一部のアプリ）にとっては大きな問題です。 これはいつ修正されますか（これはWindowsの問題である可能性がありますが、APIによって駆動される必要があるため、WinUIに関連しています）。

Q4）Xamlをバイパスして、ウィンドウにバインドされたSwapchainに直接レンダリングする場合に備えて、WinUIにCoreWindow（IFrameworkView）アプリモデルを含めることはできますか？

WinUIに非Xamlサーフェスを提供するように要求すると、少し奇妙に聞こえるかもしれません。 ただし、CoreWindowは同じライブラリ内のXamlWindow（UWPではWindowと呼ばれます）に属し、UWPから分離されて.net5で使用できるようになっていると思います。.net5がuwpだけでなく非uwpもターゲットにできると仮定します。 現在、UWP以外に最新のC ++アプリケーションモデルはありません。ゲーム開発者は、レガシーcコード（Win32）を使用して、ゲームまたはグラフィックスアプリのアプリケーション層を作成する必要があります。 .netCoreには最新のデスクトップアプリケーションモデルもありません。 CoreWindow用のUWPのソリューションは、効果的で快適に使用できます。 UWPの外部に存在する必要があります（C ++ / non-uwpと.net5の両方）。 UWPからCoreWindowを引き出すもう1つの利点は、コードをUWPから.net 5（および、uwp以外の最新のアプリケーションモデルを取得した場合はC ++）に直接移植する方法を提供することです。

ゲーム開発者は、ウィンドウ動作が変更され、配布ストーリーが整理されるまで、UWPを使用できません。 マイクロソフトが問題を理解していないように見えるほど長い間です。 したがって、これらのAPIをUWPの外部にプルする必要があります。 UWPが修正された場合、修正する必要はありません。

そして問題1215からのさらなるコメント

非包含/非XamlシナリオでWin32WindowをCoreWindowに置き換え、CoreWindowを.Net 5 Non-UWPに提供すると、非Xaml作業用にWindows全体で統一されたアプリ/ウィンドウモデルを使用できます。 これは、Win32 FOR EVERを保持したり、新しいアプリモデルを作成したりするよりも理にかなっています。

含まれている実行と含まれていない実行を切り替えたいという理由だけでアプリケーション層を書き直す必要があるのはなぜですか（たとえば、UWPとWin32の間）-これは今日のゲーム開発者が直面している典型的な問題です。 Win32の配布の自由が必要です。 そのため、HWndまたは.NetFrameworkアプリモデルを使用する必要があります。 UWPアプリ/ウィンドウモデルがuwpを含まないアプリで利用できるようになった場合、問題ありません。アプリケーションレイヤーに同じコードを記述し、MSストアと他のストアの両方で同じコードベースからコンパイルできます。

@leoniDEVこれの多くは、「ハイブリッドアプリ」が正確に何を意味するのかという憶測です。 たとえば、XAML Islandアプリがそのカテゴリに属していないと言われているこのTwitterスレッドを参照してください（Matteo PaganiはMicrosoftでWindows AppConsult Engineerとして機能します）。 UWPコミュニティのMS従業員は、Win32完全信頼プロセスを実行するUWPアプリのサポートは、ある日はサポートされないが、後で追加される予定であると述べました。

@ Gavin-Williams WinUIには、WinUIUWPとWinUIDesktopの2つのフレーバーがあります。 WinUI UWPを使用すると、Windows10XのUWPコンテナーで実行される完全なUWPアプリを作成できます。 次に、Win32アプリがUWP UI API（XAML、コンポジション、入力など- CoreWindowなどのいくつかのAPIを除く）にフルアクセスできるようにするWinUIデスクトップがあります。 これらのタイプのアプリは、UWPサンドボックスやその他のUWPの設計上の制限に対処する必要はありません。 ただし、これらはUWPアプリではないため、WinUIデスクトップアプリは、UWPアプリが可能な幅広いWindows10デバイスカテゴリをターゲットにすることはできません。
概要については、 WinUIロードマップから取得した以下の画像を参照してください。

WinUIはゼロからC ++で記述されているため、管理されていないアプリのコンテキストで使用できます。

上で強調したように、私の執筆I believe they will run in the mentioned Win32 containerは、WinUI Desktop、10Xで実行した10Xビデオおよびデスクトップブリッジテストアプリについての現在の理解に純粋に基づいています。 私にはインサイダーの知識がありません。 WinUIチームは、WinUIデスクトップアプリと使用される10Xコンテナーの計画を確実に知らせてくれます。ここで修正され、WinUIデスクトップアプリは10XのUWPコンテナーで実行されると言われました。

WinUI / Microsoft UIを使用してアプリを構築するときに、Java、Python、JavaScriptなどの他のプログラミング言語を使用できる可能性についての考えについてもっと知りたいです。

Xlang（cross-lang）と呼ばれるプロジェクトがあることを私は知っています-これは本質的に.NETがどうあるべきか、より良いCOMのように見えます。

それはWinUIとどのように関連していますか？

xlangは、完全な互換性はありませんでしたが、基本的にはWindowsランタイム（WinRT）のクロスプラットフォームのオープンソースバージョンです。 WinRTの目的は、あなたが言ったこと、言語間の相互運用性であり、COMに基づいています。 WinUIのAPIは、C ++とC＃の両方をサポートする方法であるWinRT上に構築されています。 Python 、 Rust （これは私が個人的に取り組んだものです）、 JavaScriptなど、WinRTをさまざまなレベルでサポートしている言語は他にもあり
C ++ / WinRTの作成者であるKennyKerrは、現在、新しいRustWinRTプロジェクションに取り組んでいます。

私は実際、Rustがコンポーザブルタイプ（したがってWinUI）を最適にサポートする方法について最近よく考えています。 それは確かに可能ですが、開発者にとってどれほど自然に感じられるかはまだわかりません。 基本的に、誰かがプロジェクションを作成する作業を行った場合、どの言語でもWinRTをサポートできるはずですが、言語の設計によっては、WinRT型システム構造を言語の型システムにマッピングするのが難しい場合があります。それは自然な感じです。

xlangは私には死んでいるように見えます。 C ++ / WinRTは実際には完成していませんでした。バグと非常に奇妙な使い方の話が残っていたため、平均的な開発者にとっては望ましくありませんでした。 私はC ++ / WinRTを機能させるのに何時間も苦労し、C ++ / CXで30分でやったことを実行できませんでした。 そして、C ++ / CXは、長い目で見れば使いやすかったです。 マイクロソフトがこれらのクロスランゲージツールをアベレージジョーが使用できるようにしたい場合は、人々のチームを問題に巻き込み、すべての作業を自分で行うのはケニーカーに任せないようにする必要があります。 彼はいくつかの素晴らしいアイデアを持っています。 しかし、これらのツールには幅広い魅力が必要であり、彼はこれらの製品を成熟させ、可能な限りすべてのものにするための支援が必要だと思います。

今のところ、UWPとその後継のWinUIはLOBアプリケーションの準備ができていません

私たちが直面しているいくつかの問題があります

• 業績不振。 たとえば、WinUIの依存関係プロパティはhttps://github.com/microsoft/microsoft-ui-xaml/issues/1633よりも50倍遅くなり
• コンパイルパフォーマンスが悪い。 wpfより数倍遅い
• dotnetネイティブ
• リリース間で多くの重大な変更があります。
• サンドボックスと権限モデル
• wpfと比較してサードパーティベンダーのカスタマイズ機能が制限されている

WinUIはこの制限を克服し、今後10年間で次のLOB対応フレームワークになることができると思いますか。 または、電子ブレイザーアプリに進む時が来ました）

WinUIの現在の状態に関していくつか問題があります。

C ++ / WinRTは、C ++ / CXツールや全体的な開発者エクスペリエンスと比較して、依然として非常に貧弱な開発者エクスペリエンスです。 C ++で記述されたWinUIコンポーネントを扱うことが期待される場合、C ++ / CXツールの機能を少なくとも1：1でカバーすることが期待されます。

標準のC ++ 17であることは、C ++ / CXを使用するだけでなく生産性が低下する場合は役に立ちません。また、UWPコンポーネントまたはXAMLベースのUIを作成するのに2倍の時間がかかります。

これは、UWP / WinUIでC ++を処理する必要がある主な理由である、私の2番目の質問につながります。これは、Microsoftが.NET言語へのあらゆる種類のDirectXバインディングでボールを落としたためです。 では、WinUIは、置換やWPF 3DシーングラフなどのXNAのサポートを提供するのでしょうか？ どうやら私たちはここでラジオの沈黙を得るだけであり、MonoGameのようなコミュニティプロジェクトやUnityのような本格的なエンジンに入ることを余儀なくされています。

Win2Dが最終的にWinUIの一部になるのはいつですか？ 現在、将来は不透明なメンテナンスモードになっているようです。

現在、私の石鹸箱の周りのリスナーの数が減り続けているため、UWPの夢を売り続けることは非常に困難になっています。

Windows 10XUI要素がデスクトップWindows10に移行するのはいつですか？

@carmellolb 2022-2025？

編集：MSはおそらくこれを削除します。これは、製品の配送スケジュールを提案しているためです。これは存在しないため、誤解を招く可能性があります;）

@ Felix-Dev "WinUI Desktop ..は、Win32アプリがUWP UIAPIにフルアクセスできるようにします..CoreWindowなどのいくつかのAPIを除きます。

CoreWindowを除外しますか？ OMG-これは、UWPから取得する必要がある最初の最も重要なAPIです。 これは、基本的なウィンドウ機能を提供する最も基本的なAPIです。 UWPコンテナの内外でユニバーサルである必要があります。 それが発表されるまで、アプリケーション層の共通のコードベースを持つことはできず、C ++またはC＃用に提供される.netコア（別のWindowクラス？）のレガシーWin32cコードで立ち往生しています。

Microsoftにお願いします-UWPの内外でXamlWindowを提供しているのと同じように、UWPの内外でCoreWindowも提供してください。

電話について：なぜTeamsから離れたのですか？ YouTubeは最後のものではあまりうまくいきませんでした。

@ Gavin-Williams

https://github.com/microsoft/microsoft-ui-xaml/issues/1215#issuecomment -531994216から：

私たちのアプローチは、WinUI 3がUWPで実行されている場合はCoreWindowを使用し、デスクトップ（Win32）で実行されている場合はWin32 Window（HWind）を使用するというものです。

UWPアプリのWinUI3は、AppWindowAPIを使用できるようになります。 デスクトップの場合、同様のものを出す必要があります。 私たちはまだこれを設計しているので、これ以上の詳細はありません。

チームはまた、WinUIデスクトップ用のCoreApplicationViewTitleBar.ExtendViewIntoTitleBarなどのAPIも提供することを検討しているため、両方の長所を活用できる可能性があると述べました。 Win32ウィンドウデザインのフルパワー（つまり、タイトルバーなし/ 100％カスタムタイトルバー、アプリウィンドウ<必要な最小サイズ、タスクバーボタンなしなど）と新しい最新のUWPカスタマイズAPI。 （UWPの場合、AppWindow V2が現在のWin32ウィンドウ機能に近いウィンドウ機能を備えているのを待つ必要があります。）

@jesbis WinUIデスクトップに関する質問：問題https://github.com/microsoft/microsoft-ui-xaml/issues/1939で、トースト通知のアクティブ化が（少なくとも）上のMSIXパッケージデスクトップアプリでは機能しないことが指摘されています。ドキュメントに記載されている1909年：

デスクトップブリッジアプリの場合は、UWPアプリのようにトースト通知を送信するだけです。 ユーザーがトーストをクリックすると、トーストで指定した起動引数を使用してアプリがコマンドラインで起動されます。

上記の修正がデスクトップブリッジアプリの影響を受けるOSバージョンにバックポートされるかどうかを待つ必要がありますが、私の質問は次のとおりです。WinUIデスクトップアプリは、上記のすぐに使用できるトーストアクティベーション機能を提供します（したがって、使用する必要はありません）。すべてのWinUIターゲットWindows10バージョンのCOMアクティベーター）？ （または同様のトーストアクティベーションの概念。）

@ Felix-Devドキュメントから、XAML Islandは厳密にはハイブリッドアプリを意味しないようです。理解していれば、カスタムコントロールの使用など、一部の機能を失うことを犠牲にして、Win32アプリから直接UWPXAMLホスティングAPIを呼び出すことができます。正しくドキュメント（およびドキュメント内のメモ）：

XAMLアイランドを使用してWPFアプリで標準のUWPコントロールをホストする

必要なコンポーネント

アプリのプロジェクトとソースコード。 WindowsXamlHostコントロールを使用して標準のファーストパーティUWPコントロールをホストすることは、.NETFrameworkまたは.NETCore3を対象とするアプリでサポートされています。

XamlApplicationから派生するルートアプリケーションクラスを定義するUWPアプリプロジェクト。 WPFまたはWindowsフォームプロジェクトは、Windows CommunityToolkitによって提供されるMicrosoft.Toolkit.Win32.UI.XamlHost.XamlApplicationクラスのインスタンスにアクセスできる必要があります。 このオブジェクトは、アプリケーションの現在のディレクトリにあるアセンブリにカスタムUWPXAMLタイプのメタデータを読み込むためのルートメタデータプロバイダーとして機能します。

Although this component isn't required for trivial XAML Island scenarios such as hosting a
first-party UWP control, your app needs this XamlApplication object to support the full
range of XAML Island scenarios, including hosting custom UWP controls.
Therefore, we recommend that you always define a XamlApplication object in any solution
in which you are using XAML Islands.

私はC ++ / WinRTを機能させるのに何時間も苦労し、C ++ / CXで30分でやったことを実行できませんでした。

C ++で記述されたWinUIコンポーネントを扱うことが期待される場合、C ++ / CXツールの機能を少なくとも1：1でカバーすることが期待されます。

@ Gavin-Williams、@ pjmlp発見した問題について、 cppwinrtリポジトリで問題を開いたことがありますか？ それとも、このリポジトリで問題を開くことができるWinUIに固有の問題ですか？ 私たちはC ++ / WinRTのサポートに積極的に取り組んでいるので、うまく機能していないものについての詳細を聞くのは素晴らしいことです。 私たち自身もそれを使用しています-新しいWinUI機能はすべてC ++ / WinRTにあり、それを使用するアプリ（電卓など）も同様です。

電話について：なぜTeamsから離れたのですか？ YouTubeは最後のものではあまりうまくいきませんでした。

オーディオの問題を意味する場合：先月はケーブルが不良だったと思いますが、明日はもっと良くなることを望んでいます。 YouTubeはほとんどの人にとってアクセスしやすいようで、Channel9スタジオは、チームで使用していた会議室よりもはるかに優れたオーディオとビデオを備えています。

RE：CoreWindow、win32サポート、コンテナ-明日のコミュニティコールで@ marb2000と現在の方向性について話します:)

また、これまでの他の質問（SwapChainPanelタイムライン、Win2D / DirectX、島などの現在のステータスなど）にもアクセスしようとします。これまでのコメントと質問に感謝します。

@jesbisご連絡いただきありがとうございます。

開発へのC ++ / WinRTアプローチは、C ++ / CXによって提供される生産性に完全に逆行しているため、開く問題はありません。

C ++ / CXを使用して、私は当初、MicrosoftがついにVisual C ++を正しい方法で販売していると思っていましたが、25年後、Visual C ++はC ++ BuilderのRADエクスペリエンスに追いつきました。

代わりに、C ++ / WinRTが私に与えるのはATL / WTL時代への回帰であり、MIDL 3.0は元のMIDLよりもいくらか優れていますが、C ++ / CXが処理するUWPバインディングボイラープレートを手動で作成する必要があります。自分。

C ++ / CXが完璧であるというわけではありません。イベントハンドラーを処理する方法は、C＃/ VB.NET、またはC ++ Builder以外では失敗します。

UWPはとにかくWindowsに関連付けられているため、純粋なC ++バインディングを使用することは、C ++ / Winrtに私を惹きつけるものではなく、C＃やVB.NETとまったく同じように、まだ次のようなコードを処理する必要がありません。 ATL / WTL。

そして、前述のように、DirectXをUWPランタイムコンポーネントのセットとして公開するというアピールが無視され続けているため、私はC ++で忙しいだけです。

したがって、cppwinrtで問題を開くことで、BlendとVisualStudioでC ++ / WinrtをC ++ / CXと同じくらい簡単に、理想的にはC＃とVB.NETと同じくらい簡単に使用できるようになるとは思いません。これは、cppwinrtチームがVisual Studioチームに問題が発生し、従来（MFC / ATL / WTL）、C ++ツールチームは、他の企業がC ++（Qt、エンバカデロ）。

@pjmlp詳細に感謝します-明日までには良い答えが得られないかもしれませんが、C ++ / WinRTツールで共有できる情報が他にあるかどうかを確認しています。 私たちは新しい開発のためにC ++ / WinRTに焦点を合わせていますが、それが役立つのであれば、WinUI3用のC ++ / CXテンプレートも用意することをロードマップに載せています。

また、今後のWinUIアプリの分離の計画についても知りたいと思います。 企業の観点からは、分離/サンドボックス化と機能制御（ユーザーのオプトインではない）が必要です。 だから、これをミゲルのトピックとしてそこに出す。

@infoequipt分離とはどういう意味か、詳しく説明してAppContainerサポートのように？

今のところ、UWPとその後継のWinUIはLOBアプリケーションの準備ができていません

• リリース間で多くの重大な変更があります。

@Xarlotどのような

ギャビン・ウィリアムズ@ SharpDX廃止予定されている、あなたがに見たいと思うかもしれませんVortice.Windowsそれのための素晴らしい選択肢です。 @Aminatorは現在、完全にUWP / C＃/ XAMLDX12ゲームエンジンおよびエディターであるDX12GameEngineます。
うまくいけば、それはあなたのアプリのニーズに合っています！ 😄

通話に関する質問については、細かい部分がありますが、その間、WinUI 3への切り替えを使用して、「重大な変更」と見なされる可能性のあるいくつかの小さなレガシーUIバグを修正できますか。 StackPanel Spacingプロパティを折りたたまれたアイテムに誤って適用しますか？

NS。 StackPanelに折りたたまれたアイテムがある場合でも、それらの間に間隔が適用され、プログラムで表示/非表示にできるアイテムがある場合は、アイテム間の手動のパディング/マージンにフォールバックする必要があります。 Windows Community Toolkit（ ＃2838 ）のWrapPanel PRでこの特定のバグを修正しました。明らかに、 StackPanelでのこの動作は、他のMSエンジニアによって認識された既知の問題でした。同様に。 🤔

これからもいい結果を出し続けてください！ 🚀

@leoniDEVこれを指摘してくれてありがとう。 明日、明確な答えが得られるかどうか見てみましょう🙂

@jesbis WinUIデスクトップに関する

1. WinUIデスクトップアプリには、マルチインスタンス（Win32標準）とシングルインスタンス（UWP標準）の間のスイッチが組み込まれていますか？ 現在、Win32アプリを単一インスタンスにする場合は、この動作を自分で実装する必要があります。 これには、アプリロック（インスタンスがすでに実行されているかどうかを確認するミューテックスなど）だけでなく、2番目のアプリインスタンスからプライマリアプリインスタンスに操作を渡すためのSendMessageなどのWin32 APIも必要になる場合があります（質問2を参照）。 WinUIデスクトップアプリ用にUWPアプリの単一インスタンスの動作を実行するオプションを取得できれば素晴らしいと思います。

1. WinUIデスクトップアプリはUWPジャンプリストAPIを使用できますか？ 現在、デスクトップブリッジアプリは、アプリをアクティブ化できないように見えるため、効果的に使用できません（問題の概要については、Windowsターミナルの問題https://github.com/microsoft/terminal/issues/576を参照してください）。 Win32 / WPF APIよりも操作がはるかに簡単なため、WinUIデスクトップアプリでこのAPIを完全にサポートしたいと思います。 たとえば、ジャンプリストタスクアイコンは、画像を含む.exeまたは.dllを作成してから、そのバイナリファイルへのパスを設定する代わりに、 ms-appx:///またはms-appdata:/// URIスキームを使用して簡単に設定できます。また、特定のアイコンのファイルへのオフセット。

   ドキュメントには、UWP JumplistAPIの利点がまとめられています。

   または、代わりにUWP Windows.UI.StartScreen.JumpList APIを使用します。これにより、パッケージ相対のms-resource URIスキーム（言語、DPI、高コントラスト対応）を使用して文字列と画像のアセットを参照できます。

UWPアプリの単一インスタンスの動作により、ジャンプリストの操作もはるかに簡単になる可能性があります。 現在実行中のアプリインスタンスで動作するジャンプリストタスクがある場合、WPF / Win32で、2番目のアプリインスタンスが起動されます。これは、たとえば、 SendMessage Win32APIを使用して要求された操作を送信する必要があります。プライマリアプリインスタンスに。 UWPで単一インスタンスの動作を使用すると、実行中のアプリは呼び出されたジャンプタスクを簡単に取得できます。 Win32の場合、追加の作業は一切必要ありません。

@pjmlp見たことがない場合に興味深いもう一つのことは、前回のBuildカンファレンスの

https://youtu.be/X41j_gzSwOY?t=2659

時間があれば、明日の電話でも少し話をすることができます。

@jesbisに感謝し

今のところ、既存のDirectXコードをVorticeライブラリのようなものに移植する可能性が高く、そのようなツールが実を結ぶのを待つよりも、 @ Sergio0694によって指摘されています。

私はあなたの努力に感心しますが、ここでは、Silverlight、XNA、WinRT、UAP、UWP、WinUI、.NET Framework、WCF、EF6の後、書き直しを続けることに飽き飽きしています。

WinUIは、あらゆる意味でWPFよりも優れている必要があります。理由により、C ++の使用を余儀なくされた場合、そのツールは、.NET開発者が愛するようになったのと同じレベルである必要があり、実際にWPFを超えたり、 Electronスタイルのアプリを使いたがるビジネスを避けるためのポイント。

@ Sergio0694がすでに尋ねたように、WinUi 3.0は名前空間を切り替えるためだけでなく、誤って適用されたスペースなどのバグを修正するために必要なその他の重大な変更も含まれますか？

もしそうなら、名前とタイプが現在実際には整列していないため、 NavigationView.IsBackButtonVisibleプロパティの名前をBackButtonVisibilityに変更する可能性があります（IsBackButtonVisibleはNavigationViewBackButtonVisible列挙型であり、ブール値ではありません）。 これについてもここで説明し

@chingucodingチームが、WinUI 3.0自体の場合、既存の（UWP）アプリをできるだけ簡単に移植できるようにするために、重大な変更を最小限に抑える必要があると言ったことを思い出します。 これらの変更は、承認された場合、後続のWinUI 3.x / 4/5 / ....リリースで実装されると思われます。

Q：WinUI 3.xはHostBackdrop AcrylicBrushをサポートしますか？ 現在、アルファ版で壊れていることがわかっていますが、リリース前に修正されるロードマップにあるかどうか興味があります。

Q：WinUI Desktopを使用すると、デスクトップアプリの開発者はHostBackdrop AcrylicBrushを_最終的に_使用できますか？ 以前はcomposition属性WCA_ACCENT_POLICYをACCENT_ENABLE_ACRYLICBLURBEHINDいましたが、Microsoftは19H1 +でこれを批判的に破り、それ以来アプリは苦しんでいます。 （絵文字ピッカーなどにも影響しましたが、Microsoftは、代わりに非アクリル方式を使用するようにこれらのコンポーネントにサービスを提供しました。）

WebView2について：
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2

「開発者プレビューは、Windows 10、Windows 8.1、Windows 8、およびWindows7のWin32C ++で利用できます。将来的には、.NETおよびXAMLでWebView2をサポートする予定です。」

私の質問は..Win8.1、8、7に適用できるWebView2 SDKの.NETバージョンを計画していますか？
おそらく、.NET上のWebView2はWinUI3を介してのみサポートされるのではないかと心配しています。 私の理解では、WinUI3 WinFormsアプリのサポートは、.NET Coreベースにのみ適用され、Win10にのみ適用されます。
私の状況を説明しましょう。私のクライアントには、IEBrowserControlを使用するWinFormデスクトップアプリが多数あります。 しかし、IEは時代遅れであり、最新のブラウザーに移行したいと考えています。 そして、これらのアプリはWin7、8、8.1をサポートする必要があります。 （古いOSサポートについて私を責めないでください）

もし可能なら：

• WinUI3.0のプレビュービルドでのWin32ETA

• ソースコードを共有する準備ができていない場合は、ダウンロードして試してみることができる、実行中のいくつかのUI要素のすでにコンパイルされたデモexeを提供することは、同僚に見せびらかすのに最適です。

• WinUI 3.0は、WPF / Silverlightのようなカスタムシェーダー効果をサポートしていますか？ そうでない場合は、後でそれらを追加することについて何か考えはありますか？ WinUIで使用されるレンダリングレイヤーはこれにも対応していますか？

@leoniDEV先に進んで、強調表示した

したがって、少なくとも現時点では、別のUWPプロジェクトを使用するXAMLアイランドアプリの完全なサポートはまだ行われていないようです。

従来のWPFアプリのv-nextを実行することを検討しています。 おそらく.NETCore WPFを使用できますが、本当にWinUIを使用したいと思います。 （Microsoft.UI.Xamlではなく）Windows.UI.Xamlから派生しているPrismのようなライブラリで問題が発生しています。 この種の問題は根本的なもののように感じます。 WinUIの確かなPnPガイダンスはまだありますか、それとも早すぎますか？

シェルチームまたは受信トレイアプリチームの誰かに、Windows 10xのスタートメニューとファイルエクスプローラーがWinUIを使用する代わりにWebベースである理由について話してもらうことは可能ですか？

必要なのは、現在のUWPアプリ（デスクトップ拡張機能付き）からWinUIデスクトップアプリ（デスクトップ拡張機能なし）へのシームレスな移植エクスペリエンスです。 これは可能ですか？ このシナリオの落とし穴は何ですか？

これが難しいことが判明した場合、将来的にUWP（デスクトップで実行されているアプリの場合）を改善して、常にアプリをバックグラウンドで実行し、P / Invokeを介してすべてのwin32APIを呼び出し、dllが読み込まれるようにすることが可能になりますか？ LoadPackagedLibraryを含まない（ただしLoadLibraryを含む）他のdll。

最初のWindows10Xデバイスが起動したときに、WinUI 3.0を起動する準備ができる可能性はどのくらいありますか？ 私はWindows開発の世界に飛び込むことに興味があり、現時点でどのアプローチが最も理にかなっているのかを判断しようとしています。

質問をしてくれて、そしてあなたがそれを成し遂げることができるかどうか見てくれてありがとう！ レコーディングは同じリンクでライブです。

聞き取れなかった質問がたくさんありました。それらを要約して、すぐにいくつかの回答をここに投稿します。

良いショーの人たち、私の質問に答えてくれて、ミゲルが発表してくれてありがとう。

解決されることを期待して、私が残したいくつかの質問を追加します。

1. 従来のWin32アプリは、WM_PAINTの画面に描画されます。 XAMLアプリは保持モードです。 個々のオブジェクト/コントロールを作成するには、画面に描画するものが多すぎます。 ウィンドウに描画できるようにするが、より最新のAPIを使用できるWM_PAINTはまだありますか？ Win2Dまたはその他の即時モードAPI？

2. アクセシビリティは、Win32（COM API）とWPF（Automation Peers）では異なる方法で処理されます。 Win32 + WinUIアプリケーションを作成した場合、アクセシビリティツリーを簡単に拡張または制御できますか？ それとも、古いCOM APIを使い続けるのでしょうか？ カスタム描画コンテンツをアクセシビリティツリーのアクセシブルコントロールとどのようにブレンドしますか？

3. 今日、私たちはプリンターDCに描画することによって印刷します。 Win32 + WinUIを使用した新しい印刷はありますか？

4. HWND、CoreWindow、およびWinUIの次に来るものの間の関係に関して、私はまだ少し困惑しています。 HWNDはまだ存在しますか、それともCreateWindow呼び出しを別のものに置き換えますか？ 私はそう思います...しかし、その場合は、外部コンポーネント（たとえば親HWND）に1つを渡す必要がある場合に備えて、基礎となるHWNDがまだ存在している必要があると思います。

5. Win32 + WinUIアプリでWebView2を使用すると、組み込みIEコントロールで発生する空域の問題が発生しますか？

いくつかの質問に追いつき始めています：

WinUIは単なるUWP開発ですが、より最新の仕様ですか？ WinUIについての会話がありますが、UWP dev、UWP devの特定のライブラリ、またはまったく異なるものについて話しているのかどうかは100％わかりません。

WinUIは具体的にはUIレイヤーであり、一時停止/再開用のアプリモデル、バックグラウンドタスクなど、UWPアプリプラットフォームの他の側面は含まれていません。

UWPアプリの場合、 Windows.UI.Xaml 、 Windows.UI.Composition 、およびWindows.UI.Input一部を具体的に置き換えることができます。

WinUIアプリには、マルチインスタンス（Win32標準）とシングルインスタンス（UWP標準）の間のスイッチが組み込まれていますか？

@ Felix-Devは、win32アプリの単一インスタンスサポートを改善するというアイデアをまだ検討していません。提案がある場合は、このリポジトリで問題を開いてください。

WinUI 3.xはHostBackdropでAcrylicBrushをサポートしますか？ 現在、アルファ版で壊れていることがわかっていますが、リリース前に修正されるロードマップにあるかどうか興味があります。 WinUIデスクトップにより、デスクトップアプリの開発者は最終的にHostBackdropでAcrylicBrushを使用できるようになりますか？

@riverar残念ながら、これは

WebView2について：私の質問は.. Win8.1、8、および7に適用可能なWebView2 SDKの.NETバージョンを計画していますか？
おそらく、.NET上のWebView2はWinUI3を介してのみサポートされるのではないかと心配しています。

@ pnp0a03 WinUIXamlコントロールはWinUI3でのみサポートされていますが、Win32アプリ用のWindows 7、8、および8.1用のコアWebView 2SDKの開発者プレビューがあります。

https://docs.microsoft.com/microsoft-edge/hosting/webview2

（Microsoft.UI.Xamlではなく）Windows.UI.Xamlから派生しているPrismのようなライブラリで問題が発生しています。 この種の問題は根本的なもののように感じます。 WinUIの確かなPnPガイダンスはまだありますか、それとも早すぎますか？

@GraniteStateHacker少し早すぎると思います-WinUI3はまだ新しすぎて、多くのエコシステムをサポートできません（アルファ版のみ）が、 @ hassanuzはライブラリの互換性/移行オプションを調査するためのワークストリームを開始しています。

WinUIはストアアプリ専用ですか？

いいえ-次のように、さまざまな方法で使用できます。

• Xamlアイランドを使用して既存のwin32アプリ（WPF、WinForms、MFCなど）に含めます
• MSIXインストーラーをビルドし、必要に応じてデプロイします
• パッケージ化されていないアプリを作成し、xcopyまたはその他の方法で配布します（WinUI 3ではまだサポートされていませんが、RTMで計画されています）

最初のWindows10Xデバイスが起動したときに、WinUI 3.0を起動する準備ができる可能性はどのくらいありますか？ 私はWindows開発の世界に飛び込むことに興味があり、現時点でどのアプローチが最も理にかなっているのかを判断しようとしています。

@dwalleck WinUI 3にはすでにアルファ版があり、 Build会議の時間枠の前後でより機能的なプレビューが必要であり、どちらも2020年後半を対象としています。UWPXamlやWinUIから始める場合は、10X開発の良い道を進んでいるはずです。 。

従来のWin32アプリは、WM_PAINTの画面に描画されます。 XAMLアプリは保持モードです。 個々のオブジェクト/コントロールを作成するには、画面に描画するものが多すぎます。 ウィンドウに描画できるようにするが、より最新のAPIを使用できるWM_PAINTはまだありますか？ Win2Dまたはその他の即時モードAPI？

@jschroedl Xaml要素ツリーとブラシは保持モードですが、いくつかのオプションの1つ以上を使用して、軽量のレンダリングプリミティブを含めることができます。

• コンポジションレイヤービジュアル
• 非常に高性能な保持ジオメトリの描画を可能にするコンポジションレイヤーシェイプ-ロッティシェイプ/アニメーションを再生できるWinUI AnimatedVisualPlayerコントロールなどにも使用されます
• SwapChainPanel、SurfaceImageSource、またはVirtualSurfaceImageSourceを使用した
• Win2Dは、上記のDirectX相互運用機能を（Direct2D、DirectWriteを使用して）抽象化し、.NETAPIを提供します。

アクセシビリティは、Win32（COM API）とWPF（Automation Peers）では異なる方法で処理されます。 Win32 + WinUIアプリケーションを作成した場合、アクセシビリティツリーを簡単に拡張または制御できますか？ それとも、古いCOM APIを使い続けるのでしょうか？ カスタム描画コンテンツをアクセシビリティツリーのアクセシブルコントロールとどのようにブレンドしますか？

素晴らしい質問です！ @ marb2000をページングして、これがカバーされていることを確認し、最新の更新を提供します。 一般に、WinUI XamlツリーはAutomationPeersを使用する必要がありますが、それによってWinUI以外のwin32コンテンツに新しい機能が拡張されるかどうかはまだわかりません。

今日、私たちはプリンターDCに描画することによって印刷します。 Win32 + WinUIを使用した新しい印刷はありますか？

WinUIコンテンツの主な印刷機能は、WinRT PrintDocument APIのWinUIバージョンを使用する必要があります。

HWND、CoreWindow、およびWinUIの次に来るものの間の関係に関して、私はまだ少し困惑しています。 HWNDはまだ存在しますか、それともCreateWindow呼び出しを別のものに置き換えますか？ 私はそう思います...しかしそれが事実なら、外部コンポーネント（たとえば親HWND）に1つを渡す必要がある場合のために基礎となるHWNDがまだ存在している必要があると思います

WinUIはhwndsに取って代わるものではありませんが、目標はXaml APIを提供することにより、一般的なユースケースでの使用法を抽象化することです。これは、WPFの動作と似ています。 Xaml APIは、実際に引き続きhwnds / CoreWindowsを基盤となる実装の詳細として使用し、必要に応じてhwndsに直接アクセスするための「バックドア」/「エスケープハッチ」APIを使用する可能性があります。 これを明確にするために、数週間以内に提案案を作成する必要があります。

@jesbis回答ありがとうございますが、残念ながら私の懸念は解決しませんでした。
現在、WebView2 SDK Win32「C ++」（プレビュー）バージョンがこのサイトからリリースされています。 Win7、8、8.1をサポートしています。
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2
私の質問は.NETバージョンについてです。 現在、.NETバージョンはWinUI 3でのみサポートされていますが、ご存知のように、Win7、8、および8.1ではWinUI 3を使用できません（これは正しいですか？）。
したがって、私は以下のように私の質問を投稿しました。

私の質問は..Win8.1、8、7に適用できるWebView2 SDKの.NETバージョンを計画していますか？

@jesbisやる気を起こさせたように感じましたが、私の質問に答えてくれてありがとう。

ここで建設的にしようとしています。

したがって、MicrosoftがC ++ / WinRTツールに関して提供できる最善の方法は、空中の提案のいくつかを指摘することです。運が良ければ、ISOがC ++ 23またはC ++ 26の間のどこかに到達する可能性があります。 そして、VisualStudioチームが最終的にそれらの上にC ++ / CXを再構築するのを待ちます。これにより、約6年後になります。

優れたC ++ UIツールが必要な場合、WinUIは間違いなくそうではなく、QtまたはC ++ Builderであり、プラットフォームの移植性という追加の利点があります。

したがって、プレゼンテーションを見た後、XNA（DirectXTKを使用してC ++で書き直した）、WinRT 8.0、WinRT UAP 8.1、UWP W10、C ++ Direct2Dのシステムの代わりに傷を付けたままにします。 描画（Win2Dが登場するまで、現在は停滞しています）、WinUIは間違いなく私が保留にするものです。

今後は、.NETを使用する場合はWPFを使用し、C ++を使用する場合はQtを使用するか、Webテクノロジで実行可能な場合はPWAに焦点を当てるようにお客様にアドバイスします。

WinUI 3.0ロードマップは、UWPの販売がデスクトップ市場で失敗し続けている場合、さらに別の再起動が間近に迫っているという確信を刺激しません。

ある意味で私が指摘したいのは、Microsoftの経営陣は、Windows 8のリリース以来何度も失敗した後、WinUIを採用するというアイデアを私たちに売り込む方法を考えるべきだということです。

@pjmlpの一般的なC ++ / WinRTフィードバックは、おそらくcppwinrtリポジトリに送信するのが最適です。 ISO規格の更新には時間がかかりますが、おっしゃった時間枠よりも短いと思います。リフレクションのサポートが最優先事項であり、先週プラハで開催されたC ++カンファレンスで話し合っていました。

DirectXTKはまだ開発中であり、定期的に更新されています。

XamlフレームワークAPIに関しては、WinUIは前進の道であり、Windows 8に戻るかなり途切れることのない互換性の系統を持っています-高度な互換性を維持するために多くの時間を費やしています🙂いくつかの変更があります（シェル統合のため、 VSプロジェクト構造など）。ただし、ほとんどの場合、Windows 8Xamlを現在のWindows10アプリに移植し、再コンパイルして最新のインサイダーフライトで実行すると、機能します。

WinUIの高レベルの利点には、UWP WinRTAPIとwin32APIの間の障壁の除去、.NET 5のサポート、新機能の即時ダウンレベルサポートの有効化、多くの条件付きOSバージョンチェックの必要性の排除、OSSコントリビューションの有効化などがあります。 Xamlアイランドを使用して既存のwin32アプリの増分更新を有効にします。

@ pnp0a03.NET要素を市場に投入するための取り組みもあります。 具体的な日程はお伝えできませんが、ご要望を承知しており、詳細を検討しております。

@jschroedl空域の問題を排除したいので、これを達成するのに役立つレンダリング計画を立てようとしています。

@jesbis前述のように、cppwinrtに文句を言っても何も起こらないと思います。特に、ロードマップが受け入れられない可能性のある機能を採用することであるため、避けられないユースケースを除いて、C ++ / WinRTを採用しないことで文句を言います。 ISO。

DirectXTKに関しては、MicrosoftがXNAを削除し、DirectXTKを「代替」として提供することにより、C＃コードをC ++に書き直し、機能の劣るツールを使用するように強制した方法について、さらに別の例を示しました。

ありがたいことに、オープンソースコミュニティはMonoGameを思い付き、MicrosoftがXNAで追求することを拒否した作業を行うことができました。

プレゼンテーション中にそれを見て、ここのコメントのいくつかで、C ++がいかに素晴らしくて楽しいか、WinDev（Longhornが買収してからもう一度）がC ++を最初に販売し続け、後で.NETを販売し続ける方法について説明しました。

優れたC ++ツールが必要な場合は、Visual C ++ではなく、QtとC ++ Builderが最適な環境です。

いくつかのメタクラスやリフレクションのアイデアがISOで受け入れられることを期待するのではなく、チームが今日の競争で何が可能かを確認できるように、管理者に依頼する必要があります。

.NETFrameworkから.NETCoreに引き継がれないAPIやサードパーティライブラリを気にする必要があるだけでなく、WPF / UWPからWinUIへのすべての移行の問題に対処する必要があります。 C ++ / WinRTで使用すると、クールで、数年後には改善されます」という考え方です。

マイクロソフトの経営陣は、この書き直しを燃やされた.NET開発者にどのように販売するかを真剣に検討する必要があります。そうしないと、すでに仕事をしているスタックから離れることはありません。

@pjmlp DirectXと言えば、私は自由時間にポータブルで不可知論的なC＃グラフィック、オーディオ、入力フレームワーク積極的に取り組んでおり、WinUIビューでD3D12 / 11などを実行できます。

XNAのようなものと比較して、はるかに近代的でパフォーマンス重視のレンダリングアプローチをサポートします。 まだ使える状態ではありませんが、私も含めて多くの人が欲しがっていたものです…だから作っています。 D3D12とVulkanが最初にサポートされるターゲットになります。 HLSLやGLSLなどの代わりにC＃でシェーダーを作成することもできます。

使用する準備ができたら、さらに共有しますが、これはフレームワークであり、大規模なSDKやゲームエンジンではないため、非常にポータブルで軽量でありながら、強力で使いやすいものになります。 WinUI、WPF、またはネイティブC＃Win32またはWinRTアプリで3Dコンテンツをレンダリングするのに最適です。

https://github.com/reignstudios/Orbital-Framework

@ zezba9000情報をありがとう、あなたがしたたくさんの印象的なこと、称賛！

DirectXのマネージドサポートに関しては、あなたのようなコミュニティの取り組みにしか頼ることができないと思います。マネージドDirectXとXNAをタンクに入れた後、C ++ MSの群衆がDirectXの開発作業を引き継ぎました。

WinDevが推進しているように、「C ++またはハイロード」だけである必要はないことを他の人に示すためのマーケティングとして、少なくともこれらのプロジェクトのいずれも私の主張に数えることができます。 ここでは、Swiftを使用したOpenGL ES / Metal、またはJava / Kotlinを使用したOpenGLES / Vulkanからレッスンを受けることができます。 どうやら、3Dプログラミングにマネージド言語を使用することは、モバイルプラットフォームがWindowsに勝つための問題ではありませんでした（悲しいことに、WPは素晴らしい経験でした）。

頑張ってください。C＃でシェーダーを作成するのは本当に魅力的で、CS2Xを知りませんでした。

@pjmlp Ya CS2Xの部分は、C＃で不可知論的なGPUシェーダーを作成できるようにするものです（理論的にはシェーダーの単体テストができるので便利です）。 C＃サブセットを利用できるターゲットの場合、CS2XはC＃サブセットをC89ランタイムにコンパイルできるため、現在の.NETランタイムがサポートする範囲外のプラットフォームをターゲットにすることができます...そしてOrbital-Framework CS2X => C89ランタイムをターゲットにすることができ、次にこれらのプラットフォームもターゲットにすることができます。

大きなプロジェクトですが、私が気にかけていることであり、それを実現することに専念しています。

WinUI 2.4でHwndHostを使用することは可能になりますか？
プレリリースバージョンで試しましたが、機能しませんでした。
また、この新しく計画されたすべてのウィンドウ処理（XAMLウィンドウ）とアプリケーション（XAMLアプリケーション）を備えたWinUI3で可能になります。はいの場合、最初のプレビューでそれを確認できます。
実際、WinUI3で可能になる場合、この機能はWinUI 2の新しいリリースに追加されるのでしょうか、それともWinUI2はUwpアプリでのみ機能するのでしょうか。
たとえば、現在、HwndHostを介して多くのC ++コードを使用するWPFアプリがあります。すべてをWinUIに移動することを計画しているため、この部分はWinUIなどを使用することを決定する上で非常に重要です。 また、WinUI 2でも見栄えがよく、XAML部分は非常に簡単に転送でき、Composition Apiはうまく機能し、Uwp Community Toolkitはうまく機能しますが、HwndHostとc ++ Win32コードを使用することはできません。 それで、WinUI3がこれを解決しようとしているのはいつですか？ また、私はx：Bindが大好きですが、これはWinUI3リリースのリスクさえあります。

@ zezba9000

DirectXと言えば、私は自由時間にポータブルで不可知論的なC＃グラフィックス、オーディオ、入力フレームワーク積極的に取り組んでおり、WinUIビューでD3D12 / 11などを実行できます。

これで頑張ってください！ それは非常識な量の仕事です！

WinUI 2.4でHwndHostを使用することは可能になりますか？
プレリリースバージョンで試しましたが、機能しませんでした。
また、この新しく計画されたすべてのウィンドウ処理（XAMLウィンドウ）とアプリケーション（XAMLアプリケーション）を備えたWinUI3で可能になります。はいの場合、最初のプレビューでそれを確認できます。
実際、WinUI3で可能になる場合、この機能はWinUI 2の新しいリリースに追加されるのでしょうか、それともWinUI2はUwpアプリでのみ機能するのでしょうか。
たとえば、現在、HwndHostを介して多くのC ++コードを使用するWPFアプリがあります。すべてをWinUIに移動することを計画しているため、この部分はWinUIなどを使用することを決定する上で非常に重要です。

WinUIXAML内でuser32 / comctlまたはWPFUIをホストする方法について未解決の問題があります： //github.com/microsoft/microsoft-ui-xaml/issues/1833

作ったら3.0以降になるようです。

これを＃1833に投稿します
https://github.com/microsoft/microsoft-ui-xaml/issues/1833しかし、私はコピーします
ここにもあります：現在、多くのc ++コードを使用するWPFアプリがあります
HwndHostコントロール。 WpfアプリをWinUIに移動し、Xamlを移動することを計画しています
問題なく動作しますが、HwndHostについてはどうでしょうか？
WinUI3で可能です。 私たちの場合、相互運用性を行っています
HwndHostを介したDirectShowで、現在WinUI 2では、これはそうではありません
可能。 WinUI3でHwndHostを使用する現実的な日付は何ですか？ も、また
この新しいXamlウィンドウとアプリケーションは遅くとも2月に議論されました
WinUIコミュニティの呼び出し、役立つかどうか？

El dom。、2月23日。 de 2020 a la（s）13：42、Max Strini（
[email protected]）escribió：

WinUI 2.4でHwndHostを使用することは可能になりますか？
プレリリースバージョンで試しましたが、機能しませんでした。
また、このすべての新しい計画でWinUI3で可能になる予定です
ウィンドウ処理（XAMLウィンドウ）とアプリケーション（XAMLアプリケーション）およびはいの場合は
最初のプレビューでそれを確認できると期待できます。
実際、WinUI3で可能になる場合、この機能はありますか
WinUI 2の新しいリリースに追加するか、WinUI2はUwpアプリでのみ機能します。
たとえば、現在、多くのC ++コードを使用するWPFアプリがあります。
HwndHost、そしてすべてをWinUIに移動することを計画しているので、この部分
WinUIまたは他の何かを使用することを決定することは私たちにとって非常に重要です。

内部でuser32 / comctlまたはWPFUIをホストする方法について未解決の問題があります
WinUI XAML：＃1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833

作ったら3.0以降になるようです。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/microsoft/microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVVOQ6W3Z6LBVYZVJ63REJVLPA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXH
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AG66BVRWNTNC7FUIBBP5C6DREJVLPANCNFSM4KUFQ6MA
。

-
マリオランシック
ソフトウェアエンジニア
マイクロソフト認定プロフェッショナル

先週は本当に良いWinUIコミュニティコール！ 内容は非常に興味深く、多くの洞察を提供するのに十分詳細/技術的でした。 ロードマップ/開発ステータスの更新は、WinUIおよび当社独自の開発ロードマップの利用者にとっても非常に価値があります。 次の電話を楽しみにしています！

WinUI3のHwndHostについて。
HwndHostを使用すると、WPF内でWin32コンテンツをホストできます。 残念ながら、WinUI 3.0デスクトップやWinUIアイランドを含め、これをサポートする計画はWinUI3.0にはありません。 説明されているシナリオ@ mariorancic01について、DirectShowではなくUWP MediaPlayer APIを評価しましたか？

Uwp Cameraの方が見栄えは良いですが、シナリオで使用できるかどうかはわかりません。
DirectShowで仮想カメラとしてカメラを使用しており、表示する必要があります
ビデオ、写真のカメラストリームを取得し、PjSipを使用して
同時に、DirectShowでそれを行う前に。 このUwpを使用できますか
PjSipを備えたMediaPlayer。

Elmié。、2月26日。 de 2020 a la（s）23：47、Miguel Ramos（
[email protected]）escribió：

WinUI3のHwndHostについて。
HwndHostを使用すると、WPF内でWin32コンテンツをホストできます。 残念ながらそこに
WinUI 3.0デスクトップを含め、これをサポートするWinUI3.0の計画はありません。
WinUI諸島。 シナリオについて@ mariorancic01
https://github.com/mariorancic01の説明、UWPを評価しましたか
DirectShowの代わりにMediaPlayerAPI？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/microsoft/microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVR4ABZ7KA3S2RQVHELRE3WOJA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AG66BVSBFMKZMD3TD5RGDKTRE3WOJANCNFSM4KUFQ6MA
。

-
マリオランシック
ソフトウェアエンジニア
マイクロソフト認定プロフェッショナル

Windows Store for Businessについて質問があります。これは、LOBアプリにとって非常にクールで非常に便利に見えますが、これは放棄される可能性があると読みました。 誰かがこれについての計画について何か言うことができますか？

@ marionrancic01 MSIXパッケージを介してUWPアプリを配布できるようになったため、実際には必要ありません。

悲しいことに、 @ mariorancic01のように、Windows Store

@leoniDEV @kmgallahanが言ったようにあなたは、単に、MSIXとして公開することができたときに、ビジネスのためのWindowsストアを必要とする理由は、私は正直に好奇心

@kmgallahan @jtorjo彼らが探しているのは、プライベートアプリケーションカタログを
同様に、古いMSIインストーラーは、アプリを検出する方法も提供していません。

Windows Storeへの公開は、公園を散歩することではありません。想像以上に複雑です。 まず、MSからの証明書（公開に使用する証明書）を待つ必要があります（正確な手順は今のところ覚えていません）。 次に、アプリがストアの要件に違反していないことを確認する必要があります。 次に、行った更新が受け入れられるまでに数日かかる場合があり（または拒否される場合もあります）、ユーザーがアプリを見つけるためにストアのアルゴリズムに依存します。

しかし、自分でデプロイする場合、セットアップするのは少し難しいでしょう（私は知っているでしょう）が、一度それが行われると、それは簡単に簡単になります。 しかし、ええ、あなたはあなたのアプリを世界に見せることを担当するでしょう。

ビジネス向けストアを含め、Microsoft Storeに複数のアプリを持っている人として、Microsoftストアへの公開は過去数か月ではるかに良くなっていると言えます。 定期的な更新の認定は、数時間の速さで行われることがあります。 店舗のガイドラインも非常に簡単に満たすことができます。
一方、スタンドアロンのmsixを妨害することは複雑になる可能性があります。 パッケージに署名するストアとは異なり、ストアの外部にアプリを配布する場合は、自分で署名する必要があります。

@jtorjo証明書は必要ありません。

明確にするために、ストアに問題があり、開発者ダッシュボードが時々ダウンしますが、上記の私のポイントは、ビジネスアプリ用のストアがあると非常に便利であるということでした。

ビジネス向けストアを含め、Microsoft Storeに複数のアプリを持っている人として、Microsoftストアへの公開は過去数か月ではるかに良くなっていると言えます。 定期的な更新の認定は、数時間の速さで行われることがあります。 店舗のガイドラインも非常に簡単に満たすことができます。

@yaichenbaumそれは間違いなく知っておくと良いことです。 私が出版していたとき（2年ほど前）、それはもっと大変でした。 はい、自分で署名する必要があります。実際、証明書を購入し、「公開」プロセスの一部として署名します。 したがって、一度設定すると、忘れることができます。

@riverar私が公開していたとき（2年ほど前）、名前を予約する必要があり、MSがアプリに署名するために使用するものを待つ必要があることを覚えています（これは私が意味する証明書です- > MSが発行するもの）。