Mungkin hal yang jauh, tetapi Blend perlu dirombak dan membutuhkan alur kerja yang berfokus pada desain.

Desainer XAML harus kuat, dan kuat.

Beberapa cara untuk memvisualisasikan struktur berlapis halaman/jendela, terutama penting dengan kontrol yang ditinggikan.

Cara untuk memvisualisasikan elemen UI di luar halaman, seperti kontrol/templat individual.

Kustomisasi kontrol tampilan yang dibuat untuk CoreOS, "Surface Phone", Surface Hub, Xbox, HoloLens, semua dalam desainer.

Desainer gabungan untuk XAML dicampur dengan WinForms, WPF, MFC, dan semua Kerangka kerja lain yang akan digunakan oleh Desktop WinUI.

Cara yang baik untuk mengimpor dan mengekspor XAML, sehingga desainer dapat bekerja di Blend yang diisolasi dari aplikasi utama, dan kemudian menyerahkannya ke tim pengembangan untuk dibawa ke dalam aplikasi.

Visualisasi dan daftar sumber daya sistem yang lebih baik, serta cara hebat untuk mengeluarkan sumber daya global yang dapat ditata ringan untuk mengesampingkan default, dan permukaan desain mencerminkan perubahan tersebut secara real time.

Cara yang lebih baik untuk menguji penskalaan DPI yang berbeda dengan aplikasi yang melibatkan WinForms, MFC, dll.

Template untuk kontrol baru, kamus sumber daya tema yang disesuaikan, mengintegrasikan Editor Tema Lancar, template untuk kombinasi aplikasi yang didukung (Win32 MFC dengan Xaml UI, dll).

Template untuk titik integrasi shell, seperti pemetik file, flyout baki tugas.

Itu hanya beberapa pemikiran ...

Pikiran saya adalah sebagai berikut:

1. MSIX semuanya baik dan bagus, tetapi saya masih menggunakan MSI lama yang bagus untuk menginstal aplikasi yang lebih kompleks yang memerlukan fitur yang tidak didukung MSIX. Saya juga ragu untuk menggunakan MSIX karena betapa mahalnya sertifikat Authenticode yang diperlukan. (Saya dapat dengan mudah menandatangani kode saya dengan sertifikat yang ditandatangani sendiri, yang saya yakini sama amannya dengan yang saya beli dari perusahaan, tetapi kemudian Windows tidak akan memuatnya. Windows akan dengan senang hati menerima file MSI yang ditandatangani sendiri, namun .) Selama saya bisa menggunakan WinUI 3 dari aplikasi berbasis MSI, saya senang.
2. Desainer XAML yang lebih baik akan sangat dihargai, tetapi saya tidak memerlukan kerumitan tambahan untuk mengintegrasikan desainer WinUI XAML dan WinForms/WPF menjadi satu. Saya baik-baik saja dengan flip-flopping di antara tab yang berbeda di VS.
3. Seperti yang saya komentari sebelumnya , memisahkan kompiler XBF dari sistem proyek C# dan Visual Basic akan sangat berguna. (Akan lebih baik jika sumber kompiler XBF, atau dokumentasi yang cukup untuk membuatnya kembali, dirilis, tetapi saya tidak tahu seberapa besar kemungkinan itu terjadi.)
4. Dukungan yang lebih baik untuk C++/WinRT dan MIDL 3 dalam sistem proyek C++. Saat ini, dukungan proyek untuk menggunakan C++/WinRT rapuh dan kikuk. (Misalnya, jika Anda mengubah namespace di file IDL — yang sering diperlukan jika ada titik dalam nama proyek yang ingin Anda gunakan di namespace, karena templat mengonversinya menjadi garis bawah secara otomatis — proyek Anda akan gagal dikompilasi , dan untuk memperbaiki masalah menurut pengalaman saya, file *.h dan *.cpp harus dipindahkan ke samping, membuat ulang dari awal, menyalin kode, lalu membongkar dan mengedit file vcxproj untuk memperbaiki sarangnya.) Sebanyak saya ingin menggunakan sesuatu yang lebih modern dan fleksibel daripada vcxproj, saya tidak dapat melakukannya karena ketergantungan keras yang dimiliki kompiler XBF.

Kalau ada yang lain, pasti saya posting di sini. Terima kasih!

1. Apa yang saya ingin tahu di sini, adalah... Yah, apakah saya perlu menggunakan awalan namespace seperti < winui:Listview atau < controls:listview atau apa pun yang diputuskan oleh pengembang? Saya pikir akan jauh lebih baik, jika mungkin, menggunakan pengalaman yang sama seperti sekarang, hanya Awalan tidak apa-apa, dan luar biasa, hanya untuk beberapa kontrol. Tetapi ketika Anda mulai menggunakan di semua tempat, ini membuat XAML membaca mimpi buruk dan sangat.
   Tidak masuk akal untuk menggunakan awalan namespace, karena tidak mungkin menggunakan Windows.UI.Xaml.Controls dan karena WinUI akan menjadi pilihan default.

2. Saat ini saya bahkan tidak menggunakan desainer XAML. Saya benar-benar menonaktifkan dalam pengaturan. XAML Designer lamban, dan membutuhkan dukungan yang lebih baik. Itu bagus untuk WPF, tetapi tidak untuk UWP, khususnya jika Anda ingin melakukan desain responsif, menangani halaman, menampilkan data, dll.
   Ini mungkin umpan balik untuk masa depan yang jauh, tetapi saya pikir umpan balik yang baik untuk dilihat. Desainer WPF jauh lebih cepat.
   Apakah ini karena kotak pasir atau apa?

3. Akan menarik alat untuk melakukan migrasi. Terutama karena mungkin memiliki beberapa masalah kompatibilitas dengan kontrol WinUI 3.0 yang diperbarui, seperti ScrollViewer. Jadi jika ada alat, setidaknya perlu menunjukkan kemungkinan peringatan pada kontrol yang diperbarui/ditulis ulang ini.

1. Kami membutuhkan editor kode xaml yang kuat dengan IntelliSense yang terpisah dari desainer.
   Sebagian besar waktu saya hanya menulis kode xaml seperti C#. Saat ini, editor kode lambat dan rapuh, dijelaskan dalam komentar saya sebelumnya . Pengalaman IntelliSense juga cukup sederhana. Tidak ada info dokumentasi cepat, tidak ada penggantian nama anggota.
2. Dukungan data desain untuk x:Bind mungkin cukup sulit, karena saya sedang menulis pembantu yang kompleks di binding fungsi. Tetapi segalanya bisa lebih baik jika fungsi bawaan xaml dapat menggantikan beberapa pembantu.
3. Saya ingin lebih banyak kombinasi model kemasan gratis untuk aplikasi saya. Mungkin di luar topik, tetapi saya tidak dapat menemukan tempat untuk memberi masukan kepada tim model aplikasi.

TL;DR Saya ingin model aplikasi mendukung co-existance arbitary instance . Bahkan versi yang sama dapat berjalan dengan kumpulan data/opsi yang berbeda, seperti kumpulan Visual Studio. Saat ini satu-satunya solusi tampaknya adalah xcopy.

Adakah yang bisa memberi tahu saya cara meruntuhkan ini?

Pertama, saya juga menggunakan aplikasi yang saya kembangkan setiap hari (dan menggunakan>> debug hampir setiap hari). Jadi membuat dev build berdampingan dengan stable build akan banyak membantu saya. Saat ini saya harus menambah nomor versi, mengemas msix debug, memperbarui versi paket yang diinstal ke debug.
Selama fase debug yang berbeda, saya akan menginginkan kemampuan yang berbeda. Untuk data dunia nyata yang kompleks, saya ingin instance debug membagikan data dengan yang stabil. Untuk data palsu yang sewenang-wenang, saya ingin isolasi. Ini secara teoritis diselesaikan dengan mengakses data menggunakan pemilih folder, tetapi sangat disayangkan bahwa SQLite di UWP tidak mendukung itu, dan tidak ada mesin ACID tertanam lain yang saya tahu.

Oh, dan satu hal lagi. Saya akan sangat, _sangat_ menghargainya jika ada sesuatu yang dapat dilakukan tentang bagaimana vcxproj memerlukan penggunaan package.config untuk referensi paket NuGet. WinUI didistribusikan sebagai paket NuGet, seperti C++/WinRT dan komponen kunci lainnya. Saya sangat tidak suka menggunakan package.config. PackageReference jauh lebih efisien (dan tidak menghasilkan build yang rusak jika Anda memindahkan vcxproj ke direktori lain). Ini benar-benar berfungsi ketika digunakan dari vcxproj, selama target Pemulihan dijalankan pada waktu yang tepat. (Ini karena target vcxproj secara tidak langsung mengimpor mesin pemulihan PackageReference untuk proyek C# non-SDK.) Saya telah menulis serangkaian target yang secara otomatis menjalankan target Pemulihan ketika set item PackageReference telah berubah, karena VS tidak akan melakukan ini sendiri (belum). Sayangnya, sistem NuGet tidak tahu apa-apa tentang ini, dan karena itu mencoba untuk menambahkan file package.config ketika saya menambahkan template file C++/WinRT. Ini menyebabkan segala macam malapetaka, menghasilkan pengecualian yang dilemparkan dan file proyek yang rusak. Saya tidak yakin cara terbaik untuk menyelesaikan ini, tetapi saya akan sangat menghargainya jika setidaknya bisa dilihat sebelum WinUI 3 dirilis. Terima kasih!

Alangkah baiknya, jika WinUI mendukung sdk proyek baru - Microsoft.NET.Sdk atau MSBuild.Sdk.Extras .
File csproj gaya lama sulit dipelihara. Dan kami tidak dapat menggunakan beberapa TargetFrameworks dengannya, yang dapat berguna untuk migrasi ke WinUI.

Mengapa tidak ada dukungan F#?

Haruskah fungsionalitas Azure DevOps dan Visual Studio App Center dibahas di sini?

Seperti @vitorgrs , saya lebih suka kontrol asli tanpa awalan namespace, itu menambahkan "noise" ke kode. Dan itu membantu untuk melihat mana yang merupakan kontrol asli, dan mana yang merupakan pihak ke-3.

Alat migrasi akan menyenangkan, tentu saja. Jika bekerja dengan penyedia pihak ke-3 besar (Telerik, DevExpress,...) itu sudah menjadi hal yang besar.

Template

Apakah ada minat/kebutuhan untuk versi sebelumnya dari templat UWP XAML untuk tetap berada di alur proyek baru VS?

Dari sisi saya tidak perlu menyimpan template. Tetapi mungkinkah UWP memiliki Kontrol yang tidak ada di WinUI? Jika itu bisa terjadi, maka ini bisa menjadi alasan yang sah untuk membangun aplikasi UWP tradisional dan memigrasikannya ke WinUI ketika Kontrol yang diperlukan ada di sana. Maka template mungkin diperlukan.

Mungkin juga membingungkan bagi pengembang jika Anda telah membangun sebuah aplikasi dan Anda tidak dapat membuatnya lagi dengan versi Visual Studio terbaru.

Tapi secara pribadi, saya tidak tertarik untuk menyimpan template

Bagaimana kami dapat membantu Anda menjadi lebih efisien atau sukses sehubungan dengan template dan komponen di Visual Studio?

Bagi saya ini terlihat bagus untuk UWP. Sekarang saya ingin melihat hal yang sama untuk Win32. :)

Apakah panduan ini bermanfaat dan apakah Anda ingin melihat lebih banyak dari ini saat skenario terbentuk?

Iya tentu saja. Perjalanan ini sangat membantu untuk memahami seperti apa masa depan dan seharusnya. Saya ingin melihat lebih banyak dari ini.

Migrasi

Apakah akan bermanfaat jika kami menyediakan alat migrasi yang mengotomatiskan langkah 1-3?

Tentu saja. Mungkin sedikit Visual Studio Extension akan menjadi pilihan yang bagus untuk migrasi ini. Saya juga dapat memikirkan sesuatu seperti "Penganalisis Kompatibilitas WinUI" yang menampilkan apa yang dapat dimigrasikan dan apa yang tidak. Sesuatu yang mirip dengan penganalisis portabilitas .NET.

Pustaka apa yang Anda gunakan dari luar set kontrol Windows 10 Asli?

Biasanya Telerik DataGrid dan Toolkit Komunitas

Dengan cara apa kami dapat membantu migrasi yang saat ini tidak kami pikirkan?

Jika Anda membuka aplikasi UWP di Visual Studio yang memiliki versi lebih rendah daripada Win SDK yang telah Anda instal, Visual Studio memigrasikannya untuk Anda. Mungkin Anda harus memikirkan hal seperti itu untuk migrasi WinUI juga. Saya tidak yakin, tapi itu sesuatu yang perlu diingat. Terutama ketika Visual Studio tidak memiliki template UWP normal lagi, dapat membingungkan bagi pengembang untuk memiliki aplikasi yang tidak dapat Anda buat dengan template.

Yang lain

Seperti yang sudah disebutkan di komentar lain, saya pikir sudah waktunya untuk beralih ke file .csproj bergaya SDK.

tambahkan templat winui 3.0 ke studio templat windows.

WinUI di Aplikasi Desktop

WinUI di Desktop akan memungkinkan pengembang untuk menggunakan Perpustakaan UI Windows pada model Aplikasi Desktop. @marb2000 sedang mengerjakan posting diskusi yang lebih rinci dalam beberapa minggu mendatang. Jangan ragu untuk menggunakan utas ini sampai saat itu untuk saran.

Sebagai pengembang .net, ini adalah bagian yang paling saya minati.

Template

• Apakah ada minat/kebutuhan untuk versi sebelumnya dari templat UWP XAML untuk tetap berada di alur proyek baru VS?

