Xamarin.forms: Uwp Xamarin.Forms.Shell

Dukungan Shell hanya tersedia untuk Android dan iOS saat ini. Kami terus mengevaluasi umpan balik mengenai potensi dukungan UWP di masa mendatang dan akan memberikan lebih banyak informasi di masa mendatang saat tersedia.

Saya biasanya menggunakan iOS dan Android untuk pengguna ponsel saya dan UWP untuk pengguna tablet dan desktop saya. Jadi memiliki dukungan UWP akan sangat penting untuk membuat pengguna windows tetap terlibat.

Apa?? MS benar-benar membuang platform mereka sendiri. Ini menyedihkan untuk didengar!

Apakah tidak ada kejelasan kapan dukungan UWP akan diberikan? Atau apakah keputusan sudah dibuat?

Dukungan shell untuk UWP - tolong!

Saya juga ingin melihat dukungan UWP untuk Shell.

Bagi perusahaan saya, UWP cukup penting karena pelanggan kami menggunakan Tablet Windows yang dikombinasikan dengan beberapa ponsel Android untuk menyelesaikan pekerjaan mereka. Kami tidak akan dapat bermigrasi ke Shell jika dukungan UWP tidak ada.

Setuju -- Kompatibilitas UWP memungkinkan saya untuk memasukkan kemampuan tablet Windows dengan implementasi seluler saya. Saya harus mengkodekan ini sepenuhnya secara terpisah tanpa itu. Yuck! Kompatibilitas UWP harus dimiliki!

Saya tidak tahu apakah itu masuk akal, karena saya belum pernah menggunakan Shell. Tapi mungkin ada cara untuk menggunakan semua elemen lain dari Aplikasi (selain Shell) untuk implementasi UWP. Bagaimanapun menggunakan TabbedPage dan MasterDetailPage akan mencapai hal yang sama, sepertinya.

Saya juga akan memilih kemampuan untuk menggunakan UWP dengan Shell.

Tolong UWP... atau setidaknya beberapa rasa dari Microsoft UX API yang bisa kita andalkan selama beberapa tahun. Pendekatan "kami akan memberi tahu Anda jika kami dapat mendukungnya nanti" hanya berarti.

Jadi, ya, UWP atau apa pun akan mendukungnya tetapi yang lebih penting: KOMITMEN KAPAN KITA TAHU JIKA ATAU KAPAN.

Tidak dapat pindah ke Shell tanpa kepastian itu.

Tidak hanya UWP tetapi juga MacOS.

Saya tidak tahu apakah Anda menyadari bahwa UWP bukan hanya platform yang masih banyak digunakan oleh pengembang, tetapi juga cara tercepat untuk menjalankan dan menjalankan aplikasi XF berbasis Android dan iOS. Karena - sebagai perbandingan - emulator yang disediakan untuk dunia Android dan Mac sangat lambat, rentan terhadap masalah dan mari kita tidak membicarakan pengalaman sertifikasi yang mengerikan atau masih dipaksa memiliki Mac asli, bukan? Jadi, meskipun tidak dapat menggantikan pengembangan pada hal yang sebenarnya, aplikasi UWP meningkatkan produktivitas pengembang dengan menawarkan cara yang cepat, mudah, dan komprehensif untuk menyelesaikan… sesuatu… selesai. Dan kemudian: Lakukan apa yang diperlukan untuk mengaktifkan dan menjalankan aplikasi Anda di iOS dan Android juga.

Jadi, maukah Anda menambahkan dukungan shell untuk UWP?

https://github.com/xamarin/Xamarin.Forms/pull/6015

Setuju dengan @Mephisztoe itu benar-benar alat produktivitas yang hebat, dan tentu saja opsi untuk benar-benar membuat aplikasi tersedia untuk Windows juga merupakan nilai tambah yang bagus :)

Tolong jangan turunkan Xamarin.Forms ke platform seluler saja. Saya ingin melihat dukungan lanjutan untuk UWP khususnya, tetapi juga WPF dan GTK#.

