Runtime: Port System.Xaml ke .NET Core

HORRAY! Pengakuan/pengakuan resmi! Dan ya, saya menyadari bahwa kata-kata itu TIDAK sama dengan "komitmen" tetapi ini jelas lebih baik daripada apa pun yang saya lihat sejauh ini. @terrajobst kamu adalah pahlawanku. :hati: :hati: :hati:

@cwensley dan @SuperJMN , akan sangat bagus jika ada dialog di antara semua orang di sini. Idealnya (dari sudut pandang saya) setiap orang pada akhirnya harus menggunakan satu port/versi perpustakaan Xaml baru dan tidak memiliki versi/dialek Xaml yang berbeda di luar sana. Apakah ini bahkan mungkin dari jarak jauh? Saya setuju jika tidak, tetapi saya ingin melihat apakah kita bisa jika demikian. :)

Juga, saya saat ini sedang dalam "sabat kerja (dari klien yang suka memerintah LOL)" dan saya memiliki 3-4 bulan yang dijadwalkan untuk lintas platform Xaml saja. Saya benar-benar dapat bekerja penuh waktu dan membantu ini selama waktu itu jika perlu. Apa pun untuk penyebabnya (dan juga, saya seorang oportunis untuk waktu yang tepat!)

jika System.Xaml mendapat open source saya yakin komunitas dapat mem-portingnya ke .net core sesuai dengan kebutuhan dan tujuan desain proyek ini, pengelola proyek hanya perlu memandu komunitas. Mari manfaatkan kekuatan komunitas .net.

@Michael-DST, saya setuju memiliki satu dialek xaml itu penting. Namun, implementasinya mungkin sama sekali berbeda. Standarisasi pada satu implementasi sangat tergantung pada masyarakat.

Untuk Portable.Xaml yang merupakan port PCL 259/136 dari implementasi System.Xaml (berlisensi MIT) yang sangat baik dari Mono, dengan banyak perbaikan bug. Idenya adalah untuk mendukung semua yang dilakukan MS' System.Xaml (termasuk membaca/menulis) menggunakan API yang sama, tetapi tidak harus terbatas pada itu.

Sebagai contoh fungsionalitas yang diperluas, Portable.Xaml mendukung penggunaan konverter tipe pada item dalam daftar, di mana System.Xaml menggunakan IList.Add(object) yang harus Anda terapkan menggunakan koleksi kustom untuk mendukung berbagai tipe.

@cwensley Saya mengklaim ketidaktahuan saya tentang ini ... tapi apa perbedaan antara .NET Core dan PCL? Saya pikir mereka sama? Artinya, itu adalah pemahaman saya bahwa jika Anda mendesain di bawah profil PCL tertentu, itu akan terbawa ke .NET Core ... ini beberapa waktu yang lalu (dan sejujurnya saya sedang menunggu .NET Core ke RTM/W), jadi sekarang adalah waktu yang tepat untuk menyegarkan diri. :P

Ini adalah pemahaman/kesan saya bahwa Portable.Xaml memang port dari System.Xaml mono, sedangkan OmniXaml adalah penulisan ulang dari bawah ke atas yang menampilkan beberapa hotness baru di arena parsing. Idealnya (dari sudut pandang saya sendiri) akan sangat bagus untuk menggabungkan keduanya, tetapi saya bahkan tidak yakin itu layak, atau bahkan diinginkan di antara kedua basis. Dalam pikiran saya (tanpa melakukan spelunking/analisis) pada dasarnya menggabungkan kematangan yang satu (Portable.Xaml) dengan hotness baru yang lain (OmniXaml).

@Michael-DST PCL 259 memang kompatibel dengan .NET Core, menurut posting ini . Saya telah memasukkan \lib\dotnet sebagai target dalam paket nuget untuk Portable.Xaml, sehingga _harus_ dapat digunakan apa adanya untuk .NET Core, meskipun saya belum mengujinya.

Saya tidak punya waktu untuk melihat ke OmniXaml, tetapi jika memang menulis ulang dari bawah ke atas, mungkin tidak masuk akal untuk menggabungkan kedua proyek karena saya yakin semuanya akan dilakukan dengan cara yang sama sekali berbeda. Saya juga tidak yakin manfaat dari hal seperti itu jika Portable.Xaml sebagian besar lengkap apa adanya. Saya bisa saja salah (;

:) Ya, saya mengeksplorasi opsi di sini, dan juga berurusan dengan ketidaktahuan saya dengan benar-benar berada di dunia open source. Saya benci gagasan memiliki banyak basis kode di luar sana melakukan hal yang sama. Dan terutama dengan komunitas Xaml yang lebih kecil, itu akan menyebalkan karena terfragmentasi sejak awal (bukankah itu seharusnya terjadi _setelah_ sesuatu menjadi terlalu sukses untuk kebaikannya sendiri?! haha). Bagaimanapun, akan sangat menyenangkan mendengar pendapat @SuperJMN tentang ini. Saya tahu dia tampak cukup tegas pada modifikasi barunya. Misalnya, penggunaan MarkupExtensionContext sebagai pengganti IServiceProvider untuk ekstensi markup, yang akan menjadi perubahan besar bagi siapa saja yang ingin memindahkan kode yang ada ke dunia baru ini.

Untuk memperjelas, semua profil PCL kompatibel dengan .NET Core. Kumpulan kontrak dan pemfaktoran yang kami miliki sekarang merupakan evolusi dari profil PCL. Ini tidak berlaku untuk perpustakaan portabel "gaya lama" (dikompilasi dengan mscorlib, dll.) yang tidak langsung kompatibel dengan .NET Core.

@Michael-DST

@terrajobst kamu adalah pahlawanku. :hati: :hati: :hati:

Meskipun saya sangat menghargai antusiasme Anda, saya ingin menjelaskan bahwa siapa pun dapat mengajukan permintaan seperti ini. Anda tidak memerlukan sponsor atau pengakuan dari kami untuk mengajukan masalah, meminta pekerjaan :-) Saya hanya mengajukan sendiri untuk menghemat waktu dan tidak menjadi super lumpuh ("jangan ragu untuk mengajukan bug") :-)

LOL @terrajobst tidak apa-apa, antusiasme saya setengah lidah dan setengah serius ... MSFT pada dasarnya diam tentang masalah ini selama hampir satu tahun sekarang, meskipun banyak suara dan percakapan ekstensif .

Jadi, pertimbangkan apa yang Anda lakukan setara dengan menyelipkan makanan di bawah pintu seseorang yang terkunci di sel isolasi selama hampir satu tahun. :stuck_out_tongue:

[Sunting: setelah membaca analogi itu (dan melihatnya dikutip di bawah), saya harus mengatakan itu mengerikan dan mungkin dipengaruhi oleh artikel yang saya baca saat itu -- berita sialan, mengapa Anda harus memengaruhi saya begitu?! Yang lebih baik/relevan mungkin akan mendapatkan suntikan uang tunai yang sangat dibutuhkan dari putaran malaikat setelah setahun kehabisan asap.]

cc: @Harikm86 , pemilik System.Xaml

Saya suka XAML. Ini adalah bahasa deklaratif yang bagus untuk semuanya, mulai dari Silverlight (ya, saya mengatakannya) hingga Windows Workflow dan sekarang ke platform Aplikasi Universal yang baru. Porting ke Core akan memungkinkan untuk mem-porting teknologi lain yang bergantung pada XAML. Kami membutuhkan ini!

Senang mendengar dukungan Anda @rschiefer! Terima kasih atas masukannya. Pastikan Anda memiliki pengembang Xaml lain yang Anda ketahui bergabung dengan utas ini dan membantu dengan percakapan/arah.

Saya juga penggemar Silverlight dan telah mengejar inkarnasi berikutnya sejak 2011 (steker tak tahu malu: jika Anda ingin memberi tahu tim Visual Studio bahwa Anda ingin melihat bentuk Silverlight berikutnya yang lebih cerdas, silakan pilih dan biarkan mereka tahu di sini ).

Saya ingin meluangkan waktu sejenak dan memastikan bahwa ketika kita mengatakan "Xaml" kita harus menginginkan set sistem/fitur Xaml yang ditemukan di .NET 4.x+ (atau "System.Xaml"). Bahkan Xaml Silverlight 5 akan melakukannya, sungguh.

(Tentu saja, menambahkan peningkatan baru yang ditemukan di OmniXaml juga diinginkan.)

Selama itu bukan versi "baru", versi bajingan di UWP yang pasti telah di-porting oleh tim magang, karena kita semua telah menderita sejak itu (lihat suara yang saya sebutkan di posting saya di atas).

Saya benar-benar bahkan ragu untuk menyebutnya sebagai sistem "Xaml", karena ini benar-benar XML dengan beberapa penguraian token tambahan untuk keberuntungan (yang jelas dibutuhkan). Fakta menyenangkan: Sistem Xaml UWP pada akhirnya menggunakan rakitan System.Xaml selama proses pembuatannya. Hmm... #ironi.

Idealnya setelah port ini terpasang, sistem UWP Xaml akan dihentikan sama sekali dan gunakan yang ini sebagai gantinya. Kami kemudian dapat meletakkan bab sejarah Xaml yang memalukan itu di belakang kami, dan banyak pengembang bersukacita akan didapat.

Mendapatkan Silverlight kembali dalam bentuk yang lebih baru dan lebih baik juga tidak buruk. :) :) :)

@Michael-DST

Jadi, pertimbangkan apa yang Anda lakukan setara dengan menyelipkan makanan di bawah pintu seseorang yang terkunci di sel isolasi selama hampir satu tahun. :stuck_out_tongue:

lumayan :senyum:

@Michael-DST

Saya sebenarnya telah menghindari UWP sampai saat ini mengetahui banyak yang telah berubah dan saya lupa UWP menggunakan "versi" Xaml-nya sendiri. Terima kasih telah mengingatkan saya.

Saya sepenuhnya setuju, System.Xaml harus di-porting dan kemudian kita dapat memperbaiki UWP untuk menggunakan Xaml asli.

Saya sepenuhnya setuju, System.Xaml harus di-porting dan kemudian kita dapat memperbaiki UWP untuk menggunakan Xaml asli.

Maaf @terrajobst , saya punya pahlawan baru sekarang di @rschiefer. :senyum: :senyum: :senyum:

Terima kasih semua atas diskusinya. Ini sangat keren bagi saya (tapi saya bisa dengan mudah terkesan!).

@Michael-DST @rschiefer

@helmsb YA! LOL haha!

FWIW, teknologi Desain Material Google yang populer untuk web (Angular.js), aplikasi (Android), dll. juga tersedia open source. Semoga argumen ini membantu meyakinkan bos dan entitas seperti bos.

@dsaf apa maksudmu?

FWIW Saya telah mereferensikan masalah ini dalam sebuah artikel yang diposting hari ini berjudul Is the Tide Turning on project.json? , lihat bagaimana Xaml merupakan mekanisme yang disukai untuk menggambarkan objek .NET dari perspektif bisnis/IP teknis dan MSFT.

Nah semuanya, bagaimana dengan kesepakatan Xamarin itu, ya! sesuatu memberitahu saya bahwa masalah ini akan menjadi jauh lebih sibuk dalam beberapa bulan mendatang. :senyum:

Belum tentu. Mungkin ada peluang bagus apa yang kita lihat UWP's Xaml atau Xamarin's flavor of Xaml menjadi beberapa perpustakaan lintas platform. Yang mungkin berarti baik port System.Xaml atau bahkan implementasi Xaml yang dikelola murni tidak dapat terjadi.

Sistem Xaml Xamarin tertutup/internal dan tidak sedewasa System.Xaml. Kode itu sendiri agak tipis (kekhawatiran yang diakui di pihak mereka - sebenarnya menggunakan itu adalah salah satu alasan ditutup/internal). Selain itu, ini terkait erat dengan BindingObject yang menjadi penghalang jika Anda ingin melakukan serialisasi POCO, dll.

Dan seperti diuraikan di atas, sistem Xaml UWP sangat buruk. Kecuali ada sesuatu yang Anda tahu yang saya tidak tahu. :stuck_out_tongue:

Bisakah Anda menjelaskan apa yang Anda maksud dengan "implementasi Xaml yang dikelola murni"? FWIW, harapan saya di sini bukan port langsung 1:1 dari System.Xaml tetapi perpustakaan System.Xaml (Microsoft.Xaml?) "baru" yang mengambil semua kebaikan dari System.Xaml, Xamarin.Core.Xaml, dan ... yah, saya akan mengatakan Xaml UWP, tapi ... :wink:

Saya pernah mendengar bahwa secara internal ada preferensi untuk Xaml UWP daripada WPF dan Xaml semacam itu, meskipun jelas tim yang berbeda di Microsoft mungkin memiliki pendapat yang berbeda. Xaml DotNet tidak diragukan lagi lebih kuat dan fleksibel, tetapi seperti apa pun dengan deskriptor yang kemungkinan datang dengan kelemahan itulah alasan UWP sangat dikurangi.
Dan dengan tidak murni dikelola, saya mengacu pada satu hal yang baik tentang Xaml UWP karena tidak eksklusif DotNet. Jadi Microsoft.Xaml yang potensial di masa depan dapat menjadi implementasi asli lintas platform dengan fasad yang dikelola sehingga dapat digunakan di luar DotNet. (Itu juga akan mengecualikan penyertaannya dalam dotnet/corefx kecuali pustaka masa depan ini diputuskan untuk dikirimkan sebagai komponen CoreFX)

Baiklah, saya bingung. Ketika Anda mengatakan .NET... Anda sedang berbicara 4.6, kan? Dari pemahaman saya, ini untuk .NET Core Xaml library, yang pada dasarnya bersifat lintas platform dan eksklusif .NET (4.6)? Ketika Anda mengatakan "tidak eksklusif DotNet", maksud Anda "apakah DotNet inklusif"? Negatif ganda. :stuck_out_tongue: Ini jelas tidak benar karena Anda tidak dapat menggunakan UWP Xaml di .NET 4.6 (Anda juga tidak ingin :stuck_out_tongue:).

