コミュニティのフィードバックを聞いていただきありがとうございます。 私はWinUI3.0（Win32 + WinUI + C ++）に本当に興奮しています。 これは私たちが待ち望んでいたフレームワークのように感じます！ RIPGDI😉

（Win32アプリモデル）+（WinUI 3.0 UI）+（。NETまたはC ++言語）

つまり、これは基本的にUWP UIですが、電話のようなライフサイクルとサンドボックスはありませんか？ これはデスクトップアプリにとっては興味深いことのようです。それでは、これを試してみます。

更新していただきありがとうございます。WinUI3.0の初期機能セットがロックダウンされ、新しいコントロールまたは提案されたコントロール機能がWinUI 3.0になる可能性があるため、さらに多くの更新が行われることを願っています。

ああ、デスクトップのWinUIがどのように

おそらく、フレームワークとAPIのどの組み合わせに含まれているものと、Buildで取得したアーキテクチャ図の優れたマトリックスです。

あなたたちは信じられないほどです、すべてに感謝します！
xplatセクションは私の一日を作りました、特に宇野がレーダーに乗っていること。

私たちの焦点はまだWindows10と8.1ですが、Win7にはまだユーザーと顧客がいるというフィードバックがあり、市場とオプションを徐々に評価していきます。

このUIフレームワークの埋め込みが移植性を念頭に置いて設計されていると仮定すると、少なくともそのUIコア（レンダリング/入力）が.NET Core3 +をサポートするすべてのWindowsOSで機能できるようになります。なれ？ 人々がデスクトップで使用するほとんどの機能は正常に機能するようですが、機能しない特別な/プラットフォーム固有の機能については、コアUIシステムの一部にならないようにし、（Win10、 Win8.1、Win7 Nugetsなど）。

また、HTML（残念ながらXamarinではない）で実行できるように、すべてのデバイス（Win32、Android、iOS、およびWASM）で同じルックアンドフィールを持つクロスプラットフォームXAMLがあった場合、私の会社は何年も前にそれに飛びついたでしょう。

また、皆さんがこれを「マラソン（素晴らしいバンジーゲームも）」と見なしてくれてうれしいです。 XAMLスペースでの断片化が少ないほど、すべての人にとってより良いものになり、多くのショートカットを使用すると、開始した場所に戻ることができます;）

デスクトップのWinUIがどのように機能し、UWP、WPF、およびWin32とは異なるかに関するドキュメントは非常に役立ちます

私たちはそれに取り組んでおり、これが発展するにつれてより多くを共有します！

このUIフレームワークの埋め込みが移植性を念頭に置いて設計されていると仮定すると、少なくともそのUIコア（レンダリング/入力）が.NET Core3 +をサポートするすべてのWindowsOSで機能できるようになります。なれ？

@ zezba9000 WinUIは.NETを使用せず、

デスクトップのWinUIがどのように機能し、UWP、WPF、およびWin32とは異なるかに関するドキュメントは非常に役立ちます

私たちはそれに取り組んでおり、これが発展するにつれてより多くを共有します！

このUIフレームワークの埋め込みが移植性を念頭に置いて設計されていると仮定すると、少なくともそのUIコア（レンダリング/入力）が.NET Core3 +をサポートするすべてのWindowsOSで機能できるようになります。なれ？

@ zezba9000 WinUIは.NETを使用せず、

Windows 7との互換性については、XAML用の独自の互換性のあるレンダラーを構築するサードパーティと、必要なOSレベルのAPI用の何らかの代替Shimが必要になります。

今のところ、これが可能かどうかはわかりません。WinUIビットがOSから削除されたときに、他のプラットフォームが何らかの互換性コンポーネントを提供できるように、オープンソースプロジェクトに組み込まれることが期待されています。 Xamarin、Uno、または.NetCoreとカスタムレンダラーを考えてみてください。

これはOSAPIに基づいて構築されたネイティブフレームワークであり、Win7には存在しなかったWin8 / Win10の新機能に依存しています。コア機能の場合もあります。

私の考えでは、「コア機能」を構成するものは、もちろんレンダリングと入力以外に、OSの詳細に依存するものではありません。 そのような場合、誰でも拡張できる抽象化レイヤーになります。 基本的なレベルでは、理論的には、カスタムソフトウェアレンダラーを使用してUIをレンダリングし、必要に応じて仮想カーソルを使用してカスタムXInputバックエンドを使用して入力を実行できる必要があります。 そのようなモジュール性を実行できれば、ほとんど何でも実行でき、プラットフォームサポートの拡張は非常に簡単になります（ゲームで行われているように）。 あなたはこのエリアでもう少し時間を過ごし、将来的にはすべてがはるかに少ない労力で済みます。 WPF XAMLがこのように設計されていれば、UWPアプリで使用されていた可能性があります。 そうでなければ、技術的負債は無限ループになります。

トレイアイコンのサポートなどは、「WinUI Windowsの基本機能（Win7-Win10）」パッケージに含まれている可能性があります。 プッシュ通知のようなものは、「WinUI Windows拡張機能（Win8-Win10）」パッケージに含まれている可能性があります。

それが理にかなっていることを願っています。

@ mdtauk 、 @ zezba9000理論的にはすべて可能であり、チームにはプラットフォーム抽象化の専門知識がたくさんあります。 何でもそうですが、それはコスト、スケジュール、期待される利益に帰着します😊

開発とテストのコスト（たとえば、すべてが古い支援技術で機能することを確認するなど、潜在的に非自明な領域にまで及ぶ）に加えて、長期間にわたるサポートコストも考慮する必要があります。

2020年以降にWin7に新しい顧客が来ると思いますか？ フィードバックと明確なユースケースは、優先順位付けに役立ちます。

開発とテストのコスト（たとえば、すべてが古い支援技術で機能することを確認するなど、潜在的に非自明な領域にまで及ぶ）に加えて、長期間にわたるサポートコストも考慮する必要があります。

2020年以降にWin7に新しい顧客が来ると思いますか？ フィードバックと明確なユースケースは、優先順位付けに役立ちます。

@jesbis WinUI 3.0のWin7に互換性を追加してもあまりメリットはありませんが、Linux、Android、iOS、iPadOS、MacOSは、ネイティブUIフレームワークに依存しないクロスプラットフォームソリューションを提供するのに役立つ可能性があります。

@mdtauk
@jesbis WinUI 3.0のWin7に互換性を追加してもあまりメリットはありませんが、Linux、Android、iOS、iPadOS、MacOSは、クロスプラットフォームソリューションを提供するのに役立つ可能性があります。

それに同意します。 Webアセンブリを追加するだけですが、Linuxよりもさらに重要です。

2020年以降にWin7に新しい顧客が来ると思いますか？ フィードバックと明確なユースケースは、優先順位付けに役立ちます。

いいえ、私の会社はそうではありません。 XAMLが（私の観点から）すべての反復で苦労しているのを見た領域で、より多くの設計上の議論をしていましたが、MSがそこで時間を過ごしたくない理由は完全にわかります。 ただし、WinUIが、現在のWPFの場合のように、Windowsの依存関係のうさぎの穴を掘り下げることなく、必要に応じて他の人がこの作業を実行できるようになっていれば、すばらしいでしょう。

私の会社が望んでいることを明確にするために、AndroidとWASMのサポートはUNOよりも少し公式です（そして3年前）。 ローカルコンピューターのコレクションの状態と、通常はWin32 APIの大きな必要性を伴うシステムセットアップを管理する管理ソフトウェアを作成します（UWPは機能しませんが、HTMLビルドシステムとは異なり、コンパイル時エラーのためにUIが好きです）。クライアント+私たちには、統一されたエクスペリエンスと感触を持つWin32 + Android +ブラウザーUIエクスペリエンスが必要です。 HTMLは、主要なコードベースがC＃であるため、他の方法では必要のない不必要な抽象化と複雑さを追加するため、大きな問題点にすぎません。

それがあなたのためのより良いフィードバックであることを願っています。

また、はい、WASMは他のプラットフォームと比較して私たちが望む最大のターゲットです。 はるかに！！
Android / iOS /モバイルの問題だけでなく、Webポータルの問題も解決します。

フィードバックをお聞きいただきありがとうございます！

デスクトップ+ WASMはゴールドになります！

わあ、大声でありがとう、@ jesbis！ まったく予想外で、非常に高く評価され、尊敬されています。 👍

Windows 7に関する議論は、（コストは言うまでもなく）労力の量がWin​​UI 3.0に大幅な遅延を引き起こすため、少し気が散ります。 Windows 7は1月にサポートが終了するため、すべてのお客様にWindows 10へのアップグレードをお勧めします。私のお客様はここで他のお客様と連携できない可能性がありますが、Windows8.1でさえ私たちにとって関心のあるプラットフォームではありません。

アップデートに非常に満足しています。 WinUIの今後のターゲットは非常に明るく有望に見えます！ Xplatセクションでさえ私が予期していなかったものでしたが、大歓迎です。 WinUIの改善点とグッズを使用することを楽しみにしています。

透明性のあるチームに感謝します。

さまざまな問題の解決において人々を支援する上での基幹業務ソフトウェアの重要性について言及したいと思います。

ライトスイッチツールを使ってしばらく作業しましたが、構築時間が大幅に短縮されました。 迅速なアプリケーション開発は、LOBアプリケーションにとって非常に有望です。 しかし、米国での特許戦争は非常に深刻に受け止められており、製品が終了するまでに時間がかかりました。

次の配信のためにINotifyDataErrorInfoがあることはわかっています。 しかし、WinUIに3.x以降のような将来の配信のためのRADリソースがあれば素晴らしいと思います。

おかげでチーム、あなたがウェブアセンブリを鉛筆で書く日を待つことができません。 それは私の日、年、そして10年を作り、MSをテクノロジースタックのトップに置くでしょう。 WinUI + Xamarin + WASM + .NET =>純粋な素晴らしさ!!

@jesbisこのアップデートをありがとう。 良い作業チーム：+1:。 それはまだ早いことを理解していますが、 WinUI 3.0マイルストーンが作成され、それに対して問題がタグ付けされるのは

WinUI 3.0マイルストーンが作成され、それに対して問題がタグ付けされるのはいつになると思いますか？

@shaggygiいい質問です！ 私はそれを作成しました：

WinUI3.0マイルストーン

これはすごい人です！

簡単な質問： Windows.UI.CompositionをMicrosoft.UI.Compositionに移動しますが、これは2.2または3.0に近いですか？
そして、これを期待する時間枠で、3.0が利用可能になったとき、これは2〜3か月以上のようになりますか？

将来、（「年末までに」のように）年について話すときは、暦年と[Microsoft]会計年度について明確にしてください。
これが明確に述べられていない場合、混乱するのは簡単です。これにより、意図したよりも6か月早く物事が来ると人々が信じる場合があることを私は知っています。

Windows.UI.CompositionをMicrosoft.UI.Compositionに移動しますが、これは2.2または3.0に近いですか？

@jtorjoこれは3.0になります（少なくとも）。 3.0の最初のプレビューに初期ビルドを含めることを望んでいますが、まだ100％保証されているわけではありません。

将来、（「年末までに」のように）年について話すときは、暦年と[Microsoft]会計年度について明確にしてください。

@mrlaceyありがとう、私はそれを覚えておきます！ 私たちが使用するすべての日付は、通常、暦時間です。

@jesbisそれは

@jtorjo

3.0の

多くの場合、多くのプレビューリリースがあります。 たとえば、.NET Core3はプレビュー6にあります。

私たちの計画は、3.0にコンポジションAPIを含めることです。

ただし、Xamlフレームワーク部分は、構成部分の前にオープンソースになります。

@jesbisありがとう、いいですね！

素晴らしいロードマップ、素晴らしい仕事です！

ここにいる皆さんと同じように、私は透明性が大好きで、WinUI3.0を本当に楽しみにしています。 私にとって、WinUI 3.0は、2006年にWPFが導入されて以来最もエキサイティングなものです。

まだWindows7を実行しているお客様もいますが、Windows 10のサポートが最も重要であり、Win7のサポートに時間とリソースを費やすことはないと思います。 私が働いているほとんどの企業は10に切り替えています。そして、2020年後半に、まだWindows7を使用していることがわかる唯一の企業はおそらく私の歯科医になると思います。 そして、彼が私に彼のためにWindowsアプリを書くように頼むかもしれないなら、私は彼のPCをWindows10に移行します。:-)

将来のWASMサポートは素晴らしいでしょう。

昨日の会議で：

@jesbisとここで作成して参加しているチームに示す小さな話は、興奮した氷山の一角にすぎません。 :-)

ちょうど昨日、ドイツで開催された開発者会議で.NET開発者とチャットし、WinUI 3.0について話しましたが、彼らはそれについて知りませんでした。 私は彼らにロードマップについて話しました、そして彼らは言いました：

"わおそれは驚きだ"。

グループの女の子が私に尋ねました：

「でも、これを全部教えてもらえますか？」

私は彼女と他の人たちを見ました、そしてそれから私は

await Task.Delay(3000);

私が言う前に

「そうだね！これはすべてGitHubで読むことができる」。

@jesbisと関係者全員に感謝します。 Windows開発者になるのに最適な時期❤️

ファーストパーティのアプリケーション（Word？など）がWinUIのレイヤーを利用できることを願っています。開発者は、「WinUIはおもちゃではなく、ビジネスを実行できる本物です」と喜んで理解します。
すでに使用している場合は、大声で人々に知らせてください！

WPF、Win32、およびWinUIデスクトップ用のアクリル。

ああ、おそらくアクティブなWindowsポリシーでのみアクリルを再考してください。

はい、複数のモニターがある場合は、1つのウィンドウにレンダリングされます。 少なくとも複数のモニターでは、正しく機能するはずです。

UWPアプリで2セットのUIコントロールを使用できることの開発経験への影響について考えていました-WinUIコントロールとレガシーUIコントロールの両方にアクセスできる場合、C＃コードビハインドの場合、IntelliSenseは常に正しく必要になるため、 Alt + Enterを押してusingを追加する代わりに、コントロールの取得元の名前空間を選択して続行します。 どういうわけかこれを回避することは可能でしょうか？

WinUI3が開発者向けにリリースされたら、Windows 10 SDKは、サポートされているSDKがインストールされた状態で開かれたプロジェクトの名前空間の変更を提案することを検討する必要があります。 OSの名前空間から人々を遠ざけるようにしてください。

WPF、Win32、およびWinUIデスクトップ用のアクリル。

私が最初に見たいのは、MSがXaml諸島を十分に成熟させていることです。たとえば、タイトルバーのアクリルは、WinUIに基づいてUIをベースにした非UWPプロジェクトに使用できます（この投稿の最後の段落を参照）。 @ marb2000はおそらくこれについて尋ねる人です。

@MartinZikmundこのシナリオは避けたいと思います。 WinUI 3を使用する場合は、パッケージからのコントロールにのみアクセスできる必要があります。 最新かつ最大の変更で必要なものがすべて揃っているという考えです。

@MartinZikmund
@LucasHaines

1つの修正は、ビルドからWindows.UI.Xaml.* WinMD参照を除外できることです。 これで、ビルドターゲットはUnifiedWinMD別名のみを参照します。 Windows.winmd 、個々のWinMDも参照するオプションをターゲットに追加します。これにより、構築しているアプリに基づいて参照を含めたり除外したりできます。

この方法であれば、名前空間を変更する必要はありません。.NET dllように動作するため、システムが提供するものではなく、パッケージ内のローカルバージョンへのアセンブリリダイレクトを処理できます。

この方法は特に.NETFramework用であることは知っていますが、UAPの場合は、この種のシナリオに対する解決策があるはずです。 msix/appxマニフェストにFrameworkDependencyがあることは知っています。 我々が新しいWinUIを供給するためにそれを使用することができかもしれWindows.*のではなく、名前空間Microsoft.*のもの。

開発者側では、コードではなく参照を変更するだけなので、アプリをアップグレードするのに苦労することは少なくなります。

名前空間をまったく変更したくない！

利点：

1. コードを前後に変更する必要はありません。

2. ローカルのWinUIコードが安定したら、Windowsプラットフォームにマージして戻すことができるため、システムアプリとLOBアプリは、新しいWindowsリリースごとに新しい改善点を利用できます。

3. 一方では、.NETFrameworkのような互換性の高い非常に安定したシステムフレームワークです。 反対側は.NETCoreに似ており、変更がより速いペースで行われ、両方の利点がすべてあり、問題はありません。

クロスプラットフォームのネイティブアプリにラップされたBlazor +（HTML以外）UIに関するSteveSandersonによる素晴らしいプレゼンテーションを見たところです。 ビデオの約52分。 UWP、WinUI、およびc＃ファンには必見です。 私はblazorに真剣に感銘を受けました!!!

https://youtu.be/uW-Kk7Qpv5U

これらの議論で私が言うのを忘れた一つのことは、私が重要だと思うことです...
WinUI 3.0自体にパフォーマンスの改善はありますか？ XAMLレンダリングエンジンが分離されたばかりですか、それとも変更がありますか？ XAMLコントロールは主にCompositionを使用するので、DirectUIのようにオフスレッドとdwmを駆動しますか？

ListView / GridView = ItemsControlのように、一部のコントロールのパフォーマンスとRAM使用量ははるかに優れている可能性があります。

これはWindows自体で見られます。 Windows 8のスタートメニュー（DirectUI）は、Windows 10のXAMLスタートメニューよりもはるかに流動的です。
Groove Albumsページなど、十分な情報を含むGridViewをロードしてみてください。そうすると、うまくいきません。 これは、iOSとAndroidの動作がはるかに優れていることであり、winforms、QTも同様です。
（私の意見では、WPFはUWP XAMLよりもさらに悪いです）。

WinUI 3.0自体にパフォーマンスの改善はありますか？ XAMLレンダリングエンジンが分離されたばかりですか、それとも変更がありますか？ XAMLコントロールは主にCompositionを使用するので、DirectUIのようにオフスレッドとdwmを駆動しますか？

パフォーマンスは間違いなく私たちが投資し続けたいものですが、3.0の改善は期待できません。 最初の3.0の取り組みは、主にXamlを分離してNuGetパッケージとして出荷し、オープンソーシングすることに重点を置いています。

WinUI 3.0（今日のUWP Xamlなど）はコンポジションレイヤー上に構築されており、レンダリングとアニメーションの多くをDWMを介してオフスレッドで実行します。

これは、iOSとAndroidの動作がはるかに優れていることであり、winforms、QTも同様です。
（私の意見では、WPFはUWP XAMLよりもさらに悪いです）。

これらのシナリオを検討する場合、多くの場合、パフォーマンスと柔軟性/豊富さのトレードオフがあります。 Xamlベースのプラットフォーム（UWPとWPFを含む）は、すべてのコントロールに対してより大きく、より豊富なUIオブジェクトツリーを持つ傾向があります。これにより、コントロールのスタイルとUXを変更するための柔軟性が大幅に向上しますが、他の一部のプラットフォームでは、オブジェクトツリーがはるかにフラットになる傾向があります。柔軟性はありませんが、読み込みが速くなる場合があります。

そのトレードオフは間違いなく私たちが考えていることであり、将来の潜在的な変化に備えて心に留めておくでしょう。 複雑なXamlコントロールテンプレートの追加の柔軟性は、多くの場合必要ではないため、追加の柔軟性が必要ない場合は、コントロールを単純化して読み込みを高速化できる可能性があります。

MicrosoftがWinUI3.0に基づく新しいcomctl32.dllとcomdlg32.dllを提供できることを願っています。

ほとんどのWin32アプリは最新のUIエクスペリエンスを備えており、開発者がアプリを最新のUIに適合させるのに役立ちます。

多くのWin32開発者は、いくつかのWindowsバージョンを適応させる必要があります。 そのため、今日ではWinUIを直接使用することはできません。 Microsoftが、アプリのUIを最新化するための作業負荷を軽減するのに役立つ方法を提供できれば素晴らしいことです。

また、MicrosoftがWinUIを使用しているC ++ Win32アプリ用のXAMLデザイナーを提供できることを願っています。

毛利健二

@MouriNaruto今日はFileOpenPickerを使用できます（Win32から）。

@MouriNaruto今日はFileOpenPickerを使用できます（Win32から）。

私は知っていますが、すべての最新の一般的なコントロールとダイアログがWin32にもたらされることを願っています。

@MouriNaruto

技術的には可能です。 ただし、Windows開発者は、 COMCTLおよびCOMDLG実装の正確な動作だけでなく、コードベースに存在する既知および未知のバグも再作成する必要があります。

互換性は私たちのフレネミーです！

彼らがそれを行ったとしても、彼らがそれを完了するまでに、それらのライブラリを使用するすべてのソフトウェアは、WinUIに移行するのに十分な時間を持っているでしょう！ 皮肉！！ 🤨🤣

@MarkIngramUK

参考： FileOpenPickerはネイティブのWinRTダイアログ/コントロールではありません。 これは基本的にExplorerFrameラッパーであり、それ自体がDirectUI （ATGチームによって開発され、 DirectX基づいています）とCOM記述されています。

技術的には可能です。 ただし、Windows開発者は、COMCTLおよびCOMDLG実装の正確な動作だけでなく、コードベースに存在する既知および未知のバグも再作成する必要があります。
互換性は私たちのフレネミーです！
彼らがそれを行ったとしても、彼らがそれを完了するまでに、それらのライブラリを使用するすべてのソフトウェアは、WinUIに移行するのに十分な時間を持っているでしょう！ 皮肉！！ 🤨🤣

現実のため、多くのプロジェクトがそれなしでWinUIに移行するのは簡単ではないと思います。

「互換性は私たちのフレネミーです！」とおっしゃいました。 はい、それは私の提案の理由の1つでもあります。 皮肉！！ 🤨🤣

WPFとWinFormsが新しいバージョンを使用するためにオプトインする必要がある場合でも、一般的なダイアログのXAMLWinUIバージョンがあれば嬉しいです。

WinUI 3ターゲットは非常にエキサイティングに聞こえ、私はそれを楽しみにしています。 WinUI 3を使用する従来のWin32アプリケーションのコンテキストで、配布/展開に関していくつか質問があります。

1. すべてのアプリはWinUIライブラリを持ってくる必要がありますか、それともアプリ間で共有できますか、おそらくWindowsメカニズムを介して自動的に行われますか？
2. WinUIを静的にリンクすることは可能ですか？
3. 再配布する必要があるとしましょう。WinUIのサイズはおよそMB単位でどれくらいになりますか？

すべてのアプリはWinUIライブラリを持ってくる必要がありますか、それともアプリ間で共有できますか、おそらくWindowsメカニズムを介して自動的に行われますか？

WinUI 3は、パッケージを自動的にキャッシュして共有するメカニズムを備えたNuGetを介して主に配布することを計画しています。詳細については、こちらをご覧ください。

https://docs.microsoft.com/nuget/what-is-nuget#what -else-does-nuget-do

https://docs.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders

WinUIを静的にリンクすることは可能ですか？

これは私たちが現在計画していることではありません-これが利益になるシナリオを念頭に置いていますか？

再配布する必要があるとしましょう。WinUIのサイズはおよそMB単位でどれくらいになりますか？

最終的な依存関係グラフがどのようになるかはまだ検討中ですが、UI部分については、関連する既存のsystem32 dllサイズ（数十MB）と同様になる可能性があります。

パッケージを自動的にキャッシュして共有するメカニズムを備えたNuGetを介してWinUI3を主に配布することを計画しています。

nugetは開発用だと思ったのですか、それとも何かが足りないのですか？ 私の知る限り、nugetベースのパッケージはすべてのアプリで個別にデプロイする必要があり、共有することはできません。 そのため、共有dotnetコアランタイム専用のインストーラーがあります。そうでない場合は、dotnetコアパッケージが既にnugetにあることを考慮すると必要ありません...

UIフレームワークパッケージを共有するためだけに開発ツールやSDKをインストールする必要はありません。 WPFとWinFormsfor .NET Coreは同じ問題を抱えており、共有バンドルの構築に投資したため、エンドユーザーのマシンにSDKをインストールする必要はありません。おそらく、WinUIに到達したら、それを実行する価値があります（おそらくWindowsDesktopバンドルに参加してください）

特に、フレームワークに依存する展開のためにVSにはすでにビルドオプションがあり、WinUIはこれらを活用してパッケージが確実に共有されるようにする必要があります。 もちろん、最初に共有可能なパッケージを提供する必要があります。

Microsoft Storeから提供されるアプリの場合、リリースパッケージの内容も展開時に自動的に共有される必要があります。

他の方法でデプロイされたwin32アプリの場合、あなたが言及したようなオプションを調査することは、私たちのToDoリストにあります😊

WinUIを静的にリンクすることは可能ですか？

これは私たちが現在計画していることではありません-これが利益になるシナリオを念頭に置いていますか？

明確にする必要があると思います：静的にリンクされたEXE（VCランタイムを静的にリンクする）でWinUIを使用することは可能ですか？ 私はそれがC ++ / WinRTのために問題になるべきではないと思います、しかし私はただ確かめたかっただけです...

再配布する必要があるとしましょう。WinUIのサイズはおよそMB単位でどれくらいになりますか？

最終的な依存関係グラフがどのようになるかはまだ検討中ですが、UI部分については、関連する既存のsystem32 dllサイズ（数十MB）と同様になる可能性があります。

情報ありがとうございました。

そのような巨大な事業のための素晴らしい透明性ところで、私はそれがとても好きです。

明確にする必要があると思います：静的にリンクされたEXE（VCランタイムを静的にリンクする）でWinUIを使用することは可能ですか？ C ++ / WinRTのおかげで問題はないと思いますが、確認したかっただけです。

これは（理論的には）可能であるはずですが、 @ jesbisが言ったように、パッケージ化されていないアプリが共有フレームワークでどのように取得されるかについては、まだ

Windows 7に関する議論は、（コストは言うまでもなく）労力の量がWin​​UI 3.0に大幅な遅延を引き起こすため、少し気が散ります。 Windows 7は1月にサポートが終了するため、すべてのお客様にWindows 10へのアップグレードをお勧めします。私のお客様はここで他のお客様と連携できない可能性がありますが、Windows8.1でさえ私たちにとって関心のあるプラットフォームではありません。

あなたが正しいです。 しかし、私たちは私の顧客を制御することができず、60％以上のシステムが中国でwin7です。 そして、この市場をあきらめることはできないので、win7をサポートしないテクノロジーを使用することはできません。

データはbaiduからのものです。https： //tongji.baidu.com/data/osを参照して

しかし、私たちは私の顧客を制御することができず、60％以上のシステムが中国でwin7です

TBH Win7で立ち往生している場合は、.NET Framework 4.8 + WPFを使用します。

しかし、私たちは私の顧客を制御することができず、60％以上のシステムが中国でwin7です

TBH Win7で立ち往生している場合は、.NET Framework 4.8 + WPFを使用します。

ただし、Win7Sp1は.NETFramework 4.8をインストールでき、sp1のないwin7はインストールできません。

.NETFrameworkのシステム要件|

SP1さえ持っていない場合は、すでに6年が経過しています。

サービスパックなしのWindows7 RTMのサポートは、2013年4月9日に終了しました。

https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet

Windows 7のサポートが必要な場合は、既にWindows 7をサポートしているテクノロジを使用する必要があり、Microsoftがこの問題を解決することを期待しないでください。

@MarkIngramUK Microsoftがこの問題を解決したわけではありませんが、sp1なしでwin7を使用している顧客をサポートすることはできません。 私はお客様がシステムを使用するように制御することはできませんが、sp1なしでwin7を使用しているお客様はアプリケーションを放棄し、この市場を失ったことを意味します。 しかし、新しいテクノロジーを使用しない競合他社は、sp1なしでwin7をサポートでき、競合他社はこの市場に勝ちます。

悲しいことですが、本当のことですが、あまりにも多くのお客様は、私たちが使用するテクノロジーを気にかけていませんが、アプリケーションがすべてのデバイスで正常に実行できることを気にかけています。

これは私の業界の現状であり、上記の結論は他の業界には適していない可能性があります。

@lindexiは、私が言っているように、新しいテクノロジーが、すでに6年が経過したOSに移植されることを期待することはできません。 古いOSをターゲットにする場合は、古いテクノロジーが必要です。

@lindexi顧客がサポートされているテクノロジーを使用することを望まず、古いものを好む場合、最新のUIを使用することを合理的に期待することはできないと思います。 これらの2つの要件は、純粋に相互に排他的です...

@MarkIngramUK悲しい。 今日の新技術が使えるようになると、この新技術は古い技術になっていると思います。

@lindexiこれは文字通り何が起こっているのか反対です。 新しい技術を「古い技術」と呼ぶことはできません。それは、古いOSに移植されていないからです。 Win7（SP1なし）のサポートが必要な場合は、WinFormsまたはMFCなどを使用してください。

@MartinZikmundその通りです。 実際、私たちのユーザーはほとんどコンピューター技術を理解しておらず、win7とwin10でさえ理解できません。 彼らは私たちがどのテクノロジーを使用するかを気にしません。

@jesbis C ++を使用した新しいWinUIで手を汚したいです。 過去にUWPとC ++ / Cxを使用して最善を尽くしましたが、PhotoEditorアプリといくつかのサンプルに加えて、常に頭を悩ませて、XAMLをPlatform :: Collectionsなどにバインドするための優れたドキュメントを見つけようとしました。それ。 これが、WindowsでのUWP開発用にC＃に、C ++開発用にQtに切り替えた理由の1つです。 C ++への愛をもっと示してください。

私の顧客では、Windows 10 MediaでUSBスティック（PenDrive）を使用し、それをWindows7から最新のWindows10に無料でアップグレードするだけでした。 ウイルス対策、Windows Update、Edge WebBrowserを備えた最新のOSのメリットを享受し、WinForms、WPFなどの古いものから、UWP以降（WinUI）を含む最近のものまでのGUIテクノロジをサポートします。 また、シャットダウンの代わりに、Windowsを休止状態に設定し、電源ボタンを押すだけでPCの操作を開始し、PCの使用が終了したら電源ボタンを押すようにユーザーに教えました。
また、マシンを簡単にインストール/アップグレードできるように、ネットワークにISOを配置しました。

また、CandyCrushがコンピューターにプリインストールされているという利点もあります。

意見

WPFのコントロールの実装は、古いバージョンのWindowsサポート用にWinUIにマージできると思いました。 （たとえば、Windows 7です。）しかし、社内政治のせいで、マイクロソフトがそれを実現するのは難しすぎます（笑）。

返信

@lindexi
今日、中国には古いWindowsバージョンのユーザーがたくさんいることを私は知っています。 しかし、今日はWindows NT 5.xユーザーを放棄する必要があると思いますし、それは難しいことだと思います。

@MartinZikmund

顧客がサポートされているテクノロジーを使用したくなく、古いものを好む場合、最新のUIを使用することを合理的に期待することはできないと思います。 これらの2つの要件は、純粋に相互に排他的です...

少数派に仕事を提供したくない場合、中国では最新のUIと古いプラットフォームのサポートの両方が必要です。 そのため、私の友人の1人である中国の開発者は、更新プログラムをインストールせずにBlinkとV8をWindows XPに移植し、多くの開発者がそれを使用して最新のアプリエクスペリエンスを実装しています。 中国では、オペレーティングシステムの最小バージョン要件は、アップデートがインストールされていないバージョンと同じです。 たとえば、中国のアプリのオペレーティングシステムバージョン要件がWindows 7であることがわかっている場合、「Windows 7RTM」または「6.1.7600.16385（win7_rtm.090713-1255）」でアプリを使用できることが示されます。 Androidの世界でも、今日でも多くのアプリがAndroid4.4をサポートしています。

これが、中国以外の開発者によって作成されたほとんどのアプリが中国で多数派の選択肢にならない理由です。

PS最新のVisualStudio 2019を使用して更新プログラムをインストールせずに、最新のWindows 10SDKと最新のC ++ 17標準を使用して、または今すぐC ++ 20を試してWindowsXPRTM用のアプリをビルドできます。 VC-LTL（https://github.com/Chuyu-Team/VC-LTL）とYY-Thunks（https://github.com/Chuyu-Team/YY-Thunks）のため。

私自身についての注意

ほとんどの場合、私は最新の安定したWindowsビルドを使用しています。 任意のインストールされた更新プログラム以降の条件理由すべての更新なしのWindows Vista RTM用に設計された私のWin32プロジェクトが

毛利健二

すべてのWinUI3.0コントロールクラスの封印を解除することを検討してください。

私の理解によると、JavaScript（継承を認識しない）は継承されたクラスで使用すると問題が発生したため、MicrosoftはすべてのUWPコントロールクラスを封印することを決定しました。 JS / HTMLが非推奨になったため、新しいUIフレームワークですべてのクラスをシールする必要はなくなりました。 セラリングを解除すると、WPFで常に可能だったように、UWPコントロールのカスタマイズがはるかに簡単になります。 また、カスタムの仮想化リストコントロールまたはパネルを作成するときに、シールされていない仮想化基本クラスを継承することも非常に役立ちます。 C＃、C ++ / CX、C ++ / WinRTのいずれにも継承の問題はありません。 これを私たちに強いたのは、JS / HTMLと呼ばれる失敗だけでした。

したがって、WinUI 3.0を作成するときは、この不要な制限を削除してください。

@gisfromscratchフィードバックをありがとう！ 私たちは間違いなくC ++開発（特にC ++ / WinRT）をサポートしたいと思っています。

C ++を使いやすくするものは何ですか？ CXの代わりにC ++ / WinRTを試しましたか？

より多くのサンプルアプリが役立ちますか？

バインディングに関するドキュメントを見つけるのは難しいとおっしゃいましたが、より良いドキュメントが必要な他の特定の機能はありましたか？

すべてのWinUI3.0コントロールクラスの封印を解除することを検討してください。

@lukasfこれは私たちがやろうとしていることです🙂＃780で進行中のいくつかの関連する議論があります

@jesbis C ++ / WinRTを使用して手を汚す必要があります。 Photo Editor C ++ / WinRTサンプルアプリケーションをフォローしました。 ただし、データバインディングなどの提供されたリンク

@gisfromscratchありがとう！ WinUI 3のドキュメントの更新に取り組む際には、このことを念頭に置いておく必要があります。

それが役立つ場合は、あなたが言及したそのデータバインディングページは、特にC ++ / WinRTを使用したデータバインディングに関するいくつかの個別のページにもリンクしています。

XAMLコントロール;

XAMLアイテムコントロール。

そのセクションには、他にもC ++ / WinRT固有のトピックがいくつかあります。

あなたの素晴らしい仕事をありがとう！ XamlIslandがWinUi3.0から削除されたことを非常にうれしく思います。
ところで：WinUi3.0での言語プロジェクションの低レベルの実装はWinRTコンポーネントとは異なるのではないかと思います。 WinRTコンポーネントの言語プロジェクションの実装は、コンパイル時と実行時の両方で.NETUWPプロジェクトのパフォーマンスに大きな打撃を

@zenjiaXAMLアイランドはWinUI3から削除されません。WinUI3には、WPF / WinForms / MFCアプリがWinUI3コントロールをホストできるようにするAPIが含まれます。

私はWinUIの進歩についていくように努めてきました。 過去にC＃でUWPアプリを作成しようとしましたが、困難な戦いでした。 しかし、winui3.0の後でもう一度やり直したいと思っています。

winuiロードマップについて質問があります。 これが4つです。 他の場所でカバーされている場合は申し訳ありません。 多くの検索にもかかわらず、私は答えを見つけられませんでした...これらのタイプの質問をするためのより良いフォーラムがあるかどうか私に知らせてください。

• ネイティブコントロールの.netラッパーもオープンソースになりますか？ 私が見つけた唯一のc＃コードが自動テスト用であることを考えると、これがwinuiの.Net側を担当するgithubreproであるかどうかは明らかではありません。 Microsoft.UI.Xaml.UIElementのようなものを探していますが、そのコードがどこにも見つかりません。

• winui 3.0のリリースに到達すると、UWPappmodelとwin32appmodelは同じ.NetCoreランタイムを実行しますか？ UWPアプリケーションで使用されている.Netコアのバージョンを完全に把握したことはありません。 これはWindows自体に組み込まれているものであり、Windows 10 SDKにより、VS2019がUWPで利用可能な正しいバージョンの.Netコアをターゲットにできるようになっていると思います。

• Xaml島についての質問。 WPFとUWPが同じ空域を共有する可能性はありますか？ winformsとWPFの間で行ったように、空域の問題に対処する必要があることを楽しみにしていません。 WPFとUWPの両方がdirect-X上に構築されていることを考えると、互いにピクセルを共有できれば素晴らしいと思います。 たとえば、UWP xamlアイランドをオーバーレイする必要があるリボン（WPF内）に舞台裏のメニューがある場合、それがシームレスに行われると便利です。 そのようなことのために私がたくさんのフープを飛び越えなければならないように思われません。 ... WPFの初期の頃、彼らは「WebBrowser」winformsコントロールを使用したいクライアントアプリケーションの空域の問題を解決しようとしたことを覚えています。 彼らは「WebBrowser.CompositionMode」と呼ばれるWebブラウザーの機能を試し、WebBrowserがWPFとうまく連携できるようにするはずでした。 ...しかし、私は戦略が最終的に放棄されたと思います。 おそらく、UWPとWPFの間の相互運用性は非常にシームレスであるため、互いにピクセルを共有することさえできます（winformsやWPFとは異なります）。 これの潜在的な利点の1つは、WPFがUWPコントロールの機能を強化できるようにすることです。 たとえば、WPFは、装飾レイヤーに類似した方法で、xamlアイランドに追加のビジュアルをオーバーレイできます。 これはピンチで便利になる可能性があります。

• xamlアイランドを含むWPFアプリ（たとえば、50％WPFと50％WINUI）がいつかARM64にネイティブにコンパイルされる可能性はありますか？ ARMのターゲティングは、100％UWPのアプリケーションで可能です。また、WPFの依存関係によって、ネイティブのARM64ターゲティングを強制的に放棄しないようにするとよいでしょう。 （別の方法は、x86エミュレーションでアプリを実行することですが、それは遅く、使用できるメモリが制限されます）。

うまくいけば、これらの質問はすべてwinuiのロードマップに関連しています。 何かアドバイスをいただければ幸いです。

ネイティブコントロールの.netラッパーもオープンソースになりますか？ 私が見つけた唯一のc＃コードが自動テスト用であることを考えると、これがwinuiの.Net側を担当するgithubreproであるかどうかは明らかではありません。 Microsoft.UI.Xaml.UIElementのようなものを探していますが、そのコードがどこにも見つかりません。

UIElementはWinUI2にないため、現在リポジトリにはありません。 まだリリースまたはオープンソース化されていないWinUI3に含まれる予定ですが、現在取り組んでいます。

WinRTプロジェクションを介して.NETに公開されている他のネイティブコントロールのリポジトリに例があります。たとえば、れているWinUI2.2コントロール

@ marb2000は、島/デスクトップの質問に最もよくコメントできます。

Q： _WinUI 3 UWPとデスクトップは同じ.NETランタイムを使用しますか？_
A：はい、これは計画です。 UWPとデスクトップは.NETCore 3を使用します。マネージドWinRTライブラリは、.NETNativeではなく.NETCore3を使用します。

Q： _WPFとUWPは同じ空域を共有しますか？_
A： WPFとWinUI（およびXAML UWP）は似ているように見えますが、そうではありません。 WPFはDirectX9を使用し、WinUI / XAML UWPはWindows.UI.Compositionを使用して、XAMLの構成、レンダリング、およびアニメーションのニーズに対応します（DirectX11の最新バージョンを除く）。 悲しいことに、これは相互運用が非常に複雑になる原因になります。 WPF装飾者についてのあなたの提案は興味深いものです。 理論的には、採用者はポップアップを作成して、WinUI / XAMLコンテンツをWPFコンテンツの上に配置できます。 または、再レイアウトが必要であることをWPFビジュアルツリーに通知できますが、すべてHWndに基づいています。
@dbeavonこれは良い提案ですが、これに対する機能リクエストを作成できますか？

Q： _XamlIslandsを使用するWPFアプリはARM64にコンパイルされますか？_
A： .NET Core 3 forWindowsがARM64を確実にサポートしている場合。 現在、WindowsでARM32をサポートしています。 ただし、LinuxではARM64をサポートしています。 WindowsでもARM64をサポートすることは.NETCoreロードマップにあると思います。 AFAINですが、まだ日付はありません。 @richlander 、何かニュースはありますか？

@ marb2000

Q：WPFとUWPは同じ空域を共有しますか？

UWPはWindows.UI.Compositionを使用して、DirectXビットマップからレンダリングを取得できるレイヤーを作成できますか？ 次に、WPFはウィンドウをwin2dのようにこのレイヤーにレンダリングします。 多分それは同じ空域を共有することができます。 ただし、WPFをレイヤーにレンダリングすることは困難です。

@lindexi私はそれが天国かもしれないと思います：D

UWPはWindows.UI.Compositionを使用して、DirectXビットマップからレンダリングを取得できるレイヤーを作成できますか？

UWP Xamlには、DirectXビットマップまたはスワップチェーンをXamlでレンダリングし、それらをWindows.UI.Compositionと合成して、 SurfaceImageSource 、 VirtualSurfaceImageSource 、 SwapChainPanelなどの同じ空間を共有する方法がいくつかあります。

https://docs.microsoft.com/windows/uwp/gaming/directx-and-xaml-interop

Windows.UI.CompositionビジュアルをUWPXaml UIツリーに挿入し、DirectXコンテンツを描画することもできます。たとえば、ここで概説するように、 ICompositorInterop 、 ICompositionDrawingSurfaceInterop 、およびICompositionGraphicsDeviceInteropを使用します。

https://docs.microsoft.com/windows/uwp/composition/composition-native-interop

これらのアプローチは、WinUIでも同様に機能するはずです。

UWPデスクトップアプリは、WPF / WinForm DLLを参照し、WPF / WinFromウィンドウを開くことができますか？ これにより、徐々に移行できるようになります。

@ marb2000-.NET Core for WindowsARM64はロードマップにあります。 私は今そのための計画に取り組んでいます。

WinUI 3.0では、その上にwin2dをコンパイルすることは可能ですか？
（したがって、UWPから切り離します）
もしそうなら、それはめちゃくちゃ素晴らしいでしょう！

DirectX統合の詳細についてはまだ検討中ですが、UWPXaml基本クラスの代わりにWinUI基本クラスを使用するようにWin2Dを更新できることを願っています。

指が交差した：D

これがトピックから外れている場合は申し訳ありません：UWPのバグレポート-https： //github.com/microsoft/microsoft-ui-xaml/または他の場所に問題を追加し

これがトピックから外れている場合は申し訳ありません：UWPのバグレポート-https： //github.com/microsoft/microsoft-ui-xaml/または他の場所に問題を追加し

@jtorjo素晴らしい質問です！ このリポジトリは、以下に関連する問題を提出するのに最適な場所です。

• UWP UIフレームワークAPI（Windows.UI.Xamlなど）
• 流暢なデザイン
• WinUI

一般に、 docs.microsoft.comのほとんどのドキュメントページの下部に「この製品に関するフィードバックを送信する」リンクがあり、特定の機能またはAPIに関するフィードバックを提供するための最良の方法が

上記以外のUWPのほとんどの側面では、関連するサブカテゴリがいくつかあるフィードバックハブの開発者プラットフォームカテゴリでバグを報告します。

WinUI3にはUWPSemanticZoomコントロールが含まれますか？ 私はそれがそれらすべての中で最もクールなコントロールだと思います。

@jesbisありがとう！ System.IOに関するディスカッションを投稿しました

MicrosoftでさえOfficeのWindows7サポートを廃止していませんが、なぜWinUI3は廃止するのでしょうか。 つまり、ほとんどすべての本格的なソフトウェアはWindows 7をサポートしています（Photoshop、Office、Visual Studio 2019、VSCodeなど）。WinUIがWindows7をサポートしていない場合...

MicrosoftでさえOfficeのWindows7サポートを廃止していませんが、なぜWinUI3は廃止するのでしょうか。 つまり、ほとんどすべての本格的なソフトウェアはWindows 7をサポートしています（Photoshop、Office、Visual Studio 2019、VSCodeなど）。WinUIがWindows7をサポートしていない場合...

MicrosoftのWindows7のサポートは間もなく終了するため、Officeはおそらく間もなくサポートを終了します。 しかし、それはすでにWindows7をサポートしているコードベースに基づいて構築されています。

WinUIはWindows10上に構築されているため、Windows 7にバックポートする必要があります。これを行う努力は、OSがEnd Of Lifeに入ると意味がないため、Windows10にアップグレードする必要があります。

Q：WinUI 3 UWPとデスクトップは同じ.NETランタイムを使用しますか？
A：はい、これは計画です。 UWPとデスクトップは.NETCore 3を使用します。マネージドWinRTライブラリは、.NETNativeではなく.NETCore3を使用します。
Q：WPFとUWPは同じ空域を共有しますか？
A：WPFとWinUI（およびXAML UWP）は似ているように見えますが、そうではありません。 WPFはDirectX9を使用し、WinUI / XAML UWPはWindows.UI.Compositionを使用して、XAMLの構成、レンダリング、およびアニメーションのニーズに対応します（DirectX11の最新バージョンを除く）。 悲しいことに、これは相互運用が非常に複雑になる原因になります。 WPF装飾者についてのあなたの提案は興味深いものです。 理論的には、採用者はポップアップを作成して、WinUI / XAMLコンテンツをWPFコンテンツの上に配置できます。 または、再レイアウトが必要であることをWPFビジュアルツリーに通知できますが、すべてHWndに基づいています。
@dbeavonこれは良い提案ですが、これに対する機能リクエストを作成できますか？
Q：Xaml Islandsを使用するWPFアプリはARM64にコンパイルされますか？
A：.NET Core 3 forWindowsがARM64を確実にサポートしている場合。 現在、WindowsでARM32をサポートしています。 ただし、LinuxではARM64をサポートしています。 WindowsでもARM64をサポートすることは.NETCoreロードマップにあると思います。 AFAINですが、まだ日付はありません。 @richlander 、何かニュースはありますか？

では、UWPサンドボックスを削除していますか？ これは、現在の形式のUWPも廃止され、私たちが知っているように、App Storeの保護されたサンドボックスがなくなることを意味しますか？

では、UWPサンドボックスを削除していますか？ これは、現在の形式のUWPも廃止され、私たちが知っているように、App Storeの保護されたサンドボックスがなくなることを意味しますか？

UWPサンドボックスを取り除くことはめちゃくちゃ素晴らしいでしょう！

これは、UWPがなくなるという意味ではありません。 ユニバーサルWindowsプラットフォームは、Windowsデバイス（PC、Xbox、HoloLensなど）の全範囲をネイティブに構築する唯一の方法であり、Windowsがネイティブプラットフォームへの投資に注力している場所です。 RE：特にサンドボックス化：アプリコンテナの分離は、アプリとUWPアプリとデスクトップアプリの両方のユーザーに多くの重要なメリットを提供し続けます。

主な変更点は次のとおりです。

• デスクトップ（win32）アプリモデルでも使用できるように、UXプラットフォーム（つまりWinUI）の範囲を拡大しています
• WinUIをWindowsから切り離して、より頻繁に更新し、新しい機能に下位互換性を持たせ、より簡単にオープンソース化できるようにします。

つまり、新しいアプリの場合、アプリの意味に応じてUWPモデルとデスクトップアプリモデルのどちらかを選択できます。既存のデスクトップアプリ（WPF、WinForms、MFCなど）がある場合は、それらを最新のアプリで段階的に更新できます。 Xamlアイランドを使用したWinUI機能。

では、UWPサンドボックスを削除していますか？ これは、現在の形式のUWPも廃止され、私たちが知っているように、App Storeの保護されたサンドボックスがなくなることを意味しますか？

UWPは、WinUI3.0アプリを構築するためのオプションの1つになります。 UWPを使用すると、アプリをXbox、Hololensなどで実行できるようになります。

ただし、WinUI 3.0を使用してWin32アプリを構築し、UWP APIにアクセスすることもできますが、アプリを実行できる場所はさらに制限されます。

@mdtauk @jesbis私は完全にUWPに

1. コンパイル時間はめちゃくちゃ遅いです！ （かなり、WPFの6倍遅い-私はターゲットバージョンのビルド1809を使用しています-ビルド17783）
2. StorageFolderファイル列挙APIがUWPの一部ではないことは知っていますが、それはめちゃくちゃ遅いです。 UWPサンドボックス（少なくともWindowsデスクトップでは）は、支援以上に痛いです。
3. 確かに、非同期プログラミングは楽しいですが、UWPでは、例外が発生すると、何らかの形でUWPコードに食われ、後でデバッガーで中断され、すべてのスタックコンテキストが失われます。 スローされた例外自体の中にスタックコンテキストがある場合もありますが、常にそうとは限りません。
4. UWPコードのプロファイリングはほぼ不可能です。 イベントdotTraceは、実行しようとすると即座に中断します。

（コードをWPFからUWPに移植するのに1か月以上かかりました。これは、win2dがめちゃくちゃ必要なので、UWPを回避する方法がないためです。）

@mdtauk @jesbis私は完全にUWPに

1. コンパイル時間はめちゃくちゃ遅いです！ （かなり、WPFの6倍遅い-私はターゲットバージョンのビルド1809を使用しています-ビルド17783）
2. StorageFolderファイル列挙APIがUWPの一部ではないことは知っていますが、それはめちゃくちゃ遅いです。 UWPサンドボックス（少なくともWindowsデスクトップでは）は、支援以上に痛いです。
3. 確かに、非同期プログラミングは楽しいですが、UWPでは、例外が発生すると、何らかの形でUWPコードに食われ、後でデバッガーで中断され、すべてのスタックコンテキストが失われます。 スローされた例外自体の中にスタックコンテキストがある場合もありますが、常にそうとは限りません。
4. UWPコードのプロファイリングはほぼ不可能です。 イベントdotTraceは、実行しようとすると即座に中断します。

（コードをWPFからUWPに移植するのに1か月以上かかりました。これは、win2dがめちゃくちゃ必要なので、UWPを回避する方法がないためです。）

これがこのスレッド＃1517に投稿されると便利であり、SDKチームの誰かの名前に含めることができれば幸いです。

@jtorjo

コンパイル時間はめちゃくちゃ遅いです！ （かなり、WPFの6倍遅い

C ++ / WinRTを使用していますか？ もしそうなら、プリコンパイル済みヘッダーを使用していますか？

@mdtaukが投稿されました

@MarkIngramUKそれはc＃コードです

締めくくり-ロードマップとアルファフィードバックを次の宛先に送信してください：＃1531

今のところ、これが可能かどうかはわかりません。WinUIビットがOSから削除されたときに、他のプラットフォームが何らかの互換性コンポーネントを提供できるように、オープンソースプロジェクトに組み込まれることが期待されています。 Xamarin、Uno、または.NetCoreとカスタムレンダラーを考えてみてください。

これは本当にロードマップ上のものですか、それとも単なる仮定でしたか？

@ mdtauk 、 @ zezba9000理論的にはすべて可能であり、チームにはプラットフォーム抽象化の専門知識がたくさんあります。 何でもそうですが、それはコスト、スケジュール、期待される利益に帰着します😊

おそらく、サードパーティがAndroidまたはiOSで動作させることを可能にするような方法でそれを抽象化することは巨大です。 私はコミュニティがこれを行うことができると確信しています。 私は間違いなくそれに貢献したいと思います。

@andreinitescu怒りと苦情を申し訳ありませんが、私が理解していることからの私の考え： Windows / Win32専用のもののWPFを置き換えるためにWinUI3を使用しますが... Windows上のWinUIはWindowsのみのレンダリングAPIを使用し、無関心ではないためです1つは、WinUIがサードパーティに依存して他のプラットフォームでWinUIを再実装/フラグメント化（ugg）しているようです（UNOプロジェクトのようにクールですが、Mono to .NETのように不要であり、断片化が必要な場合は時間を無駄にしますそもそも設計されています）。 Skiaのようなポータブルなものを使用したり、MSのものを作成したりする代わりに。 また、WinUIでC＃を使用しない1％の人々をサポートする必要性を理解していないため、C＃はある意味でセカンドクラスのターゲットになり、さらに重要なことに、開発時間が大幅に長くなります。 Androidが多くのコアアプリにJava + post-AOTを使用するのと同じように、WindowsはC＃+ pre-AOTを使用する必要があります。 時間を節約できるからです。 結局、C ++を使用しているバグの70％は、割り当て解除されたptrを使用しています。

長期的なユースケースでの企業内のグループ間のコミュニケーションの欠如は、モバイルプラットフォーム用のAndroid OSフレーバー（私が使用する予定です）をリリースするときにますます問題になり、より多くの人々がそれをターゲットにしたいと考えていますMSツールを使用すると...ある意味で再びWinPhone7のような状況になると感じます。 用語としてのWindowsは、もはやWinNTカーネルにそれほど結び付けられるべきではありません。 エコシステムは、その上に構築された単一のプラットフォームまたは1つの企業のフレームワーク以上のものです。

悪いことに、MSは、AppleがOS9からOSXへの移行でほぼ20年前に行ったことを実行できない/実行しません。 UNIX / LINUXカーネルに移行することでバンドエイドを取り除いていますが、ソフトウェアと開発ツールをネイティブに実行するために移行する間、レガシーソフトウェア用のエミュレーター/シミュレーターがOSに組み込まれています。 （これについてあなたが何をするか考えてください、しかし私は夢を見ることができます）