Tergantung pada jumlah template. Jika jumlahnya rendah (mis. hanya "Aplikasi Kosong (Universal Windows)" per bahasa, jadi 1 dalam kasus c#), kebisingannya rendah dan dapat didukung. Tetapi jika melibatkan lebih dari beberapa template, maka jangan sertakan secara default dan tambahkan komponen instalasi VS opsional untuk menambahkannya.

• Bagaimana kami dapat membantu Anda menjadi lebih efisien atau sukses sehubungan dengan template dan komponen di Visual Studio?

Simpan template kosong asli tanpa perancah (lebih baik untuk tutorial). Intip apa yang asp.net core lakukan, ada banyak perubahan yang mereka lakukan dalam pengalaman proyek baru mereka. Pada dasarnya, Anda memilih template umum "Aplikasi (UWP WinUI)", lalu layar kedua, khusus untuk model aplikasi Anda memungkinkan Anda memilih dari berbagai template. Gunakan langkah ini untuk juga memilih versi platform minimum dan target (jadi tidak ada langkah tambahan). Anda dapat menambahkan opsi untuk membuat proyek pengemasan aplikasi secara langsung misalnya.

Juga memberikan dukungan yang baik untuk komponen di kotak peralatan antar proyek. Kontrol baru harus segera ditampilkan di kotak alat, dikelompokkan berdasarkan proyek. Mungkin dukungan untuk ikon desainer untuk membantu membedakannya.

• Apakah panduan ini bermanfaat dan apakah Anda ingin melihat lebih banyak dari ini saat skenario terbentuk?

Ya

Dukungan bahasa

• Apakah akan bermanfaat jika kami menyediakan alat migrasi yang mengotomatiskan langkah 1-3?

Dokumentasi yang baik (satu halaman dengan langkah-langkah yang jelas) sudah cukup. Jika semuanya dapat dilakukan dari dalam VS tanpa mengedit csproj dengan tangan, saya sarankan untuk hanya menambahkan halaman dokumentasi yang menjelaskan langkah-langkahnya.

Jika Anda memutuskan (dan saya harap Anda akan melakukannya) untuk beralih ke format csproj baru, maka alat migrasi pasti akan diperlukan, karena migrasi akan memerlukan pengeditan file csproj.

Kemasan

MSIX adalah metode pengemasan modern untuk semua aplikasi. Untuk WinUI di Win32 haruskah kita mendukung ClickOnce? Metode pengemasan lain apa yang harus kami sertakan dukungannya? Khusus untuk WinUI di Win32

Bandingkan perbedaan antara penerapan clickonce dan msix:

1. fitur Penginstal Aplikasi tidak menawarkan pengalaman yang sama pada versi windows yang lebih lama
2. MSIX memerlukan paket bertanda tangan yang valid (internal atau publik). Clickonce mendukung paket yang ditandatangani sendiri.
3. model paket memiliki beberapa keterbatasan, sebagian besar disebabkan oleh lingkungan yang terisolasi (misalnya, tidak ada akses appdata lokal, tidak ada operasi yang ditinggikan).

Bagi saya masalah yang paling menjengkelkan adalah 2. Kami biasanya memiliki aplikasi clickonce yang digunakan secara internal dengan komputer yang tidak terdaftar dengan domain. Jadi, untuk aplikasi semacam ini, kita harus menandatangani paket dengan sertifikat penandatanganan publik yang valid.

Sulit untuk mengantisipasi semua perbedaan antara kedua kerangka kerja ini, karena format pengemasan Appx sering kali hanya diiklankan untuk aplikasi yang menargetkan Store, dan ketika kami melihat batasan, kami tidak selalu tahu apakah itu berlaku juga untuk format distribusi Web.

• Pengalaman Desainer

Pertunjukan, pertunjukan, pertunjukan, dan dukungan untuk solusi besar dengan banyak proyek.

Akankah versi WinUI dari Windows 10 SDK dan desainer WinUI Xaml, dibuat open source?

Apakah kami dapat memposting permintaan untuk alur kerja waktu desain, dan pengalaman?

Akankah SDK mengikuti irama rilis yang serupa dengan rilis nuget WinUI?

Beberapa rasa sakit tambahan:
meningkatkan pengalaman debug pencampuran terkelola-tidak terkelola.
Saat ini ketika pengecualian terjadi dalam kode yang tidak dikelola, COMException ditampilkan di situs debug terkelola. Hal-hal mungkin lebih buruk jika tumpukan panggilan melintasi batas terkelola/tidak terkelola lebih dari 1 kali.
Dibandingkan dengan WPF, tumpukan panggilan terkelola selalu tersedia, dan pengecualian yang dilemparkan membawa string yang berguna untuk debug.
Saya tahu dunia yang tidak dikelola dan model COM tidak senyaman yang dikelola. Tapi setidaknya, ketika pengecualian (HResult yang salah) dilemparkan oleh kerangka kerja, saya ingin informasi yang diperlukan untuk menemukan baris kode dari repo open source. Caranya bisa manual, tapi harus deterministik.

Kami sangat bergantung pada ClickOnce, jadi akan menyenangkan untuk mendukung untuk jangka pendek. Kami akan bersedia untuk bermigrasi ke MSIX, tetapi setelah fitur serupa ditawarkan.

Untuk template, akan lebih baik jika memiliki template yang menyediakan UI boilerplate dan kode untuk NavigationView dan navigasi.

Terima kasih

Kami sangat bergantung pada ClickOnce, jadi akan menyenangkan untuk mendukung untuk jangka pendek. Kami akan bersedia untuk bermigrasi ke MSIX, tetapi setelah fitur serupa ditawarkan.

Untuk template, akan lebih baik jika memiliki template yang menyediakan UI boilerplate dan kode untuk NavigationView dan navigasi.

Terima kasih

Struktur dan pola "cangkang" Aplikasi yang paling umum - harus tersedia sebagai templat sehingga pengembang dapat bangun dan berjalan dengan cepat. Aplikasi pihak pertama Microsoft harus menjadi contoh dalam tata letak ini dan bertindak sebagai praktik terbaik dalam hal perilaku, konsistensi, dan mematuhi norma desain UI untuk Desain Lancar, dan WinUI.

@shaggygi @mdtauk
Untuk "struktur dan pola "Shell" Aplikasi yang paling umum dan "Untuk template, akan lebih baik jika memiliki satu yang menyediakan UI boilerplate dan kode untuk NavigationView dan navigasi." ada Windows Template Studio yang dikelola dan dikembangkan oleh Microsoft dan Komunitas. Mengutip pengantarnya:

Windows Template Studio (WTS) adalah Ekstensi Visual Studio 2017 dan 2019 yang mempercepat pembuatan aplikasi Universal Windows Platform (UWP) baru menggunakan pengalaman berbasis wizard. Proyek UWP yang dihasilkan adalah kode yang dibentuk dengan baik dan dapat dibaca yang menggabungkan fitur Windows 10 terbaru sambil menerapkan pola dan praktik terbaik yang telah terbukti.

@Felix-Dev apakah akhirnya akan ada template WPF selain UWP?

@shaggygi Mungkin ada kabar baik untuk Anda! Lihat utas ini : Meskipun tampaknya tidak ada yang dijamin pada saat ini, gagasan untuk menyediakan templat khusus untuk proyek WPF tampaknya sedang dieksplorasi. Seperti disebutkan di utas tertaut, ada sesi mengintip non-publik yang disebut "Windows Template Studio - Edisi WPF" yang dihosting di Build 2019.

Kami menggunakan C++/WinRT. Kami tidak menggunakan desainer atau penjilidan xaml saat ini. Tapi kami akan membuat kontrol saat runtime dan menatanya mungkin melalui UWP xaml. Kami juga akan membutuhkan dialog dan Windows anak tanpa mode dengan pulau xaml termasuk jendela dok/mengambang dll.

Saya sudah mencoba menulis XAML untuk aplikasi C++ saya dan pengalaman itu menyakitkan.

Saya harus menambahkan banyak properti proyek yang tidak berdokumen dan beberapa peretasan lain untuk menghasilkan semuanya dengan benar dan mengemasnya dengan benar.

Sebagai contoh:

• Saat membuat proyek untuk menyimpan halaman XAML saya, saya harus menambahkan <_NoWinAPIFamilyApp>true</_NoWinAPIFamilyApp> dan <_VC_Target_Library_Platform>Desktop</_VC_Target_Library_Platform> , dua properti proyek yang sepenuhnya tidak berdokumen dan hanya diketahui dengan memeriksa kode sumber Terminal baru.
• Saya memiliki samar "Tidak dapat membuat tampilan baru karena jendela utama belum dibuat" sampai saya membuat dan menggunakan kelas Aplikasi, yang tidak ada cara untuk di VS kecuali membuat halaman normal dan masuk ke properti File XAML di VS dan mengubahnya menjadi definisi aplikasi, lalu menyesuaikan file MIDL, kode sumber, dan XAML.
• Saya menambahkan paket Microsoft.Toolkit.Win32.UI.XamlApplication NuGet untuk membuat kelas aplikasi saya dan tidak dapat memuatnya sampai saya juga menambahkan Microsoft.VCRTForwarders , sekali lagi saya menemukan ini ketika memeriksa sumber Terminal, tidak ada indikasi tentang salah satu paket di mana pun.
• PRI tidak akan digabungkan menjadi satu sampai saya menambahkan sesuatu di file .wapproj, sehingga tidak dapat menemukan sumber daya XAML saya.
• XBF tidak berfungsi sampai saya menambahkan <DisableEmbeddedXbf>false</DisableEmbeddedXbf> yang secara mengejutkan menonaktifkan XBF yang disematkan alih-alih mengaktifkannya. Satu-satunya kesalahan yang saya miliki adalah kesalahan penguraian XAML tanpa menunjukkan kepada saya bahwa file XBF tidak berfungsi.
• maxVersionTested dalam manifes aplikasi saya benar-benar diabaikan sampai saya mengubah semuanya menjadi huruf kecil, meskipun instruksinya diminta untuk menggunakan versi kasing unta: https://github.com/MicrosoftDocs/windows-uwp/issues/1781 #issuecomment -511173811

Selain itu, C++/WinRT juga menyebalkan:

• Setiap kali saya menjalankan build tambahan, saya memiliki [msg]redefinition [context]: MyClass untuk kelas kustom saya yang mencegah saya membangun dan tidak hilang sampai saya menjalankan build bersih yang karena header C++/WinRT membutuhkan waktu lama. Masalah itu entah bagaimana secara ajaib hilang di tengah jalan.
• Sekarang ketika saya menjalankan build bersih, saya mendapatkan kesalahan tentang header yang hilang. Menekan tombol build untuk kedua kalinya membuatnya berfungsi kembali.
• Saya harus menulis kelas AppT<> saya sendiri karena codegen buruk dari C++/WinRT. Aplikasi Terminal dan sampel pulau XAML melakukan hal yang sama, seolah-olah itu adalah sesuatu yang perlu dilakukan pengguna alih-alih masalah root diperbaiki.
• Mengubah apa pun di file MIDL menghasilkan kesalahan build hingga saya melakukan build bersih.

Meski begitu, itu masih tidak berfungsi tanpa paket bahkan ketika menambahkan barang activatableClass ke manifes aplikasi saya (sesuatu tentang tidak dapat menemukan sumber daya XAML, seperti ketika saya belum menggabungkan PRI), yang penting untuk aplikasi saya untuk mendukung.

Migrasi

Otomatisasi untuk langkah 1-3 sangat membantu terutama karena mengganti nama ruang nama pada ratusan file sangat memakan waktu dan rentan terhadap kesalahan. Selain itu penganalisis compat akan bagus seperti .net framework > .net core one yang membuat laporan tentang seberapa kompatibel basis kode saat ini dan mencatat semua kemungkinan perubahan yang diperlukan.

Perkakas

Seperti yang telah dikatakan orang lain, editor yang lebih kaya fitur akan menyenangkan. Sebagian besar waktu di sini di tempat kerja XAML dilakukan dengan tangan dan sebagian besar menggunakan perancang sebagai panduan tentang kerangka kasar tentang bagaimana tampilan aplikasi. Intellisense dan refactoring cerdas akan sangat membantu, QoL hal-hal seperti CTRL + R + R untuk mengganti nama sesuatu (misalnya properti Ketergantungan atau bahkan tag) misalnya terutama ketika Anda cenderung memiliki banyak kustom UserControls dan juga Implementasi GoTo dan referensi. Dukungan penganalisa Roslyn juga akan sangat bagus.

Untuk memperluas peningkatan namespace. Akan lebih baik jika entah bagaimana mungkin untuk memiliki kontrol khusus awalan non lebih mudah dilakukan tanpa menambahkan XmlnsDefinition s baru ke namespace default, itu mendeklarasikan imo markup dan hanya perlu awalan ketika ada kontrol ambigu yang ditemukan seperti bagaimana kelas bekerja, ini akan cocok dengan implementasi GoTo juga. Biasanya nama kontrol dan mungkin mengarahkannya untuk menunjukkan namespace lengkap akan cukup untuk mengetahui dari mana asalnya, Anda biasanya tidak menggunakan alias namespace baik pada kode C# kecuali jika diperlukan.

Sebagian besar pada perkakas akan lebih baik jika berperilaku seperti Editor C # untuk membuat refactoring kurang rapuh atau merepotkan dan menavigasi markup lebih mudah. Selain itu untuk bahasa XAML itu sendiri yang mengurangi verbositas akan menjadi contoh yang bagus juga salah satunya adalah Styling seperti yang dibahas #62 dan #279.

Untuk memperluas peningkatan namespace. Akan lebih baik jika entah bagaimana mungkin untuk memiliki kontrol kustom non awalan lebih mudah dilakukan tanpa menambahkan XmlnsDefinition s baru ke namespace default, itu mendeklarasikan imo markup dan hanya perlu awalan ketika ada kontrol ambigu yang ditemukan seperti bagaimana kelas bekerja, ini akan cocok dengan implementasi GoTo juga. Biasanya nama kontrol dan mungkin mengarahkannya untuk menunjukkan namespace lengkap akan cukup untuk mengetahui dari mana asalnya, Anda biasanya tidak menggunakan alias namespace baik pada kode C# kecuali jika diperlukan.

Saya ingin berpikir bahwa versi WinUI 3.0 dari kontrol Halaman akan menghilangkan kebutuhan untuk menggunakan awalan untuk kontrol tersebut. Saya kira ini akan menjadi hal tingkat SDK.

Apakah mungkin untuk tidak mengubah ruang nama saat menggunakan WinUI?

Satu perbaikan seharusnya, bahwa Anda dapat mengecualikan Windows.UI.Xaml.* referensi WinMD dari build. Sekarang target build hanya merujuk pada Unified WinMD alias. Windows.winmd , tambahkan opsi di target untuk juga merujuk masing-masing WinMD, dengan begitu, kita dapat menyertakan atau mengecualikan referensi berdasarkan Aplikasi yang sedang kita buat.

Apakah ini caranya, maka tidak perlu mengubah namespace, karena ia berperilaku seperti .NET dll ia dapat bekerja dengan pengalihan Majelis ke versi lokal di dalam paket daripada yang disediakan sistem.

Saya tahu metode itu khusus untuk .NET Framework, tetapi untuk UAP, harus ada solusi untuk skenario semacam ini. Saya tahu ada FrameworkDependency pada manifes msix/appx . Mungkin kita dapat menggunakannya untuk memasok WinUI baru dengan ruang nama Windows.* daripada Microsoft.* .

Di sisi pengembang, kami tidak akan kesulitan untuk mengupgrade aplikasi kami, karena kami hanya mengubah referensi dan bukan kode !

Saya lebih suka tidak mengubah namespace sama sekali!

Manfaat:

1. Tidak perlu mengubah kode bolak-balik.

2. Setelah kode WinUI lokal distabilkan, Anda dapat menggabungkan kembali ke platform windows, sehingga aplikasi sistem dan aplikasi LOB dapat memanfaatkan peningkatan baru, pada setiap rilis windows baru.

3. Di satu sisi ini adalah kerangka kerja sistem yang sangat stabil dengan kompatibilitas tinggi seperti .NET Framework. Dan di sisi lain seperti .NET Core, dengan perubahan yang lebih cepat, dengan semua manfaat dari keduanya dan tidak ada masalah.

Saya tidak berpikir itu perlu untuk menyediakan alat porting. Ini adalah perubahan satu kali, cukup mudah dengan Find&Replace, dan jumlah instance akan cukup rendah.

Juga mengalami lebih banyak masalah:

• Setelah menambahkan sumber daya ke kelas App , XAML saya tidak dapat menemukannya sampai saya menambahkan ini, lagi-lagi ditemukan dari aplikasi Terminal dan tanpa banyak gagasan tentang apa yang sebenarnya dilakukannya:
  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>
• Bangunan akan benar-benar rusak secara acak dengan kesalahan yang mirip dengan cannot find type Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication dan satu-satunya cara untuk mendapatkan pembangunan proyek lagi adalah dengan melakukan pembangunan bersih
• Saya tidak dapat menjalankan aplikasi dengan langsung mengatur vcxproj untuk exe utama sebagai proyek startup, saya harus secara manual memulai output appx yang tidak dikemas dalam bin\x64\Debug\AppX dan kemudian menyuntikkan debugger dari dalam VS, atau mengatur paket aplikasi sebagai proses startup.

Hal-hal terkait di Desktop Windows: .NET Community Standup - 25 Juli 2019 jika tertarik.

LAMA WinForms, pengembang WPF di sini dengan beberapa pengalaman UWP. Ini 2 sen saya:

Migrasi

• Alat untuk memigrasi aplikasi UWP yang ada ke WinUI adalah suatu keharusan.
• Alat untuk mengonversi kontrol WinForms atau WPF ke kontrol WinUI di aplikasi yang ada akan sangat luar biasa. Dengan mengonversi kontrol, maksud saya ubah referensi dalam wadah ke kontrol individual.
• Alat untuk memigrasikan Xamarin Forms ke WinUI untuk memungkinkan back-porting aplikasi seluler ke Windows.

Perkakas

• Editor XAML saat ini sangat buruk! Itu perlu menggunakan kanvas editor teks normal dan menyediakan fitur Roslyn untuk diterapkan ke model objek XAML untuk intellisense dan refactoring yang lebih baik.
• Hingga Visual Studio 64 bit, Editor XAML harus menjadi aplikasi 64-bit yang berdiri sendiri di belakang layar. Saya terus-menerus harus memulai ulang VS 2017 dan VS 2019 untuk menghentikan kesalahan kehabisan memori saat bekerja dengan banyak XAML.

Template

• Kami membutuhkan templat proyek ini

  • NavigationView WinUI
  • NavigasiTampilan WPF
  • Pita WinUI
  • Pita WPF
  • Ribbon WinForms

• Kami membutuhkan templat halaman/jendela ini

  • Halaman Pengontrol Media
  • Halaman Peramban
  • Jendela Dialog
  • Jendela Tanpa Batas
  • Jendela Mengambang

• Kami membutuhkan template kontrol

  • Tampilan kisi data yang dienkapsulasi
  • Tampilan data anak yang dienkapsulasi

Dua yang terakhir ini akan bekerja sama untuk membuat jendela Master-Detail yang mudah.

semua template dan halaman ini dll sudah dilakukan di proyek Windows Template Studio, mengapa tidak mengikuti rute yang sama alih-alih membuat ulang semuanya?

File proyek Gaya SDK
Salah satu bagian terpenting yang ingin saya lihat - seperti yang telah disebutkan banyak orang lain - adalah dukungan untuk format file proyek Gaya SDK baru untuk aplikasi UWP dan "Desktop XAML".

Migrasi antara model aplikasi UWP dan Desktop XAML
Jika kita mulai membangun aplikasi "Desktop XAML", seberapa jauh dari aplikasi UWP? Apakah sepele untuk mengubahnya menjadi aplikasi UWP nanti jika kita menyadari bahwa kita tetap berada dalam batasan sandbox UWP? Atau jika kami mulai membuat aplikasi UWP dan menyadari bahwa kami membutuhkan lebih banyak, apakah akan mudah untuk mengubahnya menjadi aplikasi "Desktop XAML"?

Saya dengan dukungan Template Studio.

Saya dengan dukungan Template Studio.

Apakah Template Studio mendukung proyek XAML C++?

Apa yang dilakukan Template Studio, harus menjadi bagian dari WinUI SDK IMO

Apa yang dilakukan Template Studio, harus menjadi bagian dari WinUI SDK IMO

Harus menjadi bagian Visual Studio IDE IMO! 😎

intinya adalah windows template studio melakukan semua dalam satu hal untuk pembuatan proyek UWP jadi ingatlah itu jika ada sesuatu yang hilang seperti dukungan xaml c++, kita harus mempertimbangkan untuk menambahkannya ke windows template studio, saya pikir itu akan lebih cepat dan lebih efisien jika semua inovasi baru dalam proyek uwp tetap dalam satu proyek.

Biarkan ada beberapa metode untuk menggunakan lapisan bawah tumpukan WinUI 3 secara langsung tanpa XAML atau bahkan MVVM. Ini sangat berguna untuk perangkat lunak C++ besi besar yang sudah ada yang sudah memiliki semacam arsitektur MV-apa pun dalam basis kode mereka. Mereka hanya menginginkan sesuatu yang lebih baik dari HWND + GDI.

Dan, tolong buat orang berpikir bahwa WinUI 3 bukan mainan, itu benar-benar dapat mendukung perangkat lunak yang serius .

@be5invis Saya setuju sepenuhnya. Satu-satunya solusi saat ini adalah XamlDirect, tetapi itu lebih ditujukan untuk pengembang middleware.

Anda sudah dapat membuat konten secara manual dengan Xaml Islands. Cukup buat DesktopWindowXamlSource berfungsi dan dilampirkan ke jendela, lalu buat dan atur/tata kontrol dalam kode.

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

@MarkIngramUK Mereka mungkin membutuhkan sesuatu yang lebih "lengkap", seperti mengganti CreateWindow dengan fungsi WinUI.

Demi desain, saya sangat ingin templat WPF WinUI masa depan memiliki dukungan untuk memperluas konten halaman ke bilah judul seperti aplikasi UWP saat ini. Saat ini, dengan solusi pulau XAML yang ada, kami hanya menghosting kontrol di dalam Jendela WPF/WinForms daripada tampilan modern.

@LucasHaines Daftar bahasa yang kami rencanakan untuk didukung dengan WinUI 3.0: C#, C++/WinRT, Visual Basic. Kami sedang menjajaki dukungan F#.

Ini menunjukkan bahwa Anda melakukan kesalahan, tidak hanya untuk F# tetapi untuk semua bahasa .Net. Anda mulai dengan memikirkan template dan file .xaml, yang seperti membangun rumah dan meletakkan karpet dan gorden di tempatnya tanpa menyelesaikan strukturnya.

Anda harus dapat menginstal WinUI ke proyek .Net Standard 2.0/.Net Core 3.0/.Net 5 apa pun sebagai paket Nuget. Kemudian Anda memiliki akses ke semua kelas yang ditentukan di dalamnya. Anda kemudian dapat mereferensikan proyek semacam itu dari proyek WinUI (yang mungkin hanya C#). Ini memungkinkan tampilan WinUI dibuat dalam bahasa .Net apa pun. Lihat bagaimana Xamarin.Forms melakukannya .

Kelas sudah tersedia untuk digunakan di F# (karena mereka adalah komponen Windows Runtime, yang dapat digunakan oleh semua bahasa .NET)

Anda akan dapat membuat tata letak secara manual. Anda bahkan dapat melakukannya melalui Python menggunakan Py/WinRT untuk semua perhatian WinUI.

@sylveon Apa kelas khusus? saya akan tertarik...

Mereka semua. API publik WinUI hanya komponen Windows Runtime.

@LucasHaines Daftar bahasa yang kami rencanakan untuk didukung dengan WinUI 3.0: C#, C++/WinRT, Visual Basic. Kami sedang menjajaki dukungan F#.

Ini menunjukkan bahwa Anda melakukan kesalahan, tidak hanya untuk F# tetapi untuk semua bahasa .Net. Anda mulai dengan memikirkan template dan file .xaml, yang seperti membangun rumah dan meletakkan karpet dan gorden di tempatnya tanpa menyelesaikan strukturnya.

Anda harus dapat menginstal WinUI ke proyek .Net Standard 2.0/.Net Core 3.0/.Net 5 apa pun sebagai paket Nuget. Kemudian Anda memiliki akses ke semua kelas yang ditentukan di dalamnya. Anda kemudian dapat mereferensikan proyek semacam itu dari proyek WinUI (yang mungkin hanya C#). Ini memungkinkan tampilan WinUI dibuat dalam bahasa .Net apa pun. Lihat bagaimana Xamarin.Forms melakukannya .

Topik/pertanyaan ini adalah tentang perkakas. Ya, perpustakaan dapat direferensikan secara langsung dari bahasa apa pun yang dapat menggunakannya, tetapi ada ketidakjelasan definisi antara alat dan dukungan bahasa.
Mengambil Xamarin.Forms sebagai contoh Anda. Itu hanya menyediakan perkakas untuk C# dan pada tingkat lebih rendah F#. Dimungkinkan untuk membuat aplikasi dengan VB.Net dan Xamarin.Forms tetapi tidak _didukung secara resmi_ karena tidak ada alat dan hanya dokumentasi terbatas untuk melakukannya.

Juga, karena WinUI khusus untuk Windows, ia tidak dapat direferensikan di sembarang proyek .Net Standard 2.0/.Net Core 3.0/.Net 5.
Ada juga kebutuhan untuk dukungan tingkat proyek/kompiler/pengemasan untuk beberapa skenario juga.

Tim kerja yang hebat pada rilis v2.2 . Adakah kemungkinan kita bisa mendapatkan pembaruan singkat tentang status v3.0?

Saya melihat ini disebutkan beberapa kali tetapi tidak ada arah yang jelas satu atau lain cara. Sejak WinUI 3.0 akan memiliki semua kontrol sekarang persyaratan namespace untuk referensi kontrol perpustakaan WinUI HARUS dihapus. Ini sangat mengacaukan XAML, sangat menghambat migrasi, dan merusak kompatibilitas sederhana dengan hal-hal seperti platform UNO dan Avalonia.

Harap hapus kebutuhan xmlns:mux="using:Microsoft.UI.Xaml.Controls" dari XAML. Saya mengerti kode di belakang masih perlu diubah. Mungkin juga ada konfigurasi untuk ini di suatu tempat di proyek.

Harap hapus kebutuhan xmlns:mux="using:Microsoft.UI.Xaml.Controls" dari XAML.

Itu tidak akan diperlukan di _markup_ XAML, tetapi mengubah ruang nama di belakang kode masih diperlukan.

Jika Anda ingin menggunakan kontrol Windows (jika tidak dihapus dari OS) - Anda harus mendeklarasikan namespace di XAML

Jika Anda ingin menggunakan kontrol Windows (jika tidak dihapus dari OS) - Anda harus mendeklarasikan namespace di XAML

Dengan WinUI 3.0 yang bukan skenario -- Anda tidak dapat mencampur dan mencocokkan kontrol OS dengan kontrol WinUI 3.0. Itu hanya berfungsi dengan WinUI 2.x sekarang karena kontrol itu adalah add-on untuk OS (dan kami memiliki banyak kasus canggung di mana kami mengirimkan jenis di kedua tempat seperti NavigationView dan TreeView yang menyebabkan ambiguitas).

Jika Anda ingin menggunakan kontrol Windows (jika tidak dihapus dari OS) - Anda harus mendeklarasikan namespace di XAML

Dengan WinUI 3.0 yang bukan skenario -- Anda tidak dapat mencampur dan mencocokkan kontrol OS dengan kontrol WinUI 3.0. Itu hanya berfungsi dengan WinUI 2.x sekarang karena kontrol itu adalah add-on untuk OS (dan kami memiliki banyak kasus canggung di mana kami mengirimkan jenis di kedua tempat seperti NavigationView dan TreeView yang menyebabkan ambiguitas).

Senang mendengarnya. Akan membuatnya lebih mudah untuk menghentikannya dari OS. Saya harap Aplikasi Pengaturan, Shell, dan bagian lain dari OS akan pindah ke WinUI 3.0 juga.

Dan mari berharap untuk port Alat Administrator, Wordpad, dll ke XAML menggunakan kembali kode yang sama sebanyak mungkin juga!

@jevansaks Ok, mengerti, terima kasih atas umpan baliknya!

@mdtauk Tidak perlu lagi membedakan antara kontrol warisan 'OS' dan kontrol platform 'WinUI 3.0' baru di XAML. Semuanya pindah ke WinUI 3.0 dan kontrol OS tidak mendapatkan pembaruan fitur lagi seperti yang Anda tahu. Setelah WinUI 3.0 jika pengembang masih ingin menargetkan kontrol lama, mereka harus mengembangkannya dengan SDK dan versi Visual Studio yang lebih lama. Mempertahankan kemampuan untuk mereferensikan dua perpustakaan kontrol UI Microsoft/Windows dari XAML hanya akan menjadi penghalang karena alasan yang disebutkan sebelumnya. Selain itu, dengan decoupling pengembangan WinUI akhirnya dapat beralih ke jalur berkelanjutan 'memungkinkan' perubahan seperti ini -- yang bahkan tidak melanggar.

Sunting: Lupa menyegarkan sebelum membalas, sebagian besar ini berlebihan sekarang.

@robloo Saya senang ini benar-benar menggantikan versi UWP Xaml sebelumnya. Saya juga berharap OS bisa pindah ke Inbox Apps dan Shell.

Saya juga berharap akan ada banyak video pengembang yang merinci proses perpindahan ke WinUI 3.0 - dan cara bekerja dengan WinUI 3.0 dengan Siklus Hidup yang sama dengan aplikasi Win32. Tidak ada lagi rehidrasi, cara yang lebih baik untuk menyimpan status halaman dan navigasi, dll.

Ini bisa membantu (tergantung pada aplikasi mana yang berencana untuk pindah ke WinUI 3.0) untuk memberikan contoh mengatakan mengambil Wordpad dan memindahkan kode ke UI baru yang dibangun di WinUI - serta mengambil aplikasi kotak masuk seperti Groove Music, dan memindahkannya ke WinUI 3.0

Untuk WinUI 3, perlu ada konsistensi dalam penempatan fungsi aplikasi dalam Bahasa Desain.

Dalam hal ini, Pengaturan Aplikasi.

Di mana saya menemukan pengaturan Aplikasi? Apakah saya mengklik roda gigi di sudut kanan atas? Pojok kiri bawah? Apakah saya mengklik avatar Profil di kanan atas dan menekan pengaturan? Apakah saya mengklik kiri atas? Kiri bawah? Apakah saya pergi ke Edit > Preferensi?

Sangat tergantung pada apakah Anda menggunakan NavigationView ...

Dari: shaheedmalik [email protected]
Dikirim: Kamis, 12 September 2019 15:48:12
Kepada: microsoft/microsoft-ui-xaml [email protected]
Cc: Ninja Tajam [email protected] ; Komentar [email protected]
Subjek: Re: [microsoft/microsoft-ui-xaml] Pengalaman dan Perkakas Pengembang WinUI 3.0 - Diperlukan Masukan (#1045)

Untuk WinUI 3, perlu ada konsistensi dalam penempatan fungsi aplikasi dalam Bahasa Desain.

Dalam hal ini, Pengaturan Aplikasi.

Di mana saya menemukan pengaturan Aplikasi? Apakah saya mengklik roda gigi di sudut kanan atas? Pojok kiri bawah? Apakah saya mengklik avatar Profil di kanan atas dan menekan pengaturan? Apakah saya mengklik kiri atas? Kiri bawah? Apakah saya pergi ke Edit > Preferensi?

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, melihatnya di GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLB5VXXUOYIA2NIEZATQJKTIZA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TGV4I#issuecomment-531000049 , atau mematikan benang https: // github. com/notifications/unsubscribe-auth/AD3GCLCQQ6L7H3LEJAHUDMLQJKTIZANCNFSM4ICOLUJQ .

Bagaimana kami dapat membantu Anda menjadi lebih efisien atau sukses sehubungan dengan template dan komponen di Visual Studio?

Seharusnya tidak diperlukan upaya yang signifikan dan atribut konfigurasi proyek yang tidak berdokumen untuk membuat Kepulauan WinUI/XAML bekerja dengan C++/WinRT di Visual Studio.

Tidak dapat cukup menekankan ini, tetapi yang paling penting bagi saya adalah bahwa WinUI merender lebih dari sekadar Windows.

Segera setelah saya melihat Surface Duo, saya bertanya-tanya seperti apa cerita pengembangan lintas platform sekarang setelah Microsoft merilis perangkat yang didukung Android. Xamarin.Forms tidak memotongnya karena sejumlah alasan yang jelas. Saatnya Microsoft sepenuhnya merangkul toolkit lintas platform (seperti platform UNO tetapi selesai dan stabil) yang kita semua tahu telah diminta dalam berbagai bentuk selama bertahun-tahun. Saya berharap Microsoft memiliki beberapa rencana yang belum terungkap untuk pengembang di sini.

Satya menyatakan "Kami tidak ingin hanya membangun pengalaman dan satu perangkat, tetapi itu menjangkau semua perangkat dalam hidup kami." Jika Anda ingin pengembang ikut serta dalam perjalanan ini seperti yang diharapkan Panos, ini adalah cara terbaik untuk melakukannya. Jika tidak, Anda meminta pengembang untuk menulis dua UI terpisah untuk menjangkau 'pengalaman' antara Surface Duo dan keluarga lainnya. Saya tidak berpikir itu permintaan yang adil untuk pengembang dalam satu 'keluarga' perangkat.

Render berbeda pada setiap platform alias "tampilan dan nuansa asli".

Saya tidak mengerti. Tolong jangan, hal terakhir yang saya ingin Fluent Design lakukan adalah menyebabkan lebih banyak inkonsistensi, bukan lebih sedikit.

EDIT: komentar asli dihapus

Satya menyatakan "Kami tidak ingin hanya membangun pengalaman dan satu perangkat, tetapi itu menjangkau semua perangkat dalam hidup kami." Jika Anda ingin pengembang ikut serta dalam perjalanan ini seperti yang diharapkan Panos, ini adalah cara terbaik untuk melakukannya. Jika tidak, Anda meminta pengembang untuk menulis dua UI terpisah untuk menjangkau 'pengalaman' antara Surface Duo dan keluarga lainnya. Saya tidak berpikir itu permintaan yang adil untuk pengembang dalam satu 'keluarga' perangkat.

Inilah PERSIS mengapa saya merasa sedih karena Duo adalah Android.

Template harus bersumber terbuka untuk menghapus area masalah yang muncul di dalamnya.

Kapan saya akan menggunakan WinUI dengan WPF, dan kapan saya akan membuat kontrol baru dengan kode seperti:
c# public class MyControl : UserControl { ... }
Ini akan menggunakan WinUI.UserControl atau WPF.UserControl?
Apakah kita harus memilih dan bagaimana menghadapinya?

Dan menariknya, jika XAML tooling akan disatukan, apakah kita akan memiliki kemampuan untuk membuat semacam shared xaml files?
Sesuatu seperti:

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

Haruskah itu semacam dialek bersama dengan ruang nama root khusus? (seperti proyek bersama di Visual Studio). Itu bisa terlihat seperti xaml bersyarat.

Ini akan menggunakan WinUI.UserControl atau WPF.UserControl?
Apakah kita harus memilih dan bagaimana menghadapinya?

Ini harus terjadi secara otomatis di XAML tempat Anda mendefinisikan

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

Itu memberi tahu kompiler bahwa itu UWP.

public class MyControl : UserControl { ... }

Ini sebenarnya tidak benar. Anda harus menyatakan seperti ini

public partial class MyControl { }

Warisan tidak diperlukan karena ditangani oleh file .g.cs yang menentukan warisan dan juga kerangka kerja yang digunakan.

Tentang template, saya akan lebih senang jika ada lebih dari sekadar template Hello World. Yang saya maksud adalah bahwa Microsoft harus mencadangkan beberapa kerangka kerja yang dikenali periferal yang diperlukan untuk bekerja dengan aplikasi klien

@weitzhandler Saya juga ingin melihat ini!!

Proyek gaya SDK untuk proyek C# dan Cpp/WinRT juga harus dimiliki

Saya pikir harus ada template untuk semua pola aplikasi Win32 dan Inbox yang umum. Daftar singkat dari atas kepala saya:

• Pita
• Menu utama
• Antarmuka Dokumen Bertab
• Tampilan Navigasi
• Perintah/Bilah Alat
• Tampilan Navigasi Atas
• Hub/Galeri (Saya tahu ini sedikit usang)
• Treeview/MasterDetails (Penjelajah file, RegEdit, Aplikasi Administrasi)

Tetapi juga harus ada templat item untuk dialog umum, halaman, halaman pengaturan, dll.

Bagaimana kami dapat membantu Anda menjadi lebih efisien atau sukses sehubungan dengan template dan komponen di Visual Studio?

Bekerja dengan ekstensi C++ untuk VSCode/Visual Studio. Saya ingin melihat VS Code sebagai editor yang didukung juga yang memberikan pengalaman serupa dengan Visual Studio. WinUI seharusnya OSS dan begitu juga VS Code, jadi saya pikir ini bisa dilakukan.

Alat seperti Template10 dan Windows Template Studio adalah tanda-tanda kurangnya fungsionalitas dasar. Dengan WinUI3 harus ada fungsionalitas untuk apa yang dilakukan alat ini. Saya bertaruh bahwa banyak pengembang melakukan perancah dasar ini berulang kali... itu harus menjadi bagian dari kerangka kerja. Tidak perlu alat tambahan. Mungkin Anda bahkan harus mematikan scaffolding MVVM untuk kasus yang jarang terjadi ketika Anda ingin tanpanya.

Setelah bekerja dengan ASPNET Core, saya kehilangan injeksi ketergantungan. Fitur ini ada secara native di ASPNET Core. Itu hanya bekerja, tanpa Anda melakukan sesuatu yang ekstra. Dan Anda dapat menambah atau mengubah layanan dengan mudah jika Anda mau. Tetapi untuk UWP hari ini, maka Anda perlu membangunnya sendiri atau menggunakan sesuatu seperti WTS untuk memulai, tetapi masih terasa seperti terpaku setelahnya. WinUI3 dengan injeksi ketergantungan asli yang tepat akan sangat membantu.

Saya tidak berpikir bahwa kehadiran sistem Template menunjukkan kurangnya fungsionalitas dasar, saya pikir itu menyoroti kualitas komunitas pendukung yang akan menyusun sistem template ini.

Alat seperti Template10 dan Windows Template Studio adalah tanda-tanda kurangnya fungsionalitas dasar.

Saya melihat hal-hal seperti ini sebagai perluasan dari fungsionalitas dasar. Tentu saja, hal-hal seperti ini dapat dibawa ke rumah, tetapi lebih kepada tim inti untuk mempertahankan dan mendukungnya. Karena tim inti melakukan lebih banyak, itu cenderung berarti mereka tersebar lebih tipis sehingga semuanya membutuhkan waktu lebih lama. Jika Msft merasa mereka memiliki anggaran untuk membawa hal-hal seperti ini ke dalam tim utama, saya ingin membicarakannya dengan seseorang;)

Hanya beberapa pemikiran tentang penataan gaya dan kontrol template yang disederhanakan, seperti membuatnya lebih mudah untuk menambahkan perilaku kustom untuk gaya dan kontrol bawaan. Contoh sempurna di sini adalah Button styling, ketika kita perlu mengganti seluruh template kontrol untuk mengubah warna hover atau menggunakan radius batas. Mengatur beberapa dari mereka secara langsung, seperti di css , akan mencegah pembuatan kilometer kode XAML

@AntiPasha Pernahkah Anda mendengar tentang gaya kelas ringan ? Dengannya Anda dapat dengan mudah mengubah warna hover tanpa harus membuat ulang seluruh gaya:

Mengubah warna hover untuk tombol hanya akan menjadi:

            <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>

Properti Control.CornerRadius juga ditambahkan di SDK 17763 dan tim WinUI juga memperkenalkan sumber daya yang dapat diganti untuk menambahkan penyesuaian aplikasi atau halaman dengan mudah tanpa harus mengubah gaya kontrol: https://github.com/microsoft/microsoft-ui- xaml-specs/blob/user/chigy/roundedcorner/active/RoundedCorner/roundedcorner.md#customization -options

Dan menariknya, jika XAML tooling akan disatukan, apakah kita akan memiliki kemampuan untuk membuat semacam shared xaml files?
Sesuatu seperti:

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

Haruskah itu semacam dialek bersama dengan ruang nama root khusus? (seperti proyek bersama di Visual Studio). Itu bisa terlihat seperti xaml bersyarat.

@Tirraon ini adalah contoh yang sangat menarik, tetapi saya pikir ketika kita berbicara tentang alat pemersatu, lebih baik untuk memulai dengan pola pikir bahwa platform akan ada seperti yang mereka lakukan hari ini, dan kami tidak mencoba untuk membuat Standar Xaml lain setara.

Kita dapat menggunakan namespace default untuk membedakan platform "tingkat atas" mana yang dimiliki oleh file xaml, jadi misalnya, kita dapat memiliki namespace default berikut untuk setiap platform XAML (ini sebagian besar hipotetis, jadi bawalah dengan sebutir garam ):

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

Jadi untuk mencampur WinUI dengan WPF menggunakan Xaml Islands, Anda memiliki markup yang terlihat seperti ini:

<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>

Bagaimana menurutmu?

@stevenbrix
Dalam contoh Anda untuk UWP itu akan membuat kedua tombol, bukan?
Maksud saya, misalnya, ketika xmlns=".../xaml/presentation" adalah namespace tingkat atas dan UserControl wutg StackPanel tersedia di uwp dan wpf, maka bukankah Tombol kedua akan tersedia juga di kedua platform?

ketika kita berbicara tentang alat pemersatu, lebih baik untuk memulai dengan pola pikir bahwa platform akan ada seperti yang mereka lakukan hari ini

Ya, saya sangat setuju dengan itu.

Dalam contoh Anda untuk UWP itu akan membuat kedua tombol, bukan?
Maksud saya, misalnya, ketika xmlns=".../xaml/presentation" adalah namespace tingkat atas dan UserControl wutg StackPanel tersedia di uwp dan wpf, maka bukankah Tombol kedua akan tersedia juga di kedua platform?

@Tirraon , contoh yang saya berikan adalah murni untuk aplikasi WPF yang menggunakan Xaml Islands untuk memodernisasi aplikasi mereka secara bertahap. Itu tidak dimaksudkan untuk markup "standar" yang digunakan antara aplikasi WPF dan WinUI, apakah itu masuk akal?

Saat ini, pembuat aplikasi yang ingin menggunakan Pulau Xaml harus membuat kontrol pengguna untuk setiap pulau. Mereka kemudian mereferensikan tipe melalui string di markup WPF mereka, daripada menyematkan elemen WinUI secara alami di markup WPF.

Saya menggunakan ponsel saya sekarang, tetapi saya bisa mendapatkan yang lebih konkret sebelum dan sesudah apa yang saya usulkan begitu saya dekat dengan PC saya.

@stevenbrix
Oh, sekarang aku mendapatkanmu, terima kasih.

@stevenbrix
Oh, sekarang aku mendapatkanmu, terima kasih.

@Tirraon hebat! Senang kita berada di halaman yang sama ️

Maaf jika ide saya tampaknya keluar dari bidang kiri, kami telah berdiskusi awal tentang bagaimana kami berpotensi menyatukan perkakas, dengan tujuan meningkatkan skenario Pulau Xaml. Apakah Anda pikir ada nilai dalam hal seperti itu?

FWIW, saya benar-benar berpikir ada manfaat dalam sesuatu seperti yang Anda usulkan. Tapi saya mencoba untuk fokus pada sesuatu yang bisa kita selesaikan dalam kerangka waktu WinUI3/.NET5.

Cari tahu cara merender WinUI Xaml ke beberapa saluran yang menerjemahkan output ke kanvas asli dan menerima input dari sistem pesan asli. Seperti WinUi.Adapters.DirectX, WinUI.Adapters.WASM, WinUi.Adapters.X, WinUi.Adapters.Android.

Menerapkan semua adaptor tidak diperlukan saat Peluncuran, hanya yang diperlukan untuk mendukung Windows 10.

Dari: Steven Kirbach [email protected]
Dikirim: Kamis, 7 November 2019 09:13:46
Kepada: microsoft/microsoft-ui-xaml [email protected]
Cc: Ninja Tajam [email protected] ; Komentar [email protected]
Subjek: Re: [microsoft/microsoft-ui-xaml] Pengalaman dan Perkakas Pengembang WinUI 3.0 - Diperlukan Masukan (#1045)

@stevenbrix https://github.com/stevenbrix
Oh, sekarang aku mendapatkanmu, terima kasih.

@Tirraon https://github.com/Tirraon hebat! Senang kita berada di halaman yang sama ️

Maaf jika ide saya tampaknya keluar dari bidang kiri, kami telah berdiskusi awal tentang bagaimana kami berpotensi menyatukan perkakas, dengan tujuan meningkatkan skenario Pulau Xaml. Apakah Anda pikir ada nilai dalam hal seperti itu?

FWIW, saya benar-benar berpikir ada manfaat dalam sesuatu seperti yang Anda usulkan. Tapi saya mencoba untuk fokus pada sesuatu yang bisa kita selesaikan dalam kerangka waktu WinUI3/.NET5.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, melihatnya di GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLBHRGZTDFHFWQTAFK3QSQWCVA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMXFLY#issuecomment-551121583 , atau berhenti berlangganan https://github.com/ pemberitahuan/berhenti berlangganan-auth/AD3GCLF2BUTXQFPSVNULZODQSQWCVANCNFSM4ICOLUJQ .

Ya tolong, skenario Pulau XAML mengerikan saat ini

@sharpninja
Anda harus melihat Uno
https://platform.uno/
Juga akan mendukung WinUI 3.0 untuk setiap platform
https://platform.uno/winui-on-windows7-via-unoplatform/

@stevenbrix
Saya tidak terlalu berpengalaman dengan Xaml Islands dan biasanya bekerja dengan UWP biasa. Tapi saya pasti perlu melihatnya lebih dekat.
Proposal saya tidak terkait dengan Xaml Islands itu sendiri, tetapi lebih terkait untuk WinUI secara umum, karena akan bekerja di lebih dari satu platform.

Proposal saya tidak terkait dengan Xaml Islands itu sendiri, tetapi lebih terkait untuk WinUI secara umum, karena akan bekerja di lebih dari satu platform.

@Tirraon , yup saya benar-benar mengerti, dan sangat suka di mana kepala Anda berada

Saya telah berbicara singkat dengan @jeromelaban dan perusahaan tentang apa yang Anda usulkan, dan pasti ada minat. Belum ada rencana atau komitmen konkret, karena kami masih dalam tahap diskusi yang sangat awal. Masukan semacam ini sangat bagus, dan membantu kami lebih memahami nilai yang diberikannya kepada pelanggan kami

Dengan skenario pulau XAML yang saya maksud adalah skenario C++. Lihat pesan saya sebelumnya di utas ini untuk daftar masalah yang saya hadapi.

Ya tolong, skenario Pulau XAML mengerikan saat ini

Dengan skenario pulau XAML yang saya maksud adalah skenario C++. Lihat pesan saya sebelumnya di utas ini untuk daftar masalah yang saya hadapi.

@sylveon Saya melihat komentar Anda (tautan di bawah), dan ya itu terdengar sangat mengerikan. Maaf Anda mengalaminya, saya yakin kami akan membuatnya lebih baik.
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -512945553
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -513505038

Banyak rasa sakit yang Anda alami terkait sistem proyek suara, dan saya tahu itu adalah sesuatu yang ada di radar banyak orang (walaupun saya cukup terpisah). Pernahkah Anda melihat video ini yang dilakukan beberapa anggota tim kami di XAML tooling? Tautan itu akan memulai video YouTube pada titik di mana @michael-hawker dan @marb2000 mulai memasuki pengalaman Pulau

Ada banyak hal yang akan membuat pengalaman Pulau Xaml mudah dan alami untuk digunakan. Aspek yang saya maksud adalah bahwa saat ini, cara Anda memasukkan konten Island of UWP di WPF adalah seperti ini (dari video di atas):

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

Saya pikir kita bisa melakukan lebih baik dari itu, dan memberikan sesuatu seperti ini:

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

@stevenbrix

Saya telah berbicara singkat dengan @jeromelaban dan perusahaan tentang apa yang Anda usulkan, dan pasti ada minat. Belum ada rencana atau komitmen konkret, karena kami masih dalam tahap diskusi yang sangat awal. Masukan semacam ini sangat bagus, dan membantu kami lebih memahami nilai yang diberikannya kepada pelanggan kami

Ada begitu banyak minat! (Percakapan ini muncul di mana-mana) Jika posting WinUI 3.0 bergeser ke implementasi lintas platform, Anda akan memiliki banyak dukungan pengembang. Simak saja pembahasannya di #1461. Dalam jangka pendek menggunakan teknologi Uno Platform untuk mengubah XAML/C# menjadi HTML/WASM untuk menjalankan aplikasi UWP di semua platform akan luar biasa. Jangka panjang saya khawatir tentang dampak kinerja berjalan di Electron atau Browser dan ada ruang untuk arsitektur yang lebih efisien.

Intinya, saya tahu semua orang sibuk di WinUI 3.0 saat ini. Tetapi ketika itu selesai, alangkah baiknya jika kita menghubungkan @jeromelaban , @marb2000 , @jevansaks dan lainnya untuk mencari cara terbaik untuk membuat UWP dirender di mana-mana. Itu juga akan menjadi diskusi komunitas yang sangat menarik untuk panggilan di masa mendatang.

WinUi adalah satu-satunya jalan waras yang membuat Neo dan Duo bertahan

Dari: pemberitahuan [email protected]
Dikirim: Kamis, 7 November 2019 12:00:07 PM
Kepada: microsoft/microsoft-ui-xaml [email protected]
Cc: Ninja Tajam [email protected] ; Sebutkan [email protected]
Subjek: Re: [microsoft/microsoft-ui-xaml] Pengalaman dan Perkakas Pengembang WinUI 3.0 - Diperlukan Masukan (#1045)

@stevenbrix https://github.com/stevenbrix

Saya telah berbicara secara singkat dengan @jeromelaban https://github.com/jeromelaban dan perusahaan tentang apa yang Anda usulkan, dan pasti ada minat. Belum ada rencana atau komitmen konkret, karena kami masih dalam tahap diskusi yang sangat awal. Masukan semacam ini sangat bagus, dan membantu kami lebih memahami nilai yang diberikannya kepada pelanggan kami

Ada begitu banyak minat! (Percakapan ini muncul di mana-mana) Jika posting WinUI 3.0 bergeser ke implementasi lintas platform, Anda akan memiliki banyak dukungan pengembang. Simak saja pembahasannya di #1461 https://github.com/microsoft/microsoft-ui-xaml/issues/1461 . Dalam jangka pendek menggunakan teknologi Uno Platform untuk mengubah XAML/C# menjadi HTML/WASM untuk menjalankan aplikasi UWP di semua platform akan luar biasa. Jangka panjang saya khawatir tentang dampak kinerja berjalan di Electron atau Browser dan ada ruang untuk arsitektur yang lebih efisien.

Intinya, saya tahu semua orang sibuk di WinUI 3.0 saat ini. Tapi ketika itu selesai alangkah baiknya jika kita menghubungkan @jeromelaban https://github.com/jeromelaban , @marb2000 https://github.com/marb2000 , @jevansaks https://github.com/jevansaks dan lainnya ke cari tahu cara terbaik untuk membuat UWP merender di mana-mana. Itu juga akan menjadi diskusi komunitas yang sangat menarik untuk panggilan di masa mendatang.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, melihatnya di GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLCHIRMGIIB4EEMXQATQSRJSPA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDNI2QA#issuecomment-551193920 , atau berhenti berlangganan https://github.com/ pemberitahuan/berhenti berlangganan-auth/AD3GCLCAZIOGVET6CJKLKLTQSRJSPANCNFSM4ICOLUJQ .

WinUi adalah satu-satunya jalan waras yang membuat Neo dan Duo bertahan

Saya cenderung setuju, tetapi mendapatkan UI yang sama dari aplikasi Windows, berjalan di Android dan Surface Duo. Dengan intervensi minimal dari pengembang - itulah cawan suci.

Jika WinUI memiliki peluang untuk menjadi platform pengembangan utama, dan memberi Windows kesempatan untuk tidak hanya menjadi wadah aplikasi platform lain dalam jangka panjang. (Tidak selalu merupakan hal yang buruk, jika menyangkut aplikasi besar yang sudah mapan, tetapi untuk LoB dan aplikasi besar berikutnya...)

Saya membuat bahasa berorientasi Aplikasi saya sendiri dan ingin mendukung penggunaan WinUI dengan XAML dan bahasa saya untuk kode di belakang. Akan lebih baik jika alat tersebut menawarkan kemampuan bahasa untuk menyediakan pembuatan kode untuk XAML. Apa yang lebih baik adalah jika pembuat kode XAML membangun IL sebagai kelas parsial yang dapat diselesaikan menggunakan bahasa apa pun. Itu berarti generator kode akan menghasilkan rakitan IL yang dapat dikompilasi.

Saya membuat bahasa berorientasi Aplikasi saya sendiri dan ingin mendukung penggunaan WinUI dengan XAML dan bahasa saya untuk kode di belakang. Akan lebih baik jika alat tersebut menawarkan kemampuan bahasa untuk menyediakan pembuatan kode untuk XAML. Apa yang lebih baik adalah jika pembuat kode XAML membangun IL sebagai kelas parsial yang dapat diselesaikan menggunakan bahasa apa pun. Itu berarti generator kode akan menghasilkan rakitan IL yang dapat dikompilasi.

Ada XAML Direct, tetapi saat ini didukung oleh C# dan C++.
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

Bukan itu yang saya maksud. Maksud saya output dari alat pembuat kode adalah IL, bukan C# atau C++. Dengan begitu kompiler saya dapat mengubah XAML menjadi IL dan kemudian mewarisi kelas itu.

@sharpninja Ini juga akan bermanfaat, jika juga dapat menghasilkan LLVM Bytecode bukan hanya kode C++.

Dengan begitu kita dapat menggabungkannya dengan MIDL dan XLang untuk menghasilkan perpustakaan COM dan file WinMD untuk digunakan di semua skenario yang didukung Xlang.

Dengan topi C++ saya, apa yang ingin saya lihat tentang perkakas WinUI untuk C++, adalah agar Microsoft akhirnya mengejar apa yang telah dilakukan C++ Builder sejak pertengahan 90-an.

Menyediakan alat RAD aktual untuk pengembangan berbasis C++.

C++/CLI gagal, meskipun dengan formulir ada beberapa solusi.

C++/CX sepertinya memang begitu, tetap saja dibutuhkan sedikit lebih banyak usaha daripada yang mampu dilakukan oleh C++ Builder.

Sekarang C++/WinRT mungkin standar C++17, tetapi pengalaman keseluruhan untuk pengembang desktop terasa seperti penurunan, dengan peningkatan boilerplate yang harus ditulis secara manual, perhatian tambahan bagaimana tipe COM melewati batas ABI dan kurangnya desainer mendukung.

Jadi saya masih menggunakan C++/CX untuk saat ini, karena saya tidak merasa harus berurusan dengan semua boilerplate yang diperlukan oleh kompiler MIDL, dan dukungan COM ABI.

Di sisi lain, dengan topi .NET saya, saya ingin melihat pustaka C++ saja seperti DirectX akhirnya diekspos sebagai komponen WinUI, beberapa cinta Blend, dan mengingat bahwa F# seharusnya juga merupakan bahasa .NET dari Microsoft.

Saya mengalami banyak perjuangan untuk mencoba beralih ke WinUI. Ada sejumlah perpustakaan pihak pertama dan ketiga yang tidak menggunakan WinUI saat ini dan ketergantungan pada mereka menjadi bermasalah. Misalnya, SDK Perilaku.

Ini adalah ide yang saya miliki ketika berbicara tentang StatusBar di Discord Komunitas UWP ..

Di Visual Studio, minta kotak alat menyertakan entri untuk kontrol WPF yang hilang dari UWP dan ketika entri tersebut dipilih, perlihatkan sembulan yang menjelaskan cara mensimulasikan kontrol tradisional.

Ide ini berasal dari keinginan untuk memudahkan transisi bagi orang-orang yang datang dari WPF (atau kerangka kerja lain) di mana mereka berharap untuk melihat kontrol tertentu, dan tidak menemukan kontrol tersebut dapat dianggap sebagai pengalaman yang menggelegar. Bagaimana orang tahu bahwa CommandBar dapat digunakan seperti StatusBar? Saya pikir kita perlu membuatnya sesederhana mungkin bagi orang-orang untuk pindah ke WinUI. Ini mungkin berfungsi untuk mengisi beberapa celah tanpa harus benar-benar mengembangkan semua kontrol yang hilang.

EDIT:
Dan untuk kelengkapan, berikut adalah hal lain yang saya katakan tentang Status Bar .. hanya menunjukkan bagaimana seseorang mungkin mendekati UWP (atau WinUI) jika mereka tidak terbiasa dengannya ..

Re: StatusBar - Saya berpikir dari perspektif pengguna kerangka kerja tradisional yang mencoba UWP - dan melihat bahwa itu tidak memiliki StatusBar - masih menjadi pokok di banyak aplikasi. Yap, CommandBar mungkin lebih baik. Tetapi orang tidak tahu apa itu CommandBar atau mungkin mengira itu sesuatu yang lain. Seseorang di atas bahkan menyarankan agar saya menambahkan Grid, meletakkannya di bawah, membuatnya satu baris tinggi dan menambahkan berbagai kontrol untuk menampilkan barang-barang. Jadi sepertinya desainer Xaml yang ada tidak tahu tentang CommandBar. Bagaimanapun, mungkin Anda benar, mungkin CommandBar lebih baik, tetapi Paul Thurrot tidak menggunakannya di aplikasi notepad UWP-nya, ia menggunakan kisi. Jadi sepertinya CommandBar tidak dikomunikasikan sebagai pengganti StatusBar. Pengembang kasual (atau baru) masih mencari StatusBar dan tidak menemukannya. Saya tahu Paul Thurrot bukan pengembang, tetapi Anda mengerti maksud saya.

Akan lebih bagus jika cuplikan disuntikkan ke xaml dengan kasus penggunaan normal juga.

Dari: pemberitahuan [email protected]
Dikirim: Selasa, 18 Februari 2020 19:05:39
Kepada: microsoft/microsoft-ui-xaml [email protected]
Cc: Ninja Tajam [email protected] ; Sebutkan [email protected]
Subjek: Re: [microsoft/microsoft-ui-xaml] Pengalaman dan Perkakas Pengembang WinUI 3.0 - Diperlukan Masukan (#1045)

Ini adalah ide yang saya miliki ketika berbicara tentang StatusBar di Discord Komunitas UWP ..

Di Visual Studio, minta kotak alat menyertakan entri untuk kontrol WPF yang hilang dari UWP dan ketika entri tersebut dipilih, perlihatkan sembulan yang menjelaskan cara mensimulasikan kontrol tradisional.

Ide ini berasal dari keinginan untuk memudahkan transisi bagi orang-orang yang datang dari WPF (atau kerangka kerja lain) di mana mereka berharap untuk melihat kontrol tertentu, dan tidak menemukan kontrol tersebut dapat dianggap sebagai pengalaman yang menggelegar. Bagaimana orang tahu bahwa CommandBar dapat digunakan seperti StatusBar? Saya pikir kita perlu membuatnya sesederhana mungkin bagi orang-orang untuk pindah ke WinUI. Ini mungkin berfungsi untuk mengisi beberapa celah tanpa harus benar-benar mengembangkan semua kontrol yang hilang.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, melihatnya di GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLGYERSFO7LBXKWBBRDRDSAWHA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMF6O3Y#issuecomment-587982703 , atau berhenti berlangganan https://github.com/ pemberitahuan/berhenti berlangganan-auth/AD3GCLFLGA773XOS5OSG5ULRDSAWHHANCNFSM4ICOLUJQ .

Kisah pengembang harus menyertakan semacam daftar perbandingan.

Konsep yang melekat pada aplikasi Win32, jadi Bilah Status, Bilah Alat, Menu, Grippers, Tab, dll. Dalam satu daftar, dan setara WinUI di daftar lainnya.

Halaman itu sendiri termasuk contoh kode dari keduanya, untuk menunjukkan bagaimana UI Aplikasi yang ada dapat dipindahkan ke WinUI.

Pertanyaan-pertanyaan terbuka)
Apakah akan bermanfaat jika kami menyediakan alat migrasi yang mengotomatiskan langkah 1-3?

Ya. Saya mendukung 1 aplikasi Windows Forms "warisan" (warisan berarti tidak ada anggaran untuk menulis ulang) dan 2 atau 3 aplikasi WPF lawas. Aplikasi WinForms mungkin terdampar, tetapi alat untuk membantu mem-port aplikasi WPF dengan cepat ke WinUI 3 akan sangat bagus!

MSIX adalah metode pengemasan modern untuk semua aplikasi. Untuk WinUI di Win32 haruskah kita mendukung ClickOnce? Metode pengemasan lain apa yang harus kami sertakan dukungannya? Khusus untuk WinUI di Win32

Saat ini kami menggunakan ClickOnce untuk memublikasikan aplikasi ke desktop pengguna kami. Beberapa model pembaruan otomatis masih diinginkan.

@JeffSchwandt

Langkah-langkah tersebut berkaitan dengan mengonversi proyek WinUI menggunakan versi sebelumnya (1-2) ke versi 3.

Mengonversi aplikasi WPF ke aplikasi WinUI tidak terlalu layak secara otomatis (tanpa banyak usaha, tetapi meskipun demikian itu akan sangat rawan kesalahan).

Saya harap ini adalah utas yang tepat untuk memposting permintaan ini.

Rust sangat membutuhkan kerangka UI yang tepat saat ini. Akan lebih baik jika WinUI dapat mendukung Rust di masa mendatang dengan SDK asli dan beberapa perkakas.

Saya harap ini adalah utas yang tepat untuk memposting permintaan ini.

Rust sangat membutuhkan kerangka UI yang tepat saat ini. Akan lebih baik jika WinUI dapat mendukung Rust di masa mendatang dengan SDK asli dan beberapa perkakas.

Kabar baik, Rust/WinRT sedang dalam pengembangan yang akan memungkinkan aplikasi rust untuk menggunakan API WinRT seperti WinUI! Lihatlah https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/

@jevansaks Hei, terima kasih atas tanggapannya! Ya, saya tahu Kenny bekerja di Rust/WinRT, tapi saya ingin tahu apakah WinRT adalah satu-satunya lapisan API yang didukung WinUI? Saya tidak yakin bagaimana ini akan sesuai dengan fakta bahwa penggunaan WinRT API dari aplikasi desktop hanya tersedia di Windows 10 1903, sementara WinUI bertujuan untuk mendukung versi Windows 10 yang lebih lama.

Rust/WinRT (seperti C++/WinRT) harus bekerja sampai ke Windows 7. WinRT sendiri selalu bekerja pada aplikasi desktop/win32. Hanya API tertentu yang memiliki persyaratan penyimpanan/uwp/pengemasan (bukan WinRT secara keseluruhan). Selama WinUI tidak memiliki persyaratan tersebut, Anda akan dapat menggunakan WinUI dari aplikasi desktop melalui C++/WinRT dan Rust/WinRT pada platform apa pun yang didukung.

Aplikasi Desktop WinUI harus mendukung Ubin Langsung, dan Pembaruan Ubin - dengan sampel sederhana yang bagus dan alat SDK untuk membuat Ubin lebih mudah daripada aplikasi UWP hari ini.

Saya tidak yakin bagaimana ini cocok dengan fakta bahwa penggunaan WinRT API dari aplikasi desktop hanya tersedia di Windows 10 1903

WinUI Desktop sedang dirancang untuk WinUI 3.0 sekarang, dan itu akan memungkinkan aplikasi Win32 biasa untuk menggunakan downlevel WinUI (paket saat ini turun ke 1803).

Windows UI harus mendukung setidaknya kerangka kerja MVVM utama- MVVM Light, Prism, dan Caliburn. Sayangnya, masalah Anda yang terdokumentasi dengan perubahan pada INotifyPropertyChanged dan INotifyCollectionChanged melanggar ObservableCollectiontentu saja merusak MVVM Light, dan mungkin juga dua kerangka kerja lainnya. Pikir Anda harus tahu.

Sayangnya, masalah Anda yang terdokumentasi dengan perubahan pada INotifyPropertyChanged dan INotifyCollectionChanged melanggar ObservableCollection tentu saja merusak MVVM Light, dan mungkin juga dua kerangka kerja lainnya. Pikir Anda harus tahu.

Terima kasih @terrycox! Kami sadar dan ini akan ditangani oleh WinUI 3.0 RTM, dan idealnya dalam pembuatan pratinjau sebelum itu;)

@terrycox Windows UI harus mendukung setidaknya kerangka kerja MVVM utama- MVVM Light, Prism, dan Caliburn. ... masalah Anda yang terdokumentasi

Ya itu harus memperbaiki masalah yang terdokumentasi, tetapi tidak perlu perpustakaan .Net UI, termasuk WinUI, untuk mendukung kerangka kerja MVVM. Itu hanya perlu mendukung objek yang mewakili elemen UI. .Net MVVM atau kerangka kerja reaktif adalah cara untuk menghasilkan dan mengubah objek .Net yang mewakili UI berdasarkan objek yang mewakili data. Keduanya tidak perlu tahu tentang yang lain. Kerangka kerja apa pun dapat digabungkan dengan pustaka UI apa pun.

tetapi tidak diperlukan pustaka .Net UI, termasuk WinUI, untuk mendukung kerangka kerja MVVM.

Tetapi hal-hal seperti acara dan antarmuka yang disadari oleh UIElements diperlukan dan itulah yang rusak.

Dari: Charles Roddie [email protected]
Dikirim: Rabu, 25 Maret 2020 14:28:46
Kepada: microsoft/microsoft-ui-xaml [email protected]
Cc: Ninja Tajam [email protected] ; Sebutkan [email protected]
Subjek: Re: [microsoft/microsoft-ui-xaml] Pengalaman dan Perkakas Pengembang WinUI 3.0 - Diperlukan Masukan (#1045)

@terrycox https://github.com/terrycox Windows UI harus mendukung setidaknya kerangka kerja MVVM utama- MVVM Light, Prism, dan Caliburn. ... masalah Anda yang terdokumentasi

Ya itu harus memperbaiki masalah yang terdokumentasi, tetapi tidak perlu perpustakaan .Net UI, termasuk WinUI, untuk mendukung kerangka kerja MVVM. Itu hanya perlu mendukung objek yang mewakili elemen UI. .Net MVVM atau kerangka kerja reaktif adalah cara untuk menghasilkan dan mengubah objek .Net yang mewakili UI berdasarkan objek yang mewakili data. Keduanya tidak perlu tahu tentang yang lain. Kerangka kerja apa pun dapat digabungkan dengan pustaka UI apa pun.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-604040104 , atau berhenti berlangganan https://github.com/notifications/unsubscribe-auth/ AD3GCLASFGPUSCRG5PFKOOTRJJLO5ANCNFSM4ICOLUJQ .

Dotnet cli tooling harus digunakan bersama dengan a. sdk inti bersih.
Perintah seperti dotnet new dan dotnet build sudah cukup, tidak ada ketergantungan yang sulit untuk menginstal Visual Studio. Silakan, bergabung sepenuhnya dengan Era Inti .Net!

• Akan lebih baik jika perancang xaml cepat. Perancang XAML saat ini lambat dan selalu melontarkan beberapa kesalahan yang mengatakan beberapa pengecualian terjadi dan itu tidak akan berfungsi. Harap perbaiki itu dan berikan desainer yang tangguh.

• saat ini uwp desn't memiliki API yang dapat mendeteksi layar kunci. Akan lebih baik jika kita diberikan API yang dapat mendeteksi lockscreen dan memberikan boolean sebagai nilai kembalian. Kami juga harus dapat menampilkan beberapa animasi dan lencana setelah mengunci atau membuka kunci.
  - API layar kunci yang ada

• Masalah saya menjelaskan

Sejalan dengan komentar @JensNordenbro ,

Saya ingin melihat templat aplikasi yang membuat aplikasi .NET 5 dengan UI WinUI 3.0 yang mereferensikan aplikasi host toko .NET 5. Ini akan memungkinkan lebih sedikit instalasi redundan .NET 5.0

Dalam aplikasi desktop WinUI, bagaimana seseorang beralih dari muxc.Window.ThisPtr ke hWnd ke jendela asli Win32?

Saya baru saja mencoba templat Mei 2020 baru untuk WinUI 3 Pratinjau 1 untuk Desktop karena saya menyukai ide ini.

Tapi saya punya satu pertanyaan. Dengan WinUI menjadi platform UI asli di Windows, saya terkejut dengan kurangnya komunikasi untuk membuatnya benar-benar menjadi bagian dari Windows 10 juga?

Aplikasi Hello World saya yang dihasilkan berukuran sekitar 120 MB. Tentu, ruang itu murah, tetapi saya tidak memiliki ketergantungan sendiri di sini. Dari jumlah ini, WinUI menghabiskan banyak ruang, kira-kira sebanyak .NET 5 yang disertakan. Itu untuk build x64 saja. Sertakan x86 dalam paket multi-platform dan gandakan ukurannya. Tambahkan beberapa dependensi lain dan kami mungkin dengan mudah melihat aplikasi 300 MB untuk dikemas untuk distribusi.

Mengapa WinUI 3 bukan hanya bagian dari edisi Windows .NET 5? Apakah ini bagian dari upaya modularisasi .NET Core? Tetapi jika tidak, di mana tempatnya? Benar-benar berbahaya di setiap folder aplikasi? Sebagai antarmuka pengguna resmi Windows 10...?

Atau apakah itu akan menjadi bagian dari Windows 10 di masa depan? Jika WinUI diperlakukan lebih seperti perpustakaan sistem dan .NET 5 akan mulai dikirimkan dengan Windows nanti, kami akan melihat aplikasi yang relatif kecil sebagai gantinya. Tapi semoga ini persis cerita untuk Windows 10X setidaknya, dan mungkin juga Windows 10 non-X nanti? Tidak termasuk dua perpustakaan ini serta Windows 10 SDK C#/WinRT bridge DLL, ukuran aplikasi turun menjadi 1-5 MB.

@ryandemopoulos telah mengatakan pada Discord bahwa WinUI akan dikirimkan sebagai paket kerangka kerja, sehingga aplikasi yang menggunakan Store atau MSIX untuk distribusi tidak perlu membawa versi WinUI mereka sendiri, karena mereka semua akan berbagi salinan yang sama.

Membuat WinUI bagian dari Windows itu sendiri akan mengalahkan titik WinUI yang dipisahkan dari OS.

"Tersedia dengan andal dan tidak dalam ukuran aplikasi" menjadi perhatian. Saya berharap .NET 5 didistribusikan dengan cara yang sama.

@lmcdougald Saya mengundang Anda untuk membuka masalah di .NET Core Installer dan meminta .NET 5 menggunakan Framework Packaging untuk servis juga.

@jonasnordlund ada diskusi lain #2500 di mana kita berbicara tentang penyebaran Runtime WinRT. Mungkin Anda menemukan jawaban di sana. :)

@ marb2000 Saya telah membuka masalah, tapi jujur ​​saya bingung. Apakah ini tidak dianggap penting untuk aplikasi apa pun yang akan menghadirkan Windows 10X?

Berikut adalah kompilasi dari beberapa fitur, beberapa di antaranya tidak langsung WinUI, tetapi kekurangannya berdampak langsung pada pengalaman pengembangan klien .NET - termasuk klien UWP, dan terutama klien aplikasi LoB.

• Prioritas utama pertama dan terpenting bagi saya, adalah bagi Anda untuk memelihara Platform Uno. Bagi saya, itulah yang membuat UWP relevan, saya akan berkompromi pada XF atau teknologi lain jika Uno tidak ada. (https://github.com/microsoft/microsoft-ui-xaml/issues/2024)
• API manajemen identitas sisi klien abstrak untuk digunakan dari ViewModel (https://github.com/microsoft/ProjectReunion/issues/31)
• Dukungan anotasi data lengkap, validasi dan judul UI, panjang string, atribut wajib, bidang hanya-baca, tanda air, dll. dll. dll. (https://bit.ly/3gcMJ3a)
• Tingkatkan OData sehingga menjadi alternatif yang tepat untuk layanan RIA yang dulu. Misalnya: mendukung pembuatan atribut, implementasi antarmuka, tipe generik, dokumen XML (https://github.com/OData/odata.net/issues/1746)
• Bawa semua fitur yang hilang dari WPF
• x:Bind juga harus memiliki semua fitur yang dimiliki Binding , seperti cakupan atau binding bersarang (https://github.com/microsoft/microsoft-ui-xaml/issues/2237)
• Restart panas (https://github.com/microsoft/ProjectReunion/issues/44)
• Lebih dari sekadar template Hello World. Seperti yang mengakomodasi untuk login pengguna, MVVM, perutean, proyek x-plat (seperti Uno-Platform), dll. Dengan kata lain, beri lebih banyak kekuatan untuk WTS.
• Fitur tata letak editor XAML WYSIWYG seperti di WinForms, seperti docking, spasi, dll. - ini sepertinya sudah selesai! ❤

Terima kasih atas kompilasi Anda @weitzhandler , sangat nyaman.

Tim WinUI memiliki hubungan yang baik dengan tim produk Uno (non-Microsoft), tim Xamarin Forms/MAUI, dan React Native. Kami secara aktif berkolaborasi dengan mereka dan kami berharap mereka memiliki masa depan yang sukses.

Tentang fitur WPF yang hilang, bisakah Anda mencantumkan yang teratas? Menutup kesenjangan antara WPF dan WinUI adalah salah satu tujuan kami. Ini akan membutuhkan beberapa rilis.

Apropos template yang lebih kompleks. Studio Template Jendela memiliki misi ini.

Saya membuat masalah untuk mencoba mengumpulkan area di mana WinUI kurang dibandingkan dengan WPF #719 @weitzhandler @marb2000

Apropos template yang lebih kompleks. Studio Template Jendela memiliki misi ini.

@marb2000 bisakah kita membawa Window Template Studio ke VSIX kita? Atau mungkin sebaliknya? Cukup gunakan Window Template Studio sebagai kendaraan untuk mengirimkan semua template WinUI3 (dan Project Reunion) ke depan?

Apropos template yang lebih kompleks. Studio Template Jendela memiliki misi ini.

@marb2000 bisakah kita membawa Window Template Studio ke VSIX kita? Atau mungkin sebaliknya? Cukup gunakan Window Template Studio sebagai kendaraan untuk mengirimkan semua template WinUI3 (dan Project Reunion) ke depan?

👀 @crutkas @sibille

Saya sarankan meluangkan waktu dengan C++ Builder (VCL/FMX) dan Qt Creator/Design studio, untuk mempelajari apa yang mungkin dengan C++ dan perkakas modern.

Idealnya WinUI akan menawarkan perkakas serupa dengan produk ini yang sudah dilakukan hari ini untuk GUI lintas platform yang ditulis dalam C++.

Yang saya pedulikan adalah pengalaman pengembangan .NET dan memiliki pengalaman serupa untuk kasus penggunaan, saya terpaksa menggunakan C++, yang karena alasan apa pun tidak tersedia bagi kami.

C++ Builder dan QtCreator mencapai pengalaman seperti itu, dan akan disambut baik jika pengembang .NET merasa betah ketika harus menghabiskan beberapa hari untuk menulis kode C++/WinRT.

Mengapa membuat ini tentang pengembang .NET? Pengalaman C++ XAML sangat buruk, tidak masalah jika Anda seorang pengembang C++ atau .NET.

Saya percaya bahwa akan sangat bagus jika mereka membuka jalan untuk mengaktifkan XAML yang sama berjalan di Desktop, Web (Edge), Seluler, dan IoT.

Kapan kita dapat menggunakan WinUI 3 dalam proyek c++ tanpa C#, Xaml, atau desainer?
juga apakah ada berita tentang tanggal open source inti c ++ WinUI 3?

Sunting: Saya kira saya mendapat jawaban untuk pertanyaan pertama saya, sepertinya ada templat proyek c++ WinUI 3 di WinUI 3.0 Pratinjau 1 :

Setelah menginstal ekstensi .vsix, Anda dapat membuat proyek WinUI 3.0 baru dengan mencari "WinUI" dan memilih salah satu template C# atau C++ yang tersedia.

Kasus penggunaan yang saya ingin WinUI tingkatkan, adalah membuat alat berbasis GUI kecil untuk staf pendukung TI garis depan yang sering ditulis dalam PowerShell. Akan sangat bagus untuk dapat membuat alat semacam ini di Visual Studio Code. Bahkan opsi pengembangan VSCode berbasis C# akan menjadi langkah yang bagus. Visual Studio yang ditiup penuh terasa agak berat dan kompleks untuk kasus ini.

Saat ini lingkungan perusahaan menggunakan alat seperti ini sebagai gantinya:

• https://poshgui.com/ (wizard XAML berbasis web)
• Sapien PowerShell Studio 2020 (milik)
• Admin Script Editor (ASE) (proyek yang sekarang ditinggalkan)

Pola "gunakan Visual Studio untuk XAML" yang umum digunakan lainnya dijelaskan di sini:

• Buat Antarmuka Grafis Sederhana untuk Skrip PowerShell
• Cara Membangun GUI PowerShell untuk Skrip Anda

Pertanyaan saya dalam konteks pertanyaan @mqudsi yang dia tanyakan pada bulan Mei, tetapi tidak ada yang menjawab.

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

Karena ini adalah aplikasi desktop, kami tidak dapat menggunakan ICoreWindowInterop dan saya telah mencoba barang curian acak seperti new HandleRef(this, ThisPtr) mana 'ini' bertipe Microsoft.UI.Xaml.Window tetapi tetap melihat errno untuk Invalid Window Handle. Setelah saya akhirnya mendapatkan hwnd itu, saya dapat mencoba menggunakan lebih banyak COM untuk mengubah gaya jendela dan berbagi dengan orang lain sehingga mereka tidak merasakan sakit yang saya lakukan sekarang :).

Bagi siapa pun yang tertarik, ini adalah pendekatan cepat yang saya gunakan untuk mengambil hWnd untuk jendela utama sehingga saya bisa membuatnya tanpa batas. Solusi lengkap untuk WPF setara dengan WindowStyle = None ada di sini .

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

Saat ini sepertinya tidak ada cara yang mudah untuk menemukan / didokumentasikan untuk mendapatkan hWnd ketika WinUI Anda dalam proses desktop jadi itu sebabnya saya beralih ke pendekatan yang saya gunakan. Tampaknya bekerja cukup baik.

Saya pikir mungkin UWP dan Universal Windows sebagai istilah harus hilang. Persyaratan membawa beberapa bagasi malang yang membuat para pengembang menghindar.

Mungkin kita bisa mengganti template WinUI (Universal Windows) dengan WinUI (Win64)? Lalu ada pilihan Desktop atau Store?

Win64 membingungkan - itu akan menyiratkan bahwa Win32 API hanya mendukung 32-bit, dan sebaliknya UWP hanya mendukung 64 bit, keduanya salah.

Nama Win32 sendiri sudah membingungkan banyak pemula, kami tidak perlu Win64 untuk memperburuk keadaan.

@VagueGit sesuatu yang saya pelajari adalah bahwa memilih nama yang tepat dan menyusun cerita adalah salah satu hal yang lebih rumit. Lebih baik daripada mengganti nama, kami (Microsoft) harus memberikan produk (dan cerita) yang tepat untuk membantu Anda sukses. UWP adalah istilah yang terkenal sebagai Win32, jadi kita harus terus menggunakannya.

Ini adalah pendekatan kami (sangat disederhanakan):

WinUI dapat digunakan dalam dua "jenis" aplikasi yang menargetkan perangkat berbeda:

• Aplikasi Anda menargetkan banyak perangkat dengan banyak input dan faktor bentuk. Kemudian gunakan UWP. UWP dibuat untuk itu; maka Anda harus memenuhi persyaratan seperti model kemasan, toko, model aplikasi, wadah keamanan, dll.
• Aplikasi Anda hanya menargetkan Desktop dan memerlukan akses penuh ke OS. Gunakan Win32 atau Desktop (begitulah cara Visual Studio memanggil WPF, WinForms, MFC, aplikasi).

WinUI di aplikasi UWP dan WinUI di aplikasi Desktop (atau

@marb2000 Memberi nama hal-hal itu sulit, setuju. Namun beberapa nama sayangnya beracun dan harus ditinggalkan. Itu sebabnya dari waktu ke waktu produk diganti namanya. UWP adalah satu, tapi itu hanya pandangan saya ... dan semua orang yang saya ajak bicara. Tapi begitulah.

Kami memiliki aplikasi UWP yang ingin kami migrasikan ke WinUI. Kami tidak menggunakan api Win32, kami hanya menargetkan desktop dan kami tidak ingin menggunakan toko. Bagaimana itu cocok?

@marb2000 Memberi nama hal-hal itu sulit, setuju. Namun beberapa nama sayangnya beracun dan harus ditinggalkan. Itu sebabnya dari waktu ke waktu produk diganti namanya. UWP adalah satu, tapi itu hanya pandangan saya ... dan semua orang yang saya ajak bicara. Tapi begitulah.

Kami memiliki aplikasi UWP yang ingin kami migrasikan ke WinUI. Kami tidak menggunakan api Win32, kami hanya menargetkan desktop dan kami tidak ingin menggunakan toko. Bagaimana itu cocok?

Untuk siapa sebenarnya aplikasi itu?

Sebagai konsumen yang berusaha keras untuk menggunakan aplikasi UWP, jika aplikasi tersebut tidak ada di toko, saya mungkin tidak akan menyentuhnya, apalagi melihatnya.

Jangan khawatir @shaheedmalik kami tidak akan meminta Anda untuk menyentuhnya :-). Kami menulis aplikasi bisnis. Win32 dan UWP. Kami memiliki aplikasi UWP yang telah ada di toko selama beberapa tahun tetapi tidak terlihat di toko. Kami memiliki basis pelanggan bisnis yang mapan sejak 30 tahun yang lalu. Mereka senang dengan aplikasi UWP kami tetapi tidak senang dengan pengalaman toko sehingga kami memindahkannya dari toko.

Jadi kami tahu ada pasar untuk aplikasi bisnis Win64 dan kami yakin kami termasuk di antara sedikit pengembang bisnis yang telah mengirimkan aplikasi Win64 yang akan dibayar oleh pelanggan bisnis. Saya tahu ada beberapa pengembang di utas ini yang menggunakan rute Universal Windows/multi-platform, tetapi mereka cukup jarang. Sebagian besar pengembang bisnis dalam pengalaman saya menargetkan faktor bentuk tertentu.

Jadi berbicara dari perspektif perusahaan pengembang yang telah banyak berinvestasi di UWP dan membuat kesuksesan bisnis UWP, mungkin template untuk WinUI (Desktop) dan WinUI (Store)? Anda hanya perlu mengikuti media teknologi untuk mendapatkan gambaran betapa buruknya UWP dipandang sebagai platform dev.

@VagueGit
"Kami memiliki aplikasi UWP yang ingin kami migrasikan ke WinUI. Kami tidak menggunakan api Win32, kami hanya menargetkan desktop dan kami tidak ingin menggunakan toko. Bagaimana itu cocok?"

Jadi, apakah Anda ingin memigrasikan UWP ke WinUI 3 dan menyebarkan di luar Store? Pertanyaan naif: apakah Anda mencoba sideload MSIX? Adakah alasan selain Store yang menghentikan Anda menggunakan UWP?

@VagueGit
"Jadi kami tahu ada pasar untuk aplikasi bisnis Win64."

Satu pertanyaan, Win64 singkatan dari banyak hal. misalnya kompilasi aplikasi untuk x64. Apa arti Win64 bagi Anda?

@marb2000 UWP memiliki dukungan yang buruk untuk pelaporan bisnis. Kami berpikir bahwa rebranding dapat membantu memulai pengembangan alat pihak ketiga seperti penulis laporan. Kami telah bermain dengan pemuatan samping tetapi itu tidak layak bagi kami sampai 20H1 karena sideloading tidak diaktifkan secara default.

Kami pikir Win64 adalah jalan ke depan di Windows. Micro$ di masa lalu berusaha untuk menjadikan Win32 sebagai warisan tanpa hasil dan sekarang kembali ke posisi itu. Tetapi pada akhirnya Win32 harus pergi, menurut penilaian kami (saya katakan itu setelah 30 tahun pengembangan Win32 sendiri). Kami telah berhasil mengatasi sebagian besar keterbatasan UWP untuk menghadirkan aplikasi bisnis yang akan dibeli oleh perusahaan. Kami khawatir bahwa iterasi lain dari UWP akan memiliki daya tarik terbatas tanpa rebranding.

Seperti yang ditunjukkan oleh kebingungan

Saya setuju bahwa rebranding mungkin diperlukan, tetapi Win64 adalah cara yang buruk untuk melakukannya. Sampai ada yang resmi, sebaiknya gunakan istilah UWP agar dipahami semua orang.

@sylveon UWP dipahami oleh semua orang sebagai kegagalan. Kami menyukainya tetapi beberapa orang lain melakukannya. Itulah mengapa rebranding itu penting. Apa pendapat Anda tentang WinUI (Deskop) atau WinUI (Store) sebagai templat proyek?

WinUI (Store) tidak bagus karena Anda juga dapat mengirimkan aplikasi Win32 di toko, atau mengirim aplikasi UWP di luar toko. WinUI (Desktop) bagus.

@sylveon WinUI (Toko) tidak menghalangi proyek lain yang menargetkan toko. Itu hanya berarti Anda ingin memulai dengan serangkaian kemampuan yang memungkinkan rilis melalui toko.

Ini cukup buruk untuk membingungkan pemula.

Ini tidak dimaksudkan untuk ditujukan pada orang tertentu di utas ini, melainkan pendapat saya sendiri sebagai pengembang aplikasi desktop/pemilik perusahaan.

Saya tidak pernah terjebak dalam sesuatu yang bernama. Saya hanya peduli fitur apa yang dimilikinya dan seberapa baik dukungannya.

Saya berpendapat bahwa ada juga banyak pengembang (termasuk saya) yang menjadi bersemangat ketika kami di sini istilah seperti MAUI, tetapi segera kecewa ketika kami menyadari itu masih basis kode yang sama. Rebranding menunjukkan "hei lihat, kami sedang membangun hal baru yang dimulai dari basis kode yang sama sekali berbeda dari yang memblokir Anda dari xyz". Apa yang saya suka lihat adalah daftar besar fitur yang berubah yang mengimbangi perjuangan yang saya atau orang lain miliki.

Platform berkembang dari waktu ke waktu sama seperti produk atau merek apa pun. Saya menemukan kenyamanan dalam merek dan nama yang telah ada selama beberapa dekade karena secara otomatis menyiratkan LTS. Meskipun saya menyadari bahwa perubahan nama terkadang merupakan suatu keharusan, mereka juga mengingatkan pengembang akan pengabaian (Silverlight). Ada banyak model mobil yang ada selama bertahun-tahun di mana mereka diganggu dengan masalah tetapi akhirnya menjadi merek yang dicintai dan dihormati. Ada banyak hal yang bisa dikatakan dengan keakraban, bahkan jika Anda tidak menyukai pengalaman sebelumnya, karena Anda tahu apa yang diharapkan. Selama masalah diselesaikan, itulah yang terpenting.

Saya kira setidaknya ada dua audiens yang perlu diperhatikan; pengembang dan pengguna produk akhir. Sebagai pengembang/pemilik bisnis, jika saya memiliki pelanggan yang membutuhkan aplikasi, dan mereka telah digerogoti oleh nama-nama teknologi yang mendasarinya, tugas saya untuk menanamkan kepercayaan kepada mereka bahwa produk yang diwakili oleh nama tersebut telah matang dan apa yang menjadi perhatian mereka di masa depan. masa lalu telah diperbarui. Di sisi lain, jika saya mengatakan "lihat ada hal hebat baru yang disebut WinUI atau MAUI" dan mereka sudah memiliki produk WPF atau UWP atau Xamarin yang kami kembangkan untuk mereka, respons yang dapat diperkirakan dari mereka adalah "oh bagus, sekarang aplikasi kami ditulis dalam 2,3 atau 4 teknologi yang berbeda”. Di sinilah saya kemudian harus menjualnya. Mengingat semua pelanggan berbeda, saya akan menghadapi penolakan apakah Anda membiarkan nama apa adanya, atau mengubahnya.

Yang penting pada akhirnya (bagi saya) adalah kita memiliki alat yang kita butuhkan untuk menulis aplikasi kaya fitur yang menarik yang memiliki LTS. Saya terpompa ketika saya melihat produk mencapai tenggat waktu dan saya bisa membaca fitur baru dan daftar resolusi masalah saat produk dirilis. Saya menyukai ini tentang NetCore/Net5 (perubahan nama LOL) sejak 2016. (BTW, mencoba memberi tahu pelanggan saya bahwa .Net5 adalah apa yang kami rencanakan untuk ditargetkan setahun setelah saya meyakinkan mereka untuk pindah ke NetCore juga tidak mudah!)

Saat ini saya hanya ingin maju cepat ke titik ketika saya dapat menulis aplikasi desktop dengan dialek XAML dan mendapatkan kinerja rendering yang sama dengan yang ditawarkan UWP/WinUI (tanpa kotak pasir UWP). Untuk alasan itu dan karena pratinjau September yang turun, saya akan mulai menguji mengemudi Avalonia. Saya menyukai kesamaan WPF saat mendengar tentang kinerja rendering melalui SkiaSharp.

Ini akan menjadi menarik dalam beberapa tahun ketika opsi untuk pengembangan UI telah stabil. Mereka dapat memberi nama templat proyek apa pun yang mereka inginkan, itu tidak akan mengubah pendapat saya tentang kurangnya fitur.

Saya menghargai Anda semua.

Saya mendapatkan apa yang dikatakan jtbrower di emailnya. Perusahaannya seperti perusahaan kami adalah salah satu dari sedikit perusahaan yang berhasil menempuh jalur xaml. Kita tidak perlu yakin akan manfaatnya.

Tapi sebagus apa pun itu, xaml adalah bencana bagi Micro$. Pengembang sangat baik tinggal dengan WinForms, atau melompat sepenuhnya ke pengembangan web. Sejak UWP eksodus pengembang memburuk.

Agar teknologi xaml berkelanjutan, Micro$ harus memenangkan jutaan pengembang yang gagal mereka ikuti. Bagi para pengembang, vendor alat, dan media teknologi, UWP adalah jalan buntu. Iterasi lain dari UWP tidak akan memenangkan mereka.

@VagueGit tetapi pengembang cukup tertarik untuk mengetahui produk yang diganti namanya menjadi sama. Mereka mengenal MAUI sebagai Xamarin Forms yang diganti namanya. Bahkan mereka tampaknya melangkah terlalu jauh untuk mengatakan bahwa MAUI adalah nama yang dicuri. Saya tidak berpikir Anda dapat memotivasi pengembang biasa dengan perubahan nama. Kita semua menginginkan fitur bukan? Tidakkah Anda lebih suka melihat UWP mengizinkan banyak Windows, atau mengizinkan kepercayaan penuh? Jika mereka melakukan keduanya, kita semua dapat menargetkan UWP dan mungkin menyimpan kotak pasir untuk aplikasi toko. Saya hanya bermimpi keras apa yang benar-benar akan membuat saya bersemangat! Fitur!!

Sangat setuju dengan Anda jtbrower. Saya juga menghargai Anda membantu saya dan saya berharap orang lain mengkritik ide-ide mereka. Tetapi bagaimana cara menandai ke pengembang dan vendor alat bahwa ada dua UWP yang berbeda, Store dan Desktop?

Jadi tentu saja mereka yang ingin melanjutkan jalur UWP bisa mulai dengan template UWP Store, tetapi mereka yang menginginkan desktop 64bit, bukan sandbox dan kepercayaan penuh ... yah itu bukan UWP bukan?

UWP terlihat di pasar sebagai lumpuh. Semua kecuali kami yang sangat keras menyerah pada UWP ketika Micro$ sendiri mundur dari membangun aplikasi mereka sendiri di UWP.

Pasar dev tidak memperhatikan perkembangan di UWP. Desktop 64bit, bukan kotak pasir dan kepercayaan penuh, lebih dari sekadar perubahan nama; itu adalah paradigma yang berbeda. Namun jika masih disebut UWP maka akan luput dari perhatian mereka yang telah menghapus UWP.

@VagueGit Saya senang Anda telah menemukan kesuksesan dengan UWP. Penamaan itu sulit, dan fakta bahwa kami menyebutnya "Platform Windows Universal" dan itu tidak benar-benar dapat dipertahankan oleh sebagian besar pengembang Windows membuatnya, yah, tidak terlalu "universal". Ringkasan Proyek Reunion yang akurat adalah untuk memperbaikinya dan membuat setiap aspek UWP benar-benar dapat diakses oleh semua pengembang Windows.

Saya setuju bahwa UWP memiliki nama yang buruk, jika Anda mengetik frasa "UWP is" ke mesin pencari, saran otomatis pertama yang akan diberikan Bing atau Google adalah "UWP sudah mati". Namun, menurut saya @marb2000 benar bahwa kita harus terus menggunakan nama itu, terlepas dari beban yang dibawanya.

Dengan itu dikatakan...

Saat ini, banyak aspek dari proyek Desktop akan dapat menggunakan bagian berbeda dari apa yang biasa kami definisikan sebagai "UWP":

1. Tumpukan UI (alias WinUI3)
2. Kemasan MSIX
3. Sumber Daya MRT

Setelah CoreApplication diangkat, maka satu-satunya perbedaan antara UWP dan Desktop adalah model kotak pasir yang Anda pilih untuk aplikasi Anda dan perangkat mana yang dapat Anda targetkan.

Kami telah membahas membuat modifikasi pada template proyek dan memiliki pengalaman seperti wizard yang lebih akurat menjelaskan hal ini.

@JeanRoca adalah PM yang mengemudikan ini dan mungkin memiliki lebih banyak informasi yang dapat dia bagikan

Saya suka ide template WinUI Desktop. Lebih tepat dari Win32 dan melihat ke depan. Ini adalah template yang akan kita mulai sedangkan Win32 menyarankan batasan 32bit. WinUI Desktop diharapkan akan mendapatkan daya tarik di media dan di antara para pengembang.

Saat aplikasi UWP dirilis di luar toko, paketnya adalah .appinstaller. Jika kami memutakhirkan aplikasi itu ke Win UI Desktop, paket penginstal berubah dari appinstaller menjadi msix.

Dengan asumsi kami menyimpan detail dalam paket aplikasi yang sama dan mengubah versi dengan tepat, apakah Windows akan mengenali ini adalah versi baru dari aplikasi yang sama dan mempertahankan data lokal, atau akan menginstalnya sebagai aplikasi yang berbeda?

Dari pemahaman saya, WinUI 3.0 tidak akan pernah dikonsumsi dari .NET Framework <= 4.8. Jadi jika kita berbicara tentang WinUI, kita berbicara tentang .NET Native atau .NET 3.1/5+ (atau kumpulan binding lainnya).

Adakah saran tentang cara memajukan/bertanya lebih lanjut tentang pengemasan kerangka kerja untuk .NET 5 (atau saya kira 6 pada saat ini)? Saya membuka masalah dan tidak mendapat tanggapan. Bundling .NET 5 dalam aplikasi adalah nonstarter.

@stevenbrix

Setelah CoreApplication diangkat, maka satu-satunya perbedaan antara UWP dan Desktop adalah model kotak pasir yang Anda pilih untuk aplikasi Anda dan perangkat mana yang dapat Anda targetkan.

Sayangnya perbedaan besar lainnya adalah pengembang .NET dipaksa untuk beralih ke C++ untuk API seperti DirectX, yang timnya jelas menolak untuk membuatnya kompatibel dengan UWP meskipun berbasis COM.

Dan dalam proses kembali ke hari-hari produktivitas menulis MIDL secara manual dengan pengalaman seperti notepad yang bagus, dan menyalin file di sekitar, tampaknya tim Windows tidak dapat melepaskan ATL seperti pengalaman dev, alih-alih memberikan pengalaman seperti NET untuk alur kerja C++. C++/CX terlalu tertutup untuk C++ Builder, jadi itu harus dimatikan atas nama hal-hal ISO, yang dengan keberuntungan kita mungkin mendapatkannya di C++23 dan pada tahun 2025 di VS.

Saya ragu ada orang yang akan peduli dengan UWP pada saat itu, kecuali jika pengalaman pengembangan yang tepat ditetapkan untuk menghapus semua kesalahan ini.

Juga melemparkan kami adalah masalah GitHub mengenai tim mana untuk memberikan umpan balik adalah cara yang sangat cepat untuk kehilangan minat. Aku hanya kebetulan terlalu peduli rupanya.

API DirectX tidak dapat dimodifikasi untuk kompatibilitas WinRT karena ini akan menjadi pemutusan API yang signifikan bagi konsumen yang sudah ada, dan itu tidak dapat terjadi.

Ada beberapa pembungkus terkelola yang tersedia untuk DirectX, seperti TerraFX yang merupakan pengikatan 1:1 mentah atau Vortice yang merupakan pembungkus API bergaya C#.

Adapun CX, itu harus pergi. Ekstensi bahasa khusus kompiler buruk dan disukai. Ini secara signifikan menghambat portabilitas kode, sering tertinggal dalam hal dukungan standar C++, dan membutuhkan integrasi vertikal penuh dari perpustakaan yang ada. Alternatifnya, WRL, sangat sulit digunakan dan terlalu bertele-tele. Jadi, tidak mengherankan jika banyak orang (termasuk divisi DX) tidak ingin menulis API WinRT.

C++/WinRT adalah solusi yang jauh lebih baik, sangat disayangkan bahwa ia harus mengembalikan IDL (tetapi kejahatan yang diperlukan saat ini). Tim C++ telah melakukan pekerjaan yang jauh lebih baik pada dukungan standar daripada sebelumnya, jadi tidak mengherankan jika kita benar-benar mendapatkan metaclass sebelum C++23 diselesaikan, yang seharusnya meningkatkan UX pengembang secara radikal.

@sylveon

Jangan kaget bahwa komunitas pengembangan Windows mengabaikan apa pun yang keluar dari Redmond dengan alasan seperti itu untuk penurunan produktivitas.

Hal yang sama terjadi dengan CX... sebagian besar tidak digunakan karena pengembang C++ tidak menyukai ekstensi bahasa berpemilik.

Dengan asumsi kami menyimpan detail dalam paket aplikasi yang sama dan menabrak versi dengan tepat, apakah Windows akan mengenali ini adalah versi baru dari aplikasi yang sama dan mempertahankan data lokal, atau akan menginstalnya sebagai aplikasi yang berbeda?

@VagueGit , ini adalah pertanyaan yang bagus. Pada akhirnya, teknologi untuk menginstal aplikasi UWP dan Desktop adalah sama. Saya merasa jawabannya adalah ya? Saya pikir pada SDK yang lebih baru, bahkan aplikasi UWP memiliki ekstensi .msix (saya bisa saja salah, jadi jangan kutip saya). Saya yakin Anda bisa mencoba ini secara lokal dan mencari tahu? @adambraden untuk fyi.

Adakah saran tentang cara memajukan/bertanya lebih lanjut tentang pengemasan kerangka kerja untuk .NET 5 (atau saya kira 6 pada saat ini)? Saya membuka masalah dan tidak mendapat tanggapan. Bundling .NET 5 dalam aplikasi adalah nonstarter.

@lmcdougald Saya pikir saya tahu masalah mana yang Anda maksud (tetapi saya tidak dapat menemukannya). Akan ada satu, tapi saya membayangkan itu akan terjadi dalam jangka waktu .net6. Semua orang sadar ini adalah sesuatu yang perlu dilakukan.

Dan dalam proses kembali ke hari-hari produktivitas menulis MIDL secara manual dengan pengalaman seperti notepad yang bagus, dan menyalin file di sekitar, tampaknya tim Windows tidak dapat melepaskan ATL seperti pengalaman dev, alih-alih memberikan pengalaman seperti NET untuk alur kerja C++. C++/CX terlalu tertutup untuk C++ Builder, jadi itu harus dimatikan atas nama hal-hal ISO, yang dengan keberuntungan kita mungkin mendapatkannya di C++23 dan pada tahun 2025 di VS.

Juga melemparkan kami adalah masalah GitHub mengenai tim mana untuk memberikan umpan balik adalah cara yang sangat cepat untuk kehilangan minat. Aku hanya kebetulan terlalu peduli rupanya.

@pjmlp Saya menghargai kejujuran dan semangat Anda. Saya sangat setuju bahwa pengalaman C++ saat ini di bawah standar. Kami telah melakukan beberapa hal untuk membuat pengalaman C++ lebih seperti .NET, tetapi seperti yang disebutkan @sylveon , mereka dikenakan biaya. Kami akhirnya memutuskan bahwa jika kami ingin menghabiskan upaya rekayasa untuk membuat C++ hebat, kami harus menuangkannya ke dalam mendorong standar C++. Sangat disayangkan bahwa kelas meta adalah jalan keluar, dan kami sedang mendiskusikan cara untuk meningkatkan pengalaman untuk sementara, karena saya setuju dengan Anda bahwa kami tidak bisa menunggu selama itu.

Terima kasih atas tanggapannya – Saya puas dengan “semua orang sadar ini adalah sesuatu yang perlu dilakukan” dan saya akan hidup dengan biner yang meningkat selama sekitar satu tahun.

@stevenbrix dan @VagueGit - Anda masih dapat menggunakan file appinstaller untuk paket msix Anda. file appinstaller tidak lebih dari file json yang menyediakan uri ke paket Anda. Karena Anda menyebutkan skenario perusahaan, Anda dapat menyesuaikan uri penginstal aplikasi dengan tepat untuk lokasi internal, atau membuatnya berbeda untuk akses eksternal juga - semua tergantung pada CDN Anda. Mengenai pembuatan versi - ya untuk aplikasi terpaket jika Identitas Paket sama, maka menginstal versi baru akan memiliki akses ke data aplikasi yang ada.

@stevenbrix @VagueGit Saya akan membalas dengan informasi yang saya miliki saat ini tentang wizard seperti pengalaman. Saya masih sangat baru dalam peran ini jadi jangan ragu untuk mengambil semua yang saya katakan dengan sebutir garam. Dengan itu, tim saya saat ini sedang mendorong upaya di Windows Template Studio . Aplikasi ini saat ini memungkinkan Anda membuat aplikasi WPF atau UWP baru dari template yang ada di wizard kami dengan halaman dan kerangka kerja yang Anda inginkan.

Tujuan dan rencana saat ini untuk aplikasi ini di masa depan adalah untuk menyatukan dan meningkatkan pengalaman pengembangan untuk semua pengguna. Kami sedang mengembangkan template untuk aplikasi desktop dengan WinUI 3. Anda dapat menemukan masalah pelacakan di sini . Kami juga mendiskusikan melakukan hal yang sama untuk UWP sehingga pengguna kami dapat dengan mudah memigrasikan proyek mereka ketika saatnya tiba. Kami masih belum tahu persis bagaimana ini akan berhasil, tetapi tujuan kami adalah untuk menyatukan dan menyederhanakan pengalaman sebanyak mungkin. Semoga membantu!

Hal yang sama terjadi dengan CX... sebagian besar tidak digunakan karena pengembang C++ tidak menyukai ekstensi bahasa berpemilik.

Mereka menyukainya di dentang, GCC, Intel. xlCC, PGI, CUDA, C++ Builder dan kebanyakan dari platform yang disematkan.

Jelas CX terbunuh karena politik yang tidak dapat menerima lingkungan C++ RAD yang berasal dari Microsoft, dan lebih baik kita semua melakukan MDIL/ATL dengan pengalaman seperti notepad sebagai gantinya.

Saya menghindarinya dengan cara apa pun, apa pun kompilernya. Terutama ketika ekstensi kepemilikan tersebut adalah bahasa yang sama sekali berbeda.

Saya menghindarinya dengan cara apa pun, apa pun kompilernya. Terutama ketika ekstensi kepemilikan tersebut adalah bahasa yang sama sekali berbeda.

Lalu mengapa pengkodean terhadap UI berpemilik seperti WinUI, cukup gunakan standar terbuka seperti X Windows saja.

... seolah-olah itu dapat digunakan di Windows. Saya menghindari ekstensi kompiler karena saya ingin kompiler multitarget (Dentang dan MSVC) untuk validasi kepatuhan standar dan ingin menggunakan standar C++ yang lebih baru.

Kode saya menggunakan C++20. Banyak ekstensi bahasa tidak memiliki dukungan C++17 atau terlambat mendapatkannya. Situasi ini akan berulang dengan C++20 (atau memburuk karena C++20 memiliki lebih banyak hal baru daripada 17). Misalnya, Anda tidak dapat mencampur C++20 ( /std:c++latest ) dan CX ( /ZW ), Anda akan mendapatkan kesalahan kompiler yang mengatakan kedua sakelar tidak kompatibel.

Butuh waktu hingga tahun ini bagi NVCC untuk mendukung C++17 sisi perangkat. Tidak terlihat bagus.

Saya tidak ingin menempatkan diri saya di sudut di mana ekstensi bahasa yang saya gunakan tidak dapat digunakan dengan standar yang lebih baru tetapi saya juga membutuhkan fitur standar baru.

Untuk alasan di atas, saya menghindarinya. Jika kami meregresi pengalaman pengembang WinUI C++ ke ekstensi bahasa, saya akan pindah ke kerangka kerja GUI alternatif.

@sylveon Anda sangat portabel C++ 20 untuk WinUI sama sekali tidak berguna di luar Windows, bersenang-senanglah dengan Qt tanpa ekstensi juga.

Karena tidak ada lagi yang layak digunakan untuk pengguna desktop C++.

Terima kasih telah mengonfirmasi bahwa politik yang tidak masuk akallah yang membunuh CX.

Anjuran untuk bersikap ramah satu sama lain. Saya tidak dapat mengomentari argumen teknis c++ dan tidak akan menilai siapa yang benar.
Intinya adalah bahwa frasa seperti go have fun with X tidak menciptakan suasana yang bersahabat dan kolaboratif di sini. @stevenbrix dan yang lainnya silakan masuk jika diperlukan.

Terima kasih @hansmbakker ️

@pjmm dan @sylveon Saya menghargai percakapan yang penuh gairah dan jujur, senang memiliki pelanggan seperti Anda yang peduli.

Kedua poin ini sangat valid, dan saya pikir dunia ini cukup besar bagi Anda berdua untuk benar.

@pjmlp kami tidak puas dengan pengalaman saat ini untuk c++, dan kami menyadari bahwa kami perlu melakukan sesuatu sebelum metaclass c++. Kami telah berdiskusi tentang c++/winrt bebas idl, dan @kennykerr dan @Scottj1s melakukan pembicaraan Build tentangnya. Sebagian besar masalah yang kami miliki terkait dengan integrasi dengan WinUI, karena kompiler kami memerlukan metadata. Kami ingin meninjau kembali alur kerja ini untuk melihat apakah kami dapat memiliki cerita kohesif yang akan meningkatkan pengalaman pengembang secara keseluruhan. Alih-alih mengembalikan C++/Cx, Apakah versi c++/winrt bebas idl menarik minat Anda?

Hanya untuk menetapkan harapan, saya tidak akan berharap untuk melihat banyak kemajuan di sini pada tahun 2020.

Saya akan sangat tertarik dengan C++/WinRT gratis IDL.

Pengalaman IDE juga bukan yang terbaik. Misalnya, kami tidak dapat membuat panggilan balik acara dari editor XAML seperti yang kami lakukan dengan C# (menu tarik-turun buat panggilan balik baru tidak melakukan apa-apa). Menavigasi ke definisi dari editor XAML juga tidak berfungsi.

Masalah lain dengannya adalah berbagai bug kompiler XAML yang saya isi dalam repo ini, yang membuat saya memerlukan solusi yang tidak diperlukan dalam bahasa lain yang didukung.

@stevenbrix , saya ingin menambahkan suara saya ke C++/WinRT bebas IDL (dan tentu saja tidak ingin melihat kembali ke C++/CX). Kami menulis perangkat lunak lintas platform, dan kami mengkompilasi dengan MSVC dan LLVM (termasuk di Windows), jadi C++ yang sesuai standar sangat penting bagi kami.

@stevenbrix ,

@pjmlp kami tidak puas dengan pengalaman saat ini untuk c++, dan kami menyadari bahwa kami perlu melakukan sesuatu sebelum metaclass c++. Kami telah berdiskusi tentang c++/winrt bebas idl, dan @kennykerr dan @Scottj1s melakukan pembicaraan Build tentangnya. Sebagian besar masalah yang kami miliki terkait dengan integrasi dengan WinUI, karena kompiler kami memerlukan metadata. Kami ingin meninjau kembali alur kerja ini untuk melihat apakah kami dapat memiliki cerita kohesif yang akan meningkatkan pengalaman pengembang secara keseluruhan. Alih-alih mengembalikan C++/Cx, Apakah versi c++/winrt bebas idl menarik minat Anda?

Hanya untuk menetapkan harapan, saya tidak akan berharap untuk melihat banyak kemajuan di sini pada tahun 2020.

Yang hanya menunjukkan betapa buruknya seluruh ide ini dengan C++/WinRT untuk memulai, menurunkannya pada kami tanpa mempertimbangkan penurunan produktivitas kami.

Untuk menempatkan ini dalam perspektif, pengembang lama yang pengalaman pengembang Windowsnya kembali ke Windows 3.0, dan saat ini C++ sebagian besar relevan untuk digunakan bersama aplikasi berbasis .NET, tidak pernah sendiri.

Alat Borland adalah roti dan mentega saya sampai karena berbagai alasan diketahui oleh pengembang Windows lama, jalan ke depan berakhir dengan bermigrasi ke kompiler Microsoft.

Visual C++ tidak pernah _Visual_ sebagai C++ Builder, bahkan dengan C++/CLI, mengingat kurangnya integrasi dengan kompilasi Formulir dan AOT.

C++/CX tampaknya Microsoft akhirnya mendapatkannya, kami akan 25 tahun kemudian diberikan alur kerja produktivitas yang sama seperti menggunakan Delphi/C++ Builder bersama satu sama lain.

Alih-alih apa yang kami dapatkan sebagai langkah politik untuk membunuh C++/CX tanpa memperhatikan penurunan produktivitas kami melambaikan tanggung jawab atas fitur yang hilang ke ISO C++ dan WG 21, seolah-olah semua yang diambil tim Visual C++ dari kami akan menjadi diterima oleh WG 21.

Dan bahkan jika fitur yang diperlukan pada akhirnya akan diadopsi oleh ISO C++, apakah itu akan menjadi 2023, 2026,....? Dan kemudian ada intinya kapan fitur-fitur itu akan benar-benar tersedia untuk pengembang Windows, lihat saja dukungan modul. Kami membutuhkan waktu bertahun-tahun untuk mencapai kesetaraan dengan apa yang telah ditawarkan C++/CX kepada kami sejak Windows 8 dirilis pada tahun 2012.

Jadi mengingat pada tahun 2020 kita tidak akan melihat perbaikan apa pun, kita sudah berbicara tentang 9 tahun di sini, jadi maafkan saya jika saya cenderung sedikit marah dengan bagaimana semua ini telah dikelola, di atas masalah lain yang kita miliki untuk menangani kegagalan UWP, Reunion, .NET eco-system reboot, sementara kami diminta untuk membuat kode seperti tahun 2000 dengan pengalaman notepad MIDL tanpa tulang dan sup template tanpa akhir seperti ATL.

Jadi ya, baik versi C++/WinRT gratis IDL, atau setidaknya pengalaman IDL dengan dukungan Intellisense/Intelicode penuh dan tidak harus menyalin file secara manual. Namun itu tidak akan menghilangkan pengalaman seperti ATL dari kode C++ itu sendiri.

Dari sudut pandang pengembangan .NET/C++, saya tidak peduli dengan perjalanan waktu ke masa lalu kerangka kerja Microsoft, melainkan bagaimana tampilannya jika sudut pandang C++ RAD dianggap lebih serius, sayangnya dengan cara C++/ Kisah WinRT telah dikelola, dan segala sesuatu yang sekarang berjalan dengan backpedaling dari UWP, saya bertanya-tanya ke mana "pengembang, pengembang, pengembang" pergi.

Jadi maaf jika masih terasa agak kasar, tapi itulah yang saya rasakan tentang penurunan produktivitas saya ketika saya harus keluar dari .NET ke C++, atas nama beberapa kemurnian ISO yang sebagian besar kompiler C++ tidak melakukannya.

C++ masih sangat relevan secara mandiri. Banyak aplikasi ditulis dalam C++ mentah tanpa menjalankan kode terkelola. Faktanya, seluruh runtime UWP dan framework XAML/WinUI adalah C++ asli. Aplikasi UWP yang ditulis dalam C++ (untungnya) tidak melibatkan bahasa terkelola.

Saya berpendapat bahwa jika Anda merasa perlu untuk beralih ke C++ di .NET, Anda harus bertanya pada diri sendiri mengapa dan mencoba untuk mengatasi masalah tersebut secara langsung di dalam .NET. Pertunjukan? Gunakan jenis span, stackalloc, dan intrinsik vektor. DirectX, API asli, atau COM? Gunakan penjilidan seperti TerraFX. Berinteraksi dengan lib C++ saja? Terapkan kembali apa yang Anda butuhkan darinya di .NET.

.NET lebih baik tanpa C++, dan C++ lebih baik tanpa .NET.

Saya tidak berpikir templating di cppwinrt seburuk itu. Yang paling mengganggu saya adalah kebutuhan akan gen kode dan waktu kompilasi yang mengerikan yang dihasilkannya.

@sylveon Easy, karena API yang

Borland (sekarang Embarcadero), dan The Qt Company telah menunjukkan bagaimana melakukannya, terserah kepada Microsoft untuk memutuskan seberapa relevan mereka ingin mempertahankan platform.

Coba lihat seberapa jauh Anda akan melangkah dengan ISO C++ di macOS, iOS, Android, ChromeOS GUIs.

Lagi pula, berhenti di sini, ini tidak ada gunanya.

@pjmlp kami memiliki aplikasi lintas platform dengan jutaan baris ISO C++ yang berfungsi dengan baik di iOS/macOS/Windows. C++ adalah satu-satunya bahasa yang digunakan saat Anda peduli dengan kinerja dan/atau masa pakai baterai. Ekstensi C++ tidak baik bagi kami karena kami menggunakan banyak kompiler (yang jelas tidak mengimplementasikan ekstensi satu sama lain).
Kami telah menggunakan C++/CLI sebelumnya dan itu sangat menyebalkan. Pembatasan seperti anggota kelas yang hanya mengizinkan pointer C++ mentah membuat sulit untuk menyimpan pointer pintar. Waktu kompilasi lama (perubahan karakter tunggal membutuhkan waktu MD Merge 5 menit).
C++ termasuk memerlukan pembungkus untuk mengubah pragma yang dikelola / tidak dikelola
Kompiler adalah versi yang berbeda untuk C++/CLI dibandingkan dengan C++ (dan saya diberitahu di build bahwa kompiler C++/CLI tidak akan mendukung lebih dari C++17, yang merupakan masalah ketika menyertakan header dari perpustakaan yang menggunakan C++ 20 fitur).
Apa yang saya coba katakan adalah, tidak memiliki beberapa upaya bersaing. Tetap dengan standar dan bekerja dengan itu. Microsoft berada di komite C++, mereka membantu mendorong standar ke depan, ini harus menjadi fokus, bukan kepemilikan, terkunci dalam ekstensi.

Bisakah kita memiliki compiler xaml, seperti xaml.exe untuk mengkompilasi file xaml, mirip dengan midl.exe, cl.exe, atau link.exe? Akan sangat berguna untuk membangun pipa otomatis untuk aplikasi winui.

Terkadang, kami tidak ingin menggunakan visual studio untuk melakukan pengembangan, mungkin menggunakan editor apa pun yang kami inginkan, tetapi tetap memisahkan pipa build. Tampaknya aplikasi winui xaml adalah bagian khusus dan tampaknya belum ada alat baris perintah untuk mengompilasinya.

Ini diperlukan untuk skenario seperti cmake: https://github.com/microsoft/ProjectReunion/issues/58

Bisakah kita memiliki compiler xaml, seperti xaml.exe untuk mengkompilasi file xaml, mirip dengan midl.exe, cl.exe, atau link.exe? Akan sangat berguna untuk membangun pipa otomatis untuk aplikasi winui.

@sammi apakah #1433 meringkas solusi yang masuk akal untuk apa yang Anda cari?

Bisakah kita memiliki compiler xaml, seperti xaml.exe untuk mengkompilasi file xaml, mirip dengan midl.exe, cl.exe, atau link.exe? Akan sangat berguna untuk membangun pipa otomatis untuk aplikasi winui.

@sammi apakah #1433 meringkas solusi yang masuk akal untuk apa yang Anda cari?

@jtbrower , itulah fitur yang saya cari, terima kasih!

Tentu saja ini adalah pratinjau, dan itu berarti saya tidak boleh berharap banyak, tetapi pratinjau WinUI 3 2 mengecewakan bagi saya.

Kebutuhan terbesar saya adalah di bidang perancangan XAML. Saya cukup terkejut dengan kenyataan bahwa perancang XAML tidak bekerja sama sekali, dan sejauh ini saya tidak menemukan informasi yang jelas tentang kapan itu akan berfungsi.

Ya, saya setuju Desainer XAML saat ini di Visual Studio sangat lambat, dan rusak ketika seseorang mengubah hal-hal secara realtime yang seharusnya tidak merusaknya. Misalnya, mengubah Height="*" menjadi "Auto" atau 100. (jendela kesalahan mengeluarkan sekitar 10 kesalahan -- banyak coretan, dan Anda harus membangun kembali proyek)

Untuk lebih jelasnya -- saya tidak benar-benar menggunakan desainer untuk mendesain -- saya hanya ingin memiliki ide jika tata letak saya terlihat seperti yang saya bayangkan sebelum melalui proses pembuatan. Jika lebih mudah, jika perancangnya hanya "Hanya melihat", dan diperbarui saat saya mengubah XAML (tanpa mogok), itu akan baik-baik saja bagi saya, karena saya tidak menggunakan GUI untuk mengubah XAML .. atau sangat jarang . Sungguh, apa yang dilakukan WindowsCommunityToolkit dengan sumber XAML yang memungkinkan pengguna mengubah sumber dan melihat output secara realtime cukup baik untuk tujuan saya.

Semua yang dikatakan, WinUI memiliki ide bagus -- memisahkan semua hal "Mudah" ini dari OS, dan membiarkan pekerjaan pengembang berkembang jauh lebih cepat, dan kami dapat menggabungkan dependensi dengan aplikasi untuk menghindari keharusan memutakhirkan perangkat 1 Miliar sehingga mereka dapat menjalankan hal-hal hebat baru kami.

Saya harap Project Reunion juga akhirnya benar-benar memisahkan GUI dari wadah aplikasi. UX seperti UWP tanpa kotak pasir/batas akan menjadi langkah maju yang bagus.

Tapi kapan kita bisa memiliki XAML Designer yang berfungsi kembali... please?

Saya pikir hot reload sebagian besar telah menghentikan tujuan "hanya lihat" dari perancang XAML.

Tapi kita berbicara tentang perkakas WinUI di sini. Muat ulang panas dan pohon visual langsung juga tidak berfungsi untuk WinUI.

Yang saya maksud dengan desainer Hanya Lihat adalah "Saya dapat menerimanya jika itu adalah sesuatu yang dapat kami masukkan ke dalam pratinjau yang akan datang"

Saya bisa saja salah (DAN tolong BERITAHU saya jika saya salah), tetapi saat ini, satu-satunya cara untuk melihat UI Anda di WinUI adalah dengan membangun dan menjalankannya.

Tapi kita berbicara tentang perkakas WinUI di sini. Muat ulang panas dan pohon visual langsung juga tidak berfungsi untuk WinUI.

Yang saya maksud dengan desainer Hanya Lihat adalah "Saya dapat menerimanya jika itu adalah sesuatu yang dapat kami masukkan ke dalam pratinjau yang akan datang"

Saya bisa saja salah (DAN tolong BERITAHU saya jika saya salah), tetapi saat ini, satu-satunya cara untuk melihat UI Anda di WinUI adalah dengan membangun dan menjalankannya.

Hai @ericleigh007 apakah Anda memiliki kesempatan untuk melihat rilis terbaru kami WinUI 3 Pratinjau 3? Kami baru-baru ini menambahkan banyak peningkatan alat seperti IntelliSense, Hot Reload, Live Visual Tree, dan Live Property Explorer. Anda dapat memeriksa catatan rilis di sini dan mendapatkan pratinjau terbaru di sini . Saya tertarik dengan pemikiran Anda, jadi silakan hubungi kami!

@JeanRoca Sayangnya mengejar pengalaman pengembangan C++/CX bukanlah salah satu dari peningkatan alat itu. Jangan berharap banyak pengembang menyukai WinUI ketika alat C++ yang diusulkan terasa seperti kembali ke tahun 2000, menulis file IDL di notepad (tanpa dukungan editor apa pun) dan menyalin file secara manual.

Itu membuat saya tetap di .NET sebanyak yang saya bisa, atau tetap menggunakan C++/CX meskipun ada peringatan untuk pindah ke C++/WinRT.

Terima kasih atas pembaruannya; Akan mencobanya hari ini, dan akan melaporkan kembali. 🤞

Dikirim dari Mail https://go.microsoft.com/fwlink/?LinkId=550986 untuk Windows 10

Dari: pemberitahuan [email protected]
Dikirim: Rabu, 18 November 2020 04:41
Kepada: microsoft/microsoft-ui-xaml [email protected]
Cc: Eric [email protected] ; Sebutkan [email protected]
Subjek: Re: [microsoft/microsoft-ui-xaml] Pengalaman dan Perkakas Pengembang WinUI 3.0 - Diperlukan Masukan (#1045)

Tapi kita berbicara tentang perkakas WinUI di sini. Muat ulang panas dan pohon visual langsung juga tidak berfungsi untuk WinUI.

Yang saya maksud dengan desainer Hanya Lihat adalah "Saya dapat menerimanya jika itu adalah sesuatu yang dapat kami masukkan ke dalam pratinjau yang akan datang"

Saya bisa saja salah (DAN tolong BERITAHU saya jika saya salah), tetapi saat ini, satu-satunya cara untuk melihat UI Anda di WinUI adalah dengan membangun dan menjalankannya.

Hai @ericleigh007 https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fericleigh007&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df9e7fe7nknownaaaaa674aa%7C84df9e77% 3CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jha7IQJyg%2BKEZKwKvAkLEZKwKvAkLEJfFG2Sreced% Anda memiliki kesempatan untuk memeriksa kami? Kami baru-baru ini menambahkan banyak peningkatan alat seperti IntelliSense, Hot Reload, Live Visual Tree, dan Live Property Explorer. Anda dapat memeriksa catatan rilis di sini 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 & dicadangkan = 0 dan mendapatkan preview terbaru di sini https://eur05.safelinks.protection.outlook.com/?url=https% 3A% 2F% 2Fdocs.microsoft.com% 2Fen-kami% 2Fwindows% 2Fapps% 2Fwinui% 2Fwinui3% 2F & data = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & SDATA = VF2s7jilqpksevP6Fx7mXW1QCNJN2% 2BK5yWOndg3rKoc%3D&reserved=0 . Saya tertarik dengan pemikiran Anda, jadi silakan hubungi kami!

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F1045%23issuecomment -729.402.012 & data = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & SDATA = R1S2JpfBSzsNKJBAH5% 2Fgme8Bq% 2FjHbzB9FySk1KnZKbk% 3D & dicadangkan = 0 , atau berhenti berlangganan https: //eur05.safelinks.protection.outlook .com /? url = https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FABX3S2XLYXYXP7BZZC3OE73SQNGBFANCNFSM4ICOLUJQ & data = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160102680% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & SDATA = 0H6IpND3YX1s6oyXy% 2FCXNAMN9n8fvSPdWks%2FfmXT0Bc%3D&reserved=0 .

-Tidak ada editor / metode wysiwyg yang bekerja dengan winui3 c++ (desktop) saat ini, bukan?

Microsoft juga berhasil mengasingkan pengguna C++/CX? Semua ini tidak terbentuk dengan baik sama sekali. Siapa pun yang mengadopsi teknologi Microsoft beberapa tahun lalu mendorong UWP apakah .net atau c++ dalam masalah sekarang tanpa dukungan dari Microsoft.

Tampaknya WinUI 3 hanya melayani aplikasi desktop yang ditulis dalam WPF -- tetapi mereka akan segera menyadari bahwa UWP tidak memiliki semua fitur WPF dan fitur WinUI masih kurang. Semua orang akan frustrasi yang merupakan tempat yang buruk untuk memulai WinUI 3.

@robloo Sebagai seseorang yang dulu menganjurkan UWP, mereka kehilangan saya, itu adalah WPF dan Win32 sampai mereka menyelesaikan kekacauan.

C++/WinRT adalah langkah politik, dan kami diberitahu hanya untuk menyedotnya dan menunggu sampai ISO C++ akhirnya memberikan refleksi dan dukungan metaclasses, untuk tim Visual Studio untuk mereplikasi pengalaman C++/CX.

Seperti yang disebutkan, bahkan mengedit file IDL tidak berbeda dengan menggunakan Notepad mentah.

Bahwa kita di .NET harus tahan dengan Microsoft yang tidak membuat semua komponen UWP tersedia untuk kita, entah bagaimana bisa dilakukan dengan C++/CX yang menawarkan pengalaman seperti C++/CLI. Sekarang dengan C++/WinRT kita kembali ke ATL.

Kemudian dengan membaca diskusi masalah Reuni dan peta jalan pembaruan, jelas mereka akan membutuhkan waktu beberapa tahun untuk memperbaikinya.

WPF dan Win32 mungkin sudah tua, tetapi mereka ada di sini dan berfungsi, tanpa harus menulis ulang lagi dan kehilangan fitur.

-Tidak ada editor / metode wysiwyg yang bekerja dengan winui3 c++ (desktop) saat ini, bukan?

Desainer XAML berfungsi, tetapi awalnya tidak dirancang untuk pengeditan wysiwyg. Muat ulang panas (yang sekarang berfungsi di pratinjau 3) berfungsi lebih baik.

pohon visual langsung dan tampilan prop langsung berfungsi dengan baik di pratinjau 3. Kapan desainer dijadwalkan akan tersedia?

Juga perhatikan desainer desktop (WPF) (bukan UWP) dulu bekerja di 2.4 (atau sesuatu) tetapi sekarang pengujian saya tidak melihatnya berfungsi lagi? Apakah saya melewatkan sesuatu dengan keadaan desainer saat ini?

Maaf aku terlambat ke pesta. @wjk berhasil dengan poin pertamanya.

1. MSIX semuanya baik dan bagus, tetapi saya masih menggunakan MSI lama yang bagus untuk menginstal aplikasi yang lebih kompleks yang memerlukan fitur yang tidak didukung MSIX. Saya juga ragu untuk menggunakan MSIX karena betapa mahalnya sertifikat Authenticode yang diperlukan.

Saya sangat menghargai daya pikat MSIX, tetapi mandat penandatanganan sertifikat ini adalah pemecah kesepakatan bagi saya. Saya memerlukan wizard penginstal ramah-SCM yang tepat yang dapat saya gunakan untuk membuat pengalaman Penginstal Desktop klasik. Mengapa tidak melakukan peningkatan di MSIX dan membuat versi baru penginstal MSI tanpa Microsoft Store dan persyaratan sertifikasi untuk pengalaman pengembangan yang lebih modern? Mungkin ini yang dimaksud dengan fitur "Mendukung penyebaran non-MSIX" yang tercantum dalam Roadmap saat ini? Jika demikian, saya kira saya terjebak menunggu 3.x, kecuali dengan keajaiban, yang membuatnya menjadi rilis sebelumnya. Menantikan itu karena VS Installer Projects secara tragis sudah ketinggalan zaman dan sama sekali tidak ramah terhadap kontrol sumber. 😓

@Chiramisu Saya setuju dengan sentimen tersebut, tetapi saya juga bingung -- bagaimana dengan pengalaman sideloading + AppInstaller tidak cukup?

@Chiramisu Sudahkah Anda mencoba WiX ? Saya menggunakannya untuk semua penginstal berbasis MSI saya, dan itu bekerja dengan sangat, sangat baik. Ada juga ekstensi Visual Studio , sehingga Anda dapat memiliki proyek WiX yang mengotomatiskan berbagai perintah kompilasi.

@robloo Sebagai seseorang yang dulu menganjurkan UWP, mereka kehilangan saya, itu adalah WPF dan Win32 sampai mereka menyelesaikan kekacauan.

C++/WinRT adalah langkah politik, dan kami diberitahu hanya untuk menyedotnya dan menunggu sampai ISO C++ akhirnya memberikan refleksi dan dukungan metaclasses, untuk tim Visual Studio untuk mereplikasi pengalaman C++/CX.

Seperti yang disebutkan, bahkan mengedit file IDL tidak berbeda dengan menggunakan Notepad mentah.

Bahwa kita di .NET harus tahan dengan Microsoft yang tidak membuat semua komponen UWP tersedia untuk kita, entah bagaimana bisa dilakukan dengan C++/CX yang menawarkan pengalaman seperti C++/CLI. Sekarang dengan C++/WinRT kita kembali ke ATL.

Kemudian dengan membaca diskusi masalah Reuni dan peta jalan pembaruan, jelas mereka akan membutuhkan waktu beberapa tahun untuk memperbaikinya.

WPF dan Win32 mungkin sudah tua, tetapi mereka ada di sini dan berfungsi, tanpa harus menulis ulang lagi dan kehilangan fitur.

Agar saya dapat mengikuti, dapatkah Anda memberi tahu saya tentang pengeditan IDL apa yang Anda bicarakan dengan C++/WinRT? Dari apa yang saya lihat dari co_await dan sintaks C++ 17 lainnya, kompleksitas tampaknya telah meningkat dalam jumlah besar dari C++/CX.

NONA? Bukankah mungkin saja, kecuali seseorang membuat pembungkus yang sangat bagus di sekitarnya, bahwa kemampuan C++/WinRT berdasarkan C++ 17 terlalu rumit dan terlalu berbeda dari desain saat ini? Tidak bisakah C++/CX disimpan cukup untuk beberapa "pembungkus yang sangat baik" dibuat untuk C++ 17 untuk membuat C++/WinRT cukup mudah digunakan dan dimigrasikan?

(sekarang seseorang akan menautkan ke artikel yang menunjukkan bagaimana ini dilakukan, dan saya akan merasa bodoh)

@lmcdougald Saya belum mencobanya. Perlu dicatat bahwa proyek khusus saya masih menggunakan .NET Framework 3.5. Saya tahu saya tahu. Saya belum diizinkan untuk memperbaruinya, jadi saya terjebak dengan teknologi Installer apa yang akan bekerja dengan kerangka kerja kuno ini. 😖

@wjk Saya telah memeriksanya di masa lalu, tetapi tidak, saya belum mencobanya. Meskipun diberikan hal di atas, tampaknya itu adalah satu-satunya teknologi yang dapat bekerja untuk proyek saya yang ada. Pernahkah Anda menggunakan ini untuk aplikasi WinForms berdasarkan kerangka kerja lama? Sayangnya saya seorang pengembang tunggal, jadi saya harus melakukan prasangka ekstrim dengan bagaimana saya menghabiskan waktu saya dan tidak memiliki kebebasan untuk bereksperimen dengan teknologi baru.

Baik

@Chiramisu Ya, WiX berfungsi dengan versi lama .NET Framework, dan ya, itu juga berfungsi dengan aplikasi winforms. Karena membuat file MSI mentah, WiX dapat menginstal apa saja, dalam bahasa pemrograman apa pun. Dalam hal mempelajarinya, saya akan mulai dengan tutorial dasar . Saya juga ingin menunjukkan cara mendeteksi jika .NET diinstal , dan cara menjalankan NGEN pada file menggunakan WiX , karena Anda menggunakan teknologi tersebut di aplikasi Anda. Ekstensi Visual Studio juga dilengkapi dengan sejumlah templat proyek, untuk memberi Anda kode kerangka yang tepat untuk ditambahkan. (Catatan: Jangan gunakan template Bootstrapper, karena itu adalah topik yang jauh lebih maju.) Semoga ini bisa membantu!

@Chiramisu Saya sangat bingung dengan apa yang Anda cari -- bagi saya sepertinya Anda sedang mencari alat pengemasan untuk proyek Anda saat ini dan bukan untuk proyek WinUI 3.0.

Perlu dicatat bahwa .NET Framework 3.5 dapat dikemas ke dalam MSIX. Anda dapat membuat paket MSIX untuk aplikasi Anda yang sudah ada dengan Proyek Paket di VS 2019, lalu melalui transisi panjang dengan agak mulus, tetapi banyak pekerjaan:

WinUI 3.0 tidak akan pernah secara resmi mendukung .NET 3.5, dan mungkin tidak akan pernah mendukung .NET Framework di versi apa pun. Saya akan memulai modernisasi Anda dengan memutakhirkan ke .NET 4.6 (atau idealnya lebih tinggi, 4.8 akan ideal) tanpa mengubah proyek pengemasan Anda yang ada. Jika itu berjalan lancar, saya kemudian akan mulai mentransisikan fungsionalitas ke perpustakaan bersama .NET Standard yang Anda rujuk dari aplikasi .NET 4.6+ yang diperbarui.

Setelah aplikasi .NET 4.6 stabil dan diuji, Anda dapat menukarnya sebagai pembaruan otomatis untuk proyek pengemasan MSIX Anda. Setelah langkah .NET Standard, Anda dapat membuat kepala proyek yang menggunakan kode yang hampir sama dari .NET Core 3.1 (atau 5, tetapi saya merasa status LTS mungkin berarti bagi organisasi Anda). Sekali lagi, uji lalu alihkan MSIX untuk menggunakan versi ini.

Beralih ke WinUI dari WinForms pada saat itu adalah masalah mempelajari WinUI dan mengimplementasikan kembali antarmuka. Sekali lagi, buat kepala proyek baru, terapkan + referensi perpustakaan .NET Standard, uji, lalu alihkan paket untuk menggunakan versi ini.

Beginilah cara saya melakukan modernisasi tanpa membuat proyek yang sangat berbeda pada titik tertentu. Saya akan memprioritaskan pengaturan pengemasan MSIX dan .NET 4.6 + .NET Standard langkah, karena itu akan memberi Anda lebih banyak alat bantuan dan koneksi ke siklus pengembangan .NET modern. Beralih ke .NET 5 dengan tergesa-gesa terdengar seperti ide yang buruk untuk organisasi Anda dalam jangka pendek, mengingat siklus hidupnya adalah 1/10 selama .NET 3.5 telah ada.

Agar saya dapat mengikuti, dapatkah Anda memberi tahu saya tentang pengeditan IDL apa yang Anda bicarakan dengan C++/WinRT? Dari apa yang saya lihat dari co_await dan sintaks C++ 17 lainnya, kompleksitas tampaknya telah meningkat dalam jumlah besar dari C++/CX.

NONA? Bukankah mungkin saja, kecuali seseorang membuat pembungkus yang sangat bagus di sekitarnya, bahwa kemampuan C++/WinRT berdasarkan C++ 17 terlalu rumit dan terlalu berbeda dari desain saat ini? Tidak bisakah C++/CX disimpan cukup untuk beberapa "pembungkus yang sangat baik" dibuat untuk C++ 17 untuk membuat C++/WinRT cukup mudah digunakan dan dimigrasikan?

(sekarang seseorang akan menautkan ke artikel yang menunjukkan bagaimana ini dilakukan, dan saya akan merasa bodoh)

Karena C++ normal tidak memiliki kemampuan untuk mengekstrak jenis metadata yang diperlukan untuk membuat file .winmd, Anda harus menulis kelas WinRT Anda dalam file .idl, di atas .hpp dan .cpp.

co_await jauh lebih kompleks daripada menulis .then([=](Foo^ thing) { }) mana-mana, ini sangat mirip dengan sintaks await C#.

Berikut ini contoh (idl + hpp + cpp) dari proyek Komponen Runtime default:

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();
    }
}

Berikut ini contoh kecil 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);
}

Hai, yang di sana,

Kami membaca tanggapan Anda dan membuat catatan tentang poin-poin yang menyakitkan.

@ericleigh007 XAML Designer keluar karena setelah mengumpulkan umpan balik pelanggan, poin rasa sakit pelanggan teratas adalah tentang meningkatkan loop dalam pengembang. Hot Reload dan Live Visual Tree berada di atas. In-app-toolbar adalah hal lain di atas yang tidak dapat membuat Pratinjau 3. Anda benar tentang tidak jelas kapan Perancang XAML akan; kita perlu memperbarui pemikiran peta jalan fitur . Per rencana teknik saat ini, ini di luar 3.0 RTM, jadi pasca-3.0.

@pjmlp Saya bersimpati dengan pendapat Anda tentang C++/WinRT dan kebutuhan untuk menambahkan IDL. C++/CX jauh lebih baik dalam aspek ini. Meningkatkan pengalaman C++/WinRT adalah topik lain yang perlu kita bahas. Alat seperti Live Visual Tree dan Hot Reload berfungsi pada C# dan C++, tetapi ada hal-hal khusus yang hanya memengaruhi C++ dan perlu ditangani secara terpisah. Per rencana teknik saat ini, menyelesaikan masalah IDL tidak termasuk dalam 3.0 RTM.

@robloo , Kami tidak melayani aplikasi desktop yang ditulis dalam WPF. C++/WinRT adalah warga negara pertama di ekosistem WinUI. Itu yang kami gunakan untuk menulis WinUI, jadi kami melakukan dogfood pada alat dan bahasa kami yang tepat.

@Chiramisu Biarkan saya menjelaskan apa yang dimaksud dengan "mendukung penyebaran non-MSIX". Hari ini Anda perlu menginstal dan menjalankan aplikasi Desktop WinUI 3 menggunakan MSIX. Kemampuan ini adalah tentang menghilangkan kebutuhan ini. Untuk menjalankan aplikasi Desktop WinUI 3, Anda hanya perlu menggandakan file .EXE, dan hanya itu. Untuk menginstal aplikasi Anda, Anda cukup melakukan xcopy (tidak perlu menandatangani apa pun). Pada dasarnya, Anda akan dapat menggunakan sistem pengemasan dan instalasi lain seperti WiX.

@marb2000 Terima kasih telah mengakui masalah ini. Apa yang saya dan banyak pengembang Windows lainnya tidak mengerti adalah mengapa Anda (seperti dalam manajemen WinDev) memutuskan itu adalah ide yang baik untuk memaksa C++/WinRT pada kami dengan perkakas yang lebih rendah, bahkan kembali ke MFC terasa lebih baik, setidaknya kami tidak tidak menyalin file secara manual.

Saat ini saya fokus pada ASP.NET, WFP dan Win32, terus ikuti hal-hal UWP dengan harapan Microsoft akhirnya menyadari bahwa kami muak dengan penulisan ulang aplikasi dan diseret ke konfigurasi manual, seperti di UAP => UWP transisi, .NET Framework ke .NET Core, atau yes C++/CX => C++/WinRT.

Ini lebih merupakan umpan balik, sebagai anggota vokal komunitas pengembang Windows yang merasa sedikit kecewa dengan penulisan ulang terus menerus sejak diperkenalkannya Windows 8.

@pjmlp Saya tidak yakin mengapa Anda mengkritik C++/WinRT yang hanya merupakan pembungkus C++ (sesuai standar) di sekitar API Windows. Dimungkinkan untuk menulis aplikasi dengan C++/WinRT tanpa memerlukan perkakas (dan file IDL dll).

@pjmlp Saya tidak yakin mengapa Anda mengkritik C++/WinRT yang hanya merupakan pembungkus C++ (sesuai standar) di sekitar API Windows. Dimungkinkan untuk menulis aplikasi dengan C++/WinRT tanpa memerlukan perkakas (dan file IDL dll).

Itulah masalahnya, nol dukungan perkakas versus pengalaman pengembangan C++/CX di Visual Studio.

Tidak ada dukungan pengeditan untuk file IDL, bahkan penyorotan sintaks, apalagi intelisense. Dan kemudian seseorang diminta untuk menyalin, atau menggabungkan, unit terjemahan yang dihasilkan secara manual!

Ini seperti melakukan ATL di masa lalu.

Saya tidak peduli dengan kompatibilitas ISO C++, UWP hanya untuk Windows dan tidak ada kompiler C++ tanpa ekstensi bahasa.

Saya gagal melihat bagaimana orang dapat melihat ini sebagai kemajuan, selain orang-orang WinDev yang merupakan satu-satunya pengguna WRL.

@pjmlp ,

Saya tidak peduli dengan kompatibilitas ISO C++, UWP hanya untuk Windows dan tidak ada kompiler C++ tanpa ekstensi bahasa.

Bagi kita yang menulis aplikasi lintas platform C++ yang besar, mematuhi standar adalah masalah besar. Pembatasan C++/CX sangat buruk (tidak ada variabel anggota yang bukan pointer mentah, topi! ( ^ ) dll). Saat ini kami memiliki perpustakaan interop C++/CLI yang besar, dan poin-poin masalah terlalu banyak untuk dicantumkan.

Tidak ada dukungan pengeditan untuk file IDL, bahkan penyorotan sintaks, apalagi intelisense. Dan kemudian seseorang diminta untuk menyalin, atau menggabungkan, unit terjemahan yang dihasilkan secara manual!

Sekali lagi, Anda menggabungkan C++/WinRT dan perkakas. Mereka adalah 2 hal yang terpisah. C++/WinRT adalah pembungkus C++ di sekitar API WinRT. IDL adalah untuk pembuatan kode, dan ya, saya setuju itu mengerikan, sangat buruk sehingga saya tidak menggunakannya.

Saya menulis aplikasi khusus Windows dan saya masih peduli dengan kepatuhan standar karena memungkinkan saya untuk menggunakan kompiler yang berbeda dalam kasus di mana MSVC gagal.

@MarkIngramUK

Sekali lagi, Anda menggabungkan C++/WinRT dan perkakas. Mereka adalah 2 hal yang terpisah. C++/WinRT adalah pembungkus C++ di sekitar API WinRT. IDL adalah untuk pembuatan kode, dan ya, saya setuju itu mengerikan, sangat buruk sehingga saya tidak menggunakannya.

Saya telah mengkode untuk platform Microsoft sejak MS-DOS 3.3, menambahkan C++ ke kotak peralatan saya pada tahun 1992 dengan Turbo C++ 1.0, telah menggunakan sebagian besar Borland, dan produk Microsoft dalam hal pengembangan C++. Tidak perlu kuliah tentang apa itu C++/WinRT.

Apa yang pasti tidak, adalah kecocokan dengan pengalaman pengembang C++ Builder dan Qt (dengan Qt Designer), bahwa C++/CX menunjukkan janji untuk akhirnya menyusul, 25 tahun kemudian.

Tapi ternyata kebanyakan orang di sini hanya menginginkan Visual C++ 6.0 dengan ATL 3.0, dan kita semua harus tetap menggunakan pengalaman desktop .NET 5, WPF dan Win32, karena kita adalah minoritas yang tidak layak dipertimbangkan, jika tidak C++/WinRT tidak akan pernah memilikinya. didorong seperti itu.

Jujur saja, C++/WinRT sekarang hampir berusia 4 tahun, dan Microsoft bahkan tidak dapat memberikan dukungan bahkan untuk penyorotan sintaks dan intelisense?

Sesuatu yang sebagian dari kita telah buat di Notepad++ (penyorotan sintaks), Benarkah?

Ini jelas menunjukkan di mana prioritasnya, dan bukan dengan cara ini WinUI akan diadopsi, terlalu banyak penulisan ulang sejak Windows 8.

@pjmlp , sekali lagi Anda berbicara tentang hal yang salah. C++/WinRT hanyalah C++, jadi ia memiliki penyorotan sintaksis dan memang memiliki dukungan intellisense. Sama seperti kode C++ lainnya yang Anda miliki.

Integrasi IDE bisa lebih baik, seperti seperti yang Anda sebutkan penyorotan sintaks IDL dan hal-hal seperti menyarankan untuk membuat implementasi default di .hpp dan .cpp dari IDL (seperti bagaimana saat ini suatu fungsi dideklarasikan tanpa definisi di header meminta Anda dengan coretan hijau ke buat satu), tetapi kembali ke C++/CX adalah IMO downgrade bersih. Akan membutuhkan terlalu banyak upaya untuk mengintegrasikan semua perpustakaan dan kode bersama yang saya gunakan dengan C++/CX, dan memaksa saya untuk menurunkan versi proyek saya dari C++20 ke C++17 (yang saya tidak ingin menyerah, 20 memberi saya terlalu banyak hal baik).

C++/WinRT juga jauh lebih tidak mengganggu daripada C++/CX ketika program hanya ingin menggunakan kelas WinRT, bukan membuatnya.

Qt dan C++ Builder mencapai pengalaman mereka di sebagian besar standar C++ yang sesuai (perhatikan bahwa Qt memiliki sesuatu yang mirip dengan IDL, bernama Qt MOC). Jika ini bisa, VS juga bisa. Itu hanya membutuhkan lebih banyak cinta dari seseorang di DevDiv.

Dan seperti yang Anda sebutkan sebelumnya @sylveon , kami bebas membangun dengan kompiler lain (saat ini kami membangun dengan MSVC dan Dentang/LLVM). Dengan C++/CX atau ekstensi MS lainnya, ini tidak mungkin.

@MarkIngramUK dan @sylveon

Saya sudah selesai dengan utas ini, cukup jelas bahwa umpan balik seperti saya tidak diterima untuk meningkatkan pengalaman dan perkakas pengembang WinUI.

Bersenang-senanglah dengan C++/WinRT standar Anda.

dapatkah Anda mengedit ini untuk memperbaiki kesalahan ketik 'tidak ada katering'.. Saya pikir itu seharusnya 'sekarang ...'

@pjmlp Saya pikir saya mengerti PERSIS apa yang Anda maksud.

Setahun yang lalu saya meninggalkan ide untuk mem-porting kode UWP C++/CX saya ke C++/WinRT. Insentif untuk porting adalah untuk dapat menggunakan Dentang untuk mengkompilasi aplikasi UWP saya karena MSVC++ berisi bug yang saya laporkan sekitar 18 bulan yang lalu tetapi mereka sepertinya tidak tertarik untuk memperbaikinya.

Namun, ternyata Visual Studio tidak mendukung pembuatan aplikasi UWP menggunakan Dentang. Bagus, jadi manfaat "ISO C++ saja" dari C++/WinRT langsung keluar dari jendela. Tambahkan ke fakta bahwa mem-porting basis kode C++/CX melalui C++/WinRT seperti bepergian 20 tahun ke belakang.

Saya pada dasarnya sudah berhenti mem-porting aplikasi Android/iOS kami ke Windows. Sangat tidak mungkin bagi toko kecil seperti kami untuk berurusan dengan clusterfuck yaitu pengembangan aplikasi Windows selain pengembangan untuk Android/iOS.

@MarkIngramUK Tampaknya Anda tidak mengerti bahwa perkakas SANGAT PENTING. Tidak semua orang memiliki sumber daya untuk mengimbangi kurangnya peralatan yang tepat untuk dirinya sendiri.

Sekarang, setelah kata-kata kasar saya, inilah masukan saya:

Dukungan menggunakan WinUI 3 dengan C++/CX. Setelah perkakas untuk C++/WinRT dapat diterima oleh perusahaan yang tidak memiliki sumber daya untuk membangun perkakas mereka sendiri, mungkin tidak masalah untuk beralih ke C++/WinRT. Sekarang pasti tidak.

@pjmlp Saya pikir saya mengerti PERSIS apa yang Anda maksud.

Setahun yang lalu saya meninggalkan ide untuk mem-porting kode UWP C++/CX saya ke C++/WinRT. Insentif untuk porting adalah untuk dapat menggunakan Dentang untuk mengkompilasi aplikasi UWP saya karena MSVC++ berisi bug yang saya laporkan sekitar 18 bulan yang lalu tetapi mereka sepertinya tidak tertarik untuk memperbaikinya.

Namun, ternyata Visual Studio tidak mendukung pembuatan aplikasi UWP menggunakan Dentang. Bagus, jadi manfaat "ISO C++ saja" dari C++/WinRT langsung keluar dari jendela. Tambahkan ke fakta bahwa mem-porting basis kode C++/CX melalui C++/WinRT seperti bepergian 20 tahun ke belakang.

Saya pada dasarnya sudah berhenti mem-porting aplikasi Android/iOS kami ke Windows. Sangat tidak mungkin bagi toko kecil seperti kami untuk berurusan dengan clusterfuck yaitu pengembangan aplikasi Windows selain pengembangan untuk Android/iOS.

@MarkIngramUK Tampaknya Anda tidak mengerti bahwa perkakas SANGAT PENTING. Tidak semua orang memiliki sumber daya untuk mengimbangi kurangnya peralatan yang tepat untuk dirinya sendiri.

Sekarang, setelah kata-kata kasar saya, inilah masukan saya:

Dukungan menggunakan WinUI 3 dengan C++/CX. Setelah perkakas untuk C++/WinRT dapat diterima oleh perusahaan yang tidak memiliki sumber daya untuk membangun perkakas mereka sendiri, mungkin tidak masalah untuk beralih ke C++/WinRT. Sekarang pasti tidak.

Karena penasaran, bug apa yang dilaporkan 18 bulan lalu? Apakah Anda memiliki tautan ke mana saja?

hai Miguel,
___diedit untuk memperbaiki keadaan buruk setelah membalas dari Outlook untuk Android___

Saya punya ide yang dapat memperjelas tujuan Anda untuk pratinjau dan rilis karena Anda mengatakan platform Winrt adalah apa yang Anda gunakan untuk mengembangkan WINUI.

ambil artikel ini, yang menyebutkan banyak jika IDL menulis dan menyalin file if secara manual dan memodifikasinya sehingga cocok dengan keadaan yang sedang Anda kerjakan di alat

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

Jika tidak di sini, mungkin kita bisa membicarakannya di tempat lain.

omong-omong Anda membuat saya yakin dengan perancang XAML, terutama dengan alat-alat yang ada seperti studio XAML. (kalau saja itu juga dapat memuat beberapa kode di belakang sehingga berhasil memuat XAML yang menggunakan IValueConverter ...

Seperti yang disebutkan dalam posting saya sebelumnya, kepatuhan standar C++17 dari C++/WinRT itu sendiri dalam banyak kasus tidak ada insentif untuk memigrasi basis kode C++/CX ke C++/WinRT karena Anda dipaksa untuk mengkompilasi dengan kompiler Visual C++ Microsoft omong-omong. Jika Anda dapat mengganti kompiler yang akan berubah seluruhnya.

Tetapi Visual Studio tidak mendukung penggantian kompiler untuk komponen Windows Runtime. Ini adalah misteri bagi saya mengapa ini tidak didukung, terutama karena didukung untuk aplikasi desktop seperti yang diuraikan dalam posting blog ini . Dukungan dentang harus benar-benar diperluas untuk komponen Windows Runtime.

Kami menggunakan Dentang untuk mengkompilasi basis kode kami untuk Android dan iOS. Mampu menggunakan Dentang untuk mengkompilasi basis kode kami untuk Windows sebenarnya akan menjadi alasan yang sangat bagus untuk bermigrasi dari C++/CX. Permintaan fitur Visual Studio untuk itu sudah ada tetapi sejauh ini belum ada yang dilakukan oleh tim Visual Studio.

Anda memiliki kepatuhan standar C++, Anda memiliki dukungan Dentang di Visual Studio untuk aplikasi desktop. Jadi, lakukan langkah terakhir dan berikan alasan sebenarnya untuk bermigrasi dari C++/CX dengan memberikan dukungan Clang untuk komponen Windows Runtime.

Kepatuhan standar berguna bagi konsumen - seperti yang Anda sebutkan produsen terikat pada MSVC. Ada cara untuk "memaksa" clang-cl (yang secara efektif sudah dilakukan oleh LLVM toolset ) dengan mengatur properti CLToolExe ke path ke clang-cl di file .vcxproj . Saya tidak yakin seberapa baik itu bekerja di proyek UWP, tetapi patut dicoba.

Setelah alat produser XAML dan C++/WinRT dibuka kuncinya di proyek desktop, itu juga tidak akan menjadi masalah bagi saya.

@ackh Saya mendapat proyek UWP untuk dibangun di bawah Dentang 11:

Inilah yang saya lakukan:

• Bongkar proyek, dan tambahkan direktif berikut sebagai direktif pertama di bawah <Project>

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

• Ganti <AdditionalOptions>%(AdditionalOptions) /bigobj</AdditionalOptions> dengan <AdditionalOptions>%(AdditionalOptions) /bigobj -Xclang -std=c++20 -mcx16</AdditionalOptions>
• Ganti <PreprocessorDefinitions>WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions> dengan <PreprocessorDefinitions>_SILENCE_CLANG_COROUTINE_MESSAGE;WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions>
• Tepat di bawah ini, tambahkan <ModuleOutputFile />
• Muat ulang proyek
• Membangun

Ini memiliki beberapa jebakan namun:

• Beberapa peringatan tentang argumen yang tidak digunakan menopang: Anda mungkin dapat memperbaikinya dengan mengubah/menghapus argumen yang tidak digunakan.
• Untuk beberapa alasan Dentang memancarkan file objek 64-bit dalam 32 bit, mungkin hanya perlu menambahkan -m32 ke CLI.
• Karena Clang belum sepenuhnya mengimplementasikan coroutine, Anda tidak akan dapat menggunakannya.
• VS melakukan pembangunan kembali utas tunggal penuh setiap kali Anda menjalankan aplikasi daripada inkremental dan/atau paralel.

Saya sarankan membuka masalah di https://github.com/microsoft/ProjectReunion untuk mendapatkan perhatian tentang ini.

@sylveon Terima kasih banyak telah memposting instruksi ini. Saya akan mencoba ini di beberapa titik tetapi masih berharap Visual Studio akan mendukung ini di luar kotak di beberapa titik.