おそらく遠いことですが、Blendはオーバーホールする必要があり、デザインに焦点を合わせたワークフローが必要です。

XAMLデザイナーは、堅牢で強力である必要があります。

ページ/ウィンドウの階層構造を視覚化する何らかの方法。特に高架コントロールで重要です。

個々のコントロール/テンプレートなど、ページ外のUI要素を視覚化する方法。

CoreOS、「Surface Phone」、Surface Hub、Xbox、HoloLens用に作成されたディスプレイコントロールのカスタマイズは、すべてデザイナー内で行われます。

WinForms、WPF、MFC、およびWinUIデスクトップが動作する他のすべてのフレームワークと混合されたXAMLの複合デザイナー。

XAMLをインポートおよびエクスポートするための優れた方法。これにより、設計者はメインアプリから分離されたBlendで作業し、開発チームに渡してアプリに取り込むことができます。

システムリソースの視覚化と一覧表示が改善され、デフォルトを上書きするためにライトスタイルを設定できるグローバルリソースを引き出すための優れた方法があり、デザインサーフェスはそれらの変更をリアルタイムで反映します。

WinForms、MFCなどを含むアプリでさまざまなDPIスケーリングをテストするためのより良い方法。

新しいコントロールのテンプレート、カスタマイズされたテーマリソース辞書、Fluentテーマエディターの統合、サポートされているアプリの組み合わせのテンプレート（Win32MFCとXamlUIなど）。

ファイルピッカー、タスクトレイフライアウトなどのシェル統合ポイントのテンプレート。

それらはほんの少しの考えです...

私の考えは次のとおりです。

1. MSIXはすべて問題なく動作しますが、MSIXがサポートしていない機能を必要とする、より複雑なアプリケーションをインストールするために、古き良きMSIを使用しています。 また、必要なAuthenticode証明書が非常に高価であるため、MSIXを使用するのは気が進まない。 （自己署名証明書を使用してコードに簡単に署名できます。これは、会社から購入したものと同じくらい安全だと思いますが、Windowsはそれをロードしません。ただし、Windowsは自己署名MSIファイルを受け入れます。 。）MSIベースのアプリケーションからWinUI 3を使用できる限り、私は満足しています。
2. より優れたXAMLデザイナをいただければ幸いですが、WinUIXAMLデザイナとWinForms / WPFデザイナを1つに統合するという複雑さを追加する必要はありません。 VSの異なるタブ間でフリップフロップしてもまったく問題ありません。
3. 以前にコメントしたように、XBFコンパイラをC＃およびVisualBasicプロジェクトシステムから分離すると非常に便利です。 （XBFコンパイラソース、またはそれを再作成するのに十分なドキュメントがリリースされた方がよいでしょうが、それがどの程度発生する可能性があるかはわかりません。）
4. C ++プロジェクトシステムでのC ++ / WinRTおよびMIDL3のサポートの向上。 現在、C ++ / WinRTを使用するためのプロジェクトサポートは脆弱で扱いにくいです。 （たとえば、IDLファイルの名前空間を変更した場合（名前空間で使用するプロジェクト名にドットがある場合、テンプレートがそれらを自動的に下線に変換するために必要になることがよくあります）、プロジェクトはコンパイルに失敗します。 、私の経験で問題を修正するには、 *.h *.cppファイルと

他に何かあったら、必ずここに投稿します。 ありがとう！

1. ここで疑問に思っているのは...まあ、< winui：Listviewや< controls： listviewなどの名前空間プレフィックスを使用する必要がありますか？ 可能であれば、今と同じ経験を持って使用する方がはるかに良いと思います。 プレフィックスは、いくつかのコントロールで問題なく、すばらしいものです。 しかし、あちこちで使い始めると、XAMLは悪夢を読むことになります。
   Windows.UI.Xaml.Controlsを使用することはできず、WinUIがデフォルトの選択になるため、名前空間プレフィックスを使用することは意味がありません。

2. 現在、XAMLデザイナーも使用していません。 私は文字通り設定を無効にします。 XAML Designerは動作が遅く、より良いサポートが必要です。 レスポンシブデザイン、ページの処理、データの表示などを行う場合は特に、WPFには適していましたが、UWPには適していませんでした。
   これはおそらく遠い将来へのフィードバックですが、見るのに良いフィードバックだと思います。 WPFデザイナーははるかに高速です。
   これはサンドボックスのせいですか？

3. 移行を行うためのツールは興味深いでしょう。 特に、ScrollViewerなどの更新されたWinUI3.0コントロールとの互換性の問題がいくつかある可能性があるためです。 したがって、ツールがある場合は、少なくともこれらの更新/書き換えられたコントロールで発生する可能性のある警告を表示する必要があります。

1. IntelliSenseをデザイナーから分離した堅牢なxamlコードエディターが必要です。
   ほとんどの場合、私はC＃のようなxamlコードを書いています。 現在、コードエディタは遅くて壊れやすいです、私の以前のコメントで説明しました。 IntelliSenseエクスペリエンスも非常にシンプルです。 簡単なドキュメント情報やメンバーの名前変更はありません。
2. x:Bind設計データのサポートは、関数バインディングで複雑なヘルパーを書いているため、かなり難しいかもしれません。 しかし、xamlの組み込み関数が一部のヘルパーを置き換えることができれば、状況はさらに良くなる可能性があります。
3. 私のアプリケーションでは、パッケージングモデルのより多くの無料の組み合わせが必要です。 トピックから外れているかもしれませんが、アプリモデルチームにフィードバックする場所が見つかりません。

TL; DR任意のインスタンスの共存をサポートするアプリモデルが必要です。 Visual Studioハイブのように、同じバージョンでも異なるデータ/オプションセットで実行できます。 現在、唯一の解決策はxcopyのようです。

誰かがこれを折りたたむ方法を教えてもらえますか？

まず、私は毎日開発しているアプリも使用しています（そしてほとんどの日は>>デバッグを使用しています）。 したがって、devビルドをstableビルドと共存させることは私に大いに役立ちます。 現在、バージョン番号を増やし、デバッグmsixをパッケージ化し、インストールされているパッケージバージョンをデバッグ用に更新する必要があります。
さまざまなデバッグフェーズで、さまざまな機能が必要になります。 複雑な実世界のデータの場合、デバッグインスタンスが安定したインスタンスとデータを共有する必要があります。 ただし、任意の偽のデータについては、分離する必要があります。 これは理論的にはフォルダピッカーを使用してデータにアクセスすることで解決されますが、UWPのSQLiteがそれをサポートしておらず、私が知っている他の組み込みACIDエンジンがないことを残念に思います。

ああ、そして別のこと。 vcxprojでNuGetパッケージ参照にpackages.configを使用する方法について何かできることがあれば、本当に感謝します。 WinUIは、C ++ / WinRTおよびその他の主要コンポーネントと同様に、NuGetパッケージとして配布されます。 私はpackages.configを使うのが本当に好きではありません。 PackageReferenceの方がはるかに効率的です（vcxprojを別のディレクトリに移動しても、ビルドが壊れることはありません）。 復元ターゲットが適切なタイミングで実行されている限り、vcxprojから使用すると実際に機能します。 （これは、vcxprojターゲットが非SDK C＃プロジェクトのPackageReference復元機構を間接的にインポートするためです。）VSはこれを行わないため、PackageReferenceアイテムのセットが変更されたときに復元ターゲットを自動的に実行するターゲットのセットを作成しました。それ自体（まだ）。 残念ながら、NuGetシステムはこれについて何も認識していないため、C ++ / WinRTファイルテンプレートを追加すると、packages.configファイルを追加しようとします。 これにより、あらゆる種類の大混乱が発生し、例外がスローされ、プロジェクトファイルが破損します。 これを解決する最善の方法はわかりませんが、少なくともWinUI3がリリースされる前に確認できれば幸いです。 ありがとう！

WinUIが新しいプロジェクトSDK（ Microsoft.NET.SdkまたはMSBuild.Sdk.Extras）をサポートしていると便利です。
古いスタイルのcsprojファイルは保守が困難です。 また、複数のTargetFrameworksを使用することはできません。これは、WinUIへの移行に役立つ可能性があります。

F＃がサポートされていないのはなぜですか？

AzureDevOpsとVisualStudio App Centerの機能についてここで説明する必要がありますか？

@vitorgrsのように、私は名前空間プレフィックスのないネイティブコントロールを好みます。それは、コードに「ノイズ」を追加します。 また、どちらがネイティブコントロールで、どれがサードパーティであるかを確認するのに役立ちます。

もちろん、移行ツールがあれば便利です。 それが大きなサードパーティプロバイダー（Telerik、DevExpressなど）と連携する場合、それはすでに大きなことです。

テンプレート

以前のバージョンのUWPXAMLテンプレートをVSの新しいプロジェクトフローに残すことに関心/必要性はありますか？

私の側からは、テンプレートを保持する必要はありません。 しかし、UWPにWinUIにないコントロールがある可能性はありますか？ それが発生する可能性がある場合、これは、従来のUWPアプリを構築し、必要なコントロールが存在するときにそれをWinUIに移行する正当な理由である可能性があります。 次に、テンプレートが必要になる場合があります。

アプリを作成していて、最新のVisual Studioバージョンでアプリを作成できなくなった場合も、開発者にとって混乱を招く可能性があります。

しかし、個人的には、テンプレートを保持することに興味はありません

Visual Studioのテンプレートとコンポーネントに関して、どのように効率的または成功するのを支援できますか？

私には、これはUWPに最適です。 今、私はWin32についても同じことを見たいと思っています。 :)

このウォークスルーは役に立ちますか？シナリオが具体化するにつれて、これをもっと見たいですか？

はい、間違いなく。 このウォークスルーは、将来がどのようになる可能性があり、どのように見えるべきかを理解するのに非常に役立ちます。 これをもっと見たいです。

移行

手順1〜3を自動化する移行ツールを提供した場合、それは有益でしょうか？

間違いなく。 たぶん、少しのVisual Studio Extensionが、この移行に最適なオプションになるでしょう。 移行できるものとできないものを出力する「WinUI互換性アナライザー」のようなものも考えられます。 .NET移植性アナライザーに似たもの。

ネイティブWindows10コントロールセットの外部からどのライブラリを使用していますか？

通常、TelerikDataGridとCommunityToolkit

現在考えていない移行をどのように支援できますか？

インストールしたWinSDKよりも古いバージョンのUWPアプリをVisualStudioで開くと、VisualStudioによって移行されます。 WinUIの移行についても、そのようなことを考える必要があるかもしれません。 よくわかりませんが、覚えておくべきことがあります。 特に、Visual Studioに通常のUWPテンプレートがない場合、テンプレートを使用して作成できないアプリケーションを開発者が持つことは混乱を招く可能性があります。

その他

他のコメントですでに述べたように、SDKスタイルの.csprojファイルに切り替える時が来たと思います。

winui3.0テンプレートをWindowsテンプレートスタジオに追加します。

デスクトップアプリのWinUI

デスクトップのWinUIを使用すると、開発者はデスクトップアプリケーションモデルでWindowsUIライブラリを使用できます。 @ marb2000は、今後数週間でより詳細なディスカッション投稿に取り組んでいます。 それまでは、このスレッドを自由に使用して提案してください。

.net開発者として、これは私が最も興味を持っている部分です。

テンプレート

• 以前のバージョンのUWPXAMLテンプレートをVSの新しいプロジェクトフローに残すことに関心/必要性はありますか？

テンプレートの数によって異なります。 数が少ない場合（たとえば、言語ごとに「空白のアプリ（ユニバーサルウィンドウ）」のみ、c＃の場合は1）、ノイズは低く、サポートできます。 ただし、テンプレートが複数含まれている場合は、デフォルトでそれらを含めず、オプションのVSインストールコンポーネントを追加して追加します。

• Visual Studioのテンプレートとコンポーネントに関して、どのように効率的または成功するのを支援できますか？

足場のない実際の空白のテンプレートを保持します（チュートリアルに適しています）。 asp.netコアが何をしているのかを覗いてみてください。彼らが新しいプロジェクトの経験で行った多くの変更があります。 基本的に、汎用テンプレート「アプリ（UWP WinUI）」を選択してから、アプリモデルに固有の2番目の画面で、さまざまなテンプレートから選択できます。 この手順を使用して、最小およびターゲットプラットフォームバージョンも選択します（したがって、追加の手順はありません）。 たとえば、アプリパッケージプロジェクトを直接作成するオプションを追加できます。

また、プロジェクト間でツールボックス内のコンポーネントを適切にサポートします。 新しいコントロールは、プロジェクトごとにグループ化されて、ツールボックスにすぐに表示されます。 おそらく、それらを区別するのに役立つデザイナーアイコンのサポート。

• このウォークスルーは役に立ちますか？シナリオが具体化するにつれて、これをもっと見たいですか？

はい

言語サポート

• 手順1〜3を自動化する移行ツールを提供した場合、それは有益でしょうか？

優れたドキュメント（明確な手順が記載された1ページ）で十分です。 csprojを手動で編集せずに、VS内からすべてを実行できる場合は、手順を説明するドキュメントページのみを追加することをお勧めします。

新しいcsproj形式に切り替えることにした場合（そしてそうすることを願っています）、移行にはcsprojファイルの編集が必要になるため、移行ツールが必ず必要になります。

包装

MSIXは、すべてのアプリの最新のパッケージ化方法です。 Win32のWinUIの場合、ClickOnceをサポートする必要がありますか？ 他にどのようなパッケージ方法のサポートを含める必要がありますか？ 特にWin32のWinUIの場合

clickonceとmsixの展開の違いを比較します。

1. アプリインストーラー機能は、古いWindowsバージョンでは同じエクスペリエンスを提供しません
2. MSIXには、有効な署名付きパッケージ（内部またはパブリック）が必要です。 Clickonceは、自己署名パッケージをサポートしています。
3. パッケージモデルにはいくつかの制限があり

私にとって最も厄介な問題は2です。通常、ドメインに登録されていないコンピューターで内部的に展開されるClickonceアプリがあります。 したがって、これらの種類のアプリの場合、有効な公開署名証明書を使用してパッケージに署名する必要があります。

Appxパッケージ形式は、ストアを対象とするアプリに対してのみアドバタイズされることが多く、制限がある場合、それらがWeb配布形式にも適用されるかどうかが常にわからないため、これら2つのフレームワークのすべての違いを予測することは困難です。

• デザイナーの経験

パフォーマンス、パフォーマンス、パフォーマンス、および多くのプロジェクトを伴う大規模ソリューションのサポート。

Windows 10SDKのWinUIバージョンとWinUIXamlデザイナーはオープンソースになりますか？

デザインタイムのワークフローと経験のリクエストを投稿することはできますか？

SDKは、WinUIのnugetリリースと同様のリリースリズムに従いますか？

いくつかの追加の痛み：
マネージド-アンマネージドミキシングデバッグエクスペリエンスを向上させます。
現在、アンマネージコードで例外が発生すると、マネージデバッグサイトにCOMExceptionが表示されます。 コールスタックがマネージド/アンマネージド境界を2回以上超えると、状況が悪化する可能性があります。
WPFと比較すると、マネージドコールスタックは常に使用可能であり、スローされた例外にはデバッグに役立つ文字列が含まれています。
管理されていない世界とCOMモデルは管理されているほど便利ではないことを私は知っています。 しかし、少なくとも、フレームワークによって例外（誤ったHResult）がスローされた場合、オープンソースのリポジトリから

ClickOnceに大きく依存しているため、短期的にサポートしておくとよいでしょう。 MSIXに移行することもできますが、同様の機能が提供された後です。

テンプレートに関しては、NavigationViewとナビゲーションの定型的なUIとコードを提供するテンプレートがあると便利です。

THX

ClickOnceに大きく依存しているため、短期的にサポートしておくとよいでしょう。 MSIXに移行することもできますが、同様の機能が提供された後です。

テンプレートに関しては、NavigationViewとナビゲーションの定型的なUIとコードを提供するテンプレートがあると便利です。

THX

最も一般的なアプリの「シェル」構造とパターンは、開発者がすぐに立ち上げて実行できるように、テンプレートとして利用できる必要があります。 Microsoftのファーストパーティアプリは、これらのレイアウトの模範であり、動作、一貫性、およびFluentDesignとWinUIのUIデザイン基準の遵守に関するベストプラクティスとして機能する必要があります。

@shaggygi @mdtauk
「最も一般的なアプリの「シェル」構造とパターン」および「テンプレートに関しては、NavigationViewとナビゲーションの定型的なUIとコードを提供するものがあれば便利です。」 Microsoftとコミュニティの両方によって維持および開発されているWindowsテンプレートスタジオがあります。 その紹介を引用するには：

Windows Template Studio（WTS）は、ウィザードベースのエクスペリエンスを使用して新しいユニバーサルWindowsプラットフォーム（UWP）アプリの作成を高速化するVisual Studio2017および2019拡張機能です。 結果として得られるUWPプロジェクトは、実績のあるパターンとベストプラクティスを実装しながら、最新のWindows10機能を組み込んだ整形式で読みやすいコードです。

@ Felix-Devは、最終的にUWPに加えてWPFテンプレートがありますか？

@shaggygiあなたにとって良いニュースがあるかもしれません！ このスレッドを参照してください：現時点では何も保証されていないようですが、WPFプロジェクト専用のテンプレートを提供するというアイデアが検討されているようです。 リンクされたスレッドに記載されているように、Build2019でホストされている「WindowsTemplateStudio-WPFEdition」と呼ばれる非公開のスニークピークセッションがありました。

C ++ / WinRTを使用しています。 現在、xamlデザイナーやバインディングは使用していません。 ただし、実行時にコントロールを作成し、おそらくUWPxamlを介してそれらのスタイルを設定します。 また、ドッキング/フローティングウィンドウなどを含むxamlアイランドを備えたダイアログとモードレスの子ウィンドウも必要になります。

私は自分のC ++アプリ用にXAMLを書いてみましたが、その経験は苦痛でした。