Jadi pada dasarnya siapa pun yang memiliki aplikasi lintas platform untuk ketiga platform di Xamarin Forms saat ini tidak dapat memperbarui dan menggunakan fitur ini. Jika pengembangan di masa depan pada Formulir Xamarin untuk UWP tidak akan terjadi, mengapa tidak menghapus UWP saja dari daftar lintas platform?

Platform yang berbeda akan selalu memiliki prioritas yang berbeda. Lagi pula, Anda mengatakan "ketiga platform", bukan "semua tujuh platform".

@GalaxiaGuy itu benar, saya memang mengatakan ketiga platform mengingat jika saya mengatakan tujuh platform, saya akan membuat platform imajiner. Menurut dokumentasi Xamarin.Forms :

Xamarin.Forms
Xamarin.Forms memaparkan toolkit UI lintas platform lengkap untuk pengembang .NET. Bangun aplikasi Android, iOS, dan Universal Windows Platform sepenuhnya asli menggunakan C# di Visual Studio.

Dan di readme tertulis:

Xamarin.Forms menyediakan cara untuk membangun aplikasi asli dengan cepat untuk iOS, Android, Windows dan macOS, sepenuhnya di C#.

Itu tidak berarti itu juga tidak mendukung GTK, WPF dan Tizen.

Saya setuju bahwa platform tersebut mungkin kurang penting daripada UWP, tetapi ada banyak orang yang berpikir bahwa UWP kurang penting daripada iOS dan Android.

Saya biasanya setuju dengan sentimen tersebut, dan saya sendiri harus mengabaikan fitur yang lebih baru karena tidak ada di UWP.

FYI, kecuali saya salah membaca catatan rilis, sepertinya ada implementasi ShellRenderer untuk Tizen di pratinjau 4.1. Tidak disebutkan UWP.

Jika permintaan tarik dari @dotMorten membutuhkan waktu beberapa saat untuk bergabung, mungkin seseorang dapat mengambil implementasi itu dan memindahkannya ke paket NuGet "pra-rilis" terpisah yang dikelola oleh komunitas sampai/jika kami mendapatkan dukungan resmi. Dengan begitu kita bisa menggunakannya tanpa menggunakan full pre-release atau custom build dari Xamarin.Forms. Jika kami tidak mendapatkan dukungan resmi, maka repo sudah siap dan komunitas dapat mengambil alih.

Maaf ini tidak bergerak lebih cepat. Saya mengalami beberapa kemunduran ketika menyinkronkan dengan master, dan saya benar-benar dibanjiri dengan pekerjaan dan hal-hal yang berhubungan dengan keluarga, jadi tidak punya banyak waktu untuk benar-benar duduk dan mencoba dan mengatasinya. Namun saya lebih dari senang untuk mengambil PR untuk cabang saya.

Kami juga akan menggunakan shell segera setelah tersedia di UWP. Kami memiliki masalah yang sama seperti di atas. Kami memiliki campuran tablet, ponsel, dan notebook dengan android dan windows. Dan kami juga berpikir bahwa lingkungan pengembangan terbaik adalah UWP

Masalah ini adalah salah satu alasan utama saya menyerah pada XF. Bagi pelanggan kami, desktop dan seluler memiliki prioritas yang sama.

Apa yang bisa saya katakan yang belum dikatakan ..

jadi LANJUTKAN!
Dukungan UWP tidak opsional untuk Microsoft - apakah Anda benar-benar perlu diberi tahu ini?

@papiermache harap perhatikan kode etik berlaku untuk semua komunikasi, masalah, dan komentar tentang proyek ini

Juga memperlakukan ini sebagai ujian komitmen MS Xamarin untuk devs. Siapa saja di sisi MS siap untuk menimbang?

Maaf semua, akan meredam pemikiran lebih lanjut ... tapi saya benar-benar terpesona saat mengetahui kurangnya dukungan UWP – bahkan tidak pernah terpikir oleh saya bahwa UWP tidak akan menjadi platform yang disertakan sejak awal. Rick.