Tolong beri tahu saya apa yang salah saya di sini. Selain itu, tujuan yang baik di sini adalah agar Xaml dikirimkan sebagai bagian dari CoreFX. Beberapa diskusi telah terjadi selama beberapa waktu . -- dan tentu saja, jika saya tidak salah @RichiCoder1 Anda memiliki suara untuk melakukan ini di utas itu... Saya bertanya-tanya di mana saya pernah melihat tag Anda sebelumnya! :senyum:

Dan saya juga ingin mengatakan bahwa saya juga telah mendengar kecenderungan internal terhadap Xaml UWP, tetapi itu sebelum ada beberapa diskusi komunitas di sekitarnya yang dimulai di utas di atas dan di luar ( diskusi Twitter ala Tim Heuer ). Jarumnya pasti bergerak sejak saat itu. Setidaknya, itu lebih baik! TERTAWA TERBAHAK-BAHAK. Ada orang-orang dengan kesalahpahaman bahwa "Xaml adalah untuk UI" dan kemudian ada sebagian dari kita yang mengerti cara kerjanya. :stuck_out_tongue:

Ketika saya mengatakan DotNet, maksud saya DotNet termasuk inti dan kerangka kerja. Dan saya menyadari Anda tidak dapat menggunakan UWP Xaml di luar aplikasi UWP, saya mengacu pada kemampuan untuk menggunakannya di aplikasi C++ UWP. Jadi ketika saya mengatakan tidak eksklusif untuk DotNet, maksud saya akan menggunakannya dari C++ (atau kemungkinan bahasa lain). Dan saya membayangkan alasan mengapa tim yang memiliki XAML tidak menganggap serius kasus penggunaan di luar UI adalah karena hal itu jarang terjadi atau, dalam beberapa kasus, secara aktif difitnah dengan Microsoft atau dengan mitra. Bukan pendapat pribadi saya, saya menghargai ekspresi dan kekuatannya.

OK bagus @RichiCoder1 terima kasih atas penjelasan Anda. Saya pikir saya _hampir_ sepenuhnya mengikuti Anda sekarang... ketika Anda mengatakan "kerangka" maksud Anda 4.6?

Dalam pandangan saya, saya akan mengatakan bahwa sebagian alasan mengapa tim internal merasa jarang menggunakannya di luar UI berkaitan dengan keterlibatan yang buruk dengan pengembang, seperti yang saya pikir ditunjukkan oleh posting Tim. Saya juga bersalah dalam hal ini karena saya benar-benar tidak senang menggunakan MSFT sampai sekitar satu tahun yang lalu? Sebenarnya Tweet Tim adalah tentang pemungutan suara yang saya buat, setelah saya secara pribadi/pribadi mengeluh kepada semua orang sejak Windows 8.0 bahwa sistem Xaml benar-benar berbeda dan tidak seperti yang seharusnya. Ketika saya mendengar keributan bahwa UWP (Windows 10) Xaml pada dasarnya sama -- setelah 3 tahun tidak ada inovasi atau peningkatan -- saat itulah saya melangkah. Kalau dipikir-pikir itu seharusnya lebih cepat.

Aman untuk mengatakan bahwa itu adalah pelajaran pembelajaran utama. Saya (atau setidaknya merasa seperti saya) sekarang jauh lebih terintegrasi dalam ekosistem dan merasa seperti saya didengar. Faktanya, suara _sangat penting_ yang saya buat lebih dari empat bulan lalu ditandai sebagai Sedang Ditinjau oleh tim Visual Studio yang prestisius awal minggu ini. Mengatakan dunia saya telah diguncang adalah pernyataan yang meremehkan. :senyum:

Dengan kerangka kerja, saya menggunakannya untuk merujuk ke desktop .Net. Itu tampaknya menjadi cara populer untuk membedakan antara Core dan Full Framework.

Saya setuju. Salah satu hal baik tentang semua langkah terbaru Microsoft adalah hampir memaksa keterlibatan yang lebih baik dengan pengembang :).

Sangat bersemangat tentang itu sendiri! Sekarang hanya untuk melihat bagaimana drama itu. Itu bisa berarti apa saja dari menjadikan perkakas Xamarin kelas satu selain aplikasi UWP menggunakan proyek bersama mereka, atau itu bisa berarti sesuatu yang tingkat tinggi bahkan dari itu. Hanya waktu (dan saya kira, //Build) yang akan memberi tahu.

Oke gan... Terima kasih infonya. :+1:

Adapun //build... memang. :) Secara pribadi, saya ingin melihat model baru sama sekali yang (longgar?) berbasis UWP dan memanfaatkan kebaikan Xamarin baru untuk memindahkannya ke iOS/Droid. Model Xaml yang lebih kuat juga tidak ada salahnya. Kurasa kita harus merahasiakan utas ini sampai setelah 28 April. :stuck_out_tongue:

Saya harap kalian bisa melakukannya! :)

Tebak orang-orang UWP akan lebih mudah mengadopsi implementasi XAML yang tidak menarik kode .NET (bahkan jika kode itu adalah barang .NET Core).

Seperti kotak hitam mandiri (atau hanya tergantung pada UWP, tetapi kami tidak menginginkannya karena UWP adalah non-crossplatform [belum] dan jika itu salah satu masih akan kehilangan versi terkelola yang dapat berjalan di .NET/ Silverlight [tidak dapat mengunci aplikasi Anda hanya untuk target Win10]).

Tapi ini kurang lebih utopis menurut saya, kecuali jika Anda membuatnya dengan lapisan abstraksi dan pluggables / driver untuk berbagai aplikasi XAML (untuk UWP UI, untuk Workflow, untuk WPF/.NET, untuk Silverlight dll.). Seperti bagaimana DirectX tampak seperti mesin melalui HAL (Lapisan Abstraksi Perangkat Keras), yang juga membuka kemungkinan untuk HEL (Lapisan Emulasi Perangkat Keras - lihat sebutan di http://www.developer.com/net/asp/article.php/968461/What -is-DirectX.htm). Tentu saja jika Anda tidak hati-hati itu juga bisa membuka pintu neraka mengenai kinerja, tetapi karena DirectX bisa menariknya, saya kira arsitektur seperti itu tidak buruk

+1 untuk porting System.Xaml ke .NET Core.
Saya berharap untuk melihat satu dialek XAML terpadu (.NET Xaml, UWP Xaml, Xamarin Xaml) digunakan di semua platform di masa mendatang.
Sepertinya .NET Core Version dari System.Xaml diperlukan untuk mencapai ini.

+1

Untuk menghindari peringatan pemberitahuan massal, kami sekarang memiliki cara baru untuk memberi +1 pada setiap komentar di GitHub, untuk menunjukkan minat / reaksi kami terhadap topik yang ada:

Haha @jasonwilliams200OK Saya tidak keberatan dengan peringatan pemberitahuan massal dari anggota komunitas yang mengungkapkan minat dasar mereka pada solusi System.Xaml lintas platform yang kuat. :angel: Mungkin topik lain saya akan berbagi rasa sakit/gangguan/frustrasi Anda, namun. :mengedip:

Poin yang valid (dan berharga), dalam hal apa pun. Saya telah menambahkan :+1: saya untuk penyebabnya.

@jasonwilliams200OK

Terima kasih telah memanggil ini!

FWIW, saya baru saja mengundang tim Xamarin.Forms untuk bergabung dalam percakapan di sini:
https://bugzilla.xamarin.com/show_bug.cgi?id=26740

Atau jika ada, buat semua orang _di sini_ mengetahui percakapan _di sana_. :senyum:

Ada beberapa diskusi hebat yang terjadi di komentar posting ini:
https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

Pada dasarnya JSON vs Xaml untuk sistem proyek baru yang tampaknya sedang berlangsung untuk Visual Studio (hore!). Jangan ragu untuk bergabung. :) Senang sekali melihat ini terlihat lagi.

@Mike-EEE, lihat juga peta jalan ini: https://github.com/dotnet/roslyn-project-system/blob/master/docs/Roadmap.md. Sistem proyek bertenaga Roslyn yang baru akan menjadi .. berharga.

whoa... gila aku baru dengar ini sekarang. ini pasti yang dimaksud Scott Hunter dalam posting blog yang disebutkan di atas sehubungan dengan informasi lebih lanjut yang akan datang di posting mendatang. Bagus untuk dilihat. Kekuatan Roslyn tumbuh. Meskipun, saya akan merasa lebih nyaman melihat beberapa masalah untuk definisi proyek serial Xaml. :mengedip:

Lihat readme repo itu: https://github.com/dotnet/roslyn-project-system#welcome -to-the-roslyn-c-and-visual-basic-project-system (dan tautan ke blog VS MSDN ), sepertinya kita dapat mengganti berbagai komponen menggunakan MEF, yang memungkinkan untuk menyisipkan serializer tambahan untuk mengurai definisi proyek yang ditulis dalam XAML. Secara pribadi, saya telah berkembang untuk lebih memilih JSON daripada XAML/XML dalam hal menggambarkan properti proyek dan dependensi dll. Karena JSON kurang berisik (yah, YAML kurang berisik daripada JSON dan standar lang mendukung komentar tidak seperti std-JSON, tetapi di dunia dotnet, YAML dan bahasa lain dengan sintaks yang sadar lekukan belum mendapatkan daya tarik)

Secara pribadi, saya telah berkembang untuk lebih memilih JSON daripada XAML/XML

KEAMANAN! HAPUS ORANG INI!!! Eh maksudnya... :)

Saya semua untuk mengambil yang terbaik dari kedua dunia. @SuperJMN dan @Grokys mungkin berbicara lebih banyak tentang ini, tetapi saya yakin upaya sedang dilakukan di OmniXaml untuk membuatnya kurang bertele-tele dan cerewet.

Masalah saya dengan JSON bukan dengan JSON semata, tetapi pendekatan desainnya yang juga merupakan dasar dari konfigurasi .NET (yang saya asumsikan sebagai inspirasinya), dan yaitu, skema objek adalah "artefak lain" yang pengembang harus mengelola/memelihara dan _bukan_ definisi kelas. Artinya, dalam pemrograman Xaml (seperti yang Anda ketahui!) definisi kelas _adalah_ skema dokumen. Akibatnya, ini memberikan nuansa yang sangat alami untuk pengembangan dokumen, dan juga membantu/membantu dengan perkakas juga.

Belum lagi kewarasan pengembang. :smile: Tidak ada yang membuat saya lebih marah daripada harus mengejar beberapa dokumen skema yang tidak jelas dan mencari cara untuk menginstalnya dan mendapatkan intellisense paling sederhana untuk bekerja.

Masalah lain yang saya miliki dengan JSON sekali lagi bukan khusus JSON, tetapi lebih pada pola pikir web dan itu adalah konvensi penamaan. Konfigurasi .NET juga mengalami hal ini. Artinya, Anda mungkin mendefinisikan POCO seperti:

public class MyPoco {
    public string Property {get; set;}
}

Dan JSON-nya (atau app.config) akan terlihat seperti (dan Anda dapat mengajari saya tentang ini jika saya salah!):

{
 { "property": "Hello world I have inconsistent naming conventions!" }
}

Di sini sekali lagi Xaml disejajarkan antara definisi kelas dan rekan serialnya, itulah sebabnya saya lebih menyukainya.

Saya harus mengatakan bahwa .NET Configuration adalah yang TERBURUK karena desainnya menghasilkan empat artefak untuk setiap entitas konfigurasi:

1. Elemen di web/app.config
2. File .xsd yang harus Anda tautkan secara ajaib ke web/app.config (saya tidak pernah berhasil!)
3. Elemen ConfigurationElement dan/atau ConfigurationSection yang mengambil nilai dari app/web.config (dan memetakan camelCase yang tidak konsisten ke PascalCase -- oh kegilaan!)
4. POCO yang akhirnya terhubung dari elemen konfigurasi. (WAH!)

Saya belum cukup mempelajari desain proyek JSON untuk mengetahui apakah ada objek POCO yang diserialkan dengan dokumen .JSON atau apakah pemetaan asing yang diuraikan di atas juga terjadi. Saya akan senang mendengar jika Anda tahu jawabannya.

Bagaimanapun, Xaml meningkatkan desain ini dengan hanya membutuhkan dua artefak:

1. File kelas (.cs)
2. Berkas data (.xaml)

Akhirnya, terima kasih atas tautan ke readme itu! Saya sekali lagi "orang itu" yang tidak melakukan hal yang diminta file itu. :tertawa:

jika ada objek POCO yang sedang diserialkan dengan dokumen .JSON atau jika pemetaan asing yang diuraikan di atas juga terjadi. Saya akan senang mendengar jika Anda tahu jawabannya.

Saya pikir jika Anda mempertimbangkan atribut [DataContract] dan [DataMember], maka .NET framework (pada level BCL) membantu JSON dan serailizer data lainnya. Namun, tidak ada literal objek JavaScript asli/tingkat rendah <-> C# POCO yang didukung oleh kompiler transisi sebagai JSON ke JavaScript (dan banyak bahasa lainnya) atau CSON ke CoffeeScript. Namun, tidak seperti XML dengan semua ikatan XPATH XQUERY XSLT, JSON memiliki konsep skema untuk memvalidasi data dan JSON.net mendukungnya seperti seorang juara.

Untuk C#6 dan di atasnya, lihat masalah/proposal ini https://github.com/dotnet/roslyn/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+author%3Agafter+ kamus , terutama https://github.com/dotnet/roslyn/issues/6949 dan ikuti tautan di dalamnya. Dengan sintaks penginisialisasi kamus C#6 yang baru dan proposal ini, sepertinya C# secara semantik menjadi lebih ramah JSON.