すべてを正しく生成して正しくパッケージ化するには、文書化されていない多くのプロジェクトプロパティやその他のハックを追加する必要がありました。

例えば：

• XAMLページを格納するプロジェクトを作成するときに、 <_NoWinAPIFamilyApp>true</_NoWinAPIFamilyApp>と<_VC_Target_Library_Platform>Desktop</_VC_Target_Library_Platform>を追加する必要がありました。これらは完全に文書化されておらず、新しいターミナルのソースコードを調べることによってのみ理解できる2つのプロジェクトプロパティです。
• Appクラスを作成して使用するまで、「メインウィンドウがまだ作成されていないため、新しいビューを作成できませんでした」という不可解な問題がありました。これは、通常のページを作成してプロパティに移動する以外にVSでは実行できません。 VSのXAMLファイルをアプリケーション定義に変更してから、MIDL、ソースコード、およびXAMLファイルを調整します。
• Microsoft.Toolkit.Win32.UI.XamlApplication NuGetパッケージを追加してアプリケーションクラスを作成しましたが、 Microsoft.VCRTForwardersも追加するまでロードできませんでした。これも、ターミナルのソースを調べたときに見つかりました。どちらのパッケージについても何も示されていません。
• .wapprojファイルに何かを追加するまで、PRIは1つにマージされなかったため、XAMLリソースが見つかりませんでした。
• XBFは、 <DisableEmbeddedXbf>false</DisableEmbeddedXbf>を追加するまで機能しません
• アプリマニフェストのmaxVersionTestedは、キャメルケースバージョンを使用するように指示されていても、すべて小文字に変更するまで完全に無視されました： https ：

さらに、C ++ / WinRTもお尻の痛みでした：

• インクリメンタルビルドを実行するたびに、カスタムクラス用に[msg]redefinition [context]: MyClassがあり、ビルドできず、C ++ / WinRTヘッダーが原因で時間がかかるクリーンビルドを実行するまで消えませんでした。 その問題はどういうわけか途中で魔法のように消えました。
• クリーンビルドを実行すると、ヘッダーが見つからないというエラーが発生します。 ビルドボタンをもう一度押すと、再び機能します。
• C ++ / WinRTからの悪いcodegenのために、私は自分のAppT<>クラスを書かなければなりませんでした。 ターミナルアプリとXAMLアイランドのサンプルは同じことを行います。これは、根本的な問題が修正される代わりに、ユーザーが行う必要があるものであるかのようです。
• MIDLファイルの内容を変更すると、クリーンビルドを実行するまでビルドエラーが発生します。

それでも、アプリマニフェストにactivatableClassものを追加しても（PRIをマージしなかった場合のように、XAMLリソースが見つからないことに関する何か）、パッケージ化されていない状態では機能しません。これは重要です。私のアプリがサポートするために。

移行

ステップ1〜3の自動化は、特に何百ものファイルの名前空間の名前変更に非常に時間がかかり、エラーが発生しやすいため、非常に役立ちます。 その上、互換性のあるアナライザーは、現在のコードベースの互換性に関するレポートを作成し、必要なすべての可能な変更を記録する.netフレームワーク> .netコアのアナライザーと同じように便利です。

ツーリング

他の人がすでに言っているように、より機能豊富なエディターがいいでしょう。 ここでのほとんどの場合、XAMLは手作業で行われ、アプリがどのように見えるかについての大まかなスケルトンのガイドとしてデザイナーを使用します。 Intellisenseとスマートリファクタリングは非常に役立ちます。たとえば、カスタムUserControlsたくさんある傾向がある場合など、名前を変更するためのCTRL + R + RなどのQoLのようなもの（依存関係プロパティやタグなど）。 GoToの実装と参照。 Roslynアナライザーのサポートも本当に良いでしょう。

名前空間の改善を拡張します。 どういうわけか、デフォルトの名前空間に新しいXmlnsDefinitionを追加せずに、プレフィックス以外のカスタムコントロールを簡単に実行できると便利です。これにより、マークアップimoが整理され、次のようなあいまいなコントロールが見つかった場合にのみプレフィックスが必要になります。クラスがどのように機能するかは、GoToの実装ともうまく結びついています。 通常、コントロールの名前と、完全な名前空間を表示するためにそのコントロールにカーソルを合わせると、それがどこから来たのかを知るのに十分です。通常、必要でない限り、C＃コードでも名前空間エイリアスを使用しません。

ほとんどの場合、ツールでは、C＃エディターのように動作して、リファクタリングの脆弱性や煩わしさを軽減し、マークアップを簡単にナビゲートできると便利です。 それとは別に、XAML言語自体に関しては、冗長性を減らすことは、＃62および＃279で説明したスタイリングの良い例でもあります。

名前空間の改善を拡張します。 何とかそれは新しい付加することなく行うことが容易に非プレフィックスカスタムコントロールを持つことが可能だ場合、それはいいだろうXmlnsDefinitionデフォルトの名前空間にSを、それがあいまいなコントロールが同じようにそこに見つかったときのプレフィックスが必要になる芋だけのマークアップをdecluttersクラスがどのように機能するかは、GoToの実装ともうまく結びついています。 通常、コントロールの名前と、完全な名前空間を表示するためにそのコントロールにカーソルを合わせると、それがどこから来たのかを知るのに十分です。通常、必要でない限り、C＃コードでも名前空間エイリアスを使用しません。

WinUI 3.0バージョンのPageコントロールでは、これらのコントロールにプレフィックスを使用する必要がなくなると思います。 これはSDKレベルのものだと思います。

WinUIを使用するときに名前空間を変更しないことは可能ですか？

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に似ており、変更がより速いペースで行われ、両方の利点がすべてあり、問題はありません。

移植ツールを提供する必要はないと思います。 これは1回限りの変更であり、Find＆Replaceを使用するとかなり簡単であり、インスタンスの数はかなり少なくなります。

また、より多くの問題が発生しました：

• Appクラスにリソースを追加した後、これを追加するまでXAMLはそれを見つけることができませんでした。これもターミナルアプリから見つかり、実際に何をするのかよくわかりません。
  xml <Target Name="PlaceAppXbfAtRootOfResourceTree" DependsOnTargets="GetPackagingOutputs"> <ItemGroup> <_RelocatedAppXamlData Include="@(PackagingOutputs)" Condition="'%(Filename)' == 'App' and ('%(Extension)' == '.xaml' or '%(Extension)' == '.xbf')" /> <PackagingOutputs Remove="@(_RelocatedAppXamlData)" /> <PackagingOutputs Include="@(_RelocatedAppXamlData)"> <TargetPath>%(Filename)%(Extension)</TargetPath> </PackagingOutputs> </ItemGroup> </Target>
• ビルドはcannot find type Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplicationと同様のエラーで完全にランダムに中断し、プロジェクトビルドを再度取得する唯一の方法は、クリーンビルドを実行することです。
• メインexeのvcxprojをスタートアッププロジェクトとして直接設定してアプリを実行することはできません。パッケージ化されていないappx出力をbin\x64\Debug\AppXで手動で開始してから、VS内からデバッガーを挿入するか、アプリパッケージを設定する必要があります。起動プロセスとして。

Windowsデスクトップの関連2019年7月25日。

長年のWinForms、UWPの経験を持つWPF開発者。 これが私の2セントです：

移行

• 既存のUWPアプリをWinUIに移行するためのツールは必須です。
• 既存のアプリでWinFormsまたはWPFコントロールをWinUIコントロールに変換するツールは素晴らしいものではありません。 コントロールを変換するということは、コンテナー内の参照を個々のコントロールに変更することを意味します。
• Xamarin FormsをWinUIに移行して、モバイルアプリをWindowsにバックポートできるようにするツール。

ツーリング

• 現在のXAMLエディターはひどいです！ 通常のテキストエディターキャンバスを使用し、XAMLオブジェクトモデルに適用されるRoslyn機能を提供して、より優れたインテリセンスとリファクタリングを実現する必要があります。
• Visual Studioが64ビットになるまで、XAMLエディターはバックグラウンドでスタンドアロンの64ビットアプリである必要があります。 多くのXAMLを使用しているときにメモリ不足エラーを停止するには、VS2017とVS2019を常に再起動する必要があります。

テンプレート

• これらのプロジェクトテンプレートが必要です

  • NavigationView WinUI
  • NavigationView WPF
  • リボンWinUI
  • リボンWPF
  • リボンWinForms

• これらのページ/ウィンドウテンプレートが必要です

  • メディアコントローラーページ
  • ブラウザページ
  • ダイアログウィンドウ
  • ボーダレスウィンドウ
  • フローティングウィンドウ

• コントロールテンプレートが必要です

  • カプセル化されたデータグリッドビュー
  • カプセル化された子データビュー

これらの最後の2つは連携して、簡単なマスター/詳細ウィンドウを作成します。

これらのテンプレートやページなどはすべて、Windows Template Studioプロジェクトで既に実行されています。すべてを再作成するのではなく、同じルートをたどってみませんか？

SDKスタイルのプロジェクトファイル
他の多くの人も言及しているように、私が見たい最も重要なビットの1つは、UWPアプリと「デスクトップXAML」アプリの両方での新しいSDKスタイルプロジェクトファイル形式のサポートです。

UWPとデスクトップXAMLアプリモデル間の移行
「デスクトップXAML」アプリの構築を開始した場合、UWPアプリからどのくらい離れていますか？ UWPサンドボックスの制約内にとどまっていることに気付いた場合、後でUWPアプリに変換するのは簡単ですか？ または、UWPアプリの構築を開始し、さらに必要であることに気付いた場合、それを「デスクトップXAML」アプリに簡単に変換できるでしょうか。

TemplateStudioをサポートしています。

TemplateStudioをサポートしています。

TemplateStudioはXAMLC ++プロジェクトをサポートしていますか？

Template Studioが行っていることは、WinUI SDKIMOの一部である必要があります

Template Studioが行っていることは、WinUI SDKIMOの一部である必要があります

Visual Studio IDE IMOの一部である必要があります！ 😎

重要なのは、WindowsテンプレートスタジオがUWPプロジェクトの作成のためにオールインワンの作業を行っているため、xaml c ++サポートなどが不足している場合は、Windowsテンプレートスタジオに追加することを検討する必要があることを念頭に置いてください。 uwpプロジェクトのすべての新しいイノベーションが1つのプロジェクトに残っている場合、効率的です。

XAMLやMVVMを使用せずに、WinUI3のスタックの下位層を直接使用する方法があるとします。 これは、コードベースに何らかのMVアーキテクチャがすでに含まれている既存のビッグアイアンC ++ソフトウェアに特に役立ちます。 彼らはHWND + GDIよりも優れたものを求めているだけです。

そして、 WinUI 3はおもちゃではなく、本格的なソフトウェアを本当にサポートできると人々に思わせてください。

@ be5invis私は完全に同意します。 現在のところ唯一の解決策はXamlDirectですが、これはミドルウェア開発者を対象としています。

すでにXamlIslandsを使用して手動でコンテンツを作成できます。 DesktopWindowXamlSourceを機能させてウィンドウにアタッチし、コードでコントロールを作成して配置/レイアウトするだけです。

https://gist.github.com/sylveon/5bc68b2801333b24f7b3165c3f098cc9#file -picker-cpp-L46

@MarkIngramUK CreateWindowをWinUI関数に置き換えるなど、より「完全な」ものが必要になる場合があります。

設計上、将来のWinUI WPFテンプレートで、現在のUWPアプリのようにページのコンテンツをタイトルバーに展開できるようにしたいと考えています。 現在、既存のXAMLアイランドソリューションでは、最新のビューではなく、WPF / WinFormsウィンドウ内でコントロールをホストしているだけです。

@LucasHaines WinUI 3.0でサポートする予定の言語のリスト：C＃、C ++ / WinRT、VisualBasic。 F＃のサポートを検討しています。

これは、F＃だけでなく、すべての.Net言語で間違っていることを示しています。 まず、テンプレートと.xamlファイルについて考えます。これは、家を建てて、構造を完成させずにカーペットやカーテンを配置するようなものです。

WinUIは、Nugetパッケージとして任意の.Net Standard 2.0 / .Net Core 3.0 / .Net5プロジェクトにインストールできるはずです。 次に、内部で定義されているすべてのクラスにアクセスできます。 次に、WinUIプロジェクト（C＃のみの場合もあります）からそのようなプロジェクトを参照できます。 これにより、WinUIビューを任意の.Net言語で作成できます。 Xamarin.Formsがどのように機能するかをご覧ください。

クラスはすでにF＃で使用できます（すべての.NET言語で使用できるWindowsランタイムコンポーネントであるため）

手動でレイアウトを作成できるようになります。 すべてのWinUIケアにPy / WinRTを使用してPython経由でそれを行うこともできます。

@sylveon具体的にどのクラスですか？ 興味があります...

それらのすべて。 WinUIのパブリックAPIは、Windowsランタイムコンポーネントのみです。

@LucasHaines WinUI 3.0でサポートする予定の言語のリスト：C＃、C ++ / WinRT、VisualBasic。 F＃のサポートを検討しています。

これは、F＃だけでなく、すべての.Net言語で間違っていることを示しています。 まず、テンプレートと.xamlファイルについて考えます。これは、家を建てて、構造を完成させずにカーペットやカーテンを配置するようなものです。

WinUIは、Nugetパッケージとして任意の.Net Standard 2.0 / .Net Core 3.0 / .Net5プロジェクトにインストールできるはずです。 次に、内部で定義されているすべてのクラスにアクセスできます。 次に、WinUIプロジェクト（C＃のみの場合もあります）からそのようなプロジェクトを参照できます。 これにより、WinUIビューを任意の.Net言語で作成できます。 Xamarin.Formsがどのように機能するかをご覧ください。

このトピック/質問はツーリングに関するものです。 はい、ライブラリは、それらを使用できる任意の言語から直接参照できますが、ツールと言語サポートの間の定義があいまいです。
Xamarin.Formsを例として取り上げます。 これは、C＃および程度は少ないがF＃のツールのみを提供します。 VB.NetとXamarin.Formsを使用してアプリを構築することは可能ですが、ツールがなく、そのためのドキュメントが限られているため、_公式にはサポートされていません_。

また、WinUIはWindows固有であるため、 .Net Standard 2.0 / .Net Core 3.0 / .Net5プロジェクトだけで参照することはできません。
一部のシナリオでは、プロジェクト/コンパイラ/パッケージングレベルのサポートも必要です。

v2.2リリースの素晴らしい作業チーム。 v3.0のステータスに関する簡単な更新を入手できる可能性はありますか？

私はこれが何度か言及されているのを見ますが、いずれにせよ明確な方向性はありません。 WinUI 3.0にはすべてのコントロールがあるため、WinUIライブラリコントロールを参照するための名前空間要件を削除する必要があります。 これにより、XAMLが大幅に混乱し、移行が大幅に妨げられ、UNOプラットフォームやAvaloniaなどとの単純な互換性が失われます。

XAMLからxmlns:mux="using:Microsoft.UI.Xaml.Controls"の必要性を削除してください。 コードビハインドはまだ変更する必要があることを理解しています。 プロジェクトのどこかに、このための構成が存在する可能性もあります。

XAMLからxmlns:mux="using:Microsoft.UI.Xaml.Controls"の必要性を削除してください。

XAML _markup_では必要ありませんが、コードビハインドで名前空間を変更する必要があります。

Windowsコントロールを使用する場合（OSから削除されていない場合）-XAMLで名前空間を宣言する必要があります

Windowsコントロールを使用する場合（OSから削除されていない場合）-XAMLで名前空間を宣言する必要があります

シナリオではないWinUI3.0では、OSコントロールとWinUI3.0コントロールを組み合わせて使用​​することはできません。 これらのコントロールはOSのアドオンであるため、現時点ではWinUI 2.xでのみ機能します（NavigationViewやTreeViewなどの両方の場所でタイプを出荷したためにあいまいさが生じるという厄介なケースがたくさんあります）。

Windowsコントロールを使用する場合（OSから削除されていない場合）-XAMLで名前空間を宣言する必要があります

シナリオではないWinUI3.0では、OSコントロールとWinUI3.0コントロールを組み合わせて使用​​することはできません。 これらのコントロールはOSのアドオンであるため、現時点ではWinUI 2.xでのみ機能します（NavigationViewやTreeViewなどの両方の場所でタイプを出荷したためにあいまいさが生じるという厄介なケースがたくさんあります）。

聞いてよかった。 OSからそれを非推奨にするのが簡単になります。 設定アプリ、シェル、その他のOSの部分もWinUI3.0に移行することを願っています。

また、管理者ツールやワードパッドなどをXAMLに移植して、同じコードを可能な限り再利用することを期待しましょう。

@jevansaksわかりました、理解しました。フィードバックに感謝します。

@mdtaukXAMLでは「OS」レガシーコントロールと新しい「WinUI3.0」プラットフォームコントロールを区別する必要はありません。 すべてがWinUI3.0に移行しており、ご存知のようにOSコントロールは機能の更新を取得していません。 WinUI 3.0以降、開発者が引き続きレガシーコントロールをターゲットにする場合は、古いSDKおよびVisualStudioバージョンで開発する必要があります。 XAMLから2つのMicrosoft / Windows UIコントロールライブラリを参照する機能を維持することは、前述の理由から、障害になります。 その上、WinUI開発の分離により、最終的にこのような変更を「許可」する持続可能なパスに切り替えることができます。これは中断すらありません。

編集：返信する前に更新するのを忘れました。これのほとんどは現在冗長です。

@roblooこれにより、以前のバージョンのUWPXamlが本当に置き換えられることをうれしく思います。 また、OSが受信トレイアプリとシェルのためにそれに移行できることを願っています。

また、WinUI 3.0に移行するプロセス、およびWin32アプリと同じライフサイクルでWinUI3.0を操作する方法を詳しく説明した開発者向けビデオがたくさんあることを願っています。 これ以上の水分補給、ページの状態やナビゲーションなどを保存するためのより良い方法はありません。

ワードパッドを使用してコードをWinUIに組み込まれた新しいUIに移動する例や、Groove Musicなどの受信トレイアプリを使用して移動する例を示すと（WinUI 3.0への移行を計画しているアプリによって異なります）役立つ場合があります。 WinUI3.0へ

WinUI 3の場合、デザイン言語でのアプリ関数の配置に関してある程度の一貫性が必要です。

この点で、アプリの設定。

アプリの設定はどこにありますか？ 右上の歯車をクリックしますか？ 左下隅？ 右上のプロフィールアバターをクリックして設定を押しますか？ 左上をクリックしますか？ 左下の？ [編集]> [設定]に移動しますか？

あなたがNavigationViewを使用するかどうかに本当に依存します...

投稿者：shaheedmalik [email protected]
送信日：2019年9月12日木曜日15:48:12
宛先：microsoft / microsoft-ui-xaml [email protected]
Cc：シャープ忍者[email protected] ; コメント[email protected]
件名：Re：[microsoft / microsoft-ui-xaml] WinUI 3.0開発者の経験とツール-必要な入力（＃1045）

WinUI 3の場合、デザイン言語でのアプリ関数の配置に関してある程度の一貫性が必要です。

この点で、アプリの設定。

アプリの設定はどこにありますか？ 右上の歯車をクリックしますか？ 左下隅？ 右上のプロフィールアバターをクリックして設定を押しますか？ 左上をクリックしますか？ 左下の？ [編集]> [設定]に移動しますか？

—
あなたがコメントしたのであなたはこれを受け取っています。
、直接このメールに返信することはGitHubの上で閲覧https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLB5VXXUOYIA2NIEZATQJKTIZA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TGV4I#issuecomment-531000049 、またはスレッドミュートます。https：// githubのを。 com / notifys / unsubscribe-auth / AD3GCLCQQ6L7H3LEJAHUDMLQJKTIZANCNFSM4ICOLUJQ 。

Visual Studioのテンプレートとコンポーネントに関して、どのように効率的または成功するのを支援できますか？

WinUI / XAMLアイランドをVisualStudioのC ++ / WinRTで機能させるために、多大な労力と文書化されていないプロジェクト構成属性を必要としないでください。

これを十分に強調することはできませんが、私にとって最も重要なことは、WinUIがWindows以外にもレンダリングすることです。

Surface Duoを見るとすぐに、MicrosoftがAndroid搭載デバイスをリリースするようになった今、クロスプラットフォームの開発ストーリーはどうなるのだろうと思いました。 Xamarin.Formsは、いくつかの明らかな理由でそれをカットしません。 マイクロソフトがクロスプラットフォームツールキット（UNOプラットフォームのようですが、完成していて安定している）を完全に採用する時が来ました。これは、何年にもわたってさまざまな形で要求されてきました。 マイクロソフトがここで開発者のために言われていないいくつかの計画を持っていることを願っています。

Satya氏は、「エクスペリエンスと1つのデバイスだけを構築したくはありませんでしたが、それは私たちの生活のすべてのデバイスにまたがっています」と述べています。 Panosが望むように開発者にこの乗り物に参加してもらいたい場合は、これが最善の方法です。 それ以外の場合は、開発者に、SurfaceDuoと他のファミリの間の「エクスペリエンス」にまたがる2つの別々のUIを作成するように依頼しています。 これは、デバイスの1つの「ファミリ」内の開発者に対する公正な要求ではないと思います。

プラットフォームごとに異なるレンダリング、別名「ネイティブルックアンドフィール」。

わかりません。 フルーエント・デザインに最後にやってもらいたいのは、矛盾を少なくすることではなく、もっと多くの矛盾を引き起こすことです。

編集：元のコメントが削除されました

Satya氏は、「エクスペリエンスと1つのデバイスだけを構築したくはありませんでしたが、それは私たちの生活のすべてのデバイスにまたがっています」と述べています。 Panosが望むように開発者にこの乗り物に参加してもらいたい場合は、これが最善の方法です。 それ以外の場合は、SurfaceDuoと他のファミリの間の「エクスペリエンス」にまたがる2つの別々のUIを作成するように開発者に依頼しています。 これは、デバイスの1つの「ファミリ」内の開発者に対する公正な要求ではないと思います。

これがまさに、DuoがAndroidであることに私が落胆した理由です。

テンプレートで発生する問題領域を削除するには、テンプレートをオープンソースにする必要があります。

WPFでWinUIを使用する場合、および次のようなコードで新しいコントロールを作成する場合。
c# public class MyControl : UserControl { ... }
WinUI.UserControlまたはWPF.UserControlを使用しますか？
選択する必要があり、どのように対処する必要がありますか？

そして興味深いことに、XAMLツールが統合される場合、ある種の共有xamlファイルを作成する機能はありますか？
何かのようなもの：

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

それは特別なルート名前空間を持つある種の共有方言である必要がありますか？ （Visual Studioの共有プロジェクトなど）。 条件付きxamlのように見える可能性があります。

WinUI.UserControlまたはWPF.UserControlを使用しますか？
選択する必要があり、どのように対処する必要がありますか？

これは、定義したXAMLで自動的に発生するはずです。

<UserControl 
   x:Class="MyApp.MyControl" 
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

それはコンパイラにそれがUWPであることを伝えます。

public class MyControl : UserControl { ... }

これは実際には正しくありません。 あなたはこのように宣言する必要があります

public partial class MyControl { }

継承と使用されているフレームワークを指定する.g.csファイルによって処理されるため、継承は必要ありません。

テンプレートについては、HelloWorldテンプレート以上のものがあればもっと嬉しいです。 つまり、Microsoftは、クライアントアプリを操作するために必要な周辺機器で認識されているフレームワークをバックアップする必要があります。

@weitzhandlerこれも見たいです!!

C＃およびCpp / WinRTプロジェクト用のSDKスタイルのプロジェクトも必須です。

すべての一般的なWin32およびInboxアプリパターンのテンプレートが必要だと思います。 私の頭のてっぺんからの短いリスト：

• リボン
• メインメニュー
• タブ付きドキュメントインターフェイス
• ナビゲーションビュー
• コマンド/ツールバー
• トップナビゲーションビュー
• ハブ/ギャラリー（これは少し非推奨になっていることを知っています）
• Treeview / MasterDetails（ファイルエクスプローラー、RegEdit、管理アプリ）

ただし、一般的なダイアログ、ページ、設定ページなどのアイテムテンプレートも必要です。

Visual Studioのテンプレートとコンポーネントに関して、どのように効率的または成功するのを支援できますか？

VSCode / VisualStudioのC ++拡張機能を使用します。 VS Codeを、VisualStudioと同様のエクスペリエンスを提供するサポートされているエディターとしても見たいと思います。 WinUIはOSSであるはずであり、VS Codeもそうなので、これは実行可能だと思います。

Template10やWindowsTemplate Studioのようなツールは、基本的な機能が不足している兆候です。 WinUI3では、これらのツールの機能に対応できる機能が備わっている必要があります。 多くの開発者がこの基本的な足場を何度も繰り返しているに違いありません...それはフレームワークの一部であるはずです。 追加のツールは必要ありません。 たぶん、あなたがなしになりたいとき、あなたはそれらのまれなケースのためにMVVMスキャフォールディングをオフにしなければならないかもしれません。

ASPNET Coreで作業した後、依存性注入がありません。 この機能は、ASPNETCoreにネイティブにあります。 何もしなくても機能します。 また、必要に応じて、サービスを簡単に追加または変更できます。 しかし、今日のUWPの場合、これを自分で作成するか、WTSのようなものを使用して開始する必要がありますが、それでも後で接着されているように感じます。 適切なネイティブ依存性注入を備えたWinUI3は非常に役立ちます。

テンプレートシステムの存在が基本的な機能の欠如を示しているとは思いません。それは、これらのテンプレートシステムをまとめるサポートコミュニティの品質を強調していると思います。

Template10やWindowsTemplate Studioのようなツールは、基本的な機能が不足している兆候です。

私はこのようなものを基本的な機能の拡張として見ています。 もちろん、このようなものを社内に持ち込むこともできますが、その場合はコアチームが維持およびサポートする必要があります。 コアチームがより多くのことを行うと、それらがより薄く広がることを意味する傾向があるため、すべてに時間がかかります。 Msftがこのようなものをメインチームに持ち込む予算があると感じたら、誰かと話をしたいと思います;）

組み込みのスタイルとコントロールにカスタム動作を簡単に追加できるようにするなど、簡略化されたスタイリングとコントロールテンプレートについてのいくつかの考え。 ここでの完璧な例は、ホバーカラーを変更したり境界線の半径を使用したりするためにコントロールテンプレート全体をオーバーライドする必要がある場合のButtonスタイリングです。 cssように、それらの一部を直接設定すると、数キロメートルのXAMLコードを作成できなくなります。

@AntiPasha Ligthweightスタイリングについて聞いたことがありますか？ これを使用すると、スタイル全体を再作成しなくても、ホバーの色を簡単に変更できます。

ボタンのホバーカラーを変更すると、次のようになります。

            <Button Content="MyButton">  
                <Button.Resources>
                    <ResourceDictionary>
                        <ResourceDictionary.ThemeDictionaries>
                            <ResourceDictionary x:Key="Dark">
                                <SolidColorBrush x:Key="ButtonForegroundPointerOver" Color="Blue"/>
                                <SolidColorBrush x:Key="ButtonBackgroundPointerOver" Color="Transparent" />
                            </ResourceDictionary>
                        </ResourceDictionary.ThemeDictionaries>
                    </ResourceDictionary>
                </Button.Resources>
            </Button>

Control.CornerRadiusプロパティも17763SDKに追加され、WinUIチームは、コントロールのスタイルを変更せずにアプリまたはページ全体のカスタマイズを簡単に追加するためのオーバーライド可能なリソースも導入しています： https ：

そして興味深いことに、XAMLツールが統合される場合、ある種の共有xamlファイルを作成する機能はありますか？
何かのようなもの：

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

それは特別なルート名前空間を持つある種の共有方言である必要がありますか？ （Visual Studioの共有プロジェクトなど）。 条件付きxamlのように見える可能性があります。

@Tirraonこれは非常に興味深い例ですが、ツールの統合について話すときは、プラットフォームが今日のように存在するという考え方から始めたほうがよいと思います。別のXaml標準を作成しようとはしていません。同等。

デフォルトの名前空間を使用して、xamlファイルが属する「トップレベル」プラットフォームを区別できます。たとえば、XAMLプラットフォームごとに次のデフォルトの名前空間を設定できます（これらはほとんど架空のものであるため、一粒の塩でそれらを取得します） 😄）：

wpf： xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
uwp： xmlns="http://github.com/microsoft/microsoft-ui-xaml"
アバロニア： xmlns="https://github.com/AvaloniaUI/AvaloniaUI"
uno： xmlns="https://github.com/unoplatform/uno"
xamarin.forms： xmlns="https://github.com/xamarin/Xamarin.Forms"

したがって、Xamlアイランドを使用してWinUIとWPFを混在させるには、次のようなマークアップがあります。

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
                       xmlns:uwp="http://github.com/microsoft/microsoft-ui-xaml">
   <StackPanel>
     <uwp:Button Content="Hi, UWP!" x:Name="uwpButton">
     <Button Content="Hi, WPF!" Width="{x:Bind uwpButton.Width}" />
   </StackPanel>

</UserControl>

どう思いますか？

@stevenbrix
UWPの例では、両方のボタンがレンダリングされますね。
つまり、たとえば、xmlns = "... / xaml / presentation"がトップレベルの名前空間であり、UserControl wutg StackPanelがuwpとwpfの両方で使用できる場合、2番目のボタンは両方のプラットフォームでも使用できませんか？

ツールの統合について話すときは、プラットフォームが今日のように存在するという考え方から始める方がよいでしょう。

ええ、私はそれに完全に同意します。

UWPの例では、両方のボタンがレンダリングされますね。
つまり、たとえば、xmlns = "... / xaml / presentation"がトップレベルの名前空間であり、UserControl wutg StackPanelがuwpとwpfの両方で使用できる場合、2番目のボタンは両方のプラットフォームでも使用できませんか？

@Tirraon 、私が示した例は、純粋にXamlIslandsを使用してアプリケーションを段階的に最新化するWPFアプリケーション用です。 これは、WPFアプリケーションとWinUIアプリケーションの間で使用される「標準」マークアップを対象としていません。それは意味がありますか？

現在、Xamlアイランドを使用したいアプリの作成者は、すべてのアイランドのユーザーコントロールを作成する必要があります。 次に、WinUI要素をWPFマークアップに自然に埋め込むのではなく、WPFマークアップの文字列を介して型を参照します。

私は今電話をしていますが、PCの近くにいると、提案する内容の前後でより具体的になることができます。

@stevenbrix
ああ、今私はあなたを手に入れました、ありがとう。

@stevenbrix
ああ、今私はあなたを手に入れました、ありがとう。

@Tirraon素晴らしい！ 同じページにいてよかった☺️

申し訳ありませんが、私のアイデアが左翼手から出てきたように思われる場合は、Xaml Islandシナリオを改善することを目的として、ツールを統合する方法について初期の議論を行ってきました。 そのようなものに価値があると思いますか？

FWIW、あなたが提案していたようなものには間違いなくメリットがあると思います。 しかし、私はWinUI3 /.NET5の時間枠で実行できることに焦点を当てようとしています。

WinUI Xamlを、出力をネイティブキャンバスに変換し、ネイティブメッセージシステムから入力を受け取るパイプラインにレンダリングする方法を理解します。 WinUi.Adapters.DirectX、WinUI.Adapters.WASM、WinUi.Adapters.X、WinUi.Adapters.Androidのように。

起動時にすべてのアダプターを実装する必要はなく、Windows10をサポートするために必要なアダプターだけを実装する必要があります。

投稿者：スティーブンKirbach [email protected]
送信日：2019年11月7日木曜日9:13:46 AM
宛先：microsoft / microsoft-ui-xaml [email protected]
Cc：シャープ忍者[email protected] ; コメント[email protected]
件名：Re：[microsoft / microsoft-ui-xaml] WinUI 3.0開発者の経験とツール-必要な入力（＃1045）

@stevenbrix https://github.com/stevenbrix
ああ、今私はあなたを手に入れました、ありがとう。

@Tirraon https://github.com/Tirraon素晴らしい！ 同じページにいてよかった☺️

申し訳ありませんが、私のアイデアが左翼手から出てきたように思われる場合は、Xaml Islandシナリオを改善することを目的として、ツールを統合する方法について初期の議論を行ってきました。 そのようなものに価値があると思いますか？

FWIW、あなたが提案していたようなものには間違いなくメリットがあると思います。 しかし、私はWinUI3 /.NET5の時間枠で実行できることに焦点を当てようとしています。

—
あなたがコメントしたのであなたはこれを受け取っています。
GitHubの上に、直接このメールに返信して表示https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLBHRGZTDFHFWQTAFK3QSQWCVA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMXFLY#issuecomment-551121583 、または退会https://github.com/通知/購読解除-auth / AD3GCLF2BUTXQFPSVNULZODQSQWCVANCNFSM4ICOLUJQ 。

はい、お願いします、XAMLアイランドのシナリオは現時点では恐ろしいです

@sharpninja
宇野を見てください
https://platform.uno/
また、すべてのプラットフォームでWinUI3.0をサポートする予定です
https://platform.uno/winui-on-windows7-via-unoplatform/

@stevenbrix
私はXamlアイランドの経験があまりなく、通常はプレーンなUWPを使用しています。 しかし、私は間違いなくそれを詳しく見る必要があります。
私の提案はXamlIslands自体とは関係ありませんでしたが、複数のプラットフォームで機能するため、一般的にWinUIと関係がありました。

私の提案はXamlIslands自体とは関係ありませんでしたが、複数のプラットフォームで機能するため、一般的にWinUIと関係がありました。

@Tirraon 、理解し、あなたの頭がどこにあるかを絶対に愛しています🙌

私はあなたが提案していることについて@jeromelabanと会社と簡単に話しました、そして確かに興味があります。 まだ議論の初期段階にあるため、具体的な計画やコミットメントはまだありません。 この種の入力は素晴らしく、それがお客様にもたらす価値をよりよく理解するのに役立ちます😄

XAMLアイランドシナリオとは、C ++のシナリオを意味します。 私が直面した問題のリストについては、このスレッドの以前のメッセージを参照してください。

はい、お願いします、XAMLアイランドのシナリオは現時点では恐ろしいです

XAMLアイランドシナリオとは、C ++のシナリオを意味します。 私が直面した問題のリストについては、このスレッドの以前のメッセージを参照してください。

@sylveon私はあなたのコメント（以下のリンク）を見ます、
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -512945553
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -513505038

あなたが経験している多くの苦痛はプロジェクトシステムに関連しているように聞こえます、そしてそれは多くの人々のレーダーにあるものであることを私は知っています（私はかなり離れていますが）。 私たちのチームメンバーの何人かがXAMLツールで行ったこのビデオを見たことがありますか？ そのリンクは、 @ michael - @ marb2000が新しいXamlIslandエクスペリエンスに入り始める時点でYouTubeビデオを開始するはずです。 私たちは間違いなくC ++に関心を持っていますが、これまで.NETエクスペリエンスのみを扱ってきたのか、それともC ++にも改善があったのかはわかりません。 彼らはおそらくそれについてもっとコメントすることができます。

XamlIslandの体験を簡単で自然に使用できるようにするために必要なことはたくさんあります。 私が言及している側面は、現在、WPFにUWPの島のコンテンツを含める方法は次のようなものです（上のビデオから）：

  <Grid>
   <xi:WindowsXamlHost InitialTypeName="UWP_XamlApplication.SamplePage"/>
  </Grid>

私たちはそれよりもうまくやることができ、次のようなものを提供できると思います。

  <Grid>
   <uwp:SamplePage />
  </Grid>

@stevenbrix

私はあなたが提案していることについて@jeromelabanと会社と簡単に話しました、そして確かに興味があります。 まだ議論の初期段階にあるため、具体的な計画やコミットメントはまだありません。 この種の入力は素晴らしく、それがお客様にもたらす価値をよりよく理解するのに役立ちます

そう、とても興味があります！ （この会話はどこにでも現れます）WinUI post 3.0がクロスプラットフォームの実装に移行した場合、多くの開発者サポートが必要になります。 ＃1461の議論を見てください。 短期的には、Uno Platformtechを使用してXAML / C＃をHTML / WASMに変換し、すべてのプラットフォームでUWPアプリを実行できるようにするのは素晴らしいことです。 長期的には、Electronまたはブラウザーで実行することによるパフォーマンスへの影響が懸念されており、より効率的なアーキテクチャーの余地があります。

結論として、私は誰もが現在WinUI3.0で忙しいことを知っています。 その者が仕上げたときに我々は最善の方法を把握する@jevansaksと他の人がUWPはどこにでもレンダリングにするために、@ marb2000、@jeromelaban接続している場合しかし、それは素晴らしいことです。 それはまた、将来の電話のための非常に興味深いコミュニティの議論になるでしょう。

WinUiは、NeoとDuoの両方が生き残るための唯一の正しい道です。

投稿者：robloo [email protected]
送信日：2019年11月7日木曜日12:00:07 PM
宛先：microsoft / microsoft-ui-xaml [email protected]
Cc：シャープ忍者[email protected] ; 言及@ noreply.github.com
件名：Re：[microsoft / microsoft-ui-xaml] WinUI 3.0開発者の経験とツール-必要な入力（＃1045）

@stevenbrix https://github.com/stevenbrix

@jeromelaban https://github.com/jeromelabanと会社と、あなたが提案していることについて簡単に話しましたが、間違いなく興味があります。 まだ議論の初期段階にあるため、具体的な計画やコミットメントはまだありません。 この種の入力は素晴らしく、それがお客様にもたらす価値をよりよく理解するのに役立ちます

そう、とても興味があります！ （この会話はどこにでも現れます）WinUI post 3.0がクロスプラットフォームの実装に移行した場合、多くの開発者サポートが必要になります。 ＃1461https ：//github.com/microsoft/microsoft-ui-xaml/issues/1461のディスカッションを

結論として、私は誰もが現在WinUI3.0で忙しいことを知っています。 それは仕上げだときに我々は@jeromelaban接続している場合しかし、それは素晴らしいことだhttps://github.com/jeromelaban 、@ marb2000 https://github.com/marb2000 、@jevansaks https://github.com/jevansaksをし、他の人にUWPをどこにでもレンダリングさせるための最良の方法を見つけてください。 それはまた、将来の電話のための非常に興味深いコミュニティの議論になるでしょう。

—
あなたが言及されたのであなたはこれを受け取っています。
GitHubの上に、直接このメールに返信して表示https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLCHIRMGIIB4EEMXQATQSRJSPA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDNI2QA#issuecomment-551193920 、または退会https://github.com/通知/購読解除-auth / AD3GCLCAZIOGVET6CJKLKLTQSRJSPANCNFSM4ICOLUJQ 。

WinUiは、NeoとDuoの両方が生き残るための唯一の正しい道です。

私は同意する傾向がありますが、AndroidとSurfaceDuoで実行されているWindowsアプリから同じUIを取得します。 開発者からの最小限の介入で-それは聖杯です。

WinUIが主要な開発プラットフォームになる可能性があり、長期的にはWindowsが他のプラットフォームのアプリの単なるレセプタクルになる可能性がない場合。 （大きな確立されたアプリに関しては、必ずしも悪いことではありませんが、LoBと次の大きなアプリにとっては...）

私は独自のアプリケーション指向言語を作成しており、XAMLでのWinUIとコードビハインド用の言語の使用をサポートしたいと考えています。 ツールが、言語がXAMLのコード生成を提供する機能を提供するのであればよいでしょう。 さらに良いのは、XAMLコードジェネレーターがILを、任意の言語を使用して完了することができる部分クラスとして構築した場合です。 これは、コードジェネレーターがコンパイル可能なILアセンブリを出力することを意味します。

私は独自のアプリケーション指向言語を作成しており、XAMLでのWinUIとコードビハインド用の言語の使用をサポートしたいと考えています。 ツールが、言語がXAMLのコード生成を提供する機能を提供するのであればよいでしょう。 さらに良いのは、XAMLコードジェネレーターがILを、任意の言語を使用して完了することができる部分クラスとして構築した場合です。 これは、コードジェネレーターがコンパイル可能なILアセンブリを出力することを意味します。

XAML Directがありますが、現時点ではC＃およびC ++でサポートされています。
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

それは私が言っていることではありません。 つまり、コード生成ツールの出力は、C＃やC ++ではなく、ILです。 そうすれば、コンパイラはXAMLをILに変換して、そのクラスを継承できます。

@sharpninja C ++コードだけでなく、LLVMバイトコードも生成できると

このようにして、MIDLおよびXLangと組み合わせて、XLangでサポートされているすべてのシナリオで使用するCOMライブラリおよびWinMDファイルを生成できます。

私のC ++の帽子をかぶった状態で、C ++用のWinUIツールに関して私が見たいのは、Microsoftが90年代半ばからC ++ Builderが行ってきたことにようやく追いつくことです。

C ++ベースの開発用の実際のRADツールを提供します。

C ++ / CLIはそれを下回って失敗しましたが、フォームにはいくつかの回避策がありました。

C ++ / CXはそうなるように見えましたが、それでもC ++ Builderの機能よりも少し手間がかかりました。

現在、C ++ / WinRTは標準のC ++ 17かもしれませんが、デスクトップ開発者の全体的なエクスペリエンスはダウングレードのように感じられます。手動で作成する必要のある定型文が増え、COMタイプがABI境界を超える方法にさらに注意を払い、デザイナーが不足しています。サポート。

そのため、MIDLコンパイラとCOM ABIサポートに必要なすべての定型文を処理する気がないので、当面はC ++ / CXを使用しています。

一方、.NETの帽子をかぶった状態で、DirectXのようなC ++のみのライブラリが最終的にWinUIコンポーネントとして公開され、Blendが大好きになり、F＃もMicrosoftの.NET言語であると思われることを思い出してください。

WinUIに切り替えるのにかなりの苦労がありました。 現在WinUIを使用していないファーストパーティライブラリとサードパーティライブラリの両方が多数あり、それらへの依存関係が問題になります。 たとえば、BehaviorsSDKです。

これは、UWP CommunityDiscordでStatusBarについて話しているときに思いついたアイデアです。

Visual Studioで、ツールボックスにUWPにないWPFコントロールのエントリを含め、それらのエントリを選択すると、従来のコントロールをシミュレートする方法を説明するポップアップを表示します。

このアイデアは、特定のコントロールが表示されることを期待しているWPF（または他のフレームワーク）からの移行を容易にしたいという願望から来ています。これらのコントロールが見つからない場合は、不快な経験になる可能性があります。 CommandBarがStatusBarのように使用できることをどうやって知ることができますか？ 人々がWinUIに移行できるように、できるだけシンプルにする必要があると思います。 これは、不足しているすべてのコントロールを実際に開発することなく、いくつかのギャップを埋めるのに役立つ可能性があります。

編集：
そして完全を期すために、ステータスバーについて私が言った他のことをここに示します..誰かがUWP（またはWinUI）に慣れていない場合にどのようにアプローチするかを示しています..

Re：StatusBar-UWPを試している従来のフレームワークのユーザーの観点から考えていました-そして、StatusBarがないことを確認しました-まだ多くのアプリの定番です。 はい、CommandBarの方が良いかもしれません。 しかし、人々はCommandBarが何であるかを知らないか、それが何か他のものであると推測するかもしれません。 上記の誰かが、グリッドを追加して一番下に配置し、1行の高さにして、さまざまなコントロールを追加して表示することを提案しました。 したがって、既存のXaml設計者でさえCommandBarについて知らないようです。 とにかく、あなたが正しいかもしれませんし、CommandBarの方が優れているかもしれませんが、Paul ThurrotはUWPメモ帳アプリでそれを使用せず、グリッドを使用しました。 したがって、CommandBarはStatusBarの代わりとして伝達されていないようです。 カジュアルな（または新しい）開発者はまだStatusBarを探していますが、見つかりません。 Paul Thurrotが開発者ではないことは知っていますが、あなたは私の主張を理解しています。

スニペットが通常のユースケースでxamlに挿入されれば素晴らしいでしょう。

投稿者：ギャビン・ウィリアムズ[email protected]
送信：2020年2月18日火曜日19:05:39
宛先：microsoft / microsoft-ui-xaml [email protected]
Cc：シャープ忍者[email protected] ; 言及@ noreply.github.com
件名：Re：[microsoft / microsoft-ui-xaml] WinUI 3.0開発者の経験とツール-必要な入力（＃1045）

これは、UWP CommunityDiscordでStatusBarについて話しているときに思いついたアイデアです。

Visual Studioで、ツールボックスにUWPにないWPFコントロールのエントリを含め、それらのエントリを選択すると、従来のコントロールをシミュレートする方法を説明するポップアップを表示します。

このアイデアは、特定のコントロールが表示されることを期待しているWPF（または他のフレームワーク）からの移行を容易にしたいという願望から来ています。これらのコントロールが見つからない場合は、不快な経験になる可能性があります。 CommandBarがStatusBarのように使用できることをどうやって知ることができますか？ 人々がWinUIに移行できるように、できるだけシンプルにする必要があると思います。 これは、不足しているすべてのコントロールを実際に開発することなく、いくつかのギャップを埋めるのに役立つ可能性があります。

—
あなたが言及されたのであなたはこれを受け取っています。
GitHubの上に、直接このメールに返信して表示https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLGYERSFO7LBXKWBBRDRDSAWHA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMF6O3Y#issuecomment-587982703 、または退会https://github.com/通知/購読解除-auth / AD3GCLFLGA773XOS5OSG5ULRDSAWHANCNFSM4ICOLUJQ 。

開発者ストーリーには、一種の比較リストを含める必要があります。

Win32アプリに固有の概念であるため、一方のリストにはステータスバー、ツールバー、メニュー、グリッパー、タブなどがあり、もう一方のリストにはWinUIの同等のものがあります。

両方のコードサンプルを含むページ自体。既存のアプリのUIをWinUIに移動する方法を示しています。

未解決の質問
手順1〜3を自動化する移行ツールを提供した場合、それは有益でしょうか？

はい。 1つの「レガシー」Windowsフォームアプリ（レガシーは書き直す予算がないことを意味します）と2つまたは3つのレガシーWPFアプリをサポートします。 WinFormsアプリは取り残されている可能性がありますが、WPFアプリをWinUI3にすばやく移植するのに役立つツールは素晴らしいでしょう。

MSIXは、すべてのアプリの最新のパッケージ化方法です。 Win32のWinUIの場合、ClickOnceをサポートする必要がありますか？ 他にどのようなパッケージ方法のサポートを含める必要がありますか？ 特にWin32のWinUIの場合

現在、ClickOnceを使用して、ユーザーのデスクトップにアプリを公開しています。 自動更新のいくつかのモデルは依然として望まれます。

@JeffSchwandt

これらの手順は、以前のバージョン（1-2）を使用してWinUIプロジェクトをバージョン3に変換することに関するものでした。

WPFアプリをWinUIアプリに変換することは、自動化された方法では特に実現可能ではありません（多大な労力がなければ、それでもエラーが発生しやすくなります）。

これがこのリクエストを投稿するための正しいスレッドであることを願っています。

Rustは現在、適切なUIフレームワークを切実に必要としています。 将来、WinUIがネイティブSDKといくつかのツールを使用してRustをサポートできると便利です。

これがこのリクエストを投稿するための正しいスレッドであることを願っています。

Rustは現在、適切なUIフレームワークを切実に必要としています。 将来、WinUIがネイティブSDKといくつかのツールを使用してRustをサポートできると便利です。

朗報です。Rust/ WinRTは開発中であり、RustアプリでWinUIなどのWinRTAPIを使用できるようになります。 https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/をご覧ください

@jevansaksねえ、応答をありがとう！ ええ、KennyがRust / WinRTで動作することは知っていますが、WinRTがWinUIでサポートされる唯一のAPIレイヤーであるかどうか疑問に思います。 これが、デスクトップアプリからのWinRTAPIの使用がWindows10 1903でのみ利用可能になったという事実とどのように適合するかはわかりませんが、WinUIは古いバージョンのWindows10をサポートすることを目的としています。

Rust / WinRT（C ++ / WinRTなど）はWindows7まで機能するはずです。WinRT自体は常にデスクトップ/ win32アプリで機能します。 ストア/ uwp /パッケージングの要件があったのは特定のAPIのみです（WinRT全体ではありません）。 WinUIにこれらの要件がない限り、サポートされているプラ​​ットフォームでC ++ / WinRTとRust / WinRTの両方を介してデスクトップアプリからWinUIを使用できます。

WinUIデスクトップアプリは、ライブタイルとタイル更新をサポートする必要があります。これには、今日のUWPアプリよりも簡単にタイルを作成するための優れたシンプルなサンプルとSDKツールが含まれています。

デスクトップアプリからのWinRTAPIの使用がWindows10 1903でのみ利用可能になったという事実と、これがどのように適合するかはわかりません。

WinUIデスクトップは現在WinUI3.0用に設計されており、これによりプレーンなWin32アプリでWinUIダウンレベルを使用できるようになります（現在の計画は1803までです）。

Windows UIは、少なくとも主要なMVVMフレームワーク（MVVM Light、Prism、およびCaliburn）をサポートする必要があります。 残念ながら、INotifyPropertyChangedおよびINotifyCollectionChangedの変更に関する文書化された問題により、ObservableCollectionが破損します確かにMVVMLightを壊し、おそらく他の2つのフレームワークも壊します。 あなたが知っておくべきだと思った。

残念ながら、INotifyPropertyChangedとINotifyCollectionChangedへの変更に関する文書化された問題がObservableCollectionを壊すと、確かにMVVM Lightが壊れ、おそらく他の2つのフレームワークも壊れます。 あなたが知っておくべきだと思った。

ありがとう@terrycox！ 私たちは認識しており、これはWinUI 3.0 RTMによって対処され、理想的にはそれ以前のプレビュービルドで対処されます;）

@terrycox Windows UIは、少なくとも主要なMVVMフレームワーク（MVVM Light、Prism、およびCaliburn）をサポートする必要があります。 ...文書化された問題

はい、文書化された問題を修正する必要がありますが、MVVMフレームワークをサポートするためにWinUIを含む.NetUIライブラリは必要ありません。 UI要素を表すオブジェクトのみをサポートする必要があります。 .Net MVVMまたはリアクティブフレームワークは、データを表すオブジェクトに基づいてUIを表す.Netオブジェクトを生成および変更する方法です。 どちらも相手について知る必要はありません。 任意のフレームワークを任意のUIライブラリと組み合わせることができます。

ただし、MVVMフレームワークをサポートするためにWinUIを含む.NetUIライブラリは必要ありません。

しかし、UIElementsが認識しているイベントやインターフェースのようなものが必要であり、それが壊れたのです。

投稿者：チャールズ・Roddie [email protected]
送信：2020年3月25日水曜日14:28:46
宛先：microsoft / microsoft-ui-xaml [email protected]
Cc：シャープ忍者[email protected] ; 言及@ noreply.github.com
件名：Re：[microsoft / microsoft-ui-xaml] WinUI 3.0開発者の経験とツール-必要な入力（＃1045）

@terrycox https://github.com/terrycox Windows UIは、少なくとも主要なMVVMフレームワーク（MVVM Light、Prism、およびCaliburn）をサポートする必要があります。 ...文書化された問題

はい、文書化された問題を修正する必要がありますが、MVVMフレームワークをサポートするためにWinUIを含む.NetUIライブラリは必要ありません。 UI要素を表すオブジェクトのみをサポートする必要があります。 .Net MVVMまたはリアクティブフレームワークは、データを表すオブジェクトに基づいてUIを表す.Netオブジェクトを生成および変更する方法です。 どちらも相手について知る必要はありません。 任意のフレームワークを任意のUIライブラリと組み合わせることができます。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-604040104で表示するか、 https：//github.com/notifications/unsubscribe-auth/の登録を解除して

Dotnet cliツールは、と一緒に使用する必要があります。 ネットコアSDK。
dotnetnewやdotnetbuildなどのコマンドで十分であり、VisualStudioのインストールに大きく依存することはありません。 .Net Core Eraに完全に参加してください！

• xamlデザイナが高速であれば良いでしょう。 現在のXAMLデザイナは低速であり、例外が発生して機能しないというエラーを常にスローします。 それを修正し、堅牢な設計者を提供してください。

• 現在、uwpにはロック画面を検出できるAPIがありません。 ロック画面を検出し、戻り値としてブール値を与えることができるAPIが提供されていると便利です。 また、ロックまたはロック解除後に、いくつかのアニメーションとバッジを表示できるはずです。
  -既存のロックスクリーンAPI

• 私の問題は説明しました

@JensNordenbroのコメントに沿って、これがVs Codeだけで機能する可能性はありますか？

.NET5ストアホストアプリケーションを参照するWinUI3.0UIを使用して.NET5アプリケーションを作成するアプリケーションテンプレートが欲しいのですが。 これにより、.NET5.0の冗長インストールを減らすことができます。

WinUIデスクトップアプリケーションでは、muxc.Window.ThisPtrからhWnd、ネイティブWin32ウィンドウにどのように移動しますか？

このアイデアが気に入ったので、デスクトップ用のWinUI3プレビュー1の新しい2020年5月のテンプレートを試しました。

しかし、私は1つの質問があります。 WinUIがWindowsのネイティブUIプラットフォームであるため、実際にWindows 10の一部でもあるというコミュニケーションの欠如に驚いていますか？

結果として得られたHelloWorldアプリのサイズは約120MBでした。 確かに、スペースは安いですが、私はここで私自身に依存していませんでした。 このうち、WinUIは、含まれている.NET 5自体とほぼ同じ量の、かなりの量のスペースを消費しました。 これは、x64ビルドのみの場合です。 マルチプラットフォームパッケージにx86を含め、そのサイズを2倍にします。 他のいくつかの依存関係を追加すると、配布用にパッケージ化する300MBのアプリを簡単に検討できる可能性があります。

WinUI3がWindows版の.NET5の一部ではないのはなぜですか？ これは.NETCoreのモジュール化の取り組みの一部ですか？ しかし、そうでない場合、それのための場所はどこにありますか？ 本当にすべてのアプリのフォルダを調査しますか？ 公式のWindows10ユーザーインターフェイスとして...？

それとも、将来的にはWindows 10の一部になるのでしょうか？ WinUIがシステムライブラリのように扱われ、.NET 5が後でWindowsに同梱されるようになる場合は、代わりに比較的小さなアプリを検討します。 しかし、うまくいけば、これは少なくともWindows 10Xの話であり、後でWindows 10非Xの話になるのではないでしょうか？ これらの2つのライブラリとWindows10 SDK C＃/ WinRTブリッジDLLを除くと、アプリのサイズは1〜5MBに急落します。

@ryandemopoulosはDiscordで、WinUIはフレームワークパッケージとして提供されると述べています。したがって、配布にStoreまたはMSIXを使用するアプリは、すべて同じバージョンのWinUIを共有するため、独自のバージョンのWinUIを実行する必要はありません。

WinUIをWindows自体の一部にすることは、WinUIがOSから切り離されるという点を打ち負かすことになります。

「信頼性が高く、アプリのサイズではない」ことが懸念事項です。 .NET5も同様に配布されることを願っています。

@lmcdougald .NET Coreインストーラーで問題を開き、サービスにも.NET5使用フレームワークパッケージングを要求することをお勧めします。

@jonasnordlund WinRTランタイムの展開について話している別のディスカッション＃2500があります。 おそらくあなたはそこにいくつかの答えを見つけるでしょう。 :)

@ marb2000問題をオープンしましたが、正直なところ困惑しています。 これは、Windows 10Xを提供するアプリにとって不可欠であるとは見なされていませんか？

これはいくつかの機能をまとめたものです。そのうちのいくつかは直接WinUIではありませんが、それらの欠如は.NETクライアント開発のエクスペリエンスに直接影響します。UWPクライアント、特にLoBアプリクライアントが含まれます。

• 私にとって何よりも最優先事項は、あなたが宇野プラットフォームを育てることです。 私にとって、それがUWPを関連性のあるものにしているのです。宇野がいなかったら、XFや他のテクノロジーに妥協していたでしょう。 （https://github.com/microsoft/microsoft-ui-xaml/issues/2024）
• ViewModelから使用される抽象的なクライアント側ID管理API（https://github.com/microsoft/ProjectReunion/issues/31）
• 完全なデータ注釈のサポート、検証とUIタイトル、文字列の長さ、必須属性、読み取り専用フィールド、透かしなど（https://bit.ly/3gcMJ3a）
• ODataを改善して、RIAサービスの適切な代替手段になるようにします。 例：サポート属性の生成、インターフェースの実装、ジェネリック型、XMLドキュメント（https://github.com/OData/odata.net/issues/1746）
• WPFから不足しているすべての機能を取り込む
• x:Bind Bindingは、スコープやネストされたバインディングなど、
• ホットリスタート（https://github.com/microsoft/ProjectReunion/issues/44）
• 単純なHelloWorldテンプレート以上のもの。 ユーザーログイン、MVVM、ルーティング、x-platプロジェクト（Uno-Platformなど）などに対応するようなものです。言い換えると、WTSにより多くのパワーを与えてください。
• XAML WYSIWYG-ドッキング、間隔など、WinFormsのようなエディターレイアウト機能-これは完了したようです！ ❤

非常に便利な@weitzhandlerを編集していただきありがとうございます。

WinUIチームは、Uno製品チーム（Microsoft以外）、Xamarin Forms / MAUIチーム、およびReactNativeと素晴らしい関係を築いています。 私たちは積極的に彼らと協力し、彼らが成功する未来を願っています。

不足しているWPF機能について、上位の機能をリストしてください。 WPFとWinUIの間のギャップを埋めることは、私たちの目標の1つです。 ただし、いくつかのリリースが必要です。

より複雑なテンプレートの適切さ。 Window TemplateStudioにはこの使命があります。

WPF＃719 @weitzhandler @ marb2000と比較してWinUIが不足している領域を収集しようと問題を作成しました

より複雑なテンプレートの適切さ。 Window TemplateStudioにはこの使命があります。

@ marb2000 Windows Template Studioを

より複雑なテンプレートの適切さ。 Window TemplateStudioにはこの使命があります。

@ marb2000 Windows Template Studioを

👀@ crutkas @sibille

C ++ Builder（VCL / FMX）とQt Creator / Design studioを使って、C ++と最新のツールで何ができるかを学ぶことをお勧めします。

理想的には、WinUIは、C ++で記述されたクロスプラットフォームGUIに対して今日すでに提供されているこれらの製品と同様のツールを提供します。

私が気にかけているのは、.NET開発の経験と、C ++を使用せざるを得ないユースケースで同様の経験を持っていることです。これは、何らかの理由で利用できません。

C ++ BuilderとQtCreatorはそのような経験を実現し、.NET開発者がC ++ / WinRTコードの記述に数日を費やさなければならないことに直面したときに、くつろげるなら歓迎されます。

なぜ.NET開発者についてこれを作るのですか？ C ++ XAMLのエクスペリエンスは悪いだけで、C ++または.NETの開発者であるかどうかは関係ありません。

デスクトップ、Web（エッジ）、モバイル、IoTで同じXAMLを実行できるようにするために、彼らが道を開くことができれば素晴らしいと思います。

C＃、Xaml、またはデザイナーを使用せずに、C ++プロジェクトでWinUI3を使用できるようになるのはいつですか。
また、WinUI3のc ++コアのオープンソーシングの日付に関するニュースはありますか？

編集：私は私の最初の質問に対する答えを得たと思います、WinUI3.0プレビュー1にc ++ WinUI 3プロジェクトテンプレートがあるようです：

.vsix拡張子をインストールした後、「WinUI」を検索し、使用可能なC＃またはC ++テンプレートのいずれかを選択することにより、新しいWinUI3.0プロジェクトを作成できます。

WinUIで改善したいユースケースは、PowerShellで記述されることが多い最前線のITサポートスタッフ向けの小さなGUIベースのツールを作成することです。 これらの種類のツールをVisualStudioCodeで作成できると便利です。 C＃ベースのVSCode開発オプションでさえ素晴らしいステップになるでしょう。 本格的なVisualStudioは、この場合、かなり重くて複雑に感じます。

現在、エンタープライズ環境では、代わりに次のようなツールを使用しています。

• https://poshgui.com/（WebベースのXAMLウィザード）
• Sapien PowerShell Studio 2020 （独自仕様）
• 管理スクリプトエディター（ASE） （現在は放棄されたプロジェクト）

その他の一般的に使用される「XAMLにVisualStudioを使用する」パターンについて説明します。

• PowerShellスクリプト用のシンプルなグラフィカルインターフェイスを作成する
• スクリプト用のPowerShellGUIを構築する方法

私の質問は、彼が5月に尋ねた@mqudsiの質問に関連していますが、誰も応答しませんでした。

In a WinUI desktop application, how does one go from muxc.Window.ThisPtr to an hWnd to the native Win32 window?

これはデスクトップアプリケーションであるため、ICoreWindowInteropを使用できません。また、 new HandleRef(this, ThisPtr)などのランダム化されたスワッグを試しました。「this」のタイプはMicrosoft.UI.Xaml.Windowですが、無効なウィンドウハンドルのerrnoが表示され続けます。 最終的にそのhwndを取得したら、さらにCOMを使用してウィンドウのスタイルを変更し、他のユーザーと共有して、今のような苦痛を感じないようにすることができます:)。

興味のある人にとっては、これはメインウィンドウのhWndを取得して、ボーダレスにするために使用した簡単なアプローチです。 WindowStyle = Noneと同等のWPFの完全なソリューションはここにあります。

using var process = Process.GetCurrentProcess();
var hWnd = process.MainWindowHandle;

現時点では、WinUIがデスクトッププロセスにあるときにhWndを取得するための簡単な検索/文書化された方法はないようです。そのため、私が使用したアプローチに目を向けました。 十分に機能しているようです。

用語としてのUWPとユニバーサルWindowsはなくなるはずだと思います。 用語は、開発者を遠ざけるように導くいくつかの不幸な荷物を運びます。

おそらく、テンプレートWinUI（Universal Windows）をWinUI（Win64）に置き換えることができますか？ 次に、デスクトップまたはストアのオプションがありますか？

Win64は紛らわしいです-Win32APIが32ビットのみをサポートし、逆にUWPが64ビットのみをサポートすることを意味します。どちらもfalseです。

Win32の名前自体は、すでに多くの初心者を混乱させています。事態を悪化させるためにWin64は必要ありません。

@VagueGit私が学んだことは、正しい名前を選び、ストーリーを作成することは、より複雑なことの1つであるということです。 名前を置き換えるよりも、私たち（Microsoft）は、成功に役立つ適切な製品（およびストーリー）を提供する必要があります。 UWPはWin32としてよく知られている用語なので、引き続き使用する必要があります。

これが私たちのアプローチです（非常に単純化されています）：

WinUIは、異なるデバイスを対象とする2つの「タイプ」のアプリで使用できます。

• アプリは、多くの入力とフォームファクターを備えた多くのデバイスを対象としています。 次に、UWPを使用します。 UWPはそのために作成されました。 したがって、パッケージモデル、ストア、アプリケーションモデル、セキュリティコンテナなどの要件を満たす必要があります。
• アプリはデスクトップのみを対象とし、OSへのフルアクセスが必要です。 Win32またはデスクトップを使用します（これは、Visual StudioがWPF、WinForms、MFC、アプリを呼び出す方法です）。

UWPアプリのWinUIとデスクトップアプリ（またはUWPWinUIアプリまたはデスクトップWinUIアプリ）のWinUIは、プロジェクトテンプレートの目的により適しています。

@ marb2000物事に名前を

WinUIに移行したいUWPアプリがあります。 Win32 APIは使用せず、デスクトップのみを対象とし、ストアは使用しません。 それはどのように適合しますか？

@ marb2000物事に名前を

WinUIに移行したいUWPアプリがあります。 Win32 APIは使用せず、デスクトップのみを対象とし、ストアは使用しません。 それはどのように適合しますか？

正確には、誰のためのアプリですか？

UWPアプリを使いこなす消費者として、アプリがストアにない場合は、見るどころか、触れないでしょう。

@shaheedmalikを心配しないでください

したがって、Win64ビジネスアプリの市場があることはわかっており、ビジネス顧客が支払うWin64アプリを提供している数少ないビジネス開発者の1人であると信じています。 このスレッドには、ユニバーサルWindows /マルチプラットフォームルートをたどる開発者が何人かいることは知っていますが、それらは非常にまれです。 私の経験では、ほとんどのビジネス開発者は特定のフォームファクターを対象としています。

では、UWPに多額の投資を行い、UWPのビジネスで成功を収めた開発会社の観点から言えば、WinUI（デスクトップ）とWinUI（ストア）のテンプレートでしょうか。 UWPが開発プラットフォームとしてどれほど貧弱に見られているかを知るには、技術メディアをフォローするだけです。

@VagueGit
「WinUIに移行したいUWPアプリがあります。Win32APIは使用せず、デスクトップのみを対象とし、ストアは使用しません。これはどのように適合しますか？」

では、UWPをWinUI 3に移行して、ストアの外部に展開しますか？ ナイーブな質問：MSIXのサイドロードを試しましたか？ ストア以外にUWPの使用を停止する理由はありますか？

@VagueGit
「つまり、Win64ビジネスアプリの市場があることはわかっています。」

1つの質問ですが、Win64は多くのことを表しています。 たとえば、アプリはx64用にコンパイルされます。 Win64はあなたにとってどのような意味がありますか？

@ marb2000 UWPは、ビジネスレポートのサポートが不十分です。 ブランド変更は、レポートライターなどのサードパーティツールの開発を開始するのに役立つと考えています。 サイドローディングを試してみましたが、デフォルトではサイドローディングが有効になっていないため、20H1までは実現できませんでした。

Win64はWindowsでの前進の道だと思います。 Micro $は、過去にWin32をレガシーとして売り込もうとして成功しませんでしたが、現在はその位置に戻っています。 しかし、私たちの判断では、最終的にはWin32を廃止する必要があります（Win32の開発から30年が経過した後、私はそう言っています）。 UWPの制限のほとんどを克服して、企​​業が購入するビジネスアプリを提供することができました。 UWPの別のイテレーションでは、ブランドを変更せずにトラクションが制限されることが懸念されます。

@ marb2000からの混乱が示すように、Win64という用語はすでに（不十分に）使用されています。 私も以前にそれを指摘しました。

ブランド変更が必要になる可能性があることに同意しますが、Win64はそれを行うためのひどい方法です。 公式なものができるまでは、UWPという用語を使用してすべての人に理解してもらう必要があります。

@sylveon UWPは、誰もが失敗であると理解しています。 私たちはそれが好きですが、他の人はほとんど好きではありません。 そのため、ブランド変更が重要です。 WinUI（Deskop）またはWinUI（Store）をプロジェクトテンプレートとしてどう思いますか？

WinUI（ストア）は、Win32アプリをストア内に出荷したり、UWPアプリをストア外に出荷したりできるため、適切ではありません。 ただし、WinUI（デスクトップ）は優れています。

@sylveon WinUI（Store）は、ストアを対象とする他のプロジェクトを排除しません。 これは、ストアからのリリースを可能にする一連の機能から始めたいという意味です。

初心者を混乱させるほど悪いです。

これは、このスレッドの特定の人物を対象としたものではなく、デスクトップアプリケーションの開発者/会社の所有者としての私自身の意見です。

私は何かが名付けられていることに決して巻き込まれません。 私はそれがどんな機能を持っているか、そしてそれがどれだけうまくサポートされているかだけを気にします。

ここでMAUIのような用語を使用すると興奮する開発者（私を含む）もたくさんいると思いますが、それでも同じコードベースであることに気付くとすぐに失望します。 ブランド変更は、「ちょっと見て、xyzからあなたをブロックしたものとはまったく異なるコードベースから始まるこの真新しいものを構築している」ことを示唆しています。 私が見たいのは、私や他の誰かが抱えていた苦労を相殺するように変更された機能の膨大なリストです。

プラットフォームは、他の製品やブランドと同じように、時間の経過とともに開発されます。 それは自動的にLTSを意味するので、私は何十年も前から存在しているブランドと名前に快適さを見出します。 名前の変更が必要になることもあることは承知していますが、開発者に放棄を思い出させることもあります（Silverlight）。 問題に悩まされていたが、愛され尊敬されるブランドになってしまった自動車モデルはたくさん存在します。 以前の経験が気に入らなくても、何を期待するかを知っているので、親しみやすさで言うべきことがたくさんあります。 問題が解決される限り、それが本当に重要です。

考慮する必要のあるオーディエンスは少なくとも2つあると思います。 開発者と最終製品ユーザー。 開発者/ビジネスオーナーとして、アプリケーションを必要とする顧客がいて、その顧客が基盤となるテクノロジー名に悩まされている場合、その名前で表される製品が成熟し、何が彼らに関係しているかについて、彼らに自信を植え付けるのが私の仕事です。過去が更新されました。 一方、「WinUIまたはMAUIと呼ばれるこの新しい素晴らしいものがあるように見えます」と言って、彼らがすでにWPF、UWP、またはXamarin製品を所有している場合、彼らからの予測可能な応答は「ああ、今は私たちのアプリです。 2、3、または4つの異なるテクノロジで記述されています。」 これは私がそれらを売らなければならないところです。 すべての顧客が異なることを考えると、名前をそのままにするか、変更するかにかかわらず、私はプッシュバックに遭遇するでしょう。

最終的に（私にとって）重要なのは、LTSを備えた魅力的で機能豊富なアプリケーションを作成するために必要なツールがあることです。 製品が締め切りに間に合うのを見ると興奮し、製品がリリースされると新機能と問題解決リストを読むようになります。 私は2016年からNetCore / Net5（名前変更LOL）についてこれを気に入っています。

今は、XAMLダイアレクトを使用してデスクトップアプリケーションを作成し、UWP / WinUIが提供するのと同じレンダリングパフォーマンス（UWPサンドボックスなし）を取得できるようになるまで早送りしたいと思います。 そのため、9月のプレビューが削除されたため、アバロニアの試乗を開始します。 SkiaSharpを介してレンダリングのパフォーマンスについて聞いている間、WPFの類似点が大好きです。

UI開発のオプションが安定した数年後にはエキサイティングになるでしょう。 彼らはプロジェクトテンプレートに好きな名前を付けることができますが、機能の欠如についての私の意見は変わりません。

みなさん、ありがとうございました。

jtbrowerが彼のメールで言っていることがわかります。 私たちのような彼の会社は、xamlの道をうまく進んだ数少ない会社の1つです。 メリットを確信する必要はありません。

しかし、それは良いことかもしれませんが、xamlはMicro $にとって惨事でした。 開発者は圧倒的にWinFormsにとどまるか、完全にWeb開発に飛びつきました。 UWP以降、開発者の流出は悪化しました。

xamlテクノロジーが持続可能であるためには、Micro $は、オンボーディングに失敗した何百万もの開発者を獲得する必要があります。 これらの開発者、ツールベンダー、および技術メディアにとって、UWPは行き止まりです。 UWPをもう一度繰り返しても、それらは優先されません。

@VagueGitですが、開発者は

jtbrowerに絶対に同意します。 また、あなたが私を助けてくれたことに感謝し、他の人が彼らのアイデアを批判することを願っています。 しかし、ストアとデスクトップの2つの異なるUWPがあることを、開発者とツールベンダーにどのように報告するのでしょうか。

したがって、UWPパスに沿って続行したい人は、UWPストアテンプレートから始めることができますが、サンドボックス化されていない完全な信頼ではなく、64ビットデスクトップが必要な人は...そうですね、UWPではありませんか？

UWPは、市場では機能不全に陥っていると見られています。 Micro $自体がUWPで独自のアプリを構築することをやめたとき、私たちを除くすべての人がUWPをあきらめました。

開発市場はUWPの開発を監視していません。 サンドボックス化された完全な信頼ではない64ビットデスクトップは、名前の変更以上のものです。 それは別のパラダイムです。 しかし、それがまだUWPと呼ばれている場合は、UWPを書き留めた人には気付かれません。

@VagueGitUWPで成功を収めてくれてうれしいです。 命名は難しく、私たちがそれを「ユニバーサルWindowsプラットフォーム」と呼んでいて、大多数のWindows開発者がそれを実際に維持できないという事実は、まあ、あまり「ユニバーサル」ではありません。 Project Reunionの正確な要約は、これを修正し、すべてのWindows開発者がUWPのあらゆる側面に真にアクセスできるようにすることです。

UWPの名前が間違っていることに同意します。検索エンジンに「UWPis」というフレーズを入力すると、BingまたはGoogleから最初に表示される自動暗示は「UWPは死んでいます」です。 ただし、 @ marb2000は、荷物が運ばれているにもかかわらず、この名前を引き続き使用する必要があるのは正しいと思います。

そうは言っても...

今日、デスクトッププロジェクトの多くの側面で、「UWP」として定義していたもののさまざまな部分を使用できるようになります。

1. UIスタック（別名WinUI3）
2. MSIXパッケージ
3. MRTリソース

CoreApplicationが解除されると、UWPとデスクトップの唯一の違いは、アプリケーション用に選択したサンドボックスモデルと、ターゲットにできるデバイスになります。

プロジェクトテンプレートに変更を加え、これをより正確に説明するウィザードのようなエクスペリエンスを提供することについて説明しました。

@JeanRocaはこれを推進しているPMであり、彼が共有できるより多くの情報を持っている可能性があります

WinUIデスクトップテンプレートのアイデアが好きです。 Win32よりも適切で前向きです。 Win32が32ビット制約を提案したのに対し、これは私たちが始めるテンプレートです。 WinUIデスクトップは、メディアや開発者の間である程度の注目を集めることを願っています。

UWPアプリがストアの外部にリリースされると、パッケージは.appinstallerになります。 そのアプリをWinUI Desktopにアップグレードすると、インストーラーパッケージがappinstallerからmsixに変更されます。

アプリパッケージ内の詳細を同じに保ち、バージョンを適切にバンプすると仮定すると、Windowsはこれが同じアプリの新しいバージョンであると認識し、ローカルデータを保持しますか、それとも別のアプリとしてインストールしますか？

私の理解では、WinUI3.0が.NETFramework <= 4.8から消費されることはありません。 したがって、WinUIについて話している場合は、.NETNativeまたは.NET3.1 / 5 +（または別のバインディングのセット）のいずれかについて話していることになります。

.NET 5（または現時点では6だと思います）のフレームワークパッケージングについてさらに進める/質問する方法について何か提案はありますか？ 問題を開いたのですが、応答がありません。 .NET5アプリ内のバンドルは初心者ではありません。

@stevenbrix

CoreApplicationが解除されると、UWPとデスクトップの唯一の違いは、アプリケーション用に選択したサンドボックスモデルと、ターゲットにできるデバイスになります。

残念ながら、もう1つの大きな違いは、.NET開発者がDirectXなどのAPIをC ++に移行することを余儀なくされていることです。そのチームは、COMベースであるにもかかわらずUWP互換にすることを明らかに拒否しています。

そして、その過程で、経験のような素敵なメモ帳でMIDLを手動で作成し、ファイルをコピーするという生産性の時代に戻ります。明らかに、Windowsチームは、C ++ワークフローにNETのような経験を提供する代わりに、開発経験のようなATLを手放すことはできません。 C ++ / CXはC ++ Builderに近づきすぎていたので、ISOのものの名前で殺さなければなりませんでした。運が良ければ、C ++ 23とVSの2025でそれらを入手できるかもしれません。

これらすべての不正行為をクリアするための適切な開発経験が設定されていない限り、それまでに誰もがUWPを気にすることはないと思います。

また、フィードバックを提供するチームに関するGitHubの問題は、興味を失う非常に迅速な方法です。 どうやら気にしすぎただけです。

DirectX APIは、既存のコンシューマーにとって重大なAPIブレークになるため、WinRT互換性のために変更することはできません。

DirectXで使用できるマネージラッパーは複数あります。たとえば、生の1：1バインディングであるVorticeなどです。

CXに関しては、それは消えなければなりませんでした。 コンパイラ固有の言語拡張機能は悪く、嫌われています。 これはコードの移植性を大幅に妨げ、C ++標準サポートの点で遅れることが多く、既存のライブラリからの完全な垂直統合を必要とします。 代替のWRLは、使用が非常に難しく、過度に冗長でした。 したがって、多くの人（DX部門を含む）がWinRTAPIを作成したくないのは当然のことです。

C ++ / WinRTははるかに優れたソリューションであり、IDLを復活させる必要があったのは残念です（ただし、現在必要な悪です）。 C ++チームは、標準サポートで以前よりもはるかに優れた仕事をしているので、C ++ 23が完成する前に実際にメタクラスを取得しても、開発者のUXが大幅に向上するはずです。

@sylveon

Windows開発コミュニティが、生産性の低下を正当化する理由でレドモンドから出てくるものをすべて無視していることに驚かないでください。

同じことがCXでも起こっていました... C ++開発者はプロプライエタリ言語拡張を好まないため、ほとんど使用されていませんでした。

アプリパッケージ内の詳細を同じに保ち、バージョンを適切にバンプすると仮定すると、Windowsはこれが同じアプリの新しいバージョンであると認識し、ローカルデータを保持しますか、それとも別のアプリとしてインストールしますか？

@VagueGit 、これは素晴らしい質問です。 結局のところ、UWPアプリとデスクトップアプリをインストールするための技術は同じです。 答えはイエスだと思いますか？ 最近のSDKの時点では、UWPアプリでさえ.msix拡張子が付いていると思います（間違っている可能性があるので、引用しないでください）。 これをローカルで試してみることができると確信していますか？ fyiの@adambraden。

.NET 5（または現時点では6だと思います）のフレームワークパッケージングについてさらに進める/質問する方法について何か提案はありますか？ 問題を開いたのですが、応答がありません。 .NET5アプリ内のバンドルは初心者ではありません。

@lmcdougald私はあなたがどの問題を参照しているのか知っていると思います（しかし私はそれを見つけることができません）。 1つありますが、.net6のタイムフレームになると思います。 誰もがこれを行う必要があることを認識しています。

そして、その過程で、経験のような素敵なメモ帳でMIDLを手動で作成し、ファイルをコピーするという生産性の時代に戻ります。明らかに、Windowsチームは、C ++ワークフローにNETのような経験を提供する代わりに、開発経験のようなATLを手放すことはできません。 C ++ / CXはC ++ Builderに近づきすぎていたので、ISOのものの名前で殺さなければなりませんでした。運が良ければ、C ++ 23とVSの2025でそれらを入手できるかもしれません。

また、フィードバックを提供するチームに関するGitHubの問題は、興味を失う非常に迅速な方法です。 どうやら気にしすぎただけです。

@pjmlpあなたの誠実さと情熱に感謝します。 私は、現在のC ++の経験が標準以下であることにこれ以上同意できませんでした。 C ++エクスペリエンスを.NETのようにするためにかなりのことを行いましたが、 @ sylveonが述べたように、それらにはコストがかかります。 最終的に、C ++を優れたものにするためにエンジニアリングの努力を費やしたいのであれば、それをC ++標準の推進に注ぎ込むべきであると判断しました。 メタクラスが抜け道であるのは残念です。私たちはそれほど長く待つことができないことに同意するので、暫定的にエクスペリエンスを改善する方法について話し合っています。

回答ありがとうございます–私は「これはやらなければならないことだと誰もが知っている」と満足しており、1年ほど膨らんだバイナリで生きていきます。

@stevenbrixおよび@ VagueGit -msixパッケージにappinstallerファイルを引き続き使用できるはずです。 appinstallerファイルは、パッケージにURIを提供するjsonファイルにすぎません。 エンタープライズシナリオについて説明したので、appinstaller uriを内部の場所に合わせて適切にカスタマイズしたり、外部アクセス用に異なるものにしたりすることができます。これらはすべてCDNに依存します。 バージョニングについて-パッケージIDが同じであれば、パッケージ化されたアプリでは可能です。新しいバージョンをインストールすると、既存のアプリデータにアクセスできるようになります。

@ stevenbrix @ VagueGitウィザードのような経験で現在持っている情報を返信します。 私はまだこの役職に就いていないので、私が言うことはすべて一粒の塩で気軽に受け止めてください。 そうは言っても、私のチームは現在、 Windows TemplateStudioでの取り組みを推進してい

このアプリケーションの将来の目標と現在の計画は、すべてのユーザーの開発エクスペリエンスを統合して改善することです。 現在、WinUI 3を使用してデスクトップアプリ用のテンプレートを開発しています。追跡の問題については、こちらをご覧ください。 また、ユーザーが必要なときにプロジェクトを簡単に移行できるように、UWPでも同じことを行うことについても検討しています。 これがどのように機能するかはまだ正確にはわかりませんが、私たちの目標は、エクスペリエンスを可能な限り統合して簡素化することです。 お役に立てば幸いです。

同じことがCXでも起こっていました... C ++開発者はプロプライエタリ言語拡張を好まないため、ほとんど使用されていませんでした。

彼らはclang、GCC、Intelでそれらを愛しています。 xlCC、PGI、CUDA、C ++ Builder、および組み込みプラットフォームからの多数。

明らかに、CXは、MicrosoftからのC ++ RAD環境を受け入れることができない政治のために殺されました。むしろ、代わりにメモ帳のような経験でMDIL / ATLを実行するようになりました。

コンパイラーに関係なく、私はそれらを絶対に避けます。 特に、プロプライエタリ拡張機能がそれ自体で完全に異なる言語である場合は特にそうです。

コンパイラーに関係なく、私はそれらを絶対に避けます。 特に、プロプライエタリ拡張機能がそれ自体で完全に異なる言語である場合は特にそうです。

それなら、なぜWinUIのようなプロプライエタリUIに対してコーディングするのか、代わりにXWindowsのようなオープンスタンダードを使用するだけです。

...それがWindowsで使用できるかのように。 標準への準拠を検証するためにコンパイラ（ClangおよびMSVC）をマルチターゲットにし、新しいC ++標準を使用したいので、コンパイラ拡張は避けています。

私のコードはC ++ 20を使用しています。 多くの言語拡張機能はC ++ 17のサポートを欠いているか、非常に遅れています。 この状況はC ++ 20でも繰り返されます（または、C ++ 20には17よりもはるかに多くの新しいものがあるため悪化します）。 たとえば、C ++ 20（ /std:c++latest ）とCX（ /ZW ）を混在させることはできません。2つのスイッチに互換性がないというコンパイラエラーが発生します。

NVCCがデバイス側のC ++ 17をサポートするのに今年までかかりました。 見栄えが悪い。

私が使用している言語拡張機能が新しい標準では使用できないコーナーに身を置きたくありませんが、新しい標準機能も必要です。

上記の理由で、私はそれらを避けます。 WinUI C ++開発者エクスペリエンスを言語拡張に回帰する場合は、別のGUIフレームワークに移動します。

@sylveonWinUI用の完全に移植可能なC ++ 20は、Windowsの外ではまったく役に立たないので、拡張機能なしでQtを楽しんでください。

C ++デスクトップユーザーには他に使用する価値のあるものが何も残っていないからです。

無意味な政治がCXを殺したものであることを確認してくれてありがとう。

お互いに友好的であることの提案。 技術的なc ++の議論についてコメントすることはできず、誰が正しいかを判断することもできません。
重要なのは、 go have fun with Xようなフレーズは、ここでは友好的で協調的な雰囲気を設定していないということです。 @stevenbrixやその他の人は、必要に応じて参加してください。

ありがとう@ hansmbakker☺️

@pjmmと@sylveon情熱的で正直な会話に感謝します。あなたのような顧客が気にかけてくれるのは素晴らしいことです。

どちらの点も非常に有効であり、世界はあなたとあなたの両方が正しくなるのに十分な大きさだと思います。

@pjmlp c ++の現在の経験に満足しておらず、c ++メタクラスの前に何かをする必要があることを認識しています。 私たちは、IDL-フリーのC ++ / WinRTの、そして@kennykerrに関するいくつかの議論を持っていたし、Scottj1s @それについてのビルド話をしましたしました。 コンパイラにはメタデータが必要なため、発生した問題のほとんどはWinUIとの統合に関連していました。 このワークフローを再検討して、開発者の全体的なエクスペリエンスを向上させるまとまりのあるストーリーを作成できるかどうかを確認したいと思います。 C ++ / Cxを復活させる代わりに、idlフリーバージョンのc ++ / winrtに興味がありますか？

期待を設定するためだけに、2020年にここで大きな進展が見られるとは思いません。

IDLフリーのC ++ / WinRTに非常に興味があります。

IDEエクスペリエンスも最高ではありません。 たとえば、C＃の場合のようにXAMLエディターからイベントコールバックを作成することはできません（[新しいコールバックの作成]ドロップダウンは何もしません）。 XAMLエディターから定義へのナビゲートも機能しません。

その他の問題は、このリポジトリに入力したさまざまなXAMLコンパイラのバグです。これにより、サポートされている他の言語では必要とされない回避策が必要になります。

@ stevenbrix 、IDLフリーのC ++ / WinRTに自分の声を追加したいと思います（そして確かにC ++ / CXへの復帰を見たくありません）。 私たちはクロスプラットフォームソフトウェアを作成し、MSVCとLLVM（Windowsを含む）の両方でコンパイルするため、標準に準拠したC ++は私たちにとって非常に重要です。

@stevenbrix 、

@pjmlp c ++の現在の経験に満足しておらず、c ++メタクラスの前に何かをする必要があることを認識しています。 私たちは、IDL-フリーのC ++ / WinRTの、そして@kennykerrに関するいくつかの議論を持っていたし、Scottj1s @それについてのビルド話をしましたしました。 コンパイラにはメタデータが必要なため、発生した問題のほとんどはWinUIとの統合に関連していました。 このワークフローを再検討して、開発者の全体的なエクスペリエンスを向上させるまとまりのあるストーリーを作成できるかどうかを確認したいと思います。 C ++ / Cxを復活させる代わりに、idlフリーバージョンのc ++ / winrtに興味がありますか？

期待を設定するためだけに、2020年にここで大きな進展が見られるとは思いません。

これは、C ++ / WinRTのこのアイデア全体が最初からどれほど悪いものであったかを示しており、生産性の低下を考慮せずにそれを減らしていきます。

これを概観すると、Windows開発者の経験がWindows 3.0にまでさかのぼる長年の開発者であり、現在ではC ++は、単独ではなく、.NETベースのアプリケーションと一緒に使用することにほとんど関係があります。

ボーランドのツールは、昔のWindows開発者に知られているさまざまな理由で、Microsoftコンパイラに移行することで終わるまで、私のパンとバターでした。

Visual C ++は、FormsおよびAOTコンパイルとの統合がないため、C ++ / CLIを使用した場合でも、C ++ Builderとして_Visual_になることはありませんでした。

C ++ / CXは、Microsoftがついにそれを手に入れたようでした。25年後、Delphi / C ++ Builderを一緒に使用するのと同じ生産性ワークフローが与えられました。

代わりに、ISO C ++およびWG21の不足している機能の責任を負っている生産性の低下に関係なく、C ++ / CXを殺すための政治的動きとして得たものは、Visual C ++チームが私たちから奪っているすべてのものがWG21で承認されました。

そして、必要な機能が最終的にISO C ++に採用されるとしても、それは2023、2026、....でしょうか？ そして、これらの機能が実際にWindows開発者に利用可能になるのはいつかという全体的なポイントがあります。モジュールのサポートを見てください。 2012年にWindows8がリリースされて以来、C ++ / CXが提供してきたものと同等になるまで、私たちは無限の年月を費やしています。

2020年までに改善が見られないことを考えると、ここではすでに9年について話しているので、他の問題に加えて、これらすべてがどのように管理されているかに少し腹を立てる傾向がある場合は、すみません。 UWPの失敗、Reunion、.NETエコシステムの再起動に対処するために、2000年のように、必要最低限​​のMIDLメモ帳の経験とATLのような無限のテンプレートスープを使用してコーディングするように求められます。

そうです、IDLフリーのC ++ / WinRTバージョンか、少なくともIntellisense / Intelicodeを完全にサポートし、ファイルを手動でコピーする必要がないIDLエクスペリエンスのいずれかです。 ただし、それによってC ++コード自体からATLのような経験が失われることはありません。

.NET / C ++開発の観点からは、Microsoftフレームワークの過去へのタイムトラベルについては気にしません。むしろ、C ++ RADの観点をもっと真剣に受け止めた場合、残念ながらC ++ /の方法でどのように見えるかは気にしません。 WinRTストーリーは管理されており、UWPからのバックペダルで進行中の他のすべては、「開発者、開発者、開発者」がどこに行ったのだろうかと思います。

それでも少し不満を感じる場合は申し訳ありませんが、ほとんどのC ++コンパイラがとにかく実行しないISO純度の名の下に、.NETからC ++にステップアウトする必要があるときの生産性の低下について私はそう感じています。

C ++は、依然としてスタンドアロンで非常に重要です。 多くのアプリケーションは、マネージコードを実行せずに生のC ++で記述されています。 実際、UWPランタイムとXAML / WinUIフレームワーク全体はネイティブC ++です。 C ++で記述されたUWPアプリには、（ありがたいことに）管理言語は含まれていません。

.NETでC ++に移行する必要があると感じた場合は、その理由を自問し、.NET内で直接それらの問題に対処するようにしてください。 パフォーマンス？ スパンタイプ、stackalloc、およびベクトル組み込み関数を使用します。 DirectX、ネイティブAPI、またはCOM？ TerraFXのようなバインディングを使用します。 C ++のみのライブラリと対話しますか？ 必要なものを.NETで再実装します。

.NETはC ++なしの方が優れており、C ++は.NETなしの方が優れています。

cppwinrtでのテンプレート作成はそれほど悪いとは思いません。 私を最も悩ませているのは、コード生成の必要性とそれが生み出す恐ろしいコンパイル時間です。

@sylveon Easy、WindowsチームがUWPとして利用可能にすることを拒否し、サードパーティのバインディングがカウントされないため、ライセンスや将来のサポートの問題を考慮せずに、すべての人が何でも

Borland（現在のEmbarcadero）とQt Companyは、その方法を示しています。プラットフォームを維持するための関連性を決定するのはMicrosoftの責任です。

macOS、iOS、Android、ChromeOSGUIでISOC ++をどこまで使用できるか試してみてください。

とにかく、ここで停止すると、これは無意味です。

@pjmlp iOS / macOS / Windowsで問題なく動作する数百万行の
以前にC ++ / CLIを使用したことがありますが、これは非常に面倒です。 生のC ++ポインターのみを許可するクラスメンバーなどの制限により、スマートポインターの格納が困難になります。 コンパイル時間が長い（1文字​​の変更には5分のMDマージ時間が必要です）。
C ++には、マネージド/アンマネージドのプラグマを変更するためにラッピングが必要です。
コンパイラはC ++とは異なるバージョンのC ++ / CLIです（ビルド時に、C ++ / CLIコンパイラはC ++ 17以降をサポートしないと言われました。これは、C ++を使用するライブラリのヘッダーを含めるときに問題になります。 20の機能）。
私が言おうとしているのは、複数の競合する努力をしないことです。 標準に固執し、それで作業します。 MicrosoftはC ++委員会に所属しており、標準を前進させるのに役立ちます。これは、プロプライエタリではなく、拡張機能に固定された焦点である必要があります。

midl.exe、cl.exe、またはlink.exeと同様に、xamlファイルをコンパイルするためのxaml.exeなどのxamlコンパイラを使用できますか？ winuiアプリケーションの自動パイプラインを構築すると非常に便利です。

Visual Studioを使用して開発を行いたくない場合もあります。必要なエディターを使用する場合もありますが、ビルドパイプラインは分離したままにします。 winuiアプリケーションxamlは特別な部分のようで、それをコンパイルするためのコマンドラインツールはまだないようです。

これは、cmakeなどのシナリオに必要です： https ：

midl.exe、cl.exe、またはlink.exeと同様に、xamlファイルをコンパイルするためのxaml.exeなどのxamlコンパイラを使用できますか？ winuiアプリケーションの自動パイプラインを構築すると非常に便利です。

@ sammi ＃1433は、あなたが探しているものに対するもっともらしい解決策を要約していますか？

midl.exe、cl.exe、またはlink.exeと同様に、xamlファイルをコンパイルするためのxaml.exeなどのxamlコンパイラを使用できますか？ winuiアプリケーションの自動パイプラインを構築すると非常に便利です。

@ sammi ＃1433は、あなたが探しているものに対するもっともらしい解決策を要約していますか？

@jtbrower 、それはまさに私が探している機能です、ありがとう！

確かにそれはプレビューであり、それは私があまり期待するべきではないことを意味しますが、WinUI3プレビュー2は私にとってがっかりしました。

私の最大のニーズは、XAML設計の分野です。 XAMLデザイナーがまったく機能しなかったという事実にかなり驚かされました。これまでのところ、いつ機能するかについて明確な情報は見つかりませんでした。

はい、私はVisual Studioの現在のXAMLデザイナーが非常に遅いことに同意します。リアルタイムで変更すると、実際には壊れてはならないものが壊れます。 たとえば、 Height="*"を"Auto"または100に変更します（エラーウィンドウは約10個のエラーを吐き出します-たくさんの波線があり、プロジェクトを再構築する必要があります）

明確にするために、私は実際にはデザイナーを使用して設計していませんが、ビルドプロセスを実行する前に、レイアウトが想定していたように見えるかどうかを知りたいだけです。 簡単であれば、デザイナーが「表示のみ」で、XAMLを（クラッシュせずに）微調整すると更新された場合は、GUIを使用してXAMLを変更しないので、それで問題ありません。 。 実際、 WindowsCommunityToolkitがXAMLソースで実行することで、ユーザーがソースを変更し、出力をリアルタイムで確認できるようにすることは、私の目的には十分です。

とはいえ、WinUIには素晴らしいアイデアがあります。これらすべての「簡単な」ものをOSから切り離し、開発者の作業をより迅速に進化させ、依存関係をアプリにバンドルして、10億台のデバイスをアップグレードする必要をなくすことができます。彼らは私たちの新しい素晴らしいものを実行することができます。

Project Reunionでも、GUIがアプリコンテナから完全に分離されることを願っています。 サンドボックス/境界のないUWPのようなUXは、大きな前進となるでしょう。

しかし、いつ再び機能するXAMLデザイナーを手に入れることができますか...お願いしますか？

ホットリロードは、XAMLデザイナの「表示のみ」の目的をほとんど非推奨にしたと思います。

ただし、ここではWinUIツールについて説明しています。 ホットリロードとライブビジュアルツリーもWinUIでは機能しません。

ビューオンリーデザイナーで私が意味したのは、「これからのプレビューに入れることができるものであれば、それで解決できる」ということでした。

私は間違っている可能性があります（私が間違っている場合は教えてください）が、現時点では、WinUIでUIを表示する唯一の方法は、それをビルドして実行することです。

ただし、ここではWinUIツールについて説明しています。 ホットリロードとライブビジュアルツリーもWinUIでは機能しません。

ビューオンリーデザイナーで私が意味したのは、「これからのプレビューに入れることができるものであれば、それで解決できる」ということでした。

私は間違っている可能性があります（私が間違っている場合は教えてください）が、現時点では、WinUIでUIを表示する唯一の方法は、それをビルドして実行することです。

ねえ@ ericleigh007最新リリースのWinUI3プレビュー3をチェックする機会がありましたか？ 最近、IntelliSense、Hot Reload、Live Visual Tree、Live PropertyExplorerなどの多くのツールの改善を追加しました。 ここでリリースノートを確認し、ます。 ご意見をお待ちしておりますので、お気軽にご連絡ください！

@JeanRoca不幸にもC ++ / CX開発の経験に追いつくことは、それらのツールの改善の1つではありませんでした。 提案されたC ++ツールが2000に戻り、メモ帳でIDLファイルを書き込み（エディターのサポートなしで）、手動でファイルをコピーするように感じる場合、WinUIに対する開発者の愛情はあまり期待しないでください。

これにより、可能な限り.NETにとどまるか、C ++ / WinRTに移行するように警告されているにもかかわらずC ++ / CXを使い続けることができます。

更新していただきありがとうございます; 今日それを試みて、報告します。 🤞

メールから送信https://go.microsoft.com/fwlink/?LinkId=550986for Windows 10

投稿者：JeanRoca [email protected]
送信：2020年11月18日水曜日4:41 AM
宛先：microsoft / microsoft-ui-xaml [email protected]
Cc：Eric [email protected] ; 言及@ noreply.github.com
件名：Re：[microsoft / microsoft-ui-xaml] WinUI 3.0開発者の経験とツール-必要な入力（＃1045）

ただし、ここではWinUIツールについて説明しています。 ホットリロードとライブビジュアルツリーもWinUIでは機能しません。

ビューオンリーデザイナーで私が意味したのは、「これからのプレビューに入れることができるものであれば、それで解決できる」ということでした。

私は間違っている可能性があります（私が間違っている場合は教えてください）が、現時点では、WinUIでUIを表示する唯一の方法は、それをビルドして実行することです。

ねえ@ ericleigh007 https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fericleigh007&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df9e7fe9f640afb435 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0％3D％7C1000＆sdata = jha7IQJyg％2BKEZKwKvAkLEJfFG2SU 最近、IntelliSense、Hot Reload、Live Visual Tree、Live PropertyExplorerなどの多くのツールの改善を追加しました。 ここでリリースノートを確認できますhttps://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F3620&data=04%7C01% 7C％7Cae66199f9c044a728fb108d88b7c470d％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C637412713160082691％7CUnknown％7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0％3D％7C1000＆SDATA = 2jVKkAs9Whd6U9kH1ZxJKy956wI6Itg7jq6lCuaqEgE％3D＆予約= 0 、ここで最新のプレビューを取得https://eur05.safelinks.protection.outlook.com/?url=https%図3A％2F％2Fdocs.microsoft.com％2Fen米国％2Fwindows％2Fapps％2Fwinui％2Fwinui3％2F＆データ= 04パーセント7C01％7C％7Cae66199f9c044a728fb108d88b7c470d％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C637412713160092685％7CUnknown％7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0％3D％7C1000＆SDATA = VF2s7jilqpksevP6Fx7mXW1QCNJN2％ 2BK5yWOndg3rKoc％3D＆reserved = 0 。 ご意見をお待ちしておりますので、お気軽にご連絡ください！

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してくださいhttps://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F1045%23issuecomment -729402012＆データ= 04パーセント7C01％7C％7Cae66199f9c044a728fb108d88b7c470d％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C637412713160092685％7CUnknown％7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0％3D％7C1000＆SDATA = R1S2JpfBSzsNKJBAH5％2Fgme8Bq％2FjHbzB9FySk1KnZKbk％3D＆0 =予約済み、または解除HTTPS：//eur05.safelinks.protection.outlook .COM /？URL = HTTPS％3A％2F％2Fgithub.com％2Fnotifications％2Funsubscribe-AUTH％2FABX3S2XLYXYXP7BZZC3OE73SQNGBFANCNFSM4ICOLUJQ＆データ= 04パーセント7C01％7C％7Cae66199f9c044a728fb108d88b7c470d％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C637412713160102680％7CUnknown％7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0％3D％7C1000＆SDATA = 0H6IpND3YX1s6oyXy％ 2FCXNAMN9n8fvSPdWks％2FfmXT0Bc％3D＆reserved = 0 。

-現在、winui3 c ++（デスクトップ）で動作するwysiwygエディター/メソッドはありませんよね？

MicrosoftはC ++ / CXユーザーも疎外することに成功していますか？ このすべてがうまく形作られていません。 マイクロソフトが数年前にUWPにプッシュしていたテクノロジを採用した人は誰でも、.netまたはc ++のどちらが、マイクロソフトのサポートなしで問題を抱えているのかを問わず。

WinUI 3はWPFで記述されたデスクトップアプリのみを対象としているようですが、UWPにはWPFのすべての機能がなく、WinUIの機能がまだ少ないことにすぐに気付くでしょう。 WinUI 3を開始するのに悪い場所であるため、誰もがイライラするでしょう。

@robloo UWPを提唱していた人が私を失ったので、混乱を解決するまではWPFとWin32です。

C ++ / WinRTは政治的な動きであり、VisualStudioチームがC ++ / CXエクスペリエンスを複製するために、ISO C ++が最終的にリフレクションとメタクラスのサポートを提供するまで待つように言われました。

前述のように、IDLファイルの編集でさえ、生のメモ帳を使用するのと同じです。

.NETで私たちがすべてのUWPコンポーネントを利用できるようにしないことをマイクロソフトに我慢しなければならなかったことは、C ++ / CLIのようなエクスペリエンスを提供するC ++ / CXではどういうわけか耐えられませんでした。 C ++ / WinRTで、ATLに戻ります。

次に、Reunionの問題に関するディスカッションと更新のロードマップを読むと、コースを修正するのに数年かかることは明らかです。

WPFとWin32は古い可能性がありますが、これらはここにあり、機能します。さらに書き直したり、機能を失ったりすることはありません。

-現在、winui3 c ++（デスクトップ）で動作するwysiwygエディター/メソッドはありませんよね？

XAMLデザイナーは一種の作品ですが、そもそもwysiwyg編集用に設計されたものではありませんでした。 ホットリロード（プレビュー3で機能するようになりました）がより適切に機能します。

ライブビジュアルツリーとライブプロップビューはプレビュー3でうまく機能します。デザイナーはいつ利用可能になる予定ですか？

また、デスクトップ（WPF）（UWPではない）デザイナーが2.4（または何か）で動作していたことにも気づきましたが、今では私のテストでは再び動作していませんか？ デザイナーの現在の状態で何かが足りないのですか？

パーティーに遅れてすみません。 @wjkは彼の最初のポイントでそれを釘付けにしました。

1. MSIXはすべて問題なく動作しますが、MSIXがサポートしていない機能を必要とする、より複雑なアプリケーションをインストールするために、古き良きMSIを使用しています。 また、必要なAuthenticode証明書が非常に高価であるため、MSIXを使用するのは気が進まない。

MSIXの魅力に本当に感謝していますが、この証明書署名の義務は私にとって取引を妨げるものです。 従来のデスクトップインストーラーエクスペリエンスを作成するために使用できる、適切なSCM対応のインストーラーウィザードが必要です。 MSIXの改善点を取り入れて、Microsoft Storeや認定要件なしで新しいバージョンのMSIインストーラーを作成して、より最新の開発エクスペリエンスを実現してみませんか？ おそらくこれは、現在のロードマップにリストされている「非MSIX展開をサポートする」機能が意味するものですか？ もしそうなら、私は3.xを待って立ち往生していると思います。ただし、何らかの奇跡がない限り、それは以前のリリースになります。 VSインストーラープロジェクトは悲劇的に時代遅れであり、ソース管理にまったく友好的ではないので、それを楽しみにしています。 😓

@Chiramisu私は感情に同意しますが、私も混乱しています-サイドローディングの経験とAppInstallerは十分ではありませんか？

@Chiramisu WiXを試したことはありますか？ 私はすべてのMSIベースのインストーラーに使用しており、非常にうまく機能します。 Visual Studio拡張機能もあるので、さまざまなコンパイルコマンドを自動化するWiXプロジェクトを作成できます。

@robloo UWPを提唱していた人が私を失ったので、混乱を解決するまではWPFとWin32です。

C ++ / WinRTは政治的な動きであり、VisualStudioチームがC ++ / CXエクスペリエンスを複製するために、ISO C ++が最終的にリフレクションとメタクラスのサポートを提供するまで待つように言われました。

前述のように、IDLファイルの編集でさえ、生のメモ帳を使用するのと同じです。

.NETで私たちがすべてのUWPコンポーネントを利用できるようにしないことをマイクロソフトに我慢しなければならなかったことは、C ++ / CLIのようなエクスペリエンスを提供するC ++ / CXではどういうわけか耐えられませんでした。 C ++ / WinRTで、ATLに戻ります。

次に、Reunionの問題に関するディスカッションと更新のロードマップを読むと、コースを修正するのに数年かかることは明らかです。

WPFとWin32は古い可能性がありますが、これらはここにあり、機能します。さらに書き直したり、機能を失ったりすることはありません。

ちょうど私が追いつくことができるように、あなたがC ++ / WinRTで話しているIDL編集の1つで私を手がかりにできますか？ co_awaitやその他のC ++ 17構文について私が見たところ、C ++ / CXから複雑さが大幅に高まったようです。

MS？ 誰かがその周りに本当に良いラッパーを作成しない限り、C ++ 17機能に基づくC ++ / WinRTが複雑すぎて、現在の設計とは異なりすぎる可能性はありませんか？ C ++ / WinRTの使用と移行を合理的に簡単にするために、C ++ 17用にいくつかの「優れたラッパー」を作成するのに十分なC ++ / CXを維持できませんでしたか？

（今、誰か​​がこれがどのように行われるかを示す記事にリンクするつもりです、そして私は愚かだと感じるでしょう）

@lmcdougaldまだ試していません。 私の特定のプロジェクトはまだ.NETFramework3.5上にあることに注意してください。 分かった分かった。 私はまだそれを更新することを許可されていないので、インストーラー技術がこの古代のフレームワークでどのように機能するかで立ち往生しています。 😖

@wjk過去に調べたことがありますが、まだ試していません。 上記のことを考えると、それは私の既存のプロジェクトで機能する可能性のある唯一の技術のようです。 万が一、古いフレームワークをベースにしたWinFormsアプリでこれを使用したことがありますか？ 残念ながら、私は孤独な開発者なので、自分の時間をどのように使うかについて極端な偏見を持たなければならず、新しいテクノロジーを試す自由がありません。

親切に

@Chiramisuはい、WiXは古いバージョンの.NET Frameworkで動作します。また、はい、 基本的なチュートリアルから始めます。 また、.NETがインストールされているWiXを使用してファイルに対してNGENを

@Chiramisu探しているものにとても混乱しています。WinUI3.0プロジェクトではなく、現在のプロジェクト用のパッケージツールを探しているようです。

.NET Framework3.5をMSIXにパッケージ化できることは注目に値します。 VS 2019のパッケージプロジェクトを使用して既存のアプリのMSIXパッケージを構築し、長い移行をいくらかシームレスに実行することもできますが、それは多くの作業です。

WinUI3.0は.NET3.5を公式にサポートすることはなく、おそらくどのバージョンでも.NETFrameworkをサポートすることはありません。 既存のパッケージプロジェクトを変更せずに、.NET 4.6（または理想的にはより高い4.8が理想的）へのアップグレードを目指すことから、モダナイゼーションを開始します。 それが順調に進んだら、更新された.NET4.6以降のアプリから参照する.NETStandard共有ライブラリに機能を移行し始めます。

.NET 4.6アプリが安定してテストされたら、MSIXパッケージプロジェクトの自動更新としてスワップインできます。 .NET Standardの手順の後、.NET Core 3.1（または5）とほぼ同じコードを使用するプロジェクトヘッドを作成できますが、LTSステータスはおそらく組織にとって何かを意味しているように感じます。 繰り返しますが、テストしてから、MSIXをこのバージョンを使用するように切り替えます。

その時点でWinFormsからWinUIに切り替えるには、WinUIを学習し、インターフェイスを再実装する必要があります。 ここでも、新しいプロジェクトヘッドを作成し、.NET標準ライブラリを実装して参照し、テストしてから、このバージョンを使用するようにパッケージを切り替えます。

これが、どの時点でも大きく異なるプロジェクトを作成せずに近代化に取り組む方法です。 MSIXパッケージと.NET4.6 + .NET標準の手順を優先的に設定します。これらの手順を使用すると、ヘルプツールと最新の.NET開発サイクルへの接続が大幅に増えます。 .NET 3.5が存在する限りそのライフサイクルが1/10であることを考えると、急いで.NET 5に切り替えることは、短期的には組織にとって悪い考えのように思えます。

ちょうど私が追いつくことができるように、あなたがC ++ / WinRTで話しているIDL編集の1つで私を手がかりにできますか？ co_awaitやその他のC ++ 17構文について私が見たところ、C ++ / CXから複雑さが大幅に高まったようです。

MS？ 誰かがその周りに本当に良いラッパーを作成しない限り、C ++ 17機能に基づくC ++ / WinRTが複雑すぎて、現在の設計とは異なりすぎる可能性はありませんか？ C ++ / WinRTの使用と移行を合理的に簡単にするために、C ++ 17用にいくつかの「優れたラッパー」を作成するのに十分なC ++ / CXを維持できませんでしたか？

（今、誰か​​がこれがどのように行われるかを示す記事にリンクするつもりです、そして私は愚かだと感じるでしょう）

通常のC ++には、.winmdファイルの作成に必要な型メタデータを抽出する機能がないため、WinRTクラスを.hppおよび.cppの上に.idlファイルで記述する必要があります。

co_awaitは、どこにでも.then([=](Foo^ thing) { })書くよりもはるかに複雑ではなく、C＃のawait構文と非常によく似ています。

デフォルトのランタイムコンポーネントプロジェクトの例（idl + hpp + cpp）を次に示します。

namespace RuntimeComponent6
{
    runtimeclass Class
    {
        Class();
        Int32 MyProperty;
    }
}

#pragma once

#include "Class.g.h"

namespace winrt::RuntimeComponent6::implementation
{
    struct Class : ClassT<Class>
    {
        Class() = default;

        int32_t MyProperty();
        void MyProperty(int32_t value);
    };
}

namespace winrt::RuntimeComponent6::factory_implementation
{
    struct Class : ClassT<Class, implementation::Class>
    {
    };
}

#include "pch.h"
#include "Class.h"
#include "Class.g.cpp"

namespace winrt::RuntimeComponent6::implementation
{
    int32_t Class::MyProperty()
    {
        throw hresult_not_implemented();
    }

    void Class::MyProperty(int32_t /* value */)
    {
        throw hresult_not_implemented();
    }
}

これが小さなco_awaitの例です：

void PrintFeed(SyndicationFeed const& syndicationFeed)
{
    for (SyndicationItem const& syndicationItem : syndicationFeed.Items())
    {
        std::wcout << syndicationItem.Title().Text().c_str() << std::endl;
    }
}

IAsyncAction ProcessFeedAsync()
{
    Uri rssFeedUri{ L"https://blogs.windows.com/feed" };
    SyndicationClient syndicationClient;
    SyndicationFeed syndicationFeed = co_await syndicationClient.RetrieveFeedAsync(rssFeedUri);
    PrintFeed(syndicationFeed);
}

やあ、

私たちはあなたのフィードバックを読み、問題点についてメモを取っています。

@ ericleigh007 XAML Designerは、顧客からのフィードバックを収集した後、開発者の内部ループを改善することが顧客のリリースされました。 ホットリロードとライブビジュアルツリーが一番上にありました。 アプリ内ツールバーは、プレビュー3を作成できなかったもう1つの機能です。XAMLデザイナーがいつになるかが明確ではないことは間違いありません。 機能ロードマップの考え方を更新する必要があります。 現在のエンジニアリング計画によると、3.0 RTMから外れているため、3.0以降です。

@pjmlp C ++ / WinRTとIDLを追加する必要性についてのあなたのペイントに共感します。 この点では、C ++ / CXの方がはるかに優れています。 C ++ / WinRTエクスペリエンスの改善は、対処する必要のあるもう1つのトピックです。 Live VisualTreeやHotReloadなどのツールはC＃とC ++の両方で機能しますが、C ++にのみ影響し、取り組む必要のある特定のものがあります。 現在のエンジニアリング計画によると、IDLの問題の解決は3.0RTMの範囲外です。

@ robloo 、WPFで記述されたデスクトップアプリには対応していません。 C ++ / WinRTは、WinUIエコシステムの最初の市民です。 これは私たちがWinUIを作成するために使用するものであるため、適切なツールと言語をドッグフーディングしています。

@Chiramisu 「MSIX以外の展開をサポートする」とはどういう意味か説明します。 今日は、MSIXを使用してDesktop WinUI3アプリをインストールして実行する必要があります。 この機能は、この必要性を取り除くことです。 デスクトップWinUI3アプリを実行するには、.EXEを2倍にするだけで済みます。 アプリをインストールするには、xcopyを実行するだけです（何も署名する必要はありません）。 基本的に、WiXのような他のパッケージングおよびインストールシステムを使用することができます。

@ marb2000問題を認識していただきありがとうございます。 私や他の多くのWindows開発者が得られないのは、（WinDev管理のように）C ++ / WinRTを劣ったツールでブルートフォース攻撃するのは良い考えだと判断した理由です。少なくとも、MFCに戻っても気分は良くなります。手動でファイルをコピーしないでください。

現在、私はASP.NET、WFP、Win32に焦点を当てていますが、UAP => UWPのように、アプリケーションの書き換えにうんざりして手動構成に引きずり込まれていることにMicrosoftが最終的に気付くことを期待して、UWP関連のフォローアップを続けています。移行、.NETFrameworkから.NETCore、またははいC ++ / CX => C ++ / WinRT。

これは、Windows 8の導入以来、継続的な書き直しに少しがっかりしているWindows開発コミュニティの声のメンバーとしてのフィードバックのようなものです。

@pjmlp WindowsAPIの（標準準拠の）C ++ラッパーであるC ++ / WinRTを批判している理由が

@pjmlp WindowsAPIの（標準準拠の）C ++ラッパーであるC ++ / WinRTを批判している理由が

それがまさに問題であり、ツールのサポートがゼロであるのに対し、VisualStudioでのC ++ / CXの開発経験はありません。

IDLファイルの編集サポートはなく、構文の強調表示も、インテリセンスは言うまでもありません。 そして、生成された翻訳単位を手動でコピーまたはマージするように指示されます。

これは、当時ATLを行っていたようなものです。

ISO C ++の互換性は気にしません。とにかく、UWPはWindowsのみであり、言語拡張のないC ++コンパイラはありません。

WRLの唯一のユーザーであったWinDevの人たちを除いて、誰もがこれを進歩として見ることができる方法を私は見ていません。

@pjmlp 、

ISO C ++の互換性は気にしません。とにかく、UWPはWindowsのみであり、言語拡張のないC ++コンパイラはありません。

大規模なC ++クロスプラットフォームアプリケーションを作成する私たちにとって、標準に準拠することは重要です。 C ++ / CXの制限はひどいものでした（生のポインター、ハットではないメンバー変数はありません！（ ^ ）など）。 現在、大規模なC ++ / CLI相互運用ライブラリがあり、問題点が多すぎてリストできません。

IDLファイルの編集サポートはなく、構文の強調表示も、インテリセンスは言うまでもありません。 そして、生成された翻訳単位を手動でコピーまたはマージするように指示されます。

繰り返しますが、C ++ / WinRTとツールを混同しています。 それらは2つの別々のものです。 C ++ / WinRTは、WinRTAPIのC ++ラッパーです。 IDLはコード生成用であり、ええ、私はそれがひどいことに同意します、それは私がそれを使用しないほどひどいです。

私はWindowsのみのアプリを作成していますが、MSVCが失敗した場合に別のコンパイラを使用できるため、標準への準拠に引き続き関心があります。

@MarkIngramUK

繰り返しますが、C ++ / WinRTとツールを混同しています。 それらは2つの別々のものです。 C ++ / WinRTは、WinRTAPIのC ++ラッパーです。 IDLはコード生成用であり、ええ、私はそれがひどいことに同意します、それは私がそれを使用しないほどひどいです。

私はMS-DOS3.3からMicrosoftプラットフォーム用にコーディングしており、1992年にTurbo C ++ 1.0を使用してツールボックスにC ++を追加し、C ++開発に関係するBorlandおよびMicrosoft製品のほとんどを使用しています。 C ++ / WinRTについての講義は必要ありません。

間違いなくそうではないのは、C ++ BuilderとQt（Qt Designerを使用）の開発者の経験との一致であり、C ++ / CXは25年後に最終的に追いつくという約束を示しました。

しかし、明らかにここのほとんどの人はATL3.0を備えたVisualC ++ 6.0を望んでおり、残りの人は.NET 5、WPF、およびWin32デスクトップエクスペリエンスに固執する必要があります。それがそうであったように押されました。

正直なところ、C ++ / WinRTは現在ほぼ4年経過しており、Microsoftは構文の強調表示やインテリセンスのサポートすら提供できませんでしたか？

私たちの何人かがNotepad ++（構文の強調表示）で作成したもの、本当に？

それは間違いなく優先順位がどこにあるかを示しており、WinUIが採用されるのはこの方法ではなく、Windows8以降の書き直しが多すぎます。

@pjmlp 、繰り返しますが、あなたは間違ったことについて話しているのです。 C ++ / WinRTは単なるC ++であるため、構文の強調表示があり、インテリセンスがサポートされています。 あなたが持っている他のC ++コードとまったく同じです。

IDL構文の強調表示や、IDLから.hppおよび.cppでデフォルトの実装を作成することを提案するようなもの（現在、ヘッダーに定義なしで宣言された関数が緑色の波線でプロンプトを表示する方法など）のように、IDE統合の方が優れている可能性があります。 1つ作成します）が、C ++ / CXに戻ると、正味のダウングレードIMOになります。 使用するすべてのライブラリと共有コードをC ++ / CXと統合し、プロジェクトをC ++ 20からC ++ 17にダウングレードする必要があります（あきらめたくないのですが、20私にあまりにも多くの良いものを与えます）。

また、プログラムがWinRTクラスを作成するのではなく、消費するだけの場合、C ++ / WinRTはC ++ / CXよりもはるかに邪魔になりません。

QtとC ++ Builderは、ほとんどが標準に準拠したC ++での経験を実現しています（QtにはQt MOCという名前のIDLに似たものがあることに注意してください）。 これらが可能であれば、VSも可能です。 DevDivの誰かからのより多くの愛が必要です。

また、前に@sylveonで述べたように、他のコンパイラーで自由にビルドできます（現在、MSVCとClang / LLVMでビルドしています）。 C ++ / CXまたは他のMS拡張機能では、これは不可能です。

@MarkIngramUKと@sylveon

私はこのスレッドを終了しました。WinUI開発者のエクスペリエンスとツールを改善するために私のようなフィードバックが歓迎されないことは明らかです。

標準に準拠したC ++ / WinRTをお楽しみください。

これを編集して、「ケータリングなし」というタイプミスを修正できますか。

@pjmlp私はあなたが何を意味するのかを正確に理解していると思います。

1年ほど前、UWP C ++ / CXコードをC ++ / WinRTに移植するというアイデアを放棄しました。 MSVC ++には約18か月前に報告したバグが含まれているため、移植の動機はClangを使用してUWPアプリをコンパイルできるようにすることでしたが、修正には関心がないようです。

ただし、VisualStudioはClangを使用したUWPアプリの構築をサポートしていないことが判明しました。 すばらしいので、C ++ / WinRTの「ISOC ++のみ」の利点はすぐに利用できました。 これに加えて、C ++ / WinRTを介してC ++ / CXコードベースを移植することは、20年前に旅行するようなものです。

私は基本的に、Android / iOSアプリのWindowsへの移植をあきらめました。 私たちのような小さな店が、Android / iOS向けの開発に加えて、Windowsアプリの開発であるclusterfuckに対処することは単純に現実的ではありません。

@MarkIngramUKツールが非常に重要であるという点を

さて、私の暴言の後、ここに私の入力があります：

WinUI3とC ++ / CXの使用をサポートします。 C ++ / WinRTのツールが、独自のツールを構築するためのリソースを持っていない企業に受け入れられたら、C ++ / WinRTに切り替えても問題ないかもしれません。 今では絶対にそうではありません。

@pjmlp私はあなたが何を意味するのかを正確に理解していると思います。

1年ほど前、UWP C ++ / CXコードをC ++ / WinRTに移植するというアイデアを放棄しました。 MSVC ++には約18か月前に報告したバグが含まれているため、移植の動機はClangを使用してUWPアプリをコンパイルできるようにすることでしたが、修正には関心がないようです。

ただし、VisualStudioはClangを使用したUWPアプリの構築をサポートしていないことが判明しました。 すばらしいので、C ++ / WinRTの「ISOC ++のみ」の利点はすぐに利用できました。 これに加えて、C ++ / WinRTを介してC ++ / CXコードベースを移植することは、20年前に旅行するようなものです。

私は基本的に、Android / iOSアプリのWindowsへの移植をあきらめました。 私たちのような小さな店が、Android / iOS向けの開発に加えて、Windowsアプリの開発であるclusterfuckに対処することは単純に現実的ではありません。

@MarkIngramUKツールが非常に重要であるという点を

さて、私の暴言の後、ここに私の入力があります：

WinUI3とC ++ / CXの使用をサポートします。 C ++ / WinRTのツールが、独自のツールを構築するためのリソースを持っていない企業に受け入れられたら、C ++ / WinRTに切り替えても問題ないかもしれません。 今では絶対にそうではありません。

好奇心から、18か月前に報告されたバグは何でしたか？ どこかにリンクはありますか？

こんにちはミゲル、
___ Outlook forAndroidから返信した後のひどい状態を修正するために編集___

WinrtプラットフォームがWINUIの開発に使用しているものであるとおっしゃっていたので、プレビューとリリースの目標を明確にするかもしれないという考えがありました。

この記事を読んでください。IDLがファイルを書き込んだり手動でコピーしたりする場合はたくさんのことを呼びかけ、ツールで取り組んでいる状態と一致するように変更します。

https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/binding-property

ここにいない場合は、おそらくどこかでそれについて話し合うことができます。

ちなみに、XAMLデザイナー、特にXAMLスタジオのような存在するツールについて私は確信しています。 （コードビハインドをロードして、 IValueConverterを使用するXAMLを正常にロードできる場合のみ...

以前の投稿で述べたように、C ++ / WinRTのC ++ 17標準準拠自体は、MicrosoftのVisual C ++コンパイラでコンパイルする必要があるため、ほとんどの場合、C ++ / CXコードベースをC ++ / WinRTに移行するインセンティブはありません。とりあえず。 完全に変更されるコンパイラを切り替えることができれば。

ただし、Visual Studioは、Windowsランタイムコンポーネント用のコンパイラの切り替えをサポートしていません。 これがサポートされていない理由は私には謎です。特に、このブログ投稿で概説されて

Clangを使用して、AndroidおよびiOS用のコードベースをコンパイルしています。 Clangを使用してWindows用のコードベースをコンパイルできることは、実際にはC ++ / CXから移行する非常に良い理由です。 そのためのVisualStudio機能の要求は既に存在しますが、VisualStudioチームはこれまで何も行っていません。

C ++標準に準拠しており、デスクトップアプリ用のVisualStudioでClangをサポートしています。 したがって、最後のステップを実行し、WindowsランタイムコンポーネントのClangサポートを提供することにより、C ++ / CXから移行する本当の理由を提供してください。

標準への準拠は消費者にとって有用です-あなたが言うように、プロデューサーはMSVCに固執しています。 プロパティCLToolExeを.vcxprojファイルのclang-clへのパスに設定することで、 clang-clを「強制」する方法があります（これは

XAMLおよびC ++ / WinRTプロデューサーツールがデスクトッププロジェクトでロック解除されると、それも私にとってはそれほど問題にはなりません。

@ackh Clang11でビルドするUWPプロジェクトを入手しました。

これが私がしたことです：

• プロジェクトをアンロードし、 <Project>下の最初のディレクティブとして次のディレクティブを追加します

  <PropertyGroup>
    <CLToolExe>C:\Program Files\LLVM\bin\clang-cl.exe</CLToolExe>
  </PropertyGroup>

• <AdditionalOptions>%(AdditionalOptions) /bigobj</AdditionalOptions>を<AdditionalOptions>%(AdditionalOptions) /bigobj -Xclang -std=c++20 -mcx16</AdditionalOptions>置き換えます
• <PreprocessorDefinitions>WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions>を<PreprocessorDefinitions>_SILENCE_CLANG_COROUTINE_MESSAGE;WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions>置き換えます
• このすぐ下に<ModuleOutputFile />追加します
• プロジェクトをリロードします
• 建てる

ただし、いくつかの落とし穴があります。

• 未使用の引数に関するいくつかの警告が支持されます。おそらく、未使用の引数を変更/削除することでそれらを修正できます。
• 何らかの理由で、Clangは64ビットのオブジェクトファイルを32ビットで出力します。CLIに-m32を追加するだけでよい場合があります。
• Clangはまだコルーチンを完全に実装していないため、コルーチンを使用することはできません。
• VSは、アプリを実行するたびに、インクリメンタルやパラレルではなく、完全なシングルスレッドの再構築を行います。

https://github.com/microsoft/ProjectReunionで問題を開いて、これに注意を向けることをお勧めし

@sylveonこれらの指示を投稿してくれてありがとう。 いつかこれを試してみますが、VisualStudioがいつかこれをすぐにサポートすることを願っています。