Dari: Jeremy [email protected]
Dikirim: 16 Agustus 2019 14:28
Kepada: xamarin/Xamarin.Forms [email protected]
Cc: Rick Piovesan [email protected] ; Sebutkan [email protected]
Perihal: Re: [xamarin/Xamarin.Forms] Uwp Xamarin.Forms.Shell (#5593)

@papiermache https://github.com/papiermache harap dicatat kode etik berlaku untuk semua komunikasi, masalah, dan komentar pada proyek ini

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, melihatnya di GitHub https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=ABJC5GJKYHEGIOR3P2UIKX3QE4EVLA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PT3PQ#issuecomment-522141118 , atau mematikan benang https://github.com/ notifikasi/berhenti berlangganan-auth/ABJC5GKCHSPBRJ5JNNEVD5LQE4EVLANCNFSM4G7ANE7A .

Hai @dotMorten , dapatkah Anda memberikan pembaruan? Apakah Anda masih berencana untuk mencoba dan membuat UPW+Shell berfungsi? Pahami bahwa itu adalah tindakan kebaikan dan komunitas :) Hanya ingin tahu karena upaya Anda tampaknya paling dekat untuk membuat Shell+UWP berfungsi. Masih benar-benar bingung dengan apa yang tampak seperti poros Microsoft menjauh dari dukungan Windows dengan Xamarin. Bersyukur untuk semua kebaikan lainnya, tetapi masih bingung dan frustrasi.

Maaf. Agak terbakar sekarang, jadi saya belum mengunjungi ini kembali. Saya ingat bergabung dengan yang terbaru menyebabkan banyak kemunduran dan tidak punya waktu atau energi untuk mengembalikannya ke kecepatan. Juga mengidentifikasi beberapa hal yang perlu diubah dan memerlukan dukungan yang lebih luas dari tim XF tetapi tidak mendapatkan banyak dukungan di luar "tentu mari kita lihat ke dalamnya" dan kemudian mati. Umumnya dukungan dan umpan balik yang saya dapatkan dari tim XF hanya dorongan tetapi dengan sedikit tindak lanjut. Masih menunggu umpan balik tentang pekerjaan yang saya lakukan tetapi pada titik ini mungkin terlalu ketinggalan zaman. Mudah-mudahan saya akan memiliki waktu dan energi segera untuk kembali ke dalamnya.

Masalah ini saat ini berada di 10 item terbuka yang paling banyak dikomentari tetapi tidak ada dalam peta jalan untuk diselesaikan.

@pauldipietro bisakah kami mendapatkan pembaruan tentang ini? Sepertinya saya mengirim sinyal bahwa dukungan UWP tidak lagi menjadi prioritas tim XF. Jika itu benar, tolong beri tahu kami sehingga kami dapat membuat rencana untuk itu.

Terima kasih

Setuju, saya hanya ingin tahu apakah XF tidak akan menyertakan dukungan Windows. Jika tidak, saya juga ingin tahu mengapa tidak? Apakah mereka tahu seperti apa tumpukan Windows UX "berikutnya" selain UWP dan tidak ingin menyia-nyiakan siklus? Akankah beberapa hal Blazor/HTML menjadi bagian berikutnya? Jika demikian, beri tahu saya agar saya dapat bertransisi... Mungkin ke uno platform?

Dari: Scott Kuhl [email protected]
Dikirim: Kamis, 22 Agustus 2019 13:21:22
Kepada: xamarin/Xamarin.Forms [email protected]
Cc: David Gerding [email protected] ; Komentar [email protected]
Perihal: Re: [xamarin/Xamarin.Forms] Uwp Xamarin.Forms.Shell (#5593)

Masalah ini saat ini berada di 10 item terbuka yang paling banyak dikomentari tetapi tidak ada dalam peta jalan untuk diselesaikan.

@pauldipietro https://github.com/pauldipietro bisakah kami mendapatkan pembaruan tentang ini? Sepertinya saya mengirim sinyal bahwa dukungan UWP tidak lagi menjadi prioritas tim XF. Jika itu benar, tolong beri tahu kami sehingga kami dapat membuat rencana untuk itu.

Terima kasih

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, melihatnya di GitHub https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=AAD7YD4EYE5XBBSXIR6MGV3QF3KKFA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD456VUI#issuecomment-524020433 , atau mematikan benang https://github.com/ notifikasi/berhenti berlangganan-auth/AAD7YD42CJSV4KS5ZFWWJU3QF3KKFANCNFSM4G7ANE7A .

Sejujurnya, menurut saya yang terbaik adalah mengganti XF dengan Uno Platform...

Xamarin telah menjelaskan bahwa target mereka sebagian besar adalah perangkat seluler (ponsel, tablet, jam tangan), bukan desktop atau laptop.

Mereka tidak tertarik untuk mendukung dan memelihara UWP sendiri, jadi tidak ada gunanya saya merekomendasikan kepada pelanggan saya.

Saya ingin mengklarifikasi kebutuhan saya: Saya tidak perlu _UWP_ untuk Formulir Xamarin. Saya perlu _beberapa target Windows_ untuk Formulir Xamarin. UWP sepertinya kandidat yang paling layak. Jika saya harus menebak Microsoft pada akhirnya akan menyepak bola dan pergi ke klien HTML dan Blazor untuk desktop karena itu mungkin memberi mereka jangkauan UX terluas di dunia pasca-Windows. Itu mungkin juga lebih cocok dengan jalur Shell yang dapat dikomposisi (bukan xf Shell). Dengan tidak adanya peta jalan yang koheren untuk sisi Windows UX, saya tidak dapat membayangkan apa lagi yang mungkin mereka rencanakan.

Tapi untuk lebih jelasnya, menjatuhkan dukungan Windows untuk Xamarin tanpa mengumumkan dalam huruf tebal besar, "KAMI TIDAK DAN TIDAK AKAN MELAKUKAN JENDELA", minimal, benar-benar tidak baik. Itu berdering dari "Microsoft lama".

@davidortinau dkk: Tolong lakukan sesuatu yang lebih dari menunjuk ke yang sekarang efektif mati (lihat posting terbaru @dotMorten ) "dukungan komunitas untuk XF Shell + Windows".

Saya sangat bersyukur untuk semua hal baru dan keren di Xamarin. Tetapi saya membutuhkan tanggapan yang lebih jujur ​​tentang kelangsungan hidup di masa depan, jika ada, dari target Windows yang menggunakan Xamarin.

beberapa hal yang perlu diubah dan memerlukan dukungan yang lebih luas dari tim XF

Saya tahu salah satunya ada hubungannya dengan WinUI yang kami harap dapat ditarik sebagai ketergantungan dengan PR ini
https://github.com/xamarin/Xamarin.Forms/pull/7214

PR itu mempertahankan kompatibilitas 16299 dan dari pengujian saya berfungsi dengan baik ketika disertakan dengan nuget dan tidak mengharuskan pengguna untuk menginstal WinUI. Saya masih perlu mendapatkan 16299 putaran di VM untuk memastikan tetapi saya tetap optimis. Saya tahu @dotMorten Anda telah menyatakan beberapa kekhawatiran tentang menarik WinUI jadi jika saya benar-benar mengabaikannya, beri tahu saya :-)

Ini dia.

Xamarin.Forms.4.3.0.1853.zip

Jika ada orang lain yang ingin mengujinya untuk kami dan beri tahu kami jika Anda memiliki masalah yang akan sangat membantu. Saya telah mengujinya dengan template UWP dasar dan berfungsi dengan baik untuk saya tanpa crash.

Jalan yang saya lihat untuk saat ini adalah

• dapatkan #7214 bergabung sehingga kami telah menangani ketergantungan WinUI
• dapatkan UWP Shell PR rebased (kami memiliki jadwal ini untuk sprint di masa depan jadi kami akan melakukannya saat itu atau jika orang lain mengalahkan kami untuk itu)
• Morten sudah membuatnya bekerja dengan Gastropoda jadi kami hanya ingin mengujinya dengan beberapa sampel lagi (terutama Xaminal), setelah itu berfungsi dan kami membuat perubahan pembersihan kode apa pun yang diperlukan, kami akan menggabungkannya

Jika saya kehilangan sesuatu dengan jalur itu, beri tahu saya dan kami akan mencoba mengatasinya, jadi yang perlu dilakukan hanyalah rebase dan verifikasi terhadap Xaminals.

@PureWeen ,
Saya dapat menjalankan App132.zip dengan Xamarin Nuget yang Anda berikan. Aplikasi tampaknya berfungsi dengan baik ... dengan asumsi itu seharusnya menambahkan elemen stempel waktu ke kontrol daftar. Baik tombol di bagian atas dan perilaku Pull to Refresh menambahkan elemen.

Tidak yakin apa yang saya cari, tetapi saya menghargai upaya Anda dan akan mencoba dan membantu semampu saya.

Dave G

@PureWeen Senang melihat Anda bergerak maju dengan WinUI. Ketergantungan pada WinUI menciptakan perilaku melanggar bagi saya, karena WinUI menambahkan ketergantungan yang tidak ditambahkan secara transitif. Itu dapat diperbaiki jika Anda menggunakan VS2019, tetapi saya tidak yakin apakah WinUI telah memanfaatkan fitur itu (dan itu masih akan memengaruhi pengguna VS2017, tetapi setidaknya memiliki solusi).
Selain itu ada bug di WinUI yang menyebabkan banyak sakit kepala bagi saya, tapi saya perhatikan baru-baru ini beberapa yang saya login telah diperbaiki, jadi itu semua menggembirakan. Ping saya setelah 7214 masuk, dan saya akan mencoba dan memulai upaya ini.
Juga akan senang membantu dengan rebasing. Terakhir kali saya melakukan itu, saya benar-benar mengacaukan PR ini :-)

@dotMorten Kedengarannya bagus!!

Saya memang menguji aplikasi yang saya sertakan di atas pada VS 2017 dan itu berhasil untuk saya, jadi saya pikir kami baik-baik saja di depan itu

Tidak yakin apa yang saya cari, tetapi saya menghargai upaya Anda dan akan mencoba dan membantu semampu saya.

Hal utama adalah menambahkan nuget ke proyek UWP utama Anda dan hanya memastikan semuanya tampak dikompilasi dan berjalan dengan baik.

Hanya mencoba untuk memeriksa bahwa menambahkan ketergantungan WINUI tidak akan menyebabkan sakit kepala :-)

Saya telah menguji aplikasi yang saya sertakan di atas pada VS 2017

Tanpa juga menambahkan WinUI ke kepala proyek? Itulah masalah yang saya temukan: jika orang meningkatkan ke versi XF yang bergantung pada WinUI, itu tidak akan berfungsi tanpa juga menambahkan ketergantungan secara manual ke WinUI. IMHO itu perubahan yang melanggar. WinUI dapat mengubah paket mereka sehingga berfungsi secara implisit, tetapi itu akan membutuhkan VS2019 karena bergantung pada fitur NuGet 5.0 (dan afaik mereka belum membuat perubahan ini sehingga tidak akan berfungsi sekarang).

Inilah masalah yang saya masuki di WinUI: https://github.com/microsoft/microsoft-ui-xaml/issues/596#issuecomment -524187369

Saya mungkin hanya membuat PR cepat untuk setidaknya mengatasinya sehingga pengguna VS2019 tidak perlu menambahkan ketergantungan ekstra secara manual.

Hanya menambahkan bahwa ketika saya menguji app123 itu dengan VS2019.

Tanpa juga menambahkan WinUI ke kepala proyek?

Ya, proyek yang saya tautkan di atas dapat saya buka di dalam VS2017 dan dikompilasi dan berjalan dengan baik. Saya tidak memiliki nuget WinUI yang ditambahkan ke kepala UWP itu hanya ditunjukkan sebagai ketergantungan di dalam nuspec

Saya tidak begitu mengerti cara kerjanya. Ada gaya yang perlu ditambahkan dan paket kerangka kerja appx tambahan yang perlu diinstal dengan paket tersebut, dan semuanya dilakukan oleh .targets. Apakah paket kerangka kerja sudah diinstal pada mesin Anda?

Visual Studio Magazine baru saja membahas masalah ini secara khusus. Microsoft, waktu untuk tanggapan resmi.

https://visualstudiomagazine.com/articles/2019/08/23/xamarin-forms-4-2.aspx

@dotMorten Saya keluar selama beberapa hari tetapi saya akan memeriksanya ketika saya kembali. Saya juga telah menghubungi tim WinUI untuk meninjau

Target ini berjalan dengan baik secara transitif ketika saya menguji pada VS 2017
https://github.com/microsoft/microsoft-ui-xaml/blob/8f8cd0fe32754cfcd83dafb2fc8539703b6aec26/build/NuSpecs/MUXControls-Nuget-Common.targets#L6

Inilah nuget yang diperbarui yang memungkinkan Anda mengganti pengaturan di proyek formulir lokal Anda
Xamarin.Forms.4.3.0.1853.zip

<SkipMicrosoftUIXamlCheckTargetPlatformVersion>false</SkipMicrosoftUIXamlCheckTargetPlatformVersion>

Dalam proyek formulir kami memaksa ini menjadi benar sehingga tidak akan mengejutkan orang.

https://github.com/xamarin/Xamarin.Forms/pull/7214/files#diff -5e6292d5925c776aa9aa6d6f8c63ddf6R19

@PureWeen Ini adalah bit yang seharusnya berfungsi tanpa menambahkan baris ini secara eksplisit (karena semua pengguna juga harus memperbarui kepala proyek mereka):

Saya pikir Anda mengatakan itu berhasil, tetapi hanya memastikan kita berada di halaman yang sama.

Mungkin Anda menganggap ini sebagai perubahan yang melanggar yang dapat diterima, tetapi saya ingat ini terjadi baru-baru ini dengan ketergantungan lain dan membuat banyak orang keluar, karena jalur peningkatan tidak sebersih hanya memilih versi XF baru.

Re: perlunya target desktop/laptop/tablet untuk Xamarin Forms

Bagi kita yang sedang membangun aplikasi seluler di lingkungan perusahaan, kemampuan untuk menghasilkan desktop/laptop yang "bekerja sama" yang dapat dieksekusi dari basis kode dasar yang sama dengan basis Android/iOS sangat penting. Tidak perlu Windows saja (target berbasis browser seperti HTML/JS akan sama bagusnya) tetapi sebagian besar pengguna kami memiliki desktop/laptop Windows + iPhone/ponsel Android, jadi Windows yang dapat dieksekusi adalah baik untuk sebagian besar.

Kami telah menemukan bahwa ketika kami membuat aplikasi seluler tersedia dalam organisasi, sebagian besar pengguna kami ingin mencobanya di laptop/desktop mereka terlebih dahulu - dan hanya jika mereka merasa aplikasi itu berguna atau sesuai dengan kebutuhan mereka, mereka akan bersedia untuk menempatkan itu di ponsel mereka. Selain itu, mendapatkan dukungan pengguna (dan umpan balik) bekerja secara signifikan lebih baik jika mereka dapat memasukkan data atau hasil kueri dari desktop atau perangkat, tergantung di mana mereka bekerja pada saat itu.

Formulir Xamarin bekerja dengan baik untuk skenario ini, dan kami sangat ingin menggunakan Shell dan CollectionView, tetapi mereka adalah perangkat rak bagi kami sampai mereka dapat digunakan untuk menghasilkan desktop/laptop yang serupa...

@dotMorten jadi alasan saya tidak melihat pengecualian adalah karena saya memiliki WinUI sebagai ketergantungan pada nuget jadi jika Anda menginstal XF ke kepala UWP maka WinUI datang untuk perjalanan dan menerapkan targetnya.

Ini membuatnya jadi paket XF itu sendiri harus diinstal ke proyek kepala UWP agar berfungsi. Saya menguji contoh saya di atas dengan hanya menginstal XF pada proyek netstandard dan dapat membuat ulang pengecualian Anda.

Kami sudah membicarakan ini sedikit di edisi ini
https://github.com/xamarin/Xamarin.Forms/issues/4126

Ini melanggar jika orang hanya menginstal XF ke perpustakaan bersama dan bukan proyek kepala UWP. Jadi kita perlu membahas ini sedikit untuk melihat apa yang ingin kita lakukan tentang ini

@pureween oke bagus. Senang kita melihat hal yang sama saat itu. Beberapa hal yang perlu diperhatikan dalam diskusi Anda:

• Jika PR saya di WinUI digabungkan, itu hanya akan memengaruhi pengguna VS2017 (namun bisa menjadi aneh jika tim menggunakan keduanya dan itu hanya memengaruhi beberapa pengguna).
• Anda dapat mendeteksi ini selama Init() dan membuat kesalahan yang memberi tahu pengguna apa yang harus dilakukan sehingga rasa sakitnya tidak terlalu buruk.
• Saya mempermainkan gagasan bahwa XF memiliki file target yang menambahkan ketergantungan ke proyek perujuk jika belum ada, tetapi bisa
  buat pengalaman pengembang yang aneh.
• Semua proyek UWP akan selalu menggunakan ketergantungan ini setelah WinUI dipisahkan dari platform (tetapi pada saat itu VS2017 mungkin tidak lagi didukung).
  
  
  
  • Anda akan dapat mendukung versi Win10 yang lebih rendah dengan perubahan ini, menciptakan nilai tambah yang dapat membenarkannya.
  
  
  • Tidak ada yang akan memperhatikan karena menurut tim Anda, tidak ada yang benar-benar menggunakan UWP j/k
  
  

Satu pendekatan lagi yang mungkin: Deteksi jika WinUI direferensikan selama Init, tetapi biarkan aplikasi berjalan. Setiap penyaji yang bergantung pada WinUI malah akan melempar, jadi itu hanya akan memengaruhi pengguna fitur baru ini. Jadi ceritanya menjadi "Jika Anda ingin menggunakan Shell atau PullToRefresh Anda juga harus menambahkan referensi ke WinUI (jika Anda menggunakan VS2017)".

@dotMorten Terima kasih atas semua upaya Anda untuk membawa Shell ke UWP! Hal ini sangat dibutuhkan dan sudah seharusnya disikapi oleh tim inti Xamarin.

Inilah rasa Xaminal yang berjalan di UWP dengan CV dan Shell!!!

Kerja bagus!

Pekerjaan yang fantastis. Kami akan memasukkannya ke dalam kerangka kerja kami untuk membangun aplikasi tingkat perusahaan segera setelah dirilis

Kerja bagus, saya akan mencobanya di rilis aplikasi saya di masa mendatang;)

Ya, Xamarin Berhasil! saya membaca satu orang mengatakan kami pindah ke Uno. Tidak!!!! Xamarin sangat bagus untuk kami dan menghemat banyak waktu kami karena harus belajar swift + java. Mari bersabar dengan tim dan dukung mereka

ditutup oleh #6015

Kerja Hebat, terima kasih untuk semua tim <3, saya akan mengubahnya

Kerja Hebat, terima kasih banyak!

OK sesuatu yang aneh terjadi, saya memutakhirkan proyek saya untuk menggunakan 4.3.0.947036, sekarang proyek gagal saat memanggil form.init dengan
'Tidak dapat menemukan Windows Runtime ketik 'Microsoft.UI.Xaml.Controls.XamlControlsResources

Yang sangat aneh adalah jumlah kode yang sekarang ditemukan di XamlTypeInfo.g.cs, di versi Xamarin sebelumnya kami hanya memiliki 13 entri, sekarang kami memiliki lebih dari 43. Saya menginstal Win.UI Nuget pada proyek dan masih ini tidak membantu. Ada ide?

@abrantie1z - (meskipun di luar topik, saya pikir saya akan menyebutkan) Formulir Uno dan Xamarin tidak harus menjadi pilihan yang saling eksklusif lagi - lihat https://platform.uno/xamarin-forms/ dan https:/ /visualstudiomagazine.com/articles/2019/09/19/uno-platform-2.aspx Peringatan: Saya belum pernah menggunakan Uno, jadi saya tidak tahu seberapa kuat dukungan ini. Tapi apa pun yang membuat lebih banyak orang tertarik pada XF di browser adalah Hal yang Baik.