Saya harus mengatakan bahwa .NET Configuration adalah yang TERBURUK

Setuju, Anda juga dapat menikmati pola "Konfigurasi" dan "IOption" yang diperkenalkan oleh tim ASP.NET sebagai paket plug and play: https://github.com/aspnet/Configuration , https://docs.asp.net/ en/latest/fundamentals/configuration.html , yang menggantikan manajer konfigurasi lama yang terikat XML.

JSON memiliki konsep skema untuk memvalidasi data dan JSON.net mendukungnya seperti jagoan.

Kedengarannya seperti definisi kelas sebagai skema. :) :) :)

sepertinya C # secara semantik menjadi lebih ramah JSON.

Haha pasti, objek _any_ sudah ramah-JSON. JSON sangat bagus untuk melakukan apa yang dimaksudkan untuk dilakukan: membuat catatan definisi objek dengan cara yang ringkas dan dapat dibaca manusia. Dan tidak diragukan lagi bahwa JSON.net melakukan pekerjaan yang baik untuk memenuhi tujuan ini. Ketika Anda menjelaskan _aplikasi_ maka kita mulai masuk ke area di mana percakapan ini mulai, um, terlibat karena tidak ada kata yang lebih baik. :senyum:

Pada akhirnya, ada dua skenario di sini (bagi saya, setidaknya): menggambarkan objek yang dimaksudkan untuk ditransfer antara batas layanan (ringan) dan menggambarkan aplikasi yang membuat objek tersebut (signifikan). Saya pribadi ingin berusaha untuk konsistensi dalam segala hal yang mungkin dan meminimalkan konteks-switching. Selama kita menjaga pilihan kita ( IOptions ? :laughing:) terbuka dan memungkinkan pengembang untuk memilih format yang paling masuk akal bagi mereka (dan memungkinkan mereka untuk menggunakan alat yang membuat mereka merasa paling efisien! ) maka kita semua menang di sini. :+1:

UWP XAML memiliki lebih sedikit fitur dibandingkan dengan .NET WPF XAML klasik. Salah satu fitur yang paling saya rindukan adalah TypeConverters.

Saya mencoba membuat TypeConverter saya sendiri seperti yang disarankan di sini https://msdn.microsoft.com/en-us/library/bb546926 (v=vs.90).aspx (artikelnya untuk WPF TypeConverter)

Di UWP saya mendapatkan ini "Jenis tidak dikenal 'mobil' di ruang nama XML ' menggunakan: App2TypeConverters '"

        <ListBox>
            <local:car></local:car>
        </ListBox>

Apakah benar-benar tidak mungkin menambahkan TypeConverter khusus di UWP? Atau ada solusi? Saya membaca di suatu tempat bahwa XamlCompiler menggunakan IServiceProvider internal untuk mendaftarkan TypeConverter. Mungkin itu bisa didaftarkan entah bagaimana?
Saya juga tertarik untuk mempelajari lebih lanjut tentang latar belakang kompilasi XAML. Apakah XAML masih akan dihasilkan ke BAML? Bisakah kita entah bagaimana terhubung ke kompilasi XAML?
Jadi, silahkan buka System.Xaml.

Sooooooo... apakah ini berarti System.Xaml akhirnya akan bergabung dengan party??? :senyum: :senyum: :senyum:
https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it-easier-to-port-to-net-core/

Aku akan pipa di sini dan berkata:
a) Saya sangat ingin XAML berjalan dengan .Net Core dan
b) jika itu terjadi, akan lebih masuk akal untuk menggunakan rasa UWP, karena sudah di-porting ke arsitektur lain (misalnya, IoT push pada Raspberry Pi).

Mendapatkan WPF XAML akan luar biasa, jika memungkinkan.

Dengan cara yang sama bahwa inti .NET pada dasarnya dibangun kembali dari bawah ke atas, berdasarkan pembelajaran selama satu dekade terakhir, saya pikir hal yang sama harus dilakukan untuk XAML. Evolusi WPF/Silverlight/WinRt-XAML telah menjadi bencana besar. Satu langkah ke depan, dua ke belakang (satu ke samping). Janji XAML, Expression Blend dll tidak pernah membuahkan hasil.

Saya mendengar Scott Hunter membenarkan tidak ada UI lintas platform di Dotnet Core tempo hari dengan mengatakan "Yah, mereka tidak pernah menjadi baik. Pada pengguna Windows mengharapkan tombol yang mencari Windows, di Mac tombol Mac". Maafkan aku - kemana dia selama 5 tahun terakhir??? Web sepenuhnya mendominasi desain UI sekarang dan di web tidak ada yang namanya "tombol standar" - tapi coba tebak? Pengguna telah berhasil menyelesaikannya. Argumen itu bertentangan dengan semua bukti. UI Web ini sekarang mendominasi perdagangan di planet ini. Namun ternyata itu tidak cukup baik untuk Dotnet Core. Mengapa kita tidak dapat memiliki XAML lintas platform tanpa mengikuti aspirasi "tampilan & nuansa platform standar" [imajiner]?

Hambatan teknis utama yang saya kira adalah bagaimana menghubungkan "XAML" (Atau apa pun platform UI generasi berikutnya disebut) dengan API 3D lintas platform - karena kami jelas tidak dapat mengambil ketergantungan pada Direct3D/Direct2D pada MacOS dll. Tapi saya kira masalah ini telah diselesaikan oleh Unity dll yang berhasil mencapai tujuan itu.

Ada begitu banyak langkah yang diseret oleh Microsoft tentang sumber terbuka keluarga teknologi XAML, orang harus bertanya-tanya apakah yang tersembunyi di dalamnya adalah cache rahasia bitcoin atau kunci pribadi ke microsoft.com.

Lanjutkan MSFT : Open Source WPF/Silverlight/WinRT-XAML dan biarkan era keemasan UX berikutnya dimulai.

Sungguh luar biasa mendengar apa yang Anda katakan tentang Scott Hunter, @JackUkleja. Apakah Anda memiliki sumber/tautan untuk itu? Jika apa yang Anda katakan itu benar, maka selain apa yang Anda katakan, ini menunjukkan ketidaktahuan (mengejutkan) di beberapa bidang:

1. Inilah yang coba ditangani oleh Xamarin.Forms.
2. UX/interaksi/gaya khusus platform (atau meniru) adalah masalah yang dapat dan harus ditangani oleh tema. Inilah yang sangat baik dari WPF (walaupun menurut pendapat Anda itu bisa dan harus ditingkatkan).
3. Yang terburuk, ini tidak menempatkan kepercayaan apa pun ke dalam kumpulan bakat yang berhasil menciptakan WPF, yang bisa dibilang merupakan kerangka presentasi terbesar sepanjang masa. Apakah Anda mengatakan bahwa mereka tidak dapat lagi memecahkan masalah ini? Atau setidaknya melakukan keajaiban yang sama yang membuat WPF begitu sukses secara lintas platform?

UX yang baik adalah UX yang baik. Seperti yang Anda tunjukkan, web menunjukkan ini dengan jelas. Pengguna aplikasi asli pasti dikondisikan untuk tampilan dan nuansa tertentu untuk antarmuka asli mereka, tetapi sekali lagi ini harus dapat dipecahkan dari sebuah tema.

Bayangkan bisa melihat aplikasi di perangkat iOS dalam "kulit" Droid (lengkap dengan perilakunya) dan sebaliknya. Ini mungkin/mungkin dengan WPF dan persis seperti pemikiran yang harus dibawa ke depan. Artinya, tampilan/rasa/pengalaman tidak boleh menghalangi pengembangan dan perancangan aplikasi. Anda harus dapat menerapkan tema, dan whalah, "itu hanya berfungsi." Sayangnya ini adalah pencela untuk Xamarin.Forms karena meskipun memperhitungkan platform yang berbeda, ada banyak gesekan yang terlibat dengan memastikan semuanya bekerja seperti yang diharapkan pada setiap platform target.

@Mike-EEE Saya cukup yakin Scott Hunter mengatakan kata-kata yang berpengaruh pada episode batu dotnet ini: https://www.dotnetrocks.com/?show=1291

Ulang:

"kumpulan bakat yang berhasil menciptakan WPF, bisa dibilang kerangka presentasi terbesar sepanjang masa"

... pemahaman saya adalah sejumlah besar arsitek asli beberapa dari mereka yang terlibat dengan WPF meninggalkan MSFT dan pergi ke Google dan telah terlibat dengan Angular. Banyak ide dari WPF muncul di Angular dan kerangka kerja terkait seperti templating. Tapi tidak peduli dengan cara apa Anda mengiris kerangka kerja web ini, saya pikir Anda akan selalu memiliki bau HTML/CSS di latar belakang. Tidak semua UI masuk akal karena berbasis dokumen/semantik dan itulah sifat HTML, itulah sebabnya saya rasa dunia masih dapat menggunakan "inti XAML".

[jack...tidak berpikir bahwa data itu benar tentang google dan arsitek WPF]

@rrelyea Itu pemahaman saya tapi saya mungkin salah. Saya berani bersumpah saya membaca bahwa beberapa tim WPF bekerja di Angular.... Ian Ellison-Taylor antara lain? (Meskipun tampaknya dia kembali ke MSFT sekarang...)

bau HTML/CSS di latar belakang

Semakin banyak kesesuaian dan konvergensi menuju standar CSS HTML terpadu atau standar apa pun dalam hal itu (C, C++, JavaScript), tempat yang lebih baik di dunia ini. Alih-alih XAML dengan fitur uniknya, dapat menjadikan dirinya sebagai kerangka kerja superset ke tumpukan HTML+CSS dll. Atau hanya sebagai mesin front-end alternatif untuk Razor ASPNET: https://github.com/aspnet/Razor/issues/78 : bohlam:

@jasonwilliams200OK FWIW/FYI sudah ada port "standar" HTML/CSS dari .NET di JSIL . Semua outputnya 100% sesuai dengan HTML5 dan berjalan di browser modern apa pun. Ini adalah jenis pemikiran yang harus kita cita-citakan, tentu saja (dan seharusnya menjadi pemikiran sejak kematian Silverlight pada tahun 2011, tapi saya ngelantur).

Artinya, (untuk poin Anda, saya harap) yang ideal/bertanya adalah bahwa pengembang .NET hanya harus berurusan dengan .NET/C#/F#/VB.NET dan tidak pernah harus menyentuh CSS/HTML/JS, seperti bagaimana Pengembang Xamarin .NET tidak harus menyentuh dasar-dasar iOS/Droid (apa pun _mereka_. :wink: ).

@Mike-EEE, dalam bahasa superset (TypeScript ke JavaScript atau Less to CSS), kita dapat menggunakan kode lang subset di super-set di file yang sama, tetapi tidak sebaliknya. Jadi konsep superset sedikit melampaui fungsi phonegap, cordova, dll. :)

Haha yeah @jasonwilliams200OK Saya hanya ingin memastikan kita tidak membuat kasus khusus untuk pendekatan/strategi kita dengan mendapatkan kembali .NET ke browser. Menyentuh CSS/JS harus dilihat dengan penghinaan yang sama seperti menyentuh biner. :stuck_out_tongue:

Sebagai contoh, ada juga proyek lain Fayde yang menggunakan Xaml (yay), tetapi juga bergantung pada TypeScript (boo). Ini adalah cara untuk TIDAK melakukannya, karena Anda akhirnya berakhir dengan dua basis kode yang tidak kompatibel -- satu di TypeScript/JS untuk kode klien, .NET untuk yang lainnya -- yang sangat mahal dalam waktu dan sumber daya.

mesin front-end alternatif untuk Razor ASPNET

Razor hanyalah sebuah template engine menurut saya. Sebenarnya di tautan yang Anda sebutkan itu mengatakan "... bahwa Anda dapat memilih dari daftar panjang mesin templating front-end untuk dikodekan."

Saya bahkan telah mendengar beberapa komentar dari MS terhadap sintaks khusus seperti C# seperti Razor di dalam halaman HTML, yang mendukung kerangka kerja yang menggunakan tag khusus sebagai gantinya

btw, ada juga Bridge.net (http://bridge.net) dan kompiler C# ke Javascript lainnya yang dapat digabungkan dengan solusi XAML seperti Fayde

Re XAML pada HTML5/JS/etc. Ada proyek Granular yang menarik yang mengimplementasikan ulang WPF. Ia menggunakan Saltarelle untuk mengkompilasi ke JS. Sebuah contoh hidup di sini .

Granular itu cukup fantastis, @ethanhs. Itu salah satu yang tidak saya sadari. Karena telah mengambil pendekatan yang sama CSHTML5 , JSIL, Bridge.net (yang disebutkan oleh @birbilis ), ia mengalami masalah yang sama karena tidak dapat berbagi kode antara server dan klien melalui penggunaan PCL, yang benar-benar satu-satunya yang layak. cara untuk melakukannya hari ini.

Dan sungguh, sehebat tampilan proyek itu, cukup banyak gambaran neraka yang harus ditanggung oleh pengembang .NET sejak runtuhnya Silverlight. Itu dan sekitar selusin lainnya melakukan "agak" pekerjaan untuk membuat .NET bekerja di browser, tetapi tidak sepenuhnya pengalaman yang diharapkan oleh mereka yang memiliki pengalaman Silverlight.

Belum ada satu solusi pemersatu tunggal yang menyebabkan pengembang melupakan Silverlight. Padahal kami semakin dekat. Saya berharap, setidaknya. WebAssembly tampaknya menjanjikan tetapi saya belum melihat/mendengar perkembangan signifikan dalam beberapa saat sekarang. Port/inisiatif yang digerakkan oleh JSIL tampaknya agak melambat dan belum melakukan check-in sejak Oktober lalu.

Mudah-mudahan kita akan memiliki terobosan di sini dalam waktu dekat. Saya akan senang melihat pengumuman yang dibuat di //build tahun depan yang menyatakan seperti itu. :hati: :+1:

Itu akan menjadi salah satu hal terbaik dalam beberapa tahun terakhir yang terjadi pada XAML.
Pilih di sini !

Keren @bbougot. Ada juga suara lain, yang _finally_ mendapat perhatian, setelah hampir 15 bulan keberadaannya, tidak termasuk selama hampir 3 tahun tidak mengenali sistem Xaml yang mengerikan untuk memulai (tapi saya ngelantur!):
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

(Serius, 15 bulan bahkan untuk mengenali suara untuk masalah yang paling jelas? Apa yang dilakukan tim UWP di sana??? Kapan tim Visual Studio atau .NET akan mengambil alih dan memperbaiki kapal??? Apa yang akan terjadi . .. oops, benar, saya ngelantur...)

Juga, jangan lupa untuk upvote thread ini. Ini berjalan cukup baik @ 60 saat ini, terutama mengingat masalah ini dimulai sebelum kami memiliki fasilitas mewah seperti Reaksi GitHub. :senyum:

Xaml adalah satu-satunya dengan potensi untuk menyatukan seluruh ekosistem klien!
Tolong singkirkan DirectX, tolong peluk OpenGL,!
UWP dijalankan di PC, di ponsel, di situs web!
Viva Xaml!

Jadi, pertanyaan sipil di sini @terrajobst , @harikmenon , dan @karelz (Saya melihat Anda telah menambahkan tag baru-baru ini jadi selamat, saya menarik Anda ke dalam ini!). Karena rasa ingin tahu yang sederhana, saya memutuskan untuk sedikit berpetualang dan memeriksa pemfilteran GitHub lanjutan (atau mungkin tidak) pada repo ini. Berpikir bahwa ada banyak suara dan apa yang tidak untuk masalah yang berbeda.

Berikut adalah URL yang saya gunakan:
https://github.com/dotnet/corefx/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

Sepertinya masalah ini memiliki 82 suara positif saat ini, dan jika saya benar, item terdekat berikutnya dalam daftar adalah 17. Itu membuat masalah ini sejauh ini menjadi masalah yang paling banyak diminta/dipilih dalam repo ini, benar?

Jika demikian, saya ingin tahu apakah ini ada kaitannya dengan prioritas dan/atau perencanaan Anda. Jelas ini tampaknya menjadi pertanyaan/item _sangat_ populer sekarang (sekali lagi, jika saya mengerti dengan benar), jadi saya pikir mungkin akan menyenangkan untuk mendengar mungkin pembaruan atau check-in sehubungan dengan kemungkinan memulai percakapan menuju kemajuan dalam pembuatan masalah ini kemungkinan.

Akan sangat bagus untuk mendapatkan perspektif/konteks apa pun di sini, dan/atau jika saya memiliki sesuatu yang sepenuhnya disalahpahami sehubungan dengan permintaan pelanggan. Itu terjadi. 😄.

Insinyur .NET Core kami sangat fokus pada .NET Standard 2.0 (juga permintaan pelanggan yang tinggi) – lihat detailnya di sini dan di sini . Kami akan melihat perpustakaan lain yang tidak ada dalam daftar itu setelah kami mendapatkan .NET Core hingga standar terbaru.

Terima kasih telah menunjukkan kueri upvotes!

Terima kasih atas tanggapan Anda @karelz! Sangat dihargai. 👍

Saya akan meninggalkan ini di sini jika ada yang ingin menyukai/me-retweet. 👼 👼 👼.
https://twitter.com/MikeEEE76/status/776769805722521600

Saya telah bekerja dengan xaml sejak versi 3 .net, saya merasakan pengurangan dengan silverlight dan bahkan kematiannya. Saya seseorang yang menyukai perubahan untuk perbaikan untuk membuat hal-hal yang lebih baik dan lebih bermanfaat. Tapi sekarang dengan UWP, saya menemukan kemunduran bukannya bergerak maju. Jangan pedulikan semua fitur baru yang jika terasa hebat, tetapi kurangnya dukungan xaml penuh seperti yang dimiliki aplikasi desktop. Saya telah mencoba membuat aplikasi baru di UWP, dan saya belajar dengan susah payah bahwa semua yang telah saya pelajari telah berubah lagi, saya tidak dapat menemukan banyak dukungan online, karena perpustakaan xaml telah pindah. Misalnya penghias yang berada di bawah kerangka sudah tidak ada lagi, x:statis untuk properti yang tidak berfungsi, Anda harus mencari berjam-jam untuk menemukan contoh atau apa yang harus dilakukan. Tidak ada tautan untuk menunjukkan dari xaml lama ke UWP baru ...

@giworking Jelas bahwa MS harus memperhatikan pengembangan klien! Seperti dikutip Satya Nadella,azule adalah inti dan masa depan MS, Energi terkuat untuk mendorong azule adalah seluruh ekosistem .net. Dibandingkan dengan java, sisi klien hampir satu-satunya senjata untuk membujuk pembuat kode dan bisnis untuk merangkul cloud MS(Di Cina, .net benar-benar dalam kondisi bencana, orang berbicara tentang java dan bereaksi, "apa itu f k s t xamarin?". ....). Jadi, sebagai pembuat kode Cina, ketika saya melihat xamarin , uwp, TypeScript dan cshtml5, saya tahu bahwa adalah mungkin untuk menyatukan seluruh sisi klien ke dalam mode xaml+C#, tetapi mengapa teman MS kami tidak melihat peluang untuk mendapatkannya kembali pangsa pasar cina dengan jika?

Wow, masalah ini sekarang lebih dari 100 suara positif! Terima kasih banyak untuk semua orang yang telah menunjukkan dukungan mereka. Jika ada yang tertarik, ada artikel hebat ( sungguh! ) oleh @terrajobst lengkap dengan keterlibatan pengembang merek dagangnya yang luar biasa di komentar di sini:
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

(Serius, setiap karyawan MSFT yang memposting posting blog berbasis perusahaan harus mengikuti petunjuk Tuan Landwerth tentang cara memposting dan menindaklanjuti dengan komentar yang tak terelakkan, tak terhitung, dan tak terhitung yang muncul setelahnya. Dia benar-benar teratas dengan semua itu dan tampaknya seperti terlalu banyak penulis MSFT membiarkan posting mereka mengering dan meninggalkan pertanyaan untuk mati, yang tentu saja merupakan cara yang buruk untuk memperlakukan audiens Anda!)

Bagaimanapun, pasti layak dibaca jika Anda belum melakukannya, terutama komentarnya. Ini membawa saya mengapa saya memposting sekarang karena _Saya sangat senang melihat masalah ini disebutkan dalam komentar bersama dengan hasrat/keinginan untuk membawa System.Xaml ke .NET Standard/cross-platform era_. 👍

154 suara positif... dan terus bertambah. Isu tertinggi berikutnya adalah pada 25 , untuk referensi. #squeakywheel

Ini perlu dilakukan. Dapatkan di atasnya!

Kami memiliki aplikasi @ReactWindows yang menargetkan WPF yang ingin kami gunakan .NET Native untuk secara dramatis meningkatkan pengalaman unduh/instal pertama kali bagi puluhan ribu pengguna Windows 7 kami. Kami juga memiliki rencana masa depan untuk membawa React Native ke Linux dan berpotensi menggunakan kembali kode bersama @ReactWindows tetapi menargetkan Xamarin.Forms.

Memiliki System.Xaml (dan dependensi tipe/metode/perakitan lain dari WindowsBase, PresentationCore, dan Xamarin.Forms) tersedia di NETCore vNext sangat penting untuk strategi ini. Kami dapat mengatasi kekurangan ini dengan menulis ulang dan menargetkan ulang rakitan yang ada, atau dengan mengisi jenis/metode yang hilang di System.Xaml Mono dan membangunnya untuk .NET Core, tetapi akan lebih memilih Microsoft meningkatkan dan menyediakan apa yang ada. diperlukan untuk platform.. /cc @rozele @pre10der89

@matthargett Semoga berhasil dalam hal ini. Saya mengalahkan masalah ini sampai mati ketika saya melihat membawa alur kerja ke .net core. Bahkan melangkah lebih jauh dengan menjangkau tim xaml. Mereka bahkan tidak tertarik untuk membuka System.Xaml. Saya tidak mengerti mengapa - tentu saja tidak ada yang layak dilindungi di sana.

Mungkin ini akan dipertimbangkan setelah rilis 2.0 pada akhir April.

Guys, sekali lagi, kita tidak perlu System.XAML untuk membuat WF porting ke netstandard1.x ... Sudah ada karya bagus dari @dmetzgar di mana inti dari WF bekerja. Bagian utama yang hilang adalah Transaksi yang saya yakini akan kembali pada akhirnya di netstandard2.x .

Pedoman utama dari port @dmetzgar adalah untuk tidak memiliki bahasa desain apa pun yang terikat pada inti dan memiliki primitif dasar sehingga orang dapat membuat serial alur kerja apa pun yang mereka inginkan dan kemudian, buat desainer di atasnya.

Tentu saja pendekatan ini akan mengarah pada kompatibilitas non-mundur dengan alur kerja berbasis XAML saat ini, tetapi percayalah, pindahkan apa pun ke .Net Core IS perubahan besar, jadi orang perlu memahaminya.

Ada OminiSharp yang dapat dimanfaatkan untuk desainer XAML tetapi sekali lagi, desain/serialisasi adalah beberapa di luar inti WF. Itu harus ramping seperti yang lainnya dengan .Net Core.

Saya akan mengatakan bahwa masalah ini dibuat keras-keras bahwa orang ingin memindahkan WF ke .Net Core, saya hanya berpikir bahwa mengeluh dengan tim System.XAML ke OSS itu, tidak produktif. Tim XAML memiliki prioritas lain dan ini adalah inti untuk bisnis Windows/UWP/Xamarin jadi jangan berharap itu mendapatkan OSSed begitu cepat. Alih-alih itu, saya akan meminta @dmetzgar untuk mengumumkan secara resmi repo WF di bawah .Net Foundation, dan membimbing komunitas untuk menjalankannya tanpa menetapkan batas waktu atau janji untuk menyelesaikan rilis netstandard2.x . Ini akan menjadi pekerjaan berkelanjutan yang didorong oleh timnya, dan sebagian besar dibantu oleh komunitas yang jelas-jelas ingin membantu dan berhasil.

Lihat seberapa cepat hal-hal berkembang dalam proyek Orleans... Itu adalah Riset Microsoft yang mendapatkan OSSed tahun lalu dan merupakan salah satu repositori terbesar dan paling aktif di .Net Foundation dan sebagian besar didorong oleh upaya komunitas (masih memiliki Tim MSFT bekerja penuh waktu di dalamnya).

Pokoknya, IMHO, saya pikir kita perlu berhenti yaming dan mulai melakukan sesuatu. Jelas bahwa tim @dmetzgar tidak memiliki bandwidth untuk dikerjakan karena perhatian utama mereka adalah untuk mendukung pengguna utama WF, yang pada dasarnya adalah penyebaran besar Sharepoint yang tidak memiliki rencana untuk mencapai inti .net sama sekali. Jadi itu harus didorong oleh komunitas (diawasi oleh tim @dmetzgar ).

Guys, sekali lagi, kita tidak perlu System.XAML untuk membuat WF porting ke netstandard1.x...

@galvesribeiro itu mungkin benar, tetapi masalah ini adalah membuat System.Xaml di-porting ke .NET Core, yang sejauh ini merupakan fitur yang paling banyak diminta dalam repo tempat tim .NET meminta umpan balik. Jika Anda tidak mendengarkan tanggapan Anda, lalu mengapa memintanya? Bagaimanapun, WF hanyalah _satu_ dari skenario yang akan dipenuhi oleh port System.Xaml. Seperti yang Anda ketahui (atau seharusnya!) System.Xaml mampu melakukan lebih banyak lagi.

Tim XAML memiliki prioritas lain dan ini adalah inti untuk bisnis Windows/UWP/Xamarin jadi jangan berharap itu mendapatkan OSSed begitu cepat.

Ya, itu semacam masalah di sini dan apa yang kami minta untuk diubah. :) Juga, saya bahkan tidak yakin ada "Tim Xaml" lagi akhir-akhir ini, kan?! Rasanya benar-benar teknologi ini telah ditutup dan kami mulai menyiasatinya.

Pokoknya, IMHO, saya pikir kita perlu berhenti yaming dan mulai melakukan sesuatu.

100% setuju. FWIW, @SuperJMN baru saja merilis OmniXamlv2.0 , jadi ada beberapa upaya komunitas sedang berlangsung yang dapat dimanfaatkan sementara MSFT memprioritaskan energi dan upaya mereka di sekitar masalah ini (yang, kebetulan berlangsung sekitar 11 bulan sekarang -- dan terus bertambah).

Omong-omong, inilah utas yang bagus tentang hal itu (yaitu, ketidakaktifan MSFT dalam hal ini), dengan kutipan dari @terrajobst :

Untuk lebih jelasnya, saya tidak mengatakan bahwa System.Xaml tidak dapat atau tidak boleh lintas platform. Apa yang saya katakan adalah bahwa System.Xaml tidak terlalu berguna di luar WPF dan WF, dan NuGet adalah metrik proxy yang masuk akal untuk pernyataan itu. Tentu saja, System.Xaml dapat dibuat bermakna di luar ranah UI, tetapi itu adalah langkah kedua. Saya lebih suka menggunakan sumber daya kami SEKARANG untuk membuat bagian dasar bekerja dengan baik dan lengkap. Selain itu, dengan memiliki basis yang terkonvergensi, porting komponen tingkat yang lebih tinggi, seperti System.Xaml juga menjadi lebih mudah.

Jadi itu bukan pernyataan baik-atau; itu adalah pernyataan urutan eksekusi.

Mengesampingkan pernyataan yang sangat salah tentang System.Xaml yang tidak berguna di luar WPF/WF, ini semua terdengar seperti manajer proyek-glish bagi saya, tanpa niat untuk mengatasi masalah ini. Tujuan saya bukan untuk kritis dengan pernyataan itu karena saya mendukung penuh Immo dan pekerjaan hebat yang dia lakukan di sini. Namun, saya telah berada di sekitar blok cukup untuk memungkinkan bahasa semacam itu memberi saya jeda dan menempatkan saya dalam sikap menunggu dan melihat (atau lebih tepatnya "percaya ketika saya melihatnya" LOL!) Tentang masalah ini.

Sementara itu, saya mendukung upaya saat ini di .NET Standard 2.0 dan menantikan apa yang akan dihasilkan. Mungkin bisa lebih baik dari yang diharapkan. Paling tidak, sepertinya kita akan dapat merebut kembali System.Xaml untuk proyek .NET Core yang bekerja pada platform Windows, yang merupakan awal yang cukup baik bagi saya. 👍

@Mike-EEE pertama-tama saya minta maaf ... Saya pikir saya membalas ini https://github.com/dotnet/corefx/issues/2394 oO Kedua masalah itu terlalu sering berkorelasi sehingga saya bingung.

Kedua, saya tidak mengatakan bahwa XAML hanya berguna untuk UI. Saya menggunakannya selama bertahun-tahun di TFS build, WF sendiri dan akhir-akhir ini untuk UI. Ada banyak DSL seperti Azure ML, dan lainnya yang dapat memanfaatkan XAML.

Yang ingin saya katakan adalah bahwa saya tidak melihat XAML di-porting begitu cepat ke .Net Core. Seperti yang dikatakan Immo, mereka harus memperbaikinya terlebih dahulu dengan platform saat ini. .Net Core bahkan belum memiliki pustaka manipulasi gambar asli apa pun.

Ada beberapa implementasi XAML mulai dari WPF berfitur lengkap hingga lemah dan kekurangan banyak fitur di UWP. Itu harus disatukan dan distabilkan sebelum hal seperti itu mendapat OSS. Saya tidak berbicara dengan tim yang bekerja di dalamnya. Saya hanya berpikir bahwa saya tidak akan melakukan hal yang berbeda dari mereka jika saya harus memprioritaskan sumber daya saya.

Salam untuk WF, maaf sekali lagi, tetapi komentar saya sebelumnya sebagian besar menargetkan orang-orang yang berharap masalah ini adalah alasan WF port to core tidak terjadi secepat itu, yang tidak benar .

Kedua masalah itu terlalu sering berkorelasi sehingga saya bingung.

Haha @galvesribeiro Saya tidak bisa memberi tahu Anda (atau takut untuk mengakui) berapa kali itu juga telah menggigit saya. Tidak ada kekhawatiran tentang hal itu. Saya untuk satu menghargai masukan apapun!

FWIW, sepertinya @cwensley juga terus melakukan pekerjaan yang bagus atas @ Portable.Xaml , setelah baru-baru ini melakukan peningkatan kinerja pada adaptasi berbasis mono System.Xaml yang membuatnya lebih cepat daripada versi aslinya. Hampir seolah-olah itu bisa menjadi titik awal yang baik untuk upaya di sini, karena itu mungkin paling dekat dengan pengalaman System.Xaml asli dari semua rasa/pilihan di luar sana. Hanya dua sen yang diinduksi kafein untuk pagi hari.

Silakan port System.Xaml ke .NetCore

FWIW, lebih dari 200 suara untuk masalah ini, sekarang duduk di 202. Masalah tertinggi berikutnya adalah dotnet/corefx#13526 duduk di 47. Yah, WS 47... sekarang 48 setelah suara saya. :) (Pergi tunjukkan cinta, itu ide yang bagus.) #squeakywheel

Terima kasih telah mengingatkan @Mike-EEE ;-). Untuk menetapkan harapan: Kami masih belum siap untuk mulai menggali lebih dalam - saya pribadi berharap bahwa pada bulan Maret kami harus dapat berkomentar lebih banyak tentang langkah resmi kami berikutnya, bahkan jika itu lagi "kami belum punya rencana" (penafian: Saya mencoba mengomunikasikan tebakan pribadi terbaik saya, tolong jangan anggap itu sebagai janji tim resmi!).

Ketika kami membahas masalah ini sedikit terakhir kali, pertanyaan kunci yang muncul adalah untuk menentukan mana dari 200+ suara yang benar-benar hanya tentang System.Xaml vs. WPF. Asumsinya adalah bahwa banyak orang tidak membedakan keduanya. Adakah saran bagaimana cara terbaik untuk melakukannya? (misalnya membuat 2 masalah khusus dan meminta orang untuk memilih WPF vs. "Xaml murni, bukan WPF")

Juga akan membantu untuk memiliki daftar ringkasan skenario untuk System.Xaml dengan beberapa estimasi prioritas (mereka sekarang tersebar di diskusi panjang). @Mike-EEE apakah itu sesuatu yang bisa Anda bantu kami kumpulkan? (karena Anda tampaknya memiliki minat yang kuat dan pengetahuan yang mendalam di bidang tersebut)

Secara definitif System.Xaml adalah apa yang orang inginkan @karelz. Jika seseorang memikirkan WPF di sini, itu bukan tempat yang tepat IMHO. Ada banyak kerangka kerja lain yang memanfaatkan XAML seperti WF, TFS Build, dll yang masih menggunakan System.Xaml dan itu akan membantu kita.

@karelz Saya sangat menghargai balasan Anda di sini. Terima kasih telah meluangkan waktu untuk melakukannya. Seperti yang disebutkan @galvesribeiro , System.Xaml lebih dari sekadar UI, yang tampaknya merupakan pemahaman utama yang sayangnya dilewatkan oleh banyak MSFT. Ini adalah paradigma serialisasi yang kuat yang menempatkannya di atas dan di luar solusi serialisasi lain di luar sana, terutama dan terutama ketika menggambarkan aplikasi, yang merupakan hal terbaik dalam melakukan (toh "A" dalam moniker-nya). Sayangnya "aplikasi" telah digabungkan dengan "UI" dan karenanya gesekan di sini.

Mengabaikan aspek ini adalah kegagalan utama UWP dan merupakan bagian dari alasan mengapa tidak ada yang benar-benar suka bekerja dengannya. Sebaliknya, Xamarin tampaknya telah memahami aspek kunci ini dalam rasa Xaml-nya, tetapi ini bersifat internal dan tidak diekspos sebagai penawaran otoritatif kelas satu (yang sebenarnya adalah masalah ini setelah di sini).

TBH, port System.Xaml @cwensley di Portable.Xaml tampaknya menjadi yang terdepan saat ini. Dia tidak hanya mem-porting System.Xaml Mono (mempertahankan API yang familiar secara keseluruhan), tetapi telah menambahkan fitur baru dan benar-benar meningkatkan kinerjanya menjadi _lebih baik_ daripada System.Xaml.

Dalam pandangan saya, masalah ini bisa sesederhana bekerja dengan @cwensley untuk membuat apa yang dia miliki menjadi pustaka Xaml lintas platform otoritatif untuk digunakan di masa mendatang.

Di luar ini, di sinilah ia menjadi rumit dan mungkin menambah pandangan rumit Anda (dapat dimengerti) tentang masalah ini. Karena System.Xaml menyediakan bahasa yang ekspresif dan kuat untuk menggambarkan aplikasi (sekali lagi, bukan hanya antarmuka pengguna), ia juga memiliki beberapa dukungan perkakas hebat yang dimasukkan ke dalam Visual Studio (dan tentu saja Blend). Jadi idealnya akan luar biasa untuk melanjutkan pengalaman hebat yang sama dan entah bagaimana menjaga pengalaman desainer Xaml dengan cara lintas platform, tetapi secara pribadi itu meminta ceri di atas kue luar biasa yang sedang kita diskusikan di sini. :)

Juga, untuk mengulangi di sini, janji Xaml (dan pengiriman) juga merupakan peningkatan alur kerja pengembangan antara desainer dan pengembang. Saya suka berpikir kita pada akhirnya dapat mengambil satu langkah lebih jauh ini dan meningkatkan proses antara pengembangan dan _devops_. Artinya, saya ingin melihat dunia di mana devops bekerja di editor konfigurasi aplikasi yang dirancang dengan indah (diberdayakan oleh Xaml) untuk mengelola dan memelihara aplikasi yang digunakan.

_Seluruh gagasan di sini adalah mengurangi biaya keseluruhan dalam pengembangan aplikasi mulai dari pengkodean hingga penerapan. Bekerja dengan editor dan desainer cantik lebih murah (dari perspektif sumber daya) daripada harus mencari dan mempekerjakan seseorang yang harus mendapatkan kode (dan/atau skrip) untuk mewujudkan keajaiban._

Saya berbagi ini dengan Anda sebagai perspektif visi, supaya Anda sadar. Namun, saya tidak yakin seberapa tertarik Anda mendengar ini. Jadi, jika ini hanya sebuah "apa yang diperlukan untuk menutup masalah ini dan membuat Anda pergi?" Saya menyarankan untuk menjajaki kemungkinan bekerja dengan Mr. Wensley dan melihat apakah kita dapat memanfaatkan karya besarnya sejauh ini (atau apakah dia bahkan terbuka untuk melakukannya). Jika ada cara untuk mengarahkan ini sehingga dapat menjadi paket Xaml lintas platform resmi untuk rilis .NET Core Wave 2 (sekitar Mei atau lebih?) maka lebih baik. :)

Terima kasih atas infonya, saya pasti tertarik. Saya juga merasa bahwa pertanyaan saya sebelumnya tidak sesuai dengan keinginan saya, jadi izinkan saya menunjukkan beberapa hal:

Ya, saya pasti tertarik dengan detailnya. Saya tidak berpikir ada orang yang memperdebatkan Xaml != WPF di sisi MSFT. Saya pasti tidak mencoba melakukan itu. Saya hanya tahu apa yang saya tidak sepenuhnya mengerti, dan saya mencoba untuk mengisi kekosongan - yaitu sepenuhnya memahami motivasi dan kebutuhan skenario "Xaml murni".
(BTW: Saya tidak begitu mengerti skenario devops Anda dan bagaimana Xaml adalah satu-satunya/hal terbaik untuk membantu di sana? Atau bagaimana sebenarnya digunakan dalam skenario?)

Saya di sini bukan untuk mencoba menutup masalah ini. Tolong! Itu bahkan tidak terlintas di pikiranku. Saya di sini untuk membantu komunitas untuk meringkas pertanyaan, sehingga dapat didiskusikan dengan orang yang tepat (pikirkan direktur dalam hal ini). Ya, sebagian dari itu berarti bahwa saya (dan/atau beberapa MSFT lainnya) harus sepenuhnya memahami permintaan untuk mewakilinya lebih tinggi - maka pertanyaan saya.

Saya akui, saya adalah contoh yang baik dari orang yang tidak membedakan Xaml dan WPF sebelum dia melihat masalah ini. Dari obrolan acak dengan orang lain di tim .NET, banyak yang tahu bahwa Xaml != WPF, tetapi mereka tidak melihat "nilai besar" dari memiliki Xaml murni yang diajukan di sini - oleh karena itu pertanyaan saya di atas tentang skenario. Skenario akan membantu saya/kami memahami motivasi dengan lebih baik dan menceritakan/menjual cerita dengan lebih baik. (Saya harap tidak mengherankan bahwa ketika tidak ada cerita yang jelas, tidak ada yang merasa cemas untuk mendanainya :) - cerita adalah prasyarat untuk pendanaan)
Jadi mari kita membuat elevator pitch untuk memajukannya.

Mengenai pekerjaan @cwensley - senang mendengar mungkin ada beberapa solusi yang tidak terlalu mahal. Tetapi sekali lagi, akan sangat membantu untuk terlebih dahulu memahami latar belakang dan MENGAPA, sebelum kita beralih ke solusi. Saya harap itu masuk akal. (Saya tidak mencoba untuk meremehkan atau apa pun - hanya mengulangi bahwa lebih mudah untuk memajukan sesuatu ketika MENGAPA dipahami dan disepakati)

@galvesribeiro Jika seseorang memikirkan WPF di sini itu bukan tempat yang tepat IMHO

Saya tidak berbagi keyakinan Anda bahwa semua 200+ orang yang memilih benar-benar memahami Xaml != WPF hingga detail seperti itu. Juga saya kira setidaknya beberapa melihatnya - ya, mari kita dapatkan Xaml terlebih dahulu, maka akan lebih mudah untuk meminta WPF. Jadi skenario yang mereka pikirkan sepanjang waktu adalah WPF, sementara "Xaml murni" hanyalah langkah pertama menuju itu.
Dan mungkin saya salah (walaupun saya bukan satu-satunya orang di tim .NET dengan keraguan ini) ...
Sudut lain mungkin untuk memecah "Xaml murni" ke dalam daftar skenario (WPF, devops di atas, mungkin beberapa lagi?) Dan kemudian meminta orang untuk memilih mereka - Mana dari mereka yang benar-benar penting bagi mereka yang memilih di sini? Apa yang sebenarnya mereka inginkan?
(Ini bukan taktik penundaan, atau kejahatan apa pun, saya mencoba memahami "pelanggan" di sini. Saya harap itu masuk akal - jika Anda memiliki saran yang lebih baik bagaimana mendapatkan data tersebut, angkat bicara, saya terbuka untuk pendekatan alternatif )

EDIT: Seperti biasa, jika menurut Anda saya tidak mendekati masalah dengan cara yang benar, katakan saja. Saya mencoba melakukan yang terbaik di sini untuk membantu - dengan niat terbaik. Saya tidak menderita ilusi mengetahui segalanya, atau berpikir bahwa saya lebih pintar dari orang lain.

@karelz Ada banyak kerangka kerja UI yang menemukan kembali roda dan menulis bahasa markup mereka sendiri hanya karena XAML tidak lintas plat bahkan jika mereka tidak menyukai WPF sama sekali. Avalonia adalah salah satu yang teratas. Mereka menggunakan Omnisharp ketika mereka dapat memanfaatkan XAML asli sebagai gantinya.

Workflow Foundation adalah pengguna/pelanggan besar XAML dan orang-orang di Port WF ke .Net Core thread selalu menanyakannya.

Jadi ya, saya setuju dengan Anda bahwa kami harus menetapkan harapan atau menggambar set fitur mentah pada apa yang diharapkan dari lintas-plat System.Xaml bersama dengan penggunaan yang diinginkan seperti misalnya UI dan WF.

@karelz

Juga saya kira setidaknya beberapa melihatnya - ya, mari kita dapatkan Xaml terlebih dahulu, maka akan lebih mudah untuk meminta WPF. Jadi skenario yang mereka pikirkan sepanjang waktu adalah WPF, sementara "Xaml murni" hanyalah langkah pertama menuju itu.
Dan mungkin saya salah (walaupun saya bukan satu-satunya orang di tim .NET dengan keraguan ini) ...

Jadi... apa masalahnya? Solusi lintas platform seperti WPF bisa menjadi hal yang cukup baik. Xamarin tidak dapat melakukan GUI desktop lintas platform.

@jnm2 itu tidak buruk - tetapi jika itu adalah skenario utama (90%+), kita harus merencanakan untuk melakukan keduanya. Memiliki Xaml tanpa WPF tidak akan membantu dalam kasus seperti itu (setidaknya tidak banyak). Dan itu mungkin menciptakan (berpotensi) ilusi yang tidak valid bahwa WPF berkomitmen dan akan segera muncul setelahnya.

Mendapatkan WPF / GUI ke .NET Core akan menjadi langkah besar untuk .NET Core, yang menargetkan terutama skenario server dan aplikasi konsol sekarang.

@jnm2 memiliki System.Xaml akan sangat membantu orang (seperti saya) yang _mencoba_ untuk membawa sesuatu seperti WPF ke platform lain (https://github.com/AvaloniaUI/Avalonia).

@grokys kedengarannya seperti skenario yang masuk akal - dapatkah Anda menguraikannya lebih lanjut? Seberapa besar bantuannya? Apa yang menantang tanpanya?

Saya juga menggunakan Xaml untuk kerangka UI desktop lintas platform (seperti non-WPF), Eto.Forms . Inilah mengapa saya membuat proyek Portable.Xaml untuk memulai, dan sejauh ini telah bekerja dengan baik untuk saya dan pengguna saya.

Saya tidak menentang untuk membantu menjadikan ini sebagai implementasi xaml lintas platform "otoritatif" (seperti yang dikatakan @Mike-EEE). Namun, perlu diingat saya hanya mengerjakan ini di waktu luang saya (;

@karelz
Tidak hanya kerangka UI, Ini dapat digunakan di banyak adegan seperti XAML hingga HTML

@Kation dapatkah Anda membagikan detail lebih lanjut apa sebenarnya yang Anda maksud?

BTW: Saya mulai meringkas skenario di posting teratas - jika skenario Anda tidak ada, jelaskan dan setelah dipahami, saya akan menambahkannya di sana.

@karelz
Dengan editor XAML yang kuat di studio visual, kami dapat dengan cepat membuat konten komponen khusus.
Kemudian, saya pikir kita bisa menggunakan XAML untuk menghasilkan konten HTML dalam beberapa skenario khusus, bahkan lebih banyak konten SVG.
Ini adalah kerangka kerja XAML ke XML setengah jadi untuk .Net 4.5. https://github.com/Kation/WebPresentation

Saya tidak mengerti mengapa Anda ingin membuat HTML atau SVG dari XAML. Berapa nilai XAML di sini?
Apakah nilainya memiliki editor VS yang bagus? Ada juga editor HTML, mengapa tidak menggunakannya secara langsung?
Atau apakah saya kehilangan intinya sepenuhnya?

@karelz
Karena saya ingin menghasilkan konten seperti WPF dengan template dan gaya di beberapa proyek.

@karelz sekali lagi terima kasih atas dialognya. Saya untuk satu sangat menghargainya.

Saya tidak menderita ilusi mengetahui segalanya, atau berpikir bahwa saya lebih pintar dari orang lain.

Ah, aku iri. 😉.

Jadi skenario yang mereka pikirkan sepanjang waktu adalah WPF, sementara "Xaml murni" hanyalah langkah pertama menuju itu.

Ya, ini lagi-lagi penggabungan yang saya sebutkan. Xaml adalah paradigma serialisasi, murni dan sederhana. Anda dapat mendefinisikan dan mendeskripsikan aplikasi -- dan komponen yang terkandung di dalamnya -- di dalamnya. Untuk memulainya, berikut adalah contoh _console application_ yang dijelaskan dalam Xaml:
https://github.com/DevelopersWin/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml

Anda dapat melihat bahwa ada perintah yang dijelaskan dalam Xaml yang memberikan instruksi tentang apa yang harus disajikan kepada pengguna melalui penggunaan input dan output konsol. Ini tidak ada hubungannya dengan WPF atau "UI" (walaupun secara teknis ini adalah UI dalam arti CLI sebagai UI, tapi semoga Anda bisa melihat perbedaannya). Selain itu, Anda dapat melihat bahwa saya menggunakan ekstensi markup dan deklarasi anggota statis langsung di file. Ini adalah sesuatu yang belum saya lihat di JSON atau format data lainnya. Ini benar-benar kekuatan Xaml, IMO.

Sebagai contoh lain dari skenario "Xaml Murni", berikut adalah file yang saya usulkan untuk MSBuild format-agnostik baru:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Processor.xaml

(jika Anda naik level, Anda dapat melihat format lain yang melakukan hal yang sama, ini kebetulan adalah versi Xaml)

Ini adalah file prosesor yang sekali lagi merupakan kumpulan perintah ( System.Windows.Input.ICommand ) yang menjelaskan langkah-langkah yang harus diambil dalam proses pembangunan teoretis. Sekali lagi, tidak ada WPF atau UI, tetapi Anda dapat melihat bahwa itu memancarkan pesan ke konsol.

Salah satu fitur yang ingin saya tunjukkan di sini yang saya sebutkan sebelumnya adalah alat bawaan di Visual Studio yang saya dapatkan dari file ini:

Tanpa melakukan pekerjaan apa pun atau mendefinisikan skema eksternal apa pun, Visual Studio cukup "menyala" dan menyediakan editor properti lengkap dengan dropdown dan antarmuka desainer lainnya berdasarkan skema kelas file yang saya kerjakan (ini diharapkan akan membuat skenario devops lebih mudah untuk mengerti).

Selain file prosesor, berikut adalah proyek teoritis atau file input yang dapat digunakan untuk mengirim ke prosesor:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Project.xaml

Di sini saya mencoba untuk mencapai intinya dengan _markup extensions_ digunakan untuk menyediakan versi (mungkin dari file eksternal) dan juga menggunakan kueri untuk menyediakan file yang dikumpulkan untuk dibuat (perhatikan bahwa mungkin Anda mungkin tidak ingin benar-benar melakukan ini dalam sistem build terakhir, tetapi saya ingin menunjukkan kemungkinannya).

BTW, kode contoh ini beroperasi penuh, jadi Anda harus bisa mendapatkan SLN dari repo itu dan menjalankan versi Xaml, hasilnya akan terlihat seperti berikut:

(Catatan: Bekerja di Mesin Saya sehingga jarak tempuh Anda dapat bervariasi. )

BTW: Saya tidak begitu mengerti skenario devops Anda dan bagaimana Xaml adalah satu-satunya/hal terbaik untuk membantu di sana? Atau bagaimana sebenarnya digunakan dalam skenario sama sekali?

Ya, saya memperdebatkan apakah akan membahasnya, karena saya merasa posting saya agak panjang. Semoga sekarang komponen desainer visual di atas dapat membantu mengilustrasikan apa yang saya gali di sini.

Harap ketahui dan perhatikan bahwa bagi saya ini adalah permainan akhir pamungkas dan mengapa saya sangat gungho tentang semua ini. _Alasannya adalah karena pada akhirnya mengurangi total biaya kepemilikan aplikasi selama masa pakainya._

Jadi intinya di sini, yang kita bicarakan di sini adalah pengembangan berbasis POCO, di mana pengeditan dan perancangan terjadi pada POCO yang digunakan dalam proses aplikasi. Seperti yang kita ketahui, pengembang dan perancang akan mengerjakan file Xaml yang menjelaskan elemen POCO yang berhubungan dengan domain UI (inilah "WPF" tradisional "Xaml" jika Anda mau).

Di dunia saya, saya ingin melihat proses ini diperpanjang sehingga pengembangan memberikan file Xaml untuk devops untuk digunakan untuk mengelola/memelihara aplikasi yang telah digunakan ke lingkungan langsung.

Anda dapat menganggap ini sebagai file konfigurasi langsung. Bagaimana mereka dimuat harus disetrika, tetapi hasil akhirnya akan menjadi seperti apa yang Anda lihat pada tangkapan layar di atas di Visual Studio. Alih-alih pengguna akhir (devops) dipaksa untuk memasukkan kode (atau lebih tepatnya, memiliki organisasi yang dipaksa untuk mempekerjakan bakat/keterampilan mahal yang diperlukan seperti itu), mereka malah bekerja dengan kontrol pengeditan visual yang dibatasi dan divalidasi untuk mengonfigurasi dan memelihara aplikasi.

_Idenya di sini adalah karena upaya (dan keterampilan) yang diperlukan untuk melakukan ini daripada diharuskan untuk mengetahui dan memahami kode, biaya pemeliharaan aplikasi setelah penerapan sangat berkurang._

Satu aspek yang belum saya sebutkan tentang ini adalah bahwa kontrol tersebut sebenarnya dapat disesuaikan. Visual Studio memiliki API ekstensif (walaupun menua) untuk menentukan editor visual yang dilampirkan ke properti POCO tersebut:
https://msdn.microsoft.com/en-us/library/microsoft.windows.design.model.designmodevalueprovider(v=vs.90).aspx

Ini semua tersedia sekarang di Visual Studio tanpa kerja tambahan, overhead, atau usaha. Jadi ide utama di sini adalah untuk membuat suite editor dan desainer yang kuat untuk membantu tidak hanya dalam proses pengembangan, tetapi pada akhirnya proses devops.

Sekali lagi ini semua visioner dan tanpa dasar dunia nyata yang sebenarnya (belum). Yang pasti, ini bukan sepenuhnya ide saya tetapi terinspirasi oleh grup pola dan praktik dengan Editor Konfigurasi berbasis Windows Forms mereka. Saya hanya mengambil pengisap ini satu langkah lebih jauh dan melihat menggunakannya melalui kekuatan Xaml.

Beri tahu saya jika Anda memiliki pertanyaan tambahan seputar @karelz ini. Sekali lagi saya menghargai dialognya. Tidak hanya memberikan kesempatan untuk berbagi, tetapi juga memberikan kesempatan untuk memvalidasi ide dan keyakinan saya. Dan dengan kembali ke gagasan mengetahui semuanya (ya, saya bersalah ), saya mencoba untuk tetap berpikiran terbuka tentang berbagai hal dan menyadari bahwa saya tidak memiliki semua jawaban. Ini jelas merupakan proses yang terus saya coba lakukan untuk menjadi lebih baik. Terima kasih lagi!

@karelz - Avalonia saat ini menggunakan OmniXaml sebagai mesin XAML-nya, dan meskipun ini berfungsi dengan baik, masih ada bug dan fitur yang hilang. Seperti Portable.Xaml, OmniXaml dikelola oleh seorang sukarelawan yang tidak selalu memiliki banyak waktu untuk mengerjakannya.

Jika pada kenyataannya Anda memutuskan untuk tidak membuka System.Xaml, mungkin merilis test suite Anda akan menjadi kompromi yang baik - setidaknya dengan cara itu kami dapat memastikan bahwa implementasi pihak ke-3 seperti OmniXaml dan Portable.Xaml sedapat mungkin sesuai.

Saya pikir apa yang dibutuhkan ekosistem .net adalah format serialisasi default yang dapat dibaca manusia - sesuatu seperti JSON di dunia Javascript. Format ini harus menggunakan tipe data donet dan langsung menggunakan POCO sebagai skema. Kemudian format tersebut dapat digunakan untuk mendeskripsikan objek POCO. Deskripsi ini diketik dengan kuat dan statis. Yang dapat berupa tata letak UI, konfigurasi aplikasi runtime, deskripsi proyek/alur kerja, atau bahkan untuk komunikasi antara dua program .net. Dan bahkan komunikasi dengan ekosistem lain (seperti web/Javascript) juga dimungkinkan, mengingat mereka menerapkan formatnya. Tapi itu harus dirancang di sekitar ekosistem .net. Itu sebabnya JSON/BOND/Protobuf/XML tidak cukup.

Secara historis, XAML agak memenuhi tanggung jawab. Sekarang pertanyaannya adalah, seberapa bagus peran ini. Jika cukup baik, maka saya pikir XAML harus dibuat menjadi standar net dan kemudian implementasi .net. Tetapi, jika memungkinkan, format lain juga harus dipertimbangkan. Saya pikir minggu lalu, http://www.ammyui.com/ keluar. Format deskripsi UI berfokus pada kesederhanaan tetapi diterjemahkan ke XAML. Karena, XAML tidak cukup sederhana. Saya sendiri telah mengusulkan satu format di roslyn repodotnet/roslyn#16648 berdasarkan inisialisasi (objek, koleksi, dan indeks). Dan proposal saya sebenarnya diambil dari (dan kemudian sedikit dimodifikasi) posting blog ini oleh @bricelam dari tim kerangka kerja Entitas. Baik postingnya dan utas proposal saya memiliki beberapa contoh.

Maksud saya adalah, harus ada format default untuk .net, baik itu XAML atau yang lainnya.

@grokys Saya memang ingin menyebutkan OmniXaml, dan telah mengundang @SuperJMN ke percakapan di sini, tetapi sepertinya dia tidak pernah ingin berpartisipasi. Tidak yakin apakah itu pengaturan atau apa (saya juga telah mencoba di gitter juga -- karena Anda bekerja dengannya, mungkin Anda bisa lebih beruntung dengan menyeretnya ke sini ). OmniXaml tentu saja menyambut baik percakapan ini juga.

@gulshan +💯 ! Ha ha. Bagian dari bagian yang membingungkan dari semua ini adalah bahwa Xaml adalah format dan teknologi MSFT. Dengan semua investasi dan peralatan yang dibangun di sekitarnya -- baik dengan MSFT maupun di perusahaan, memang tidak dapat dipahami mengapa tampaknya ada kesenjangan dalam memastikan kesinambungannya sehingga upaya dan investasi yang ada dapat dimanfaatkan.

Yang mengatakan, saya suka apa yang saya lihat dengan Ammy dan saya terus berpikiran terbuka tentang ini. Atau mencoba untuk memilikinya. 👼.

Saya pikir penting untuk menegaskan kembali mengapa kita repot-repot dengan file data untuk memulai, nilai utama dalam menggunakan format data adalah:

• Agnostik Bahasa Imperatif . Penggunaan file tidak mengharuskan Anda untuk mengetahui bahasa pemrograman.
• Desainer/perkakas ramah. _Menggunakan desainer visual dan/atau mengaktifkan pengalaman desainer visual dengan produk Anda menghasilkan TCO yang lebih rendah _.

Yang mengatakan, apa yang secara pribadi penting bagi saya adalah:

• Alur kerja terintegrasi pengembang/desainer
• Pengalaman desainer visual untuk file pengeditan tangan.
  
  
  
  • PropertyGrid (Jendela Properti) dengan API editor yang dapat diperluas seperti yang dibahas di atas.
  
  
• Ekstensi markup
• Cherry-on-the-cake of awesome: Kemampuan untuk memanfaatkan semua hal di atas dalam skenario di luar pengembangan (contoh devops di atas).

Jika semua ini terpenuhi, maka saya akan bersedia untuk mempertimbangkan "format .NET lain" tapi jelas saya lebih memilih untuk mempertahankan dan memperluas Xaml sebagai format itu. Bagaimanapun, ini adalah teknologi MSFT dan oleh karena itu kekayaan intelektual.

@Mike-EEE Jika format dapat di-deserialized ke POCO, semua fitur tersebut harus berfungsi, Jendela properti di VS juga muncul untuk skenario non-XAML. Tapi satu hal yang saya khawatirkan adalah, keterbacaan tanpa dukungan editor. Dalam beberapa kasus, Anda harus mengedit file konfigurasi di server jauh, dan Anda hanya memiliki vim. Dibandingkan dengan JSON, XML (dan XAML) tidak terlalu bagus dalam hal ini, IMHO.

Tetapi XAML memiliki beberapa hal unik (sebenarnya fitur non-XML) seperti properti terlampir, yang sulit untuk ditiru dalam format serialisasi sederhana.

Saya akan memilih WPF terlebih dahulu (jadi saya akhirnya bisa mengucapkan selamat tinggal kepada xamarin.froms), lalu xaml

Jendela properti di VS juga muncul untuk skenario non-XAML

Benar, tetapi hampir tidak "menyala" seperti untuk Xaml, dengan kontrol pengeditan yang dapat disesuaikan sepenuhnya, dll. Koreksi saya jika saya salah di sini. Anda tidak bisa begitu saja meletakkan kursor pada properti dalam format ini dan memiliki render dropdown untuk bidang enum (misalnya). Pengalaman ini pada dasarnya adalah bentuk dan versi berikutnya dari WinForms, yang merupakan bagian dari alasan mengapa itu sangat bagus (WinForms masih populer!).

Dibandingkan dengan JSON, XML (dan XAML) tidak terlalu bagus dalam hal ini, IMHO.

Ya saya setuju, Xaml tidak terlalu singkat, dan Anda akan mendengar keluhan tentang betapa bertele-telenya itu. Di sinilah OmniXaml membuat tanda dengan memberikan peningkatan di sekitar pemformatan. Anda juga bersaing dengan format lain seperti TOML dan YAML dan semacamnya.

fitur non-XML) seperti properti terlampir ...

Dan ekstensi markup. Ini adalah fitur dari visinya.

Apa (saya percaya) Anda mengais di sini @gulshan pada dasarnya adalah "Data AST (pohon sintaksis abstrak)". Jika kita berbicara tentang peningkatan serius Xaml (atau format data .NET), maka inilah cara yang harus dilakukan. Itu bisa didukung oleh Roslyn, bahkan. Sebenarnya, saya memiliki suara pengguna untuk ide ini (bersama dengan posting blog yang sesuai ). Sayangnya tidak terlalu populer karena agak sulit dijelaskan, haha. Pada dasarnya Anda memiliki pohon AST (data) yang dapat ditulis ke berbagai format. Dengan begitu pengembang (dan perkakas) dapat bekerja dengannya sesuai dengan format apa pun yang paling masuk akal (secara estetis atau sebaliknya) bagi mereka.

jadi saya akhirnya bisa mengucapkan selamat tinggal kepada xamarin.froms

Setuju dengan Anda tentang aspek itu @groege. 😎.

@Mike-EEE Sebelumnya belum pernah memeriksa proposal AST Data Anda. Ya, secara konseptual mirip dengan proposal serialisasi / notasi objek default untuk .net. Idenya sulit dipahami karena abstraksinya. 😄.

Mengenai XAML, format serialisasi data yang diketik dengan kuat berbasis .net akan mengurangi kebutuhan akan banyak ekstensi markup XAML. Namun akan tetap ada beberapa, yang tidak dapat diinisialisasi oleh beberapa ekspresi (tanpa konstruktor). Saya berharap beberapa dari kemampuan ekstensi markup ini adalah bagian dari C# itu sendiri.

Yah saya belum mendengar kabar dari @karelz jadi saya hanya bisa berasumsi dia telah bertengger di depan monitornya setelah mengetahui bahwa Anda dapat mendefinisikan Aplikasi Konsol di Xaml:

(Buruk) selain lelucon, beri tahu saya jika Anda memiliki pertanyaan tambahan.

Juga, dari This Week di .NET, terlihat seperti mesin yang cukup keren yang sedang dibuat di .NET Core . Komentar pertama dari posting ini mengatakan itu semua . :)

@Mike-EEE Saya tahu saya berhutang jawaban kepada Anda (ini ditandai penting di kotak masuk saya & dibuka di browser).
Sejauh ini saya hanya bisa membaca sekilas balasan (terima kasih banyak semuanya untuk semua detail dan wawasan!), Tapi saya tidak punya waktu untuk mendidik diri sendiri tentang Xaml (seperti yang Anda tunjukkan) dan membaca semua balasan secara menyeluruh untuk menjadi bisa menjawab... maaf, terlalu banyak kebakaran dan pris terjadi saat ini :(, saya akan membahasnya nanti, saya janji!

Semuanya bagus @karelz! Sangat menghargai upaya dan dialog Anda di sini.

Inilah suara untuk WPF sumber terbuka, setiap versi XAML lainnya adalah sampah jika dibandingkan. Dan serius teman-teman, selesaikan loop ini, miliki .net core / XAML STORE untuk unix dan MacOS.

@Mike-EEE sangat menyesal, saya masih tidak punya waktu untuk kembali ke masalah ini :(

Ya ampun, jangan khawatir tentang itu, @karelz aku tahu semua orang sibuk sekarang. Saya menghargai percakapan lebih dari apa pun. Aku punya banyak keluar dari kepalaku. Adalah baik untuk melihatnya di luar sana dan merenungkannya seperti itu. Selain itu, kita sudah menunggu lebih dari satu tahun sejauh ini... berapa bulan lagi? :)

mereka harus opensource silverlight 5 .. sejak html5 mereka bergerak, win8 move/winrt mereka...& sekarang uwp & win10 dan xamarin .... UMUM!! menyedihkan kau tersesat di la la land seperti hollywood atau apa...

bagaimana seseorang bisa beralih dari silverlight 5 ke semua omong kosong itu? BAGAIMANA? bagaimana Anda bisa mengatakan Anda menghormati pengguna Anda ketika Anda selalu merusak antarmuka perakitan .. Anda bahkan mengganti nama paket nuget Anda sendiri dan tidak memberikan cara otomatis untuk berpindah dari yang lama ke yang baru di nuget .. sepertinya Anda masih menggunakan semua orang sebagai tak terbatas beta tester karena Anda terlalu bodoh untuk berpikir jernih sebelum membuat ide dan mengkodekannya.

anda perlu menghilangkan kebutuhan untuk proyek ios/android/uwp dalam bentuk xamarin.. BERPIKIR ada banyak cara yang lebih baik untuk mendukung multiplatform daripada memiliki proyek untuk setiap platform.

sekarang bawa semuanya di bawah satu f. kerangka kerja Anda ass wipes (saya sarankan cakupan wpf/silverlight dan bahasa xaml tapi heck jika Anda ingin membawa semuanya ke xamarin tapi tolong bisakah Anda menambahkan tipe data pada gaya/templat .. penghilangan aneh seperti banyak dan pastikan f. nucrapget Anda berfungsi A1 untuk sekali .. mengapa saya perlu menginstal paket nuget di semua rakitan dependen? sama dengan dll yang direferensikan .. ? Anda tidak memiliki visi ... niet none ... capout ... selama ini terjebak dalam ms omong kosong .. saya bisa membangun f. SDK kelas dunia saya sendiri..

saya tidak bisa menghabiskan hari tanpa MS membuang kotoran di jalan saya .. saya serius mempertimbangkan scala-js atau hanya swift .. saatnya meninggalkan rumah! aku muak

Yah, mereka membutuhkan waktu hampir dua tahun, tetapi UWP akhirnya menentukan ekstensi markup untuk model Xaml mereka:
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

Perhatikan juga, Noesis meluncurkan produk v2.0 mereka minggu lalu, dan itu terlihat cukup mengesankan. Sistem Xaml-nya sudah memiliki fitur ekstensi markup (dalam C++, dengan C# sedang dalam proses), dan tidak membutuhkan waktu tujuh tahun untuk mencapai spesifikasinya. Ini juga gratis untuk pengembang indie sekarang. Setelah Anda memperhitungkan dukungan AmmyUI -nya, saya harus mengatakan bahwa ini ada di urutan teratas daftar saya sejauh model Xaml menggunakan ATM:

http://www.noesisengine.com/

Hai @karelz mungkin Anda bisa mengomentari ini. Tapi tahukah Anda jika "spek" UWP Xaml yang terjadi sekarang memiliki korelasi dengan masalah ini? Jika tidak, apakah Anda tahu apakah itu bisa? Ide gila di sini, tapi mungkin bagus untuk memecahkan dua masalah dengan harga satu jika bisa membantu. Saya juga meninggalkan pesan di sana pada suara UWP, tetapi saya pikir saya akan melakukan ping di sini juga.

@Mike-EEE UWP Xaml "spec" kemungkinan didorong oleh org lain (saya pikir di Windows) - menanyakan detail tentang suara pengguna mungkin merupakan saluran terbaik.

Ya, aku takut itu. Saya memang mendapatkan balasan di sana, tetapi saya harus jujur ​​bahwa itu tidak masuk akal bagi saya.

Dari apa yang saya dapat grok, tampaknya mereka akan terus mengambil pendekatan tertutup dengan proses spesifikasi mereka. Ini mengkhawatirkan karena tampaknya ini akan mengarah pada hasil yang sama seperti terakhir kali, berakhir dengan API yang tidak ingin digunakan atau diadopsi oleh siapa pun.

Mungkin mereka diam-diam menikmati pengembang yang mengeluh tentang pekerjaan mereka. :)

Bagaimanapun, jika Anda membaca ini dan merupakan pendukung kolaborasi dan pengembangan sumber terbuka yang transparan, dan telah menikmati menjadi bagian dari keberhasilan inisiatif asp/.NET Core ke dalam domain ini, harap luangkan waktu sebentar untuk mengunjungi ke UserVoice WPDev dan kirimkan catatan yang mendorong mereka untuk melakukan hal yang sama. Tautan telah disebutkan sebelumnya tetapi ini dia lagi bagi mereka yang membaca ini dari email:
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

Saya harus memanggil @birbilis dan berterima kasih atas kontribusinya sebelumnya di sana. Kata-kata kepercayaan tambahan apa pun yang dapat dipinjamkan oleh siapa pun dalam mempromosikan proses yang kita semua gunakan di sini akan sangat dihargai. 👍

desah ... seperti suara pengguna Anda membuat orang memilih sesuatu dan pada akhirnya meskipun itu populer jangan lakukan apa-apa!

Memperbarui:
https://github.com/microsoft/xaml-standard

Saya yakin @Mike-EEE akan sangat senang dengan ini ;P

Itu adalah langkah yang bagus. Terima kasih telah berbagi @RichiCoder1

Sayangnya, ini hanya untuk UI. Penggunaan XAML lainnya seperti Sharepoint dan WF mungkin sudah tidak ada.

Tapi ya, setidaknya ini akan membantu menstandarisasi XAML di semua platform yang didukung.

Langkah yang bagus!

Berharap mereka akan membaginya menjadi beberapa lapisan

Misalnya selain dari lapisan XAML dasar non-UI, saya ingin melihat lapisan 3D XAML

@galvesribeiro Sepertinya seseorang membuat masalah: https://github.com/Microsoft/xaml-standard/issues/23 Saya akan memberi +1, tidak ada alasan untuk standar akhirnya tidak dibagi.

Saya yakin @Mike-EEE akan sangat senang dengan ini ;P

Haha dan benar Anda, @RichiCoder1! Semuanya salah dan rusak dan tidak ada di mana pun seharusnya, tetapi ini adalah permulaan. ;) Terima kasih untuk membiarkan kami tahu. 👍

Dan sangat senang melihat seseorang membuat https://github.com/Microsoft/xaml-standard/issues/23 sehingga saya tidak perlu melakukannya. ;) ;) ;)

Tolong, pertimbangkan untuk memasukkan WF (Workflow Foundation) dalam Standar XAML!!.

@Suriman tolong upvote!
https://github.com/Microsoft/xaml-standard/issues/23

Jadi saya benci bertanya -- dan saya melakukannya demi kepentingan menjadi warga negara repo/penerbitan yang baik, tetapi apakah masalah ini diperlukan lagi? Maksud saya, repo itu sudah mencatat 50+ masalah yang masuk ke WAYYYYY lebih detail daripada yang bisa dilakukan oleh masalah ini. Sepertinya sudah memiliki kehidupannya sendiri!

Apakah ada alasan untuk membiarkan masalah ini tetap terbuka? Kecuali saya benar-benar salah memahami sesuatu (sangat mungkin), saya pikir kami telah mencapai tujuan di sini dengan Standar Xaml. Ini didorong oleh komunitas dan segalanya, yang paling penting bagi saya, secara pribadi. :)

@Mike-EEE Ada perbedaan halus antara dua masalah; yang menurut saya adalah tentang standarisasi API yang tersedia dalam XAML itu sendiri (ketat di XAML itu sendiri), dan yang lainnya adalah tentang dukungan XAML sebagai .NET Standar komponen mirip dengan System.Xaml.

@lokitoth pasti terbuka untuk percakapan tentang ini, karena saya masih mencoba grok semua potongan baru. Saya rasa yang terbaik adalah memulai dengan menyarankan untuk menonton video @terrajobst yang sangat bagus dan informatif yang menunjukkan kode "hanya bekerja" dengan .NET Standard2.0 yang baru. Saya pribadi belum memikirkan bagaimana ini berdampak pada System.Xaml. Pemikiran saya adalah bahwa itu seharusnya "berhasil" tetapi mungkin saya mulai berpikir bahwa saya sekarang salah di sini (ala terlalu bagus untuk menjadi kenyataan).

Dan sejujurnya, setelah membaca beberapa utas ini di repo Standar Xaml, saya agak menendang diri sendiri untuk saran saya sebelumnya (☕️ kopi membuat saya melakukannya, saya bersumpah! ️). Dari kelihatannya, "Xaml Standard" lebih baik disebut sebagai "MSFT UX/UI Standard" karena itulah yang terutama dibahas dalam repo itu. Seperti berdiri, Xaml sebagai teknologi serialisasi yang kuat tidak disajikan/ditampilkan/disorot sama sekali (di luar dari beberapa suara berani di sini yang telah melakukan upaya di sana), yang juga menyebabkan beberapa pemutusan/kebingungan juga.

Saya pribadi belum memikirkan bagaimana ini berdampak pada System.Xaml.

Kita perlu memeriksa Majelis untuk mengetahui apakah pohon ketergantungannya dapat dimuat dalam konteks .NET Standard 2.0. Jika murni .NET, kemungkinan besar akan berfungsi (meskipun ada kumpulan item waktu kompilasi secara keseluruhan, misalnya BAML, Sumber Daya Tertanam, dll., yang akan dibawa ke dalam rantai alat .NET Core)

Dari kelihatannya, "Xaml Standard" lebih baik disebut sebagai "MSFT UX/UI Standard" karena itulah yang terutama dibahas dalam repo itu.

Itu, menurut saya, lebih merupakan fungsi diumumkan dalam konteks UWP/Xamarin.Forms, yang berarti pengembang yang berfokus pada kedua platform tersebut - yang mungkin tidak pernah terpapar "BigXaml" - adalah yang paling berkontribusi. Meskipun Anda melihat beberapa masalah "bawa semua dialek WPF XAML" dibuka.

Mengingat bahwa ada banyak pembersihan yang harus dilakukan tim, dan bahwa saat ini tingkat masalah baru cukup tinggi dibandingkan dengan jumlah orang yang berkontribusi, saya akan memberikan lebih banyak waktu untuk melihat ke mana tim mengambilnya.

@Mike-EEE @terrajobst @terrajobst @cwensley @mellinoe
Saya telah membuat masalah di Xaml Standard.
https://github.com/Microsoft/xaml-standard/issues/57

Terima kasih atas perhatian dan kontribusinya dalam percakapan, @juepiezhongren!

baik @lokitoth Saya senang kami menjaga masalah ini tetap utuh karena diputuskan https://github.com/Microsoft/xaml-standard/issues/23 tidak cocok untuk siang hari.

Namun, saya telah membuat masalah baru yang menurut saya melakukan pekerjaan yang lebih baik untuk menjelaskan masalah yang dihadapi dan akan luar biasa jika upvote dan/atau kontribusi Anda ditambahkan di sini: https://github.com/Microsoft/xaml-standard /isu/145

Untuk memperjelas, apa yang Anda cari sebenarnya adalah artefak yang dihasilkan _JavaScript_+HTML5+CSS3. TypeScript sebenarnya adalah transpiler untuk JS. Alih-alih membuat transpiler .NET untuk menghasilkan JS yang sesuai standar yang akan dieksekusi secara efektif dalam penelusuran (seperti JSIL ), MSFT memutuskan untuk menghabiskan waktu berharga pembuat C# untuk membuat sesuatu yang secara efektif dan pada akhirnya akan bersaing dengannya.

Saya akan mengatakan jangan biarkan saya memulai ini, tetapi saya rasa saya tidak pernah berhenti. 😛.

Juga, poin lain adalah bahwa CSHTML5 sangat dekat dengan apa yang Anda cari @weitzhandler , tetapi tidak memungkinkan untuk kode bersama antara rakitan klien/server (seperti PCL, dll). Jadi Anda masih berakhir dengan dua basis kode yang terpisah dan tidak kompatibel untuk dipelihara, menghasilkan masalah biaya/bisnis yang sama antara .NET dan JS (atau TypeScript ) yang, katakanlah, tidak ada dalam solusi NodeJS yang ketat.

Impian saya menggunakan gaya tulisan android xml ui untuk aplikasi desktop dengan inti dot net! ya, benar-benar!!

Segala upaya untuk mem-port XAML ke .NET core, saya bersedia menjadi sukarelawan.

Dalam modifikasi saya pada CoreWf (WorkflowFoundation pada standar bersih 2.0), saya melihat bahwa System.Xaml atau implementasi Portable.Xaml yang lebih kompatibel mungkin akan diperlukan untuk memungkinkan pemuatan DynamicActivity dari Xaml . Saya menjalankan CoreWf di .net framework dengan pemuatan DynamicActivity dasar menggunakan System.Xaml, tetapi masih gagal karena status parsing yang tidak valid pada inti .net dengan Portable.Xaml.

Satu pertanyaan adalah mengapa kode ke System.Xaml tidak ditambahkan ke repo sumber referensi berlisensi Mit? Apakah ada masalah lisensi, paten atau lainnya? Jika tidak ada masalah, menambahkan kode ini ke sumber referensi akan memungkinkan kami, komunitas, untuk melakukan porting yang diperlukan untuk mendukung CoreWf. Repo sumber referensi tidak mengikat Microsoft untuk mendukung System.Xaml. Haruskah saya menambahkan masalah di sana meminta System.Xaml dibuka?

Jika System.Xaml tidak dibuka, maka dapatkah kita memiliki dokumen (selain spesifikasi Xaml) atau dukungan dalam bentuk tes yang menjelaskan langkah-langkah yang benar untuk mengurai dan menandai kode Xaml untuk WorkflowFoundation?

Hai FWIW @karelz Saya telah memasukkan beberapa pemikiran ke dalam skenario DevOps di sini:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/31381861-innovate-the-xaml-designer-dawg

Berdasarkan beberapa kejadian keren di Visual Studio Xaml Designer:
https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/

Kupikir aku akan menyebutkannya di sini, sementara aku melakukannya. 👍 Selain itu, utas ini terlambat karena ada masalah. 😆.

@weitzhandler Anda perlu diperbarui, karena mono-wasm sedang dalam tahap alfa, hampir waktunya untuk mulai melupakan js.

@weitzhandler 2 atau 3 tahun diperlukan, tetapi ini bukan hanya tumpukan penuh, ini adalah tumpukan universal untuk .net.

CoreRT juga ada di papan- https://github.com/dotnet/corert/pull/4480 . Berharap untuk kombo HTML+CSS+C# yang siap produksi tahun depan.

Paket kompatibilitas .net yang diusulkan mencakup System.Xaml dengan status yang mungkin dan ditautkan ke masalah ini.

Rupanya masalah ini telah ditautkan untuk paket compat 2.1? Bisakah seseorang mengkonfirmasi? Saya melihat bahwa itu telah ditandai netfx-compat-pack, tetapi tidak dengan versi. Aku akan mengambil alih apa pun yang telah terjadi sejauh ini. 😄.

Benci mengecewakan tapi saya pikir saya tidak sengaja menandai ini sebagai 2.1 ketika saya memperbarui massal masalah paket comapt. Saya telah pindah ke Masa Depan untuk mencerminkan status yang mungkin dalam proposal.

@Mike-EEE tampaknya xamarin.wasm akan tiba.
https://github.com/mono/mono/pull/5924#issuecomment -343551464

Terima kasih atas pembaruannya tuan-tuan. Hargai kamu yang memikirkanku. :) @terrajobst itu memang mengecewakan, tapi saya menghargai Anda meluangkan waktu untuk check-in dan memperbarui. Saya tidak yakin apakah Anda masih berlangganan utas ini atau tidak. 👼.

Karena kami meluangkan waktu untuk memasang proyek tanpa malu-malu (dan itu akan memakan waktu sebelum kami mendapatkan perbaikan Xaml resmi kami), saya akan meluangkan waktu sebentar untuk menyebutkan bahwa saya telah menghabiskan tahun lalu membantu dengan v2 dari ExtendedXmlSerializer , yang baru saja dirilis. Ini menampilkan dukungan eksperimental untuk ekstensi markup dan properti terlampir (yang berfungsi pada POCO, tidak diperlukan DependencyObject ), dan juga serialisasi parameter gaya protobuf .

Jika Anda mencari (atau menambahkan) fungsionalitas Xaml-ish sementara kami menunggu System.Xaml tiba, silakan periksa, berikan umpan balik , atau (lebih baik lagi) kirimkan PR di repo. 👍

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

@danmosemsft akankah Workflow Foundation xaml didukung dalam proyek SDK sebagai bagian dari inisiatif desktop 3.0?

@lokki Saya tidak tahu rencananya. @terrajobst @karelz?

@danmosemsft
Mengapa tidak ada masalah yang mengatakan "Berikan kerangka UI sebagai bagian dari .NET Core"?

Masalah ini tidak berbicara secara khusus tentang kurangnya kerangka kerja UI, dan sepertinya orang-orang di sini tidak menyadarinya.
Lihat ini: https://github.com/Microsoft/xaml-standard/issues/232

@weitzhandler Masalah ini JAUH lebih masuk akal bagi saya sekarang. Terimakasih atas klarifikasinya.

Saya dapat melihat bahwa System.Xaml disertakan dalam .NET Standard berguna, terutama di samping XAML Standard.

jika saya memahami dengan benar "inisiatif desktop", Anda harus dapat menggunakan perpustakaan .NET yang dapat Anda gunakan di masa lalu, selama Anda hanya menargetkan Windows (tidak yakin apakah aplikasi Anda akan dapat beradaptasi secara dinamis dengan lingkungan itu berjalan, jika aplikasi utama tidak dapat melakukannya [misalnya tidak akan diluncurkan jika tidak menemukan, katakanlah OS Windows] maka mungkin Anda dapat melakukannya dengan membuat beberapa rakitan .NET Core yang memanggil hal-hal khusus platform dan memuatnya sesuai permintaan tergantung pada platform tempat aplikasi mendeteksi aplikasi itu berjalan)

@birbilis tidak cukup. XAML yang sama harus dirender secara merata di semua platform.

Inisiatif desktop bukan tentang XAML, ini tentang .NET Core tidak menjadi denominator silo yang paling umum, tetapi sebaliknya memungkinkan aplikasi yang dapat menargetkan platform tertentu (atau idealnya juga secara dinamis beradaptasi dengan platform yang mereka jalankan) dan membuat gunakan yang terbaik dari mereka, lakukan integrasi khusus platform, dll. Seseorang dapat membangun API berbasis kemampuan di atas fungsi ini sehingga aplikasi kemudian dapat ditulis yang hanya menanyakan ketersediaan kemampuan tertentu. Juga, API abstrak/kompatibilitas dapat dibangun di atasnya, menghubungkan ke implementasi yang berbeda untuk setiap platform yang ingin didukung oleh pembuat API.

Untuk saat ini, menurut saya, Portable.Xaml sangat mirip dengan System.Xaml sekarang. Jika Anda menemukan masalah, tolong beri umpan balik.

Tim WPF (@dotnet/wpf-developers ) baru saja mengumumkan sumber terbuka WPF untuk .NET Core 3.0. Sebagai bagian dari ini, pratinjau build untuk .NET Core 3.0 sekarang berisi System.Xaml, dan sumber terkait tersedia di https://www.github.com/dotnet/wpf.

OMONG-OMONG