将来のアップデートでは、.NET Core 3.1以降やデスクトップ（win32）アプリモデルなど、追加のプロジェクトタイプと言語のサポートが追加されます。

では、アルファ版はまだ.NETNativeまたは.NETCore 3.0で実行されていますか？ 前者の場合（依存関係があるため）、3.0は将来的にターゲットになりませんか？

アルファ版は今のところ.NETNativeまたはC ++で動作し、RTMは.NETCoreをサポートします。 .NETチームとのバージョン管理をまだ行っているので、現時点ではおそらく3.1と言うべきではありませんが、それまでにオープンソースになることを願っています。そのため、誰もが最新情報を簡単に入手できるはずです。 🙂

コードはいつ公開されますか？

@vitorgrsまだ確定した日付はありませんが、現在取り組んでいます。現在、これが主な焦点です。

@vitorgrsまだ確定した日付はありませんが、現在取り組んでいます。現在、これが主な焦点です。

ありがとう！

WinUI 3のコンパクトサイジングを忘れないでください。おそらくビルド'18で発表されましたが、これまでは2〜3個のコントロールしかサポートしていません。

@MuziburRahman WinUI 2（および3）でコンパクトスタイルの辞書を使用してみましたか？

https://docs.microsoft.com/windows/uwp/design/style/spacing#fluent -compact-sizing

さまざまなテキストおよびリストコントロール、ContentControl、TreeView、DatePicker、TimePicker、ComboBox、NavigationViewなどを自動的に調整する必要があります。

調整する必要があると思う特定の他のコントロールはありますか？

@jesbisもちろん、RadioButton、CheckBoxはどうですか？

@MuziburRahmanは、コンパクトスタイルを使用する場合、デフォルトですでにコンパクトマージンを持っている必要があります。

わお！！ 宇野ビットは私の一日を啓発しました！
それはすごいおかしくなります！ MicrosoftとUnoおめでとう🍻

まず、WinUIに携わったすべての人に感謝します。 WPFは、私のキャリアの中で使用する機会があった中で最も「最先端の」Windows UIフレームワークでした。これは、一般に、UWPの制限により、モダナイゼーションを困難にする通常のレガシーコードの問題が組み合わされたためです。 WinUI3.0の使用を楽しみにしています。

ロードマップに最初に出くわしてから読んだものはすべて素晴らしいですね。 たとえば、XAMLを基盤となるアプリモデルから分離することは完璧です。 x：Bindなどの機能をWPFアプリケーション（つまり、Win32アプリモデルを使用するアプリケーション）のコンパイル時のバインディングチェックにすぐに使用できるようになることは、私が何年も望んでいたことであり、主に欠けていたものです。私にとってはXAMLから。 私は最近、それが実際にはXAMLにすでに存在していて、しばらくの間UWP開発者に楽しんでいるものであることを発見しました。

その上、最終的にFluent Designに準拠するすべての優れたコントロールにアクセスし、XAMLアイランドを使用してWPFで利用できるようにします。さらに、他のすべてのものも利用できます。基本的に、Windowsデスクトップ開発に必要なものはすべてここにあります。同時に。 箱から出してすぐに素晴らしいルックアンドフィールを備えたWindowsアプリケーションを作成するのがはるかに簡単になるようです。 よろしくお願いします。

タイムラインに関していくつか質問があります。

私の最初の質問は単純だと思います。2020年2月までに（かなり安定したプレリリースとしても）WinUI 3.0の製品対応バージョンを期待するのは非現実的だと言っても過言ではありませんか？

基本的に、現在進行中の内部ツールのプロジェクトがあり、リリース予定日は2020年2月です。「純粋な」WinUI 3.0アプリとして作成できるようにしたいと思います。これにより、両方が削減されると思います。 UIの開発時間が大幅に短縮され、ユーザーが期待するものをはるかに超えてユーザーを驚かせるUIが実現します。

ただし、次のレベルの複雑さは、実際には、この新しいツールは既存のツールへの追加として作成する必要があり、既存のツールは.NET Framework4.7.2のWPFを使用して構築されることです。

これらすべてを念頭に置いて、おそらく私たちにとって最善の策は（新しいツール用のモダンな外観のFluentベースのUIを使用するために）次のことになるだろうという私の理解は正しいです。

• 既存のアプリケーションをWPFアプリケーションとして保持します
• .NET Framework4.7.2から.NETCore 3.1に移植します（これは、以下の最後のポイントをサポートするために必要だと思います）
• 新しいツールのビュー（つまりカスタムコントロール）用にWinUI2.3を使用してUWPクラスライブラリを作成します
• XAMLアイランドを使用して、WPFアプリケーションでこれらの最新のビューをホストします

そのアプローチの正しさは、私の2番目の「質問」になります。 私と同じように既存のツールを知っているので、とにかくそれを.NET Core 3.1に取り込むことができるのではないかと疑っています。もちろん、新旧のUIが衝突しすぎるという問題もありますが、私はmここで私の夢を生き続けようとしています...

とにかく、これらの2つの質問の大まかな指示が可能であれば、それは大いにありがたいです。

これが間違った場所であるかどうかを教えてください。ただし、現在のuwpアプリからWinUI + dotnet core 3への移行パスはありますか？ 移行にはコードの変更が必要ですか？

Unoの実装はブラウザーにありますか、それとも独自のウィンドウでアプリを実行することは可能ですか？

Unoの実装はブラウザーにありますか、それとも独自のウィンドウでアプリを実行することは可能ですか？

「Electronを介してChromiumでアプリを実行する」

ElectronはWebAssemblyをカプセル化して実行するようです。

@dpaulinoWinUIへの移行に関するすべてのオプションを検討しています。 現在、WinUI nugetをターゲットにして、「Windows.UI.Xaml」を「Microsoft.UI.Xaml」に検索して置き換えるだけの移行パスが表示されています。 Color、Thickness、INotifyPropertyChangedなどのコンストラクターなどの.Netのカスタムプロジェクションのメリットはありません。私たちの目標は、切り替えをできるだけ簡単にすることです。したがって、必要なもののリストが複雑になりすぎる場合は、修正を確実に検討します。それまたはそれを無痛にするためのツールを追加します。

@agoodwinコメントありがとう

リリース期間が2〜3か月しか離れていない場合、既存のアプリを拡張するのが最も合理的なアプローチのように思えます。 .NET Coreに移行でき（またはC ++で新しいビューを作成でき）、すべてのユーザーがWindows 10 May 2019 Update以降を実行し、XamlIslandsを使用してUWPXaml +で作成された新しいビューをホストする場合WinUI 2は、それがアプリにとって意味のあるものになった場合、将来のWinUI3ソリューションに向けた優れた段階的なステップになる可能性があります。

.NETCoreを使用したwin32 /デスクトップでのWinUIが待ちきれません！

WinUI3.0の安定版リリースが始まります。 その後に何が起こるかは、長期的にはプラットフォームを作り上げたり壊したりします。

すべてのキャンプの開発者のニーズに迅速に対応しますか？

現在Win32レガシーUIで「スタック」している受信トレイアプリはWinUIに移動されますか？

「制限付き」のUWPアプリは、サンドボックスからリリースされたときに、より優れたパフォーマンスと新しい強力な機能を見つけますか？

開発ストーリーは、Twitter、Facebook、Apple、Googleなどの大企業にとって明確で説得力があり、さまざまなフォームファクタでWindowsにアプリをもたらしますか。

そして最大の未知数は、MicrosoftがWindowsとAndroidの受信トレイと大きなアプリをどのように統合して、Windows 10、10X、Xbox Scarlet、Surface DuoのMicrosoftフレーバーのAndroidでシームレスに動作するかということです。

@agoodwinコメントありがとう

リリース期間が2〜3か月しか離れていない場合、既存のアプリを拡張するのが最も合理的なアプローチのように思えます。 .NET Coreに移行でき（またはC ++で新しいビューを作成でき）、すべてのユーザーがWindows 10 May 2019 Update以降を実行し、XamlIslandsを使用してUWPXaml +で作成された新しいビューをホストする場合WinUI 2は、それがアプリにとって意味のあるものになった場合、将来のWinUI3ソリューションに向けた優れた段階的なステップになる可能性があります。

明確化のおかげで、C ++が.NETCoreなしでWinUI2を短期的に使用するための別のオプションであることに気づかなかったので、それを知っておくとよいでしょう。

現実的には、私が参照していた特定のアプリケーションでC ++を使用するべきではないかもしれませんが、C ++のものがいくつかあるので、そのために役立つ可能性があります。

とにかく、今のところ、.NET Coreへの移行がうまく機能し、そこから機能することを期待する必要があるようです。 再度、感謝します。

オフトピックっぽい：

mdtaukのコメントを読んだ後、GoogleとFacebookにはWindows用のネイティブアプリすら存在しないことに気付きました（Googleドライブのバックアップを除く）。 Facebookには、iOSからの移植版であるUWPアプリがありましたが、それらは廃止されました。 FBがreactnativeを使用してネイティブアプリをリリースするのを想像できます/ react-native-windowsがreactnativeとマージされた場合

SpotifyとAdobeが何をするのか興味があります。 SpotifyはElectronに依存しており（実際にはChromium Embedded Framework、同じことです笑）、Adobeには非常に古いコードベースがあります（XDは新しいアプリであり、UWPアプリです）。 ああ、MicrosoftOfficeを私の小さなリストに追加してください。 Officeにも古いコードベースがあります。

Electronによるwin7のサポートは良い方法ではないと思います。 プラットフォームで実行する必要があるが、Electronに依存している理由。

@lindexi
Win7がまったくサポートされるべきではない場合、何もないよりはましです。
また、Win7への完全なバックポートには時間がかかるため、Microsoftのリソースを使用してWin10でWinUIを改善することをお勧めします。 私見では。

小さなプログラムをWinUI3 Alphaに移植しようとしていますが、DPIの認識が不足していることに驚いています...これは設計によるものではありませんか？😂

@Tirraon私はあなたの

ただし、この動作により、Win7のWPFスペースが圧縮されます。 「ここを見てください。UNOはElectronを使用しています。ElectronはWPFよりも優れています...」

その通りですが、生まれたばかりのフレームワークはすべて、古いフレームワークを圧縮する可能性があります。 UWPはWindows10でWPFを圧縮し、Xamlアイランドを使用したWinUIもそれを圧縮します。

ただし、この動作により、Win7のWPFスペースが圧縮されます。 「ここを見てください。UNOはElectronを使用しています。ElectronはWPFよりも優れています...」

その通りですが、生まれたばかりのフレームワークはすべて、古いフレームワークを圧縮する可能性があります。 UWPはWindows10でWPFを圧縮し、Xamlアイランドを使用したWinUIもそれを圧縮します。

Electronがdotnetテクノロジースタックにあるとは思わない。 UWP zip WPFは喜んでいますが、Electron zipWPFは好きではありません。

いいね。 しかし、ユニバーサルで最新のユーザーエクスペリエンスが必要なため、WPFXAMLがWinUIXAMLに置き換わる時期を知りたいと思います。

いいね。 しかし、ユニバーサルで最新のユーザーエクスペリエンスが必要なため、WPFXAMLがWinUIXAMLに置き換わる時期を知りたいと思います。

Xaml Standardは、熱狂して死亡しました。 WPF XAMLは2009年の仕様だと思いますが、WinUIXAMLは2006年です。

.Net Core5とWinUI5が、統一されたオープンスペックの2021XAMLスペックへの移行を完了する可能性があることを願っています。

Win32 / Desktop用のWinUI3.0 alphaが利用可能になる時期について何か考えはありますか？
仕事の場合、これは私たちの管理ソフトウェアに十分な機能を備えた唯一のターゲットです。 そこに飛び込むのが待ちきれません。

win32プレビューの確定日はまだ決まっていませんが、発表したらお知らせします。

現在サポートされていない機能のリストにAppWindowが表示されませんでしたが、必要なAPIが現在不足しているようです。

@lhak申し訳ありませんが、それを指摘してくれてありがとう（そしてアルファを試してくれてありがとう！）-現在サポートされていません。 既知のAlpha制限で文書化するために、PRを開いたところです。

@jesbis （ここ）
アルファ版は今のところ.NETNativeまたはC ++で動作し、RTMは.NETCoreをサポートします。

問題は、C＃8が.NET Core3に対してのみ機能することです。アルファ版ではかなり大きな制限があります。
とにかく、私は注意深く見て、あなたの数え切れないほどの努力に感謝します💖

WinUI 3.0はWPFで動作しますか？ はいの場合、XamlIslandsがなくても機能しますか？ いいえの場合、C＃を使用してUWPを使用せずに、サンドボックスで実行されないもので使用する選択肢はありますか？

これはWebRTCを使用するためにカメラとマイクにアクセスするための重要なイベントであるため、PermissionRequestedイベントが早い段階で存在することを望んでいます。 または、WebビューからのWebカメラとマイクの許可要求を処理する新しい方法はありますか？

win32アプリモデルを使用したWinUI3.0に関するニュースはありますか？
待ちきれません。

@amyhaber Win32をサポートするWinUIデスクトッププレビューは、来週のビルドの前後にリリースされる予定です。

@amyhaber Win32をサポートするWinUIデスクトッププレビューは、来週のビルドの前後にリリースされる予定です。

驚くばかり！

@ Felix-Devがwin32と言ったとき、私たちは今.netコアビルドについて話しているのですか？

@ Felix-Devがwin32と言ったとき、私たちは今.netコアビルドについて話しているのですか？

AFAIK WinUIデスクトップは、.netコアを備えたC ++およびC＃をサポートします

@ Pinox @ mdtaukが言ったように。 WinUI 3ロードマップからの抜粋：

.NETFrameworkをターゲットとする新しいWinUIデスクトップアプリを作成するためのAFAIKサポートはWinUIデスクトップに追加されません。

ここでは、最近のコミュニティの呼び出しで与えられたWinUI .NETストーリーについて@ryandemopoulosのコメントもあります。