Runtime: Port Workflow Foundation ke .NET Core

cc: @terrajobst , @joshfree , @weshaggard

Kita perlu System.Xaml dibuka sebelum upaya serius dapat dilakukan pada porting.

Saya mengerti @jakesays .

Intinya adalah bahwa WF dapat membuat definisi alur kerjanya di kelas C# alih-alih XAML (untuk saat ini) dan banyak orang bahkan tidak menggunakan representasi XAML itu. Nanti saat System.Xaml dibuka, kita bisa mengintegrasikan visual designer dan definisi XAML juga. Selain itu, kami telah mengerjakan mesin Alur Kerja yang secara ketat mengikuti penggunaan/implementasi WF tetapi alih-alih menggunakan XAML sebagai penyimpanan dasar untuk definisi alur kerja, kami memilikinya berdasarkan Json untuk penyimpanan, yang membuka banyak peluang bagi desainer alur kerja baru di semua platform (tidak hanya VS atau komponen desainer yang dihosting untuk WPF/WForms) dan memiliki beberapa manfaat seperti pembacaan/penulisan yang lebih cepat, kesederhanaan skema, pemuatan/kompilasi yang lebih cepat, dan operasi runtime. Ia bahkan dapat digunakan untuk memperkuat alur kerja klien, untuk memandu alur UI aplikasi pada aplikasi Windows Phone/Store misalnya karena runtimenya yang ringan.

Saya benar-benar berpikir WF adalah komponen yang BENAR-BENAR kuat pada platform .Net, tetapi untuk teknologi saat ini, XAML masih menjadi "pembatas" itu tetapi, jika untuk keputusan strategi MS kita dapat mempertahankannya apa adanya dan port ke CoreCLR.

Terima kasih

@zhenlan dapat berbicara tentang pemikiran saat ini tentang WF

@galvesribeiro banyak orang mungkin tidak menggunakan xaml, tetapi banyak yang melakukannya, dan itu memang dianggap sebagai bagian inti dari WF. Kami menggunakan xaml secara ekstensif, jadi saya akan melihat WF tanpa dukungan xaml hampir tidak layak digunakan.

Saya lebih suka kita terus melobi Microsoft untuk membuka System.Xaml.

Dan menggunakan JSON sebagai pengganti sama sekali tidak menarik.

@galvesribeiro @jakesays Kami sangat senang mengetahui seberapa besar minat pelanggan WF untuk memiliki WF versi .NET Core, jadi senang mendengar tanggapan dari komunitas. Jika ada cukup permintaan, akan sangat membantu bagi kami untuk bergerak maju.

Kami berada pada tahap awal mengevaluasi kelayakan, dependensi, prioritas fitur, dll. Jadi akan sangat membantu bagi kami untuk mempelajari skenario apa yang ada di pikiran Anda, mengapa WF di .NET Core (vs. WF dalam .NET penuh) akan menjadi berguna untuk Anda dan fitur WF apa yang ingin Anda lihat terlebih dahulu.

@galvesribeiro Dalam skenario Anda dengan membangun alur kerja dalam kode dan menyimpan definisi tersebut sebagai JSON, apa yang Anda (rencanakan?) gunakan untuk ekspresi? Apakah Anda menggunakan ekspresi VB, ekspresi C#, atau apakah Anda memiliki aktivitas ekspresi Anda sendiri berdasarkan CodeActivity untuk menangani ekspresi?

Terima kasih atas masukannya.

@jakesays ok bagi saya untuk menggunakan XAML. Saya hanya peduli dengan kinerja ...

@zhenlan Kami memiliki sakelar pembayaran elektronik yang memproses miliaran transaksi kartu kredit/debit sehari untuk beberapa bank di sini di Brasil, dan beberapa lainnya di luar negeri. Kami penuh di tempat dan kami memperbarui teknologi menjadi sepenuhnya cloud, dan ditawarkan sebagai layanan di Azure. Kami mendapat Perjanjian Perusahaan untuk menjelajahi semua yang kami butuhkan dari Azure di sini sebagai platform pemrosesan pembayaran multi-penyewa untuk pelanggan kami.

Kami sedang menyelidiki penggunaan NanoServer untuk dan CoreCLR sehingga kami dapat mengurangi jejak, permukaan serangan, dan pemeliharaan yang dihabiskan untuk menjalankan layanan kami dan kami melihat bahwa coreCLR belum memiliki (setidaknya) System.Activities yang di-porting. Dengan kata lain, tidak ada Yayasan Alur Kerja.

Mesin pemrosesan inti kami adalah mesin bisnis yang dibangun di atas WF dan berisi 40+ aktivitas khusus yang berfokus pada bisnis kami. Mesin ini memproses secara real time proses/aturan transaksi untuk mendapatkan persetujuan transaksi. Kita perlu menskalakannya melebihi permintaan, dan melakukannya dengan implementasi WF saat ini di cloud, katakanlah tidak layak.

Porting ke .net core, alih-alih menyimpannya di .net full (profil server) akan membuka kemungkinan untuk menjalankan alur kerja klien, itu adalah sesuatu yang sangat kami lewatkan dalam bisnis kami. Alur kerja klien tersebut dapat membuat orang mengembangkan deklaratif logika bisnis klien, dengan cara perangkat kecil seperti ponsel cerdas, perangkat yang dapat dikenakan, IoT, dan perangkat terminal pembayaran kami dapat mengambil beberapa keputusan tanpa menulis kode berulang yang nyata.

Karena kami tidak menemukan upaya apa pun di WF untuk .net Core, dan bahkan itu tidak berubah selama bertahun-tahun dan masih bergantung pada XAML, kami memutuskan untuk memulai Mesin Alur Kerja kami sendiri yang berperilaku persis sama seperti WF. Model aktivitas yang sama, gaya kode yang sama, dll, tetapi jauh lebih ringan dan didasarkan pada Json sebagai toko definisi mereka. Hal ini memungkinkan perangkat dengan daya komputasi kecil, untuk memproses alur kerja tanpa overhead berurusan dengan XAML/XML sehingga sebagian besar kode kami yang dibuat untuk WF berfungsi tanpa banyak perubahan pada definisi Json alih-alih alur kerja berbasis XAML. Juga, menjauh dari XAML, akan membuka kemungkinan bagi desainer alur kerja baru... Tidak terjebak pada Visual Studio dan pada aplikasi WPF untuk meng-host ulang desainer VS.

Apa yang saya coba sarankan adalah salah satu opsi itu:

1. Port WF (dengan XAML) seperti halnya .Net core. Opsi ini akan memakan lebih banyak waktu karena WF hari ini bergantung pada profil server .Net, yang akan membuat kami menghabiskan banyak waktu untuk memisahkannya agar dapat berfungsi dengan .Net core.
2. Port WF menulis ulang ke .Net core. Dengan cara ini, kita bisa mendapatkan konsep inti dan fokus pada desain mesin yang lebih ringan yang dapat berjalan di server, klien, IoT atau apa pun yang diperlukan dengan tetap menjaga prinsip desain dan fitur yang saat ini diterapkan di WF. Dengan cara ini kami membuat upaya yang sangat kecil dan proses tanpa gesekan untuk bermigrasi dari XAML ke (misalnya) definisi Alur Kerja berbasis Json. Semua aktivitas saat ini harus di-porting ke model baru.

Saya tidak meminta Anda untuk membangun tim atau melibatkan diri Anda ke dalam produk baru. Komunitas dapat melakukannya seperti yang mereka lakukan untuk ASP.Net dan Entity Framework. Jadikan itu sebagai kerangka kerja eksternal dan tambahan, bukan tertanam pada inti.

Terima kasih

@jimcarley Ekspresi akan dikompilasi dengan cara yang sama seperti saat ini di XAML. Di salah satu alur kerja kami, kami memiliki ini (bisa berupa VBValue juga, baru saja mendapatkan sampel):
<mca:CSharpValue x:TypeArguments="x:Boolean">emvFinishOutputParameters == null || emvFinishOutputParameters.Decision == EMVFinishDecision.DeniedByCard</mca:CSharpValue>

Ekspresi pada XAML hari ini, sebagian besar mengembalikan boolean, atau menetapkan beberapa nilai ke beberapa variabel, jadi ini akan disimpan dengan cara yang sama seperti yang disimpan hari ini di XAML, tetapi di Json dan dapat dikompilasi mengikuti ide yang sama. hari ini.

Jika Anda melihat Azure Resource Manager (ARM), mereka sudah melakukannya! Mereka memiliki penyebaran sumber daya yang dibuat sebagai Template Json, yang memiliki dependensi dan aliran, dan variabel dapat disebut sebagai ekspresi. Lihatlah ini:

"variabel": {
"lokasi": "[resourceGroup().location]",
"usernameAndPassword": "[concat('parameters('username'), ':', parameter('password'))]",
"authorizationHeader": "[concat('Basic ', base64(variables('usernameAndPassword')))]"
}

Oke, mereka menggunakan fungsi JavaScript tetapi prinsipnya sama. Mereka memiliki variabel $schema di atas template yang memandu struktur dokumen, langkah-langkah pada proses penerapan yang dapat kita jadikan sebagai aktivitas. Desainnya sangat mirip dengan WF tetapi DSL ini fokus pada penyebaran grup sumber daya. Kita dapat membuatnya lebih umum, dan menggunakan aktivitas dengan cara yang sama seperti yang mereka lakukan dalam implementasi WF saat ini.

Jika kalian memutuskan bahwa itu layak dicoba, kita dapat mulai menggambar beberapa dokumentasi tentang masalah lain yang akan memandu arsitektur "WF baru". Jika kedengarannya sangat gila dan di luar rencana Anda, beri tahu saya, kami akan tetap mengembangkannya di pihak kami untuk mendukung .net core, dan merilisnya nanti sebagai nuget untuk orang-orang. Saya hanya mencoba membuat kerangka kerja yang luar biasa ini mutakhir dengan teknologi saat ini (yang akan datang). Ini benar-benar kebutuhan bisnis bagi kami. Kami sangat bergantung pada WF, tetapi jika tidak menjadi lebih cepat dan tidak didukung pada coreCLR, kami harus mulai mempersiapkan kerangka kerja baru ini sehingga ketika NanoServer+coreCLR adalah RTM, kami dapat bergerak untuk itu.

Tolong beri tahu saya jika Anda memiliki pertanyaan.

Terima kasih

PS: Saya di saluran gitter setiap hari jika Anda perlu mengobrol.

@galvesribeiro Jadi Anda menggunakan TextExpressionCompiler untuk mengkompilasi ekspresi setelah membuat objek Aktivitas dari definisi alur kerja yang disimpan di JSON. Benar?

@jimcarley kami belum memiliki kompiler ekspresi yang berfungsi. Kami masih mendesainnya menggunakan prinsip yang sama dari TextExpressionCompiler tapi ya, sepertinya konsepnya hampir sama. Implementasi saat ini sepertinya terkait dengan System.XAML. Karena tidak terbuka, saya tidak dapat mengonfirmasi apakah akan bekerja dengan cara yang sama (secara internal) seperti TextExpressionCompiler tetapi ya, setelah aktivitas dimuat, kita harus mengevaluasi/mengkompilasi ekspresi (jika belum dalam cache) dan mengekspos objek Ekspresi di atasnya untuk dievaluasi oleh konsumen aktivitas (jika diperlukan).

Tahun lalu saya melakukan beberapa pekerjaan di sisi ekspresi untuk mengaktifkan dukungan ekspresi C# pada desainer WF yang dihosting sendiri. Itu didasarkan pada bit nrefactory dan roslyn. Saya bisa menggalinya jika ada yang tertarik.

@galvesribeiro setelah lebih memikirkan pendekatan json Anda, pada akhirnya saya kira itu tidak masalah untuk pengembangan baru. Jika MS tidak membuka dukungan xaml maka ini mungkin berhasil.

@zhenlan Saya setuju dengan @galvesribeiro bahwa kami tidak perlu mencari MS untuk membentuk tim untuk port WF. Ini jelas merupakan sesuatu yang dapat dilakukan komunitas dengan bimbingan dari tim Anda, dll.

@jakesays Saya setuju dengan Anda bahwa penyimpanan sebenarnya tidak masalah jika kita membuat lagi WF untuk coreclr.

Intinya adalah, mengapa tetap menggunakan XML daripada Json karena kami memiliki banyak tes di seluruh web yang membandingkan kinerja (de)serialisasi keduanya dan json jauh lebih cepat dan mengkonsumsi lebih sedikit sumber daya daripada itu? (misalnya membandingkan Json.Net Newtonsoft dengan serializer XML biasa) Jika WF akan berjalan pada perangkat klien footprint kecil (IoT apa pun), setiap byte memori penting.

Juga, dengan json, jauh lebih mudah untuk mendapatkan desainer WF berbasis web baru segera. Kompilasi dan eksekusi ekspresi tidak sulit untuk diterapkan. Ini kira-kira parser string untuk membangun objek ekspresi. Bagian yang sulit (imho), adalah untuk mendapatkan intellisense di VS untuk jenis yang digunakan saat merancang WF, tapi saya cukup yakin Roselyn dan layanan bahasa dapat membantu kami dengan itu dan VS memiliki infrastruktur untuk itu.

@galvesribeiro Anda menyebutkan bahwa Anda telah membuat mesin alur kerja Anda sendiri dengan definisi alur kerja dan serialisasi berbasis JSON. Jika WF diporting ke Core, apakah Anda akan benar-benar menggunakannya?

@dmetzgar kami mulai mengembangkan dan mengujinya sebagai bukti konsep bahwa kami dapat mencapai hasil yang lebih baik dalam WF yang lebih bersih dengan hampir tidak ada ketergantungan pada kerangka kerja, yang bagus untuk membuatnya bekerja di coreclr. Kami tidak memilikinya siap.

Saya akan senang untuk tidak harus membangun mesin saya sendiri dan tetap menggunakan WF meskipun didasarkan pada XAML tetapi porting ke coreclr dan jika mengikuti konsep yang sama dari versi coreclr dari EntityFramework dan ASP.Net misalnya (jangan bergantung pada perpustakaan server dan berjalan di mana-mana).

Intinya adalah, jika masih tergantung pada XAML dan pada profil Server, itu akan tetap lambat (membutuhkan terlalu banyak sumber daya), terbatas pada pilihan desainer, dll.

Saran saya adalah untuk mem-port-nya ke coreclr menggunakan Json, dan menghapus banyak dependensi yang dimilikinya saat ini sehingga pengguna dapat menjalankannya di mana pun mereka inginkan dengan cara yang sama seperti Anda dapat menjalankan ASP.Net vNext pada perangkat IoT ARM (segera setelah dukungan ARM selesai!) dan jangan khawatir tentang ketergantungan dan konsumsi sumber daya yang tinggi.

Semua alur kerja kami hari ini dibuat dengan versi saat ini dengan beberapa di antaranya ditulis dengan kode murni dan beberapa dengan XAML tetapi dalam kedua kasus, kami masih memiliki dependensi.

IMHO, port ke coreclr apa adanya, tidak membawa banyak manfaat kecuali seseorang datang dengan mesin ringan super baru untuk parsing/rendering XAML/XML untuk runtime dan waktu desain. Tetapi jika kalian memutuskan untuk port apa adanya, kami akan tetap menggunakannya, karena itu akan membuat alur kerja XAML saya berfungsi (saya harap) mulai hari 0, bahkan jika saya tahu itu tidak akan membawa manfaat praktis ...

Sekali lagi, saya (mungkin @jakesays dan pengguna WF lainnya) dapat membantu port ini dengan dua cara (XAML atau JSON) terlepas dari keputusan kalian. Saya hanya ingin memastikan port ini tidak hanya menyalin&menempel&memperbaiki untuk membuatnya berfungsi, dan sebaliknya, ini benar-benar membawa manfaat bagi orang-orang yang menggunakannya, mengikuti ide coreclr yang sama dan dapat berjalan di mana-mana tanpa rasa sakit.

Terima kasih

@galvesribeiro Saya setuju bahwa XAML terlalu terintegrasi dengan WF. Kembali ke buku asli Dharma tentang alur kerja, dia memiliki sampel yang membangun alur kerja dari Visio. Setidaknya dengan porting ke core, kita bisa mengukirnya sehingga runtime terpisah dari XAML. Itu memungkinkan kami untuk melanjutkan dengan atau tanpa tim XAML yang melakukan porting ke inti dan kami selalu dapat menambahkan dukungan alur kerja XAML nanti sebagai proyek GitHub/paket NuGet terpisah. Saya pasti semua untuk memungkinkan untuk mendefinisikan dan mempertahankan alur kerja dalam format apa pun. Terima kasih, umpan balik ini bermanfaat.

@dmetzgar Saya tidak ragu bahwa suatu hari nanti XAML akan di-porting ke core... Jika .net core akan berjalan di windows phone atau perangkat seluler windows 10 apa pun, itu akan terjadi pada suatu waktu dan saya sepenuhnya setuju dengan Anda bahwa kami dapat membangun inti baru, dan tambahkan kegigihan definisi dan status alur kerja nanti juga.

Jadi, apa yang perlu kita lakukan untuk memulai porting? (kami telah menandatangani perjanjian kontributor dan memiliki NDA lain sebagai perusahaan dengan MS, dll)

Terima kasih

@galvesribeiro Saya menghargai antusiasme! Meskipun menggoda untuk membuka repo GitHub dan mulai meretas, ada beberapa langkah yang harus dilakukan. Juga, bukan hanya System.Xaml yang harus diukir. Ada dependensi lain yang tertanam dalam di WF seperti System.Transactions dan beberapa komponen bersama dengan WCF. Kami sedang menyelidikinya masing-masing.

Saya mengerti. Yah, aku tidak ingin memaksa kalian, aku hanya khawatir tentang waktu. Kami memiliki keputusan untuk membuat sekarang untuk bergerak maju membangun sendiri, atau bergabung dengan komunitas di sini dan port WF ke coreCLR sehingga dapat memenuhi timeline kami untuk produk kami.

@dmetzgar Sudahkah Anda mempertimbangkan untuk menerbitkan bagian yang dapat bersumber terbuka sekarang ke https://github.com/Microsoft/referencesource? Saya pikir itu bisa jauh lebih sederhana daripada membuat proyek sumber terbuka lengkap yang benar-benar berfungsi.

Dengan begitu, Anda dapat meluangkan waktu dengan versi yang tepat, dan orang lain dapat membuat versi parsial/kustom mereka sendiri untuk sementara.

Komponen @svick WF secara lengkap .NET telah dipublikasikan di github referencesource beberapa waktu lalu. Misalnya, Anda dapat menemukan https://github.com/Microsoft/referencesource/tree/master/System.Activities

@zhenlan ya, masalahnya adalah bahwa beberapa dependensi tidak "dapat diselesaikan"... Saya tidak dapat melihat apa perilaku beberapa kelas dengan benar, karena ketergantungannya pada System.Xaml yang bukan publik...

Kita selalu bisa mencari tahu di akhir kita, tetapi itu berarti kita tidak tahu pasti apakah kita mengikuti cara yang sama.

@dmetzgar System.Transaction adalah sesuatu yang belum terbuka (belum?), tapi saya pikir kita bisa mengatasinya (untuk saat ini). Mengenai WCF, pohon ketergantungan hanya menunjukkan kepada saya aktivitas dan Host Layanan Alur Kerja. Tidak ada inti (IIRC) yang bergantung pada WCF...

@galvesribeiro Situasi dengan System.Transactions lebih kompleks dari itu. Ini ditaburkan di seluruh runtime WF dan sangat bergantung pada instance tahan lama, yang merupakan tempat kelas dasar untuk ketekunan. WCF dan WF digabungkan ke dalam tim yang sama di sekitar jangka waktu .Net 4.0 sehingga kami memiliki hal-hal seperti System.ServiceModel.Internals yang digunakan oleh WCF dan WF. .Net core memiliki banyak porting hal-hal besar, tetapi ada banyak hal yang hilang. Mengatasi bagian yang hilang mungkin memerlukan perubahan desain atau penulisan ulang fitur.

Tak satu pun dari masalah ini yang tidak dapat diatasi, saya hanya tidak ingin meremehkan upaya ini. Itu berlaku untuk kode dan segala sesuatu di sekitarnya seperti mendapatkan persetujuan hukum, membangun lingkungan, menguji infrastruktur, dll. Kami pasti ingin komunitas membantu dan kami bekerja untuk itu. Apakah Anda harus menulis port Anda sendiri atau menunggu port "resmi" tergantung pada jangka waktu Anda. Menjalankan alur kerja di server Nano adalah salah satu skenario terbesar kami dan saya ingin mendapatkan bantuan Anda untuk itu.

@dmetzgar Saya mengerti, selalu ada penundaan ketika ada pertanyaan yang harus diteruskan ke PR atau Hukum ketika saya berada di pihak Anda :)

Yah, jika setidaknya kita memiliki gagasan tentang jangka waktu tertentu, kita bisa mempersiapkan diri dan bisa menunggunya. Saya benci ide untuk tidak menerapkan sesuatu di "tempat yang salah" atau ketika sudah ada beberapa upaya yang dihabiskan di suatu tempat sehingga kita dapat bergabung untuk melakukan yang lebih baik.

Tolong beri tahu saya jika ada yang bisa kami lakukan, atau jika Anda memiliki berita, atau ping saya jika Anda memerlukan saran mengenai desain/port.

Terima kasih

Saat kerangka waktu semakin jelas, saya akan membuat pembaruan di utas ini. Saya akan senang mendengar skenario lain yang diminati orang. WF di Nano adalah skenario utama saat ini, tetapi akan lebih baik untuk mengetahui apa yang dilakukan orang lain.

Hi guys, selain XAML dan JSON, ada cara COOL untuk menyusun aktivitas : metaprogramming. Lihatlah proyek eksperimental saya: Metah.W: A Workflow Metaprogramming Language (https://github.com/knat/Metah).

@jakesays Bisakah Anda memberikan beberapa panduan tentang cara mengaktifkan dukungan ekspresi C# di WF yang dihosting sendiri.

Harap simpan Xaml. :) Objek serial JSON akan menarik juga. Tetapi saya lebih suka melihat penyedia yang entah bagaimana dikonfigurasi dalam kerangka kerja untuk memilih format yang disukai.

@dmetzgar (dan orang-orang MSFT lainnya) apakah ada berita tentang hal ini?
Terima kasih

Kami telah mengerjakan ini dan telah membuat banyak kemajuan. XAML saat ini tidak tersedia di Core jadi kami fokus pada runtime. Kami sedang mencari untuk membuka serializers lainnya. Jadi daripada memilih sisi antara JSON atau XAML, kami lebih suka mengizinkan Anda membawa serializer Anda sendiri. Masih ada lebih banyak kepatuhan dan hal-hal hukum untuk disetujui. Karena tidak banyak pelanggan yang mendorong port ini, ini menjadi prioritas yang lebih rendah.

@dmetzgar manis! Saya akan lebih dari senang untuk berkontribusi untuk itu namun saya bisa jika ini menjadi proyek inti ... apakah itu menjadi desainer alur kerja web dll. Sepertinya xaml hampir tidak perlu ada di sana untuk format definisi ... senang mendengarnya tentang pekerjaan ini!

Halo teman-teman, selamat natal dan selamat tahun baru!

Jadi, apakah kami memiliki pembaruan pada port itu atau setidaknya rilis OSS dari pekerjaan saat ini sehingga kami dapat membantunya?

Terima kasih

@galvesribeiro Saya akan mencoba menjelaskan situasinya sebaik mungkin. Dalam semangat saya untuk mendapatkan WF porting ke .NET Core, saya gagal untuk memperhitungkan sisi bisnis dari semua ini. WPF/XAML tidak di-porting ke .NET Core dan itu mewakili sebagian besar WF. Meskipun XAML tidak penting untuk runtime, ini adalah cara sebagian besar pelanggan membangun alur kerja. Ini membatasi audiens yang akan menganggap WF di Core berguna. Salah satu ketakutannya adalah kami merilis WF di Core dan tidak banyak melibatkan komunitas. Ini menambah biaya dukungan kami dan tidak memperbaiki situasi bagi sebagian besar pelanggan WF. Meskipun keren untuk melihat WF berjalan di mesin Linux, sulit untuk membuktikan bahwa ada orang yang benar-benar menggunakannya.

Saya mengetahui OmniXAML dan kami telah berhasil meyakinkan penulis untuk mengubah ke lisensi MIT. Jadi dengan beberapa investasi, kami berpotensi membuat XAML berfungsi. Tapi masih ada pertanyaan bagaimana ini menguntungkan pelanggan WF yang sudah ada. Jika suatu hari pelanggan besar seperti SharePoint atau Dynamics datang dan mengatakan mereka pindah ke Nano, maka kami akan memiliki kasus yang menarik. Itu semua diperdebatkan jika tim .NET Framework memutuskan untuk membuat paket yang dapat menjalankan kerangka penuh di Nano.

Jika ada cukup minat masyarakat dan seseorang yang bersedia untuk memperjuangkan proyek tersebut, kami dapat mencoba melakukannya dengan cara itu. Jenis seperti Open Live Writer. Bagian yang sulit adalah bahwa sementara tim saya akan berkontribusi sebanyak mungkin, proyek semacam itu tidak akan datang dengan dukungan Microsoft. Saya menduga sebagian besar pelanggan WF menggunakan WF terutama karena Microsoft mendukungnya.

Saya pikir penting untuk menyoroti bahwa .NET Core dan .NET Framework lengkap adalah dua produk yang berbeda. .NET Framework sama sekali tidak sekarat. Kami akan terus mendukungnya, menambahkan fitur, dll. Jadi kami tidak harus port WF ke .NET Core agar tetap hidup. WF pada Core pada dasarnya akan menjadi produk baru. Datang dengan pembenaran bisnis yang solid itu sulit. Bahkan mungkin masalah waktu. Karena semakin banyak perusahaan mengadopsi server Nano, mungkin ada kasus yang lebih kuat.

@dmetzgar Bagaimana dengan Portable.Xaml, apakah ini bisa menjadi alternatif? https://github.com/cwensley/Portable.Xaml Ini telah diekstraksi untuk digunakan oleh penulis proyek Eto.Forms yang fantastis untuk Eto. Ini berlisensi MIT dan (dan begitu juga perpustakaan kelas yang berasal dari proyek mono).

@dmetzgar ,

Saya akan mencoba menjelaskan situasinya sebaik mungkin. Dalam semangat saya untuk mendapatkan WF porting ke .NET Core, saya gagal untuk memperhitungkan sisi bisnis dari semua ini. WPF/XAML tidak di-porting ke .NET Core dan itu mewakili sebagian besar WF. Meskipun XAML tidak penting untuk runtime, ini adalah cara sebagian besar pelanggan membangun alur kerja. Ini membatasi audiens yang akan menganggap WF di Core berguna. Salah satu ketakutannya adalah kami merilis WF di Core dan tidak banyak melibatkan komunitas. Ini menambah biaya dukungan kami dan tidak memperbaiki situasi bagi sebagian besar pelanggan WF. Meskipun keren untuk melihat WF berjalan di mesin Linux, sulit untuk membuktikan bahwa ada orang yang benar-benar menggunakannya.

Saya pikir motivasi terbesar bagi pengguna WF saat ini adalah server Nano dan Layanan Mikro dan bukan Linux. Linux akan menambah lebih banyak pengguna, tetapi bukan motivasi sebenarnya.

Tapi masih ada pertanyaan bagaimana ini menguntungkan pelanggan WF yang sudah ada.

Kami berada di hari-hari awan. Ingat, "Cloud first, mobile first..." dan salah satu teknologi besar yang sedang berkembang adalah container, Layanan Mikro, dan tawaran besar dari MS untuk semuanya adalah Nano Server.

Jika suatu hari pelanggan besar seperti SharePoint atau Dynamics datang dan mengatakan mereka pindah ke Nano, maka kami akan memiliki kasus yang menarik.

Bahkan dengan penyebaran Sharepoint atau Dynamics terbesar di dunia, kami tidak akan pernah mencapai jumlah pengguna yang sama dan saya bahkan akan mengatakan tingkat pendapatan yang sama, daripada yang dibuat dengan teknologi cloud.

Itu semua diperdebatkan jika tim .NET Framework memutuskan untuk membuat paket yang dapat menjalankan kerangka penuh di Nano.

DNX hari ini (sejauh RC1) tidak hanya terdiri dari coreCLR. Ini memiliki kerangka kerja lengkap juga (dnx451) sehingga saat ini kami dapat menggunakan WF di DNX dan itu bukan tentang masalah di sini. Kita berbicara tentang coreCLR (dnxcore50)

Jika ada cukup minat masyarakat dan seseorang yang bersedia untuk memperjuangkan proyek tersebut, kami dapat mencoba melakukannya dengan cara itu. Jenis seperti Open Live Writer.

Saya tidak akan membandingkannya dengan apa yang dibuat di Open Live Writer... Saya rasa ini kurang lebih yang dibuat dengan ASP.Net, MVC, Entity Framework. "Produk" inti dari keluarga .Net dan yang saat ini bersifat open source.

Bagian yang sulit adalah bahwa sementara tim saya akan berkontribusi sebanyak mungkin, proyek semacam itu tidak akan datang dengan dukungan Microsoft. Saya menduga sebagian besar pelanggan WF menggunakan WF terutama karena Microsoft mendukungnya.

Memang pelanggan WF menggunakan kontrak Dukungan MS... Khususnya pelanggan Dynamics dan Sharepoint melakukannya Namun, ada banyak aplikasi di luar dunia ini yang masih memerlukan dukungan. Mengatakan bahwa orang hanya menggunakannya karena dukungan dan OSS tidak didukung, hampir sama dengan mengatakan bahwa CoreCLR, EF, ASP.Net tidak akan mendapat dukungan dari MS. Meskipun proyek-proyek itu sekarang adalah OSS, mereka sangat dipantau dan dimoderasi oleh tim MS.

Misalnya, saya mulai sebagai pengguna di proyek MS Orleans. Ini mendukung semua layanan cloud Halo selama hampir 7 tahun. Skype, Outlook, dan banyak layanan publik/cloud MS lainnya memanfaatkannya. Beberapa tahun yang lalu, OSSed dari MS Research dan sekarang dikelola oleh 343 Studios, beberapa orang dari MSR, dan beberapa lainnya dari grup lain di dalam MS tetapi sebagian besar dikelola oleh Komunitas. Hari ini, saya menganggap diri saya sebagai kontributor aktif untuk proyek itu dan saya mendukung pengguna baru bersama dengan orang-orang MS dan non-MS lainnya di sana. Kami bahkan memiliki orang-orang yang mantan (seperti saya) dan karyawan non-MS di dalam tim GH untuk Orleans. Apakah ini berarti kami tidak memiliki dukungan? Yah, saya tidak membeli Orleans jadi saya secara hukum meminta dukungan dalam kontrak saya dengan MS untuk Orleans secara khusus, namun saya dapat melakukannya dengan menargetkan .Net framework atau produk lain yang terkait, jadi, saya tidak terlalu setuju dengan pernyataan Anda.

Datang dengan pembenaran bisnis yang solid itu sulit.
Saya setuju dengan Anda jika Anda hanya mencari pelanggan Sharepoint dan Dynamics.

Yah, kami, seperti banyak perusahaan lain di seluruh dunia, memelihara Perjanjian Perusahaan (Enterprise Agreements/EA) besar dengan Microsoft menggunakan sebagian besar produk variabel pada kontrak tersebut. Dalam kasus kami, kami memproses jutaan transaksi keuangan (kartu kredit/debit) per hari dan masing-masing mewakili satu contoh WF yang berjalan di atas Orleans dan di dalam Microsoft Azure. Saya tidak tahu apa yang akan menjadi besar bagi Anda untuk bertindak sebagai pembenaran bisnis.

Saya hanya berpikir inti (System.Activities), tanpa XAML, dapat di-porting ke coreCLR dan desainer dapat dibuat sesuai permintaan untuk XAML, Json, HTML, XML, apa pun. Dengan memisahkan ketergantungan ini, kemungkinan lain terbuka.

Seperti yang saya katakan di awal utas ini, pekerjaan paling berat yang kami inginkan sekarang, adalah mendapatkannya OSSed dan seseorang (setidaknya pada awalnya) dari MSFT, tersedia untuk meninjau PR. Akal sehat di sini adalah menulis ulang WF dan bukan hanya menyalin & melewatinya untuk coreCLR jadi kami mengharapkan kontribusi besar untuk itu.

Jika itu adalah sesuatu yang tidak akan terjadi, saya pikir kita dapat menutup masalah ini dan setidaknya orang akan mulai mencari OSS lain atau bahkan mesin Workflow berbayar yang pada akhirnya akan mendapatkan dukungan CoreCLR. Saya hanya berpikir itu adalah kerugian besar tidak memilikinya di dalam CoreCLR ...

Saya dapat memberikan alasan yang sangat kuat mengapa WF harus di-porting ke .Net Core.

Microsoft mengantar pengembang ke platform UWP. UWP akan menjadi platform Windows masa depan. Ini tidak ada hubungannya dengan gagasan peri yang lapang tentang porting aplikasi ke Linux dll. Ada kebutuhan yang sulit untuk menjalankan WF di mesin Windows 10, dan UWP adalah masa depan untuk platform Windows 10.

Kami terkadang membuat aplikasi yang terhubung. Kami memiliki ujung belakang .Net, dan ujung depan UWP. Saat ini, semua logika bisnis dibagikan di .Net dan UWP. Tapi, kami ingin logika bisnis kode lunak di WF. Ini akan berfungsi dengan baik di .Net, tetapi WF saat ini tidak didukung oleh UWP, jadi WF dianggap tidak berguna karena kecuali pengguna terhubung ke internet, mereka tidak dapat melakukan panggilan yang divalidasi oleh logika WF.

UPW memiliki XamlReader, jadi mem-parsing XAML bukanlah masalah besar...

@MelbourneDeveloper setuju dengan Anda dengan semua alasan Namun, perlu diingat bahwa UWP dan .Net Core (setidaknya sekarang) tidak berada di bawah moniker yang sama, yang berarti bahwa bahkan mereka berbagi API tingkat rendah yang sama, memiliki permukaan API yang sama (dan . Net Core adalah OSS sedangkan UWP tidak), mereka tidak sama dan tidak kompatibel. Dengan kata lain, Anda tidak dapat menambahkan rakitan .Net Core ke rakitan UWP. Perbedaan itu (IMHO) pada akhirnya akan hilang tetapi untuk saat ini, mereka masih ada ...

Ya. Dipahami. Dengan asumsi kerja bahwa kedua hal itu akan dipertemukan di masa depan. Jika tidak, Tuhan tolong kami!

Juga @MelbourneDeveloper UWP's Xaml adalah versi Xaml .NET yang sama sekali berbeda dan bodoh. UserVoice WindowsDev dibumbui dengan (apa yang terus diabaikan, seperti semua yang tampaknya UWP - heran mengapa mereka bahkan memiliki UserVoice untuk memulai) suara untuk meningkatkan sistem Xaml-nya:
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9523650-add-support-for-xmlnsdefinitionattribute

Semoga mereka melakukan Hal yang Benar dan berkumpul di belakang port Mono Xaml @cwensley dan/atau OmniXaml seperti yang disarankan. Sistem Xaml UWP sebagaimana adanya benar-benar lelucon dan merupakan bagian dari alasan mengapa tingkat adopsinya sangat buruk.

Bersamaan dengan catatan tersebut, saya memiliki kasus penggunaan bisnis untuk dipertimbangkan oleh MSFT: NodeJS. Semakin lama kita semua membahas masalah ini, semakin banyak nilai yang diperoleh NodeJS di pasar, karena ini benar-benar lintas platform dan benar-benar ada di mana-mana, sesuatu yang tidak dapat diklaim oleh teknologi MSFT saat ini (atau di masa mendatang). NodeJS bekerja di server, dan klien (SEMUANYA) dan memungkinkan penggunaan kembali kode di antara keduanya. Satu basis kode akan bekerja dalam skenario asli (melalui Cordova) dan web (melalui browser HTML5 standar), yang jauh lebih murah daripada apa yang harus Anda lakukan dengan solusi berbasis MSFT.

Ini akan segera sampai pada titik bahwa mengulang sistem di NodeJS dan membuang MSFT sama sekali akan menjadi lebih enak (dan jelas lebih murah) daripada menunggu (seperti apa rasanya) tim disfungsional untuk mengejar realitas ekonomi pasar.

Saya juga menyebutkan ini karena disebutkan bahwa tampaknya MSFT mengandalkan UWP untuk platform kliennya, tetapi mencapai sebagian kecil dari pasar yang dilakukan NodeJS. Dan ketika saya mengatakan pecahan, itu mungkin berlebihan. Kita berbicara tentang 200 juta (jumlah penginstalan terakhir yang diketahui dari Windows 10) vs ~3B (MILIAR) perangkat yang dapat dijangkau oleh aplikasi berbasis nodejs.

Jangan salah paham di sini, saya suka MSFT. Saya telah menginvestasikan lebih dari 15 tahun hidup saya dengan teknologinya dan saya sepenuhnya berinvestasi di sini, secara pribadi. Namun, dengan investasi itu muncul semangat untuk melihat semua orang melakukannya dengan benar dan bangga dengan keputusan dan upaya yang dibuat di sini dengan era baru open source, kedahsyatan lintas platform. Saya juga ingin semua orang mewaspadai ancaman pasar yang menjulang (dan mungkin juga untuk memverifikasi/mengkonfirmasi ketakutan saya).

Akhirnya, jika semuanya berjalan dengan baik, kami memiliki masalah besar lainnya dengan status cross-platform Xaml kami saat ini, karena Portable.Xaml berbeda dari OmniXaml, jadi pada titik tertentu kami sebagai komunitas harus mencari cara untuk mendamaikan keduanya basis kode... idealnya. :)

@Michael-DST setuju dengan Anda dalam semua poin. Salah satu target yang kami ingin WF jalankan adalah klien (khususnya seluler dan tertanam). Kami ingin mengurangi kode klien untuk aturan bisnis lokal dengan menambahkan WF di atasnya. Oleh klien, saya tidak sepenuhnya berbicara tentang UWP seperti perangkat Windows (ponsel, tablet, dan IoT) ...

Saya percaya bahwa ada produk utama yang mengandalkan WF seperti BizTalk dan Sharepoint tetapi mereka masih dapat mengandalkan versi lengkap .Net sementara orang-orang di .Net Core (dan kemudian UWP) dapat mengandalkan API WF/XAML yang baru. Saya tahu ini akan menyiratkan banyak #jika di sekitar basis kode, tetapi itu akan menjadi cara yang harus dilakukan ...

@galvesribeiro terima kasih atas verifikasi/dukungannya. Rasanya seperti saya skating menanjak di kali karena tampaknya tidak ada yang mengenali masalah yang sangat nyata (eksistensial?) yang dihadapi .NET. Faktanya, kepemimpinan .NET membantu memperburuk masalah ini dengan merekomendasikan untuk memasangkan .NET dengan AngularJS untuk aplikasi web, yang pada dasarnya menantang organisasi untuk beralih ke NodeJS sama sekali! (pengungkapan penuh, saya menulis itu. : P ).

Saya ragu untuk memposting begitu banyak di sini mengenai NodeJS, karena WF lebih merupakan teknologi sisi server, tetapi cara saya (dan organisasi lain mulai) melihatnya, ini memengaruhi semua bidang dan mengancam .NET secara keseluruhan. Ini hanya lebih hemat biaya (dan efisien jangkauan pasar) untuk menggunakan NodeJS sebagai tumpukan solusi saat ini dan kami (sekali lagi, benci untuk mengulang sendiri -- tetapi tidak benar-benar) melihat ini tercermin dalam organisasi untuk teknologi pilihan mereka.

Intinya: Saya harus menempatkan kecemasan saya _di suatu tempat_ dan utas ini adalah korbannya. :P #maaf tidakmaaf

Mengenai #if defs... yuck, saya akan mengutip Manifesto MvvMCross di sini: "# adalah untuk twitter, bukan kode." :P

AKHIRNYA, saya lupa memberi tag @SuperJMN karena dia juga harus mengetahui utas/diskusi ini (sebagai penulis OmniXaml) -- tidak bermaksud untuk tidak menghormati, kawan! Saya akan menangani masalah OmniXaml vs. Portable.Xaml secara pribadi dalam minggu depan atau lebih.

@Michael-DST ya... Sebenarnya #if hanya satu cara... Tim Inti Net mengambil pendekatan "Native Shims" di mana implementasi nyata (khusus OS) diabstraksikan pada lapisan tipis kode asli yang lebih rendah. Dalam kasus WF itu bisa menjadi shim untuk .Net Full dan lainnya ke .Net Core misalnya ...

Saya bukan penggemar Node.js dan juga JavaScript (saya cenderung berpikir bahwa itu masih bahasa scripting, bukan bahasa pemrograman tetapi itu adalah pendapat saya sendiri), tetapi saya harus setuju bahwa saat ini, tidak ada yang bisa dibandingkan dengan itu dalam hal xplat. Microsoft sendiri menggunakannya untuk membangun agennya di VSTS (hanya untuk menyebutkan 1 kasus, ada yang lain di MS) karena berjalan di platform apa pun misalnya ...

Saya pikir WF adalah bagian teknologi yang luar biasa yang versi saat ini dimaksudkan untuk menjadi pengguna di sisi server, dengan .Net Core, dan dapat dengan sempurna pada klien juga ...

@galvesribeiro ... Saya dengan Anda 100%. EF Core 1.0 adalah cara yang sama... teknologi sisi server tradisional yang sekarang dapat digunakan di sisi klien juga. Akan sangat berguna jika WF tersedia dengan cara seperti itu juga.

Juga, ada baiknya mendengar tentang shims. Banyak menyetujui. :)

Akhirnya, saya tidak ingin menggagalkan/membajak utas (banyak) di sini, tetapi untuk memastikan kembali: JavaScript: Saya setuju sebagai bahasa skrip. Namun, ini juga merupakan "bahasa" yang sangat fleksibel yang dapat digunakan dalam bentuk lain, terutama kode byte(ish). Seperti yang saya yakin Anda telah lihat, ada keajaiban kompiler LVVM di luar sana untuk C++. Permintaan yang berkembang/populer di komunitas pengembang .NET adalah melakukan hal yang sama untuk .NET (mengubah .NET menjadi JS dalam kapasitas resmi). Ini benar-benar akan memperbaiki semua kejahatan (utama) saat ini dalam iklim pengembang MSFT saat ini.

Bagaimanapun, kembali ke pemrograman terjadwal reguler Anda. :P Terima kasih atas dialog dan pemikirannya!

Kalian menyentuh beberapa hal yang telah saya tangani selama 9 tahun. Ada sesuatu yang tidak dipahami oleh banyak orang yang bekerja dengan teknologi Microsoft; yaitu konsep komputasi terdistribusi. Persyaratan mendasar dari perangkat lunak kami sejak awal adalah bahwa ia bekerja dalam mode terhubung sesekali. Seiring waktu Microsoft telah mengambil berbagai tusukan untuk menyediakan alat untuk ini, tetapi tidak ada kerangka kerja yang komprehensif yang pernah dikembangkan. Kami memiliki sedikit kerangka sinkronisasi di sini, sedikit database LINQ di sana, tetapi tidak ada perangkat yang komprehensif untuk membuat semuanya bekerja bersama.

Selama 9 tahun terakhir kami telah mengembangkan kerangka kerja kami sendiri yang terkadang terhubung. Sekarang berjalan di .Net, Silverlight, dan UWP. Kami berusaha sangat keras untuk memanfaatkan kerangka kerja Microsoft seperti EF, dan WF, tetapi tidak ada dukungan yang ditawarkan untuk teknologi ini pada platform teknologi klien seperti Silverlight. Kami benar-benar membangun kerangka kerja ORM dan sinkronisasi kami sendiri untuk Silverlight yang sekarang kompatibel dengan UWP.

Ketika ada banyak buzz di sekitar WF di tempat pertama, itu cukup menarik karena menawarkan cara untuk logika bisnis kode lunak tanpa kode. Namun, seiring berjalannya waktu, saya menjadi semakin tidak cenderung berpikir bahwa akan ada port ke teknologi sisi klien seperti Silverlight. Saya memposting banyak pertanyaan tentang ini di forum, tetapi jawabannya selalu sama: WF adalah teknologi sisi server, mengapa Anda ingin menggunakannya di Silverlight?

Seperti yang dikatakan galvesribeiro

"Saya pikir WF adalah bagian dari teknologi yang mengagumkan yang versi saat ini dimaksudkan untuk menjadi pengguna di sisi server, dengan .Net Core, dan dapat sempurna pada klien juga..."

Dan

"Salah satu target yang kami ingin WF jalankan adalah klien (khusus seluler dan tertanam). Kami ingin mengurangi kode klien untuk aturan bisnis lokal dengan menambahkan WF di dalamnya. Oleh klien, saya tidak sepenuhnya berbicara tentang UWP seperti perangkat Windows (ponsel, tablet, dan IoT)"

Yang harus dipahami orang adalah bahwa dalam hal komputasi terdistribusi, tidak ada perbedaan antara teknologi klien dan server. Pikirkan tentang cara kerja Git. Kode untuk Git adalah sama terlepas dari apakah Anda melihat repo pusat, atau sebuah node di jaringan di suatu tempat. Kode diduplikasi di mana-mana. Ini hal yang sama dengan kerangka kerja kami. Logika bisnis diduplikasi ke semua node. Itu karena meskipun pengguna tidak terhubung ke jaringan, mereka masih harus tunduk pada logika bisnis yang sama. Dalam komputasi terdistribusi, setiap komputer secara harfiah ADALAH server. Ini benar-benar menjalankan kode yang sama dengan server.

Kami tidak pernah dapat memanfaatkan WF, karena kami tidak dapat menjalankan kode WF di Silverlight, dan sekarang kami tidak dapat menjalankannya di UWP. Sangat menggembirakan melihat EF di-porting ke UWP. Mungkin ini adalah awal dari pemahaman Microsoft bahwa komputasi terdistribusi adalah sebuah kebutuhan. Namun, Microsoft perlu bergabung dengan komputasi yang tidak terganggu dan memasukkan WF sebagai bagian dari seluruh kerangka kerja komputasi terdistribusi. Mungkin saat itu, kami akan dapat menghapus kerangka kerja komputasi terdistribusi kami, dan saya tidak perlu mempertahankan kode itu lagi.

Perspektif dan pemikiran yang benar-benar hebat @MelbourneDeveloper. Terima kasih telah berbagi. Saya juga penggemar berat Silverlight dan telah mengais-ngaisnya sejak (karenanya suara saya yang dihasilkan dan -- sungguh -- situs di atas). Juga, saya ingin tahu apa pendapat Anda tentang Layanan Seluler Azure dan apakah Anda telah mempertimbangkan untuk menggunakannya dalam cerita offline Anda? Saya seorang pemula dengan komputasi terdistribusi (tetapi gali apa yang Anda katakan), tetapi saya benar-benar ingin masuk ke dalamnya tahun depan (saya juga mendengar banyak layanan mikro, yang saya yakini setara dengan ini?) .

Yang harus dipahami orang adalah bahwa dalam hal komputasi terdistribusi, tidak ada perbedaan antara teknologi klien dan server.

Poin yang sangat bagus. Pada titik ini, ini semua tentang di mana teknologi di-host. Artinya, Anda benar-benar dibatasi oleh sejumlah teknologi yang Anda coba "distribusikan" menurut saya (dan sekali lagi saya bukan ahli dalam hal ini). Host yang paling ada di mana-mana (atau tersedia) adalah, aplikasi yang didistribusikan/diakses dengan lebih baik. Annnnnd.... Saya pikir Anda tahu ke mana saya akan pergi dengan itu. :P

Bagaimanapun, rasanya kita semua melingkari kesepakatan tentang _sesuatu_ di sini dengan diskusi ini dan itu adalah perubahan/pencapaian yang disambut baik bagi saya. ;)

@galvesribeiro

perlu diingat bahwa UWP dan .Net Core (setidaknya sekarang) tidak berada di bawah moniker yang sama, yang berarti bahwa meskipun mereka berbagi API tingkat rendah yang sama, memiliki permukaan API yang sama (dan .Net Core adalah OSS sedangkan UWP tidak) , mereka bukan hal yang sama dan tidak kompatibel. Dengan kata lain, Anda tidak dapat menambahkan rakitan .Net Core ke rakitan UWP. Perbedaan itu (IMHO) pada akhirnya akan hilang tetapi untuk saat ini, mereka masih ada ...

Lihatlah PR dotnet/corefx#5760 ini, saya harap ini menjelaskan beberapa hal.

Sisi .NET dari UWP _is_ .NET Core. Namun, .NET Core menyediakan beberapa runtime. UWP menggunakan runtime berbasis AOT, jadi fungsionalitas tertentu yang memerlukan JIT tidak didukung (seperti LCG atau RefEmit). Namun, mereka berbagi rakitan yang sama dan (bergerak maju) paket NuGet yang sama. Kami secara khusus merancang tumpukan untuk memungkinkan rakitan referensi silang (dan paket) dari UWP dan ASP.NET Core.

Tentu saja, ada alat VS di atas ini yang disebut perpustakaan kelas portabel (PCL) yang mencoba membantu Anda membangun perpustakaan yang akan bekerja pada satu set platform. Ada banyak pilihan yang dapat Anda buat dalam dialog penargetan PCL yang semuanya menghasilkan biner Anda yang kompatibel dengan .NET Core. Namun, karena portabilitas dalam VS ditentukan dengan melihat platform, Anda tidak akan dapat mereferensikan PCL dari aplikasi UWP kecuali PCL tersebut mengatakan bahwa ia dapat menargetkan UWP. Perilaku ini dirancang karena idenya adalah bahwa perkakas PCL membantu Anda untuk tidak secara tidak sengaja menggunakan fungsionalitas yang tidak didukung di mana pun Anda perlu menjalankannya. Sebaliknya, Anda hanya dapat mereferensikan PCL dari platform yang katanya ditargetkan.

Karena Anda secara eksplisit menyebut moniker, mari kita bicarakan ini sebentar juga. Desain moniker (TFM) adalah bahwa ia mewakili keseluruhan luas permukaan. Dalam perkakas kami ada dua moniker:

• TargetPlatformMonikers (TPM)
• TargetFrameworkMoniker (TFM)

Pikirkan TFM sebagai mengidentifikasi totalitas area permukaan yang dikelola, dalam kotak, sementara TPM mewakili OS yang mendasarinya, yaitu set API yang disediakan OS.

Karena kami merancang .NET Core agar portabel untuk beberapa platform, TFM tradisional tidak terlalu masuk akal. Makanya ada konsep baru yang disebut Standard Platform , yang sebelumnya disebut generasi.

Apakah ini membantu?

Namun, mereka berbagi rakitan yang sama dan (bergerak maju) paket NuGet yang sama.

Sebagian besar rakitan memiliki DLL implementasi BINARY yang sama untuk aplikasi 'netcore50' NuGet target (WIndows UWP Store App) dan 'dnxcore50' NuGet Target (ASP.NET v5 / ASP.NET Core 1.0).

Namun, beberapa paket NuGet seperti kebanyakan paket library System.Net.* memiliki implementasi yang berbeda untuk target 'netcore50' vs. target 'dnxcore50'. Sebagai contoh, library System.Net.Http dengan 'netcore50' menggunakan implementasi WinRT Windows.Web.Http di bawahnya. Implementasi 'dnxcore50' menggunakan sesuatu yang lain (WinHTTP asli).

Namun, beberapa paket NuGet seperti banyak paket perpustakaan System.Net.* memiliki implementasi yang berbeda untuk target 'netcore50' vs. target 'dnxcore50'

Ya, saya seharusnya menyebutkan itu. Cara saya melihat ini adalah bahwa paket NuGet menyediakan wadah yang memungkinkan produsen untuk menyediakan implementasi yang berbeda untuk lingkungan eksekusi yang berbeda sementara konsumen tidak perlu mengetahuinya. Dalam pengertian itu, paket NuGet adalah rakitan baru.

Terima kasih @terrajobst dan @davidsh telah berbagi penjelasan dan masalah referensi yang lebih dalam ini, tetapi, apa yang salah dengan apa yang saya katakan bahwa "1 perakitan dari satu platform tidak dapat direferensikan oleh yang lain"?

Cara saya melihat ini adalah bahwa paket NuGet menyediakan wadah yang memungkinkan produsen untuk menyediakan implementasi yang berbeda untuk lingkungan eksekusi yang berbeda sementara konsumen tidak perlu mengetahuinya. Dalam pengertian itu, paket NuGet adalah rakitan baru.

Konsep ini sebenarnya bukan hal baru... Orang-orang sudah membuat satu Paket Nuget yang tidak lebih dari referensi ke sekumpulan paket lain - yang disebut "paket meta". Ada beberapa cara untuk membuat PCL berfungsi di banyak platform. Yang paling terkenal digunakan oleh banyak perpustakaan populer (seperti Json.Net Newtonsoft) adalah Bait and Switch di mana Anda memiliki nuget yang memiliki antarmuka publik (permukaan API) dan satu rakitan untuk setiap platform tertentu (implementasi nyata dari permukaan API) yang bahkan dapat memiliki ketergantungan yang berbeda satu sama lain dan saat runtime, perakitan yang benar untuk platform itu akan dipilih. Perbedaannya sekarang adalah bahwa alih-alih memiliki beberapa nuget "di dalam" satu wadah nuget di mana semua harus berada di platform yang sama atau 1 rakitan antarmuka yang hanya digunakan oleh pengembangan dan yang akan Beralih ke yang spesifik saat runtime, kami memiliki campuran itu! 1 nuget yang merupakan wadah dan pada saat yang sama antarmuka publik untuk semua nuget khusus platform yang tertaut dengannya.

Saya pikir kita berbicara hal yang sama, saya hanya mengekspresikan diri saya dengan buruk di tempat pertama :senyum:

Omong-omong, kembali ke WF... Saya pikir terkenal bahwa orang ingin porting ke WF bukan hanya "karena keren" untuk menjalankannya di linux atau di Nano Server. Orang ingin menggunakannya dengan cara yang ringan pada klien juga.

Sekali lagi saya rasa sudah cukup banyak masyarakat yang berkeinginan untuk mewujudkan pelabuhan ini...

PS: Bagi mereka yang tertarik dengan komputasi terdistribusi (yang asli bukan kisah klien offline) silakan lihat proyek kami yang lain Orleans yang sebenarnya merupakan kasus penggunaan yang baik untuk WF di .Net Core dan yang memberdayakan layanan Microsoft besar saat ini seperti Skype, Halo5, dan yang secara pribadi saya gunakan sebagai teknologi inti platform pemrosesan transaksi keuangan saya yang memproses miliaran transaksi secara terdistribusi...

@galvesribeiro

apa yang salah dengan apa yang saya katakan bahwa "1 perakitan dari satu platform tidak dapat direferensikan oleh yang lain"?

Bukan karena pernyataan Anda salah; hanya saja itu juga tidak benar :smile: Biasanya, saya bukan tipe orang yang suka rewel, tapi yang membuat saya kesal adalah bagian ini:

Dengan kata lain, Anda tidak dapat menambahkan rakitan .Net Core ke rakitan UWP.

Saya ingin menghindari kesan bahwa UWP dan .NET Core adalah platform .NET yang berbeda, seperti .NET Framework dan Silverlight. Kami secara khusus merancang .NET Core agar Anda dapat membuat rakitan yang berfungsi di semua platform. Misalnya, System.Collections.Immutable dan hampir semua Roslyn adalah rakitan .NET Core, mereka juga akan berfungsi dengan baik di UWP.

Jadi untuk mengulang: tujuan kami adalah untuk membangun sebuah platform di mana komponen sederhana berbasis MSIL benar-benar dapat menggunakan biner yang sama pada semua platform berbasis .NET Core. Dalam kasus di mana itu tidak mungkin, misalnya, karena dependensi asli atau implementasi yang berbeda, kami melakukan persis seperti yang dijelaskan Paul Betts dengan sangat fasih sebagai Umpan dan Switch PCLs : luas permukaan portabel, berbagai implementasi per platform, dan NuGet sebagai wadah dan pemilih.

Di dunia .NET Core, perpustakaan System tidak terlalu istimewa. Siapa saja dapat menggunakan teknik yang sama untuk memastikan bahwa sebagian besar konsumen tidak perlu mengotori basis kode mereka dengan arahan #if .

Saya pikir kita berbicara hal yang sama, saya hanya mengekspresikan diri saya dengan buruk di tempat pertama :senyum:

Saya pikir kami telah menciptakan dunia di mana agak terlalu mudah untuk membingungkan orang -- yang jelas termasuk kami :smile: Itu sebabnya saya berusaha keras untuk menjelaskan secara tepat bagaimana .NET Core dibangun dan masalah apa yang kami coba pecahkan.

Ya kamu benar. Kesan adalah apa yang penting.

Saya harap suatu hari nanti kita memanggil .Net Core di UWP juga jadi ini akan berakhir ... Jadi, kita masih membutuhkan system.xaml

Sementara terkait, saya pikir System.Xaml adalah komponen terpisah yang menambah nilai dengan sendirinya. Saya telah mengajukan dotnet/corefx#5766 untuk melacak ini secara terpisah.

Terima kasih Michael-DST

Juga, saya ingin tahu apa pendapat Anda tentang Azure Mobile Services (https://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-get-started-offline-data/) dan apakah Anda telah mempertimbangkan untuk menggunakannya dalam cerita offline Anda?

Pertanyaan yang bagus. Ini mendorong sedikit pelajaran sejarah tentang pengalaman perusahaan kami dengan komputasi terdistribusi alias aplikasi yang kadang-kadang terhubung dan bagaimana hal itu terkait dengan Layanan Seluler Azure, dan komputasi terdistribusi dengan teknologi Microsoft.

Jika orang belum melihat situs web yang disebutkan di atas, saya sangat menyarankan untuk melihatnya. Ini memiliki video yang bagus tentang Layanan Seluler Azure.

Sekitar 8 tahun yang lalu kami membuat aplikasi untuk platform Windows Phone asli. Sekolah lama dengan .Net Compact Framework. Orang mungkin mengejeknya, tetapi pada beberapa poin penting platform ini lebih maju daripada platform UWP saat ini dalam hal teknologi yang kadang-kadang terhubung. Meskipun, tampaknya UWP sedang mengejar. Kunci keberhasilan aplikasi yang terkadang terhubung pada platform tersebut adalah:

1) Implementasi Database SQL Lengkap (SQL Server CE)
2) Implementasi Sync Framework antara SQL Server (backend), dan SQL Server CE (perangkat seluler). Ini adalah Sync Framework versi 1.

Aplikasi ini berhasil. Kami menulis lapisan data yang berada di atas SQL CE, dan SQL Server yang disebarkan ke server, dan disebarkan ke perangkat. Ini hampir memaksimalkan memori tetapi berhasil. Pekerja lapangan dapat melakukan pengambilan data di lapangan, dan data disinkronkan kembali ke database pusat.

Kami ngeri ketika Windows Phone 7 dirilis karena ada masalah krusial: semua database yang ada di pasaran adalah database non-SQL. Mereka sebagian besar diimplementasikan dengan LINQ. Ini tidak kompatibel dengan lapisan data kami, dan EF tidak ada untuk Windows Phone 7. Jadi, kami tidak dapat membangun kerangka kerja offline sesekali untuk Windows Phone 7 meskipun kami telah mampu membangun solusi lengkap untuk yang asli platform Windows Phone.

Silverlight adalah pengubah permainan. Sekali lagi, kami menemukan database SQL lengkap. Namun, Microsoft belum menerapkan kerangka sinkronisasi untuk Silverlight, atau untuk database inline yang dimaksud. Jadi, kami mulai menulis kerangka sinkronisasi kami sendiri yang dimodelkan setelah kerangka kerja sinkronisasi Microsoft. Kerangka kerja sinkronisasi Microsoft didasarkan pada stempel waktu. Inilah yang kami terapkan dalam kerangka sinkronisasi kami. Sekali lagi, kami sukses total dengan Silverlight. Pekerja lapangan dapat membawa tablet Windows ke lapangan, mengambil data, dan kemudian menyinkronkannya kembali ke database pusat. Masalahnya adalah ini tidak pernah tersedia untuk ponsel. Platform database tidak ada untuk Windows Phone 7.

Seperti yang telah saya sebutkan sebelumnya, kami ingin menerapkan logika bisnis dengan WF, tetapi Silverlight ditinggalkan dan tidak ada yang berbicara tentang kemungkinan porting WF ke Silverlight.

Akhirnya kita sampai di UWP. Pembungkus untuk SQLite telah ditulis untuk UWP, dan dengan beberapa peretasan pada pembungkus, saya dapat memperluas antarmuka dengan SQLite untuk memungkinkan kita bekerja kembali dengan database SQL lengkap. Itu berarti bahwa lapisan data kami kompatibel dengannya. Lapisan data kami, dan lapisan sinkronisasi sekarang berfungsi di .Net, Silverlight, dan UWP, dengan SQL Server, SQLite, dan platform database lain yang tidak disebutkan namanya.

Hari ini adalah pertama kalinya saya melihat sinkronisasi terjadi dengan teknologi murni Microsoft berkat Michael-DST. Pada dasarnya, saya dapat mengatakan bahwa sinkronisasi Layanan Seluler Azure hanyalah Microsoft Sync Framework yang diganti namanya. Ini memiliki sedikit antarmuka API yang berbeda, tetapi dasar-dasarnya sama dengan kerangka kerja sinkronisasi Windows Phone asli yang kami gunakan untuk menyinkronkan agar berfungsi sekitar 8 tahun yang lalu. Saya dapat melihat bahwa ia bahkan menggunakan dua bidang stempel waktu yang sama untuk melacak perubahan data. Ini diperkenalkan ke SQL Server sebagai fitur inti di SQL Server 2008. Kerangka kerja sinkronisasi kami bekerja kurang lebih dengan cara yang sama seperti kerangka kerja sinkronisasi Microsoft.

Jadi, untuk menjawab pertanyaan Michael, saya akan menyelidiki teknologi ini. Saya akan melihat apakah itu dapat menggantikan kerangka sinkronisasi kami. Saya ingin membuangnya dan membiarkan orang lain memeliharanya. Melihat bahwa mereka telah menyebutkan bahwa itu akan mendukung SQLite, kedengarannya menjanjikan karena sepertinya kami akan dapat meretas pembungkus SQLite untuk terus menggunakan database SQL lengkap, dan oleh karena itu dapat terus menggunakan lapisan data kami. Jika itu masalahnya, itu berarti 5+ tahun kode kerangka kerja sinkronisasi akan langsung masuk ke tempat sampah.

Bagaimanapun, intinya adalah, Microsoft sepertinya mengakui sekali lagi bahwa komputasi terdistribusi itu penting. Jika penting, WF harus porting ke UWP. UWP adalah masa depan, dan karena itu juga masa depan komputasi terdistribusi dengan teknologi Microsoft. Masa depan teknologi terdistribusi membutuhkan WF.

Sementara terkait, menurut saya System.Xaml adalah komponen tersendiri yang menambah nilai dengan sendirinya. Saya telah mengajukan dotnet/corefx#5766 untuk melacak ini secara terpisah.

Terima kasih banyak @terrajobst! Saya tidak setuju dengan semua yang Anda posting online/twitter tapi saya penggemar berat bagaimana Anda memfasilitasi dialog dan komunikasi di antara pengembang/komunitas dan saya akan selalu setuju dengan itu. :) Ini sangat berarti bagi saya pribadi karena sepertinya lebih dari setahun skating menanjak untuk mendapatkan apa pun dari MSFT (dan ya, saya menyadari itu bukan komitmen tetapi pada titik ini semuanya berarti).

Jadi, untuk menjawab pertanyaan Michael, saya akan menyelidiki teknologi ini.

@MelbourneDeveloper yang luar biasa , senang membantu! Saya merasa Azure benar-benar memiliki pegangan yang kuat di grup mereka. Seiring dengan VSO/VSTS mereka benar-benar mendengarkan pengembang mereka dan mendapatkan *_lot *_done. Faktanya, ini tampaknya menjadi kasus dengan setiap grup di MSFT _kecuali_ untuk grup UWP, yang tampaknya tidak banyak membantu dan bahkan tampaknya tidak memahami teknologi mereka sendiri (dan mari kita bahkan tidak masuk ke definisi mereka tentang "Xaml").

Saat ini kami menggunakan WF untuk beberapa layanan inti kami dan kami bahkan sekarang memperluas penggunaan kami lebih lanjut karena kami memiliki pengalaman hebat dengan Workflow dan memiliki logika bisnis kami dalam format visual yang mudah dipahami.

Seperti yang dikatakan @MelbourneDeveloper

Bagaimanapun, intinya adalah, Microsoft sepertinya mengakui sekali lagi bahwa komputasi terdistribusi itu penting. Jika penting, WF harus porting ke UWP. UWP adalah masa depan, dan karena itu juga masa depan komputasi terdistribusi dengan teknologi Microsoft. Masa depan teknologi terdistribusi membutuhkan WF.

Teknologi WF kurang dihargai oleh banyak pengembang .NET karena mereka mungkin belum melihat nilainya pada saat itu (dulu saya tidak melihatnya, tetapi sekarang saya adalah penggemar berat WF karena saya mengerti betapa kuatnya teknologi ini. be!) tetapi di era komputasi terdistribusi, sekarang lebih dari sebelumnya WF benar-benar dapat bersinar dan saya berharap pada akhirnya akan di-porting.

Saya pikir ada sedikit ruang untuk perbedaan pendapat tentang topik ini.

Dapat dikatakan bahwa pemrograman visual deklaratif seperti WF tidak seefisien penulisan kode. Saya bahkan cenderung setuju. Namun, memiliki WF sebagai alat dalam toolkit untuk melengkapi platform yang dapat dikonfigurasi tentu akan menjadi hal yang baik. Pelanggan *_DO *_ ingin melihat alur kerja visual, dan memberdayakan pelanggan untuk memodifikasi alur kerja mereka sendiri tentu merupakan hal yang baik.

Saatnya menyelesaikan ini!

Saya pikir ada sedikit ruang untuk perbedaan pendapat tentang topik ini.

Haha @MelbourneDeveloper apakah Anda pernah bertemu pengembang perangkat lunak? Atau benarkah, ras manusia? ;P

Saya pribadi merasa desainer visual WF dan alat yang ada telah merugikan XAML, karena file yang terlalu bertele-tele yang dihasilkan untuk alur kerja MSBuild benar-benar memberi Xaml nama yang buruk dalam hal ini. Itulah yang benar-benar diasosiasikan pengembang dengan Xaml ("file kembung") dan telah membantu menelurkan penerbangan ke file JSON "lebih sederhana" dan file build "berskrip". Belum lagi, seluruh proses yang misterius, sulit, dan rumit (saya masih belum bisa membuatnya sepenuhnya bekerja di proyek saya) bahkan membuat proyek untuk melihat file Xaml untuk memulai.

Padahal, sebenarnya, cara kerja WF adalah "cara yang benar" selama ini. Penyakitnya yang sebenarnya ada di perkakasnya.

Dengan demikian, jika alat perancang sedikit lebih ramah (dan mungkin melakukan pekerjaan yang lebih baik dengan membuat file bersambung dengan cara yang lebih terorganisir/terpisah), ini tidak akan menjadi masalah (atau kurang masalah).

Saya adalah penggemar berat dari apa yang menjadi tujuan WF, tetapi itu perlu diperketat sedikit dan perkakasnya ditangani dan ditingkatkan. Sungguh, pada akhirnya, sebuah teknologi hanya sebagus alat pendukungnya -- desainer dan semuanya. Semakin baik alat/desainer, semakin mudah diakses/dipahami semakin baik teknologinya, semakin baik adopsinya.

Saya pasti ingin melihat WF menjadi lebih seperti EF dan dapat diakses dalam skenario .NET apa pun, dan alat ditingkatkan untuk memfasilitasi hal ini.

Pemahaman saya adalah bahwa salah satu visi asli untuk WF adalah untuk mendukung beberapa jenis file untuk alur kerja, bukan hanya XAML. Secara keseluruhan selain beberapa kebiasaan di sana-sini, saya tidak benar-benar memiliki masalah dengan XAML. Hanya butuh beberapa saat untuk membuat kepala saya melilitnya dan menjadi nyaman mengeditnya secara manual bila perlu yang saya yakin menghadirkan penghalang untuk masuk bagi banyak orang. Jadi sementara saya pikir XAML perlu dipertahankan untuk kompatibilitas mundur (setidaknya dalam jangka pendek), saya sangat ingin melihat jenis file alur kerja lain mulai berkembang (seperti JSON). Saya bisa melihat beberapa kontribusi komunitas keren di depan itu! (Alur kerja ditulis di Whitespace siapa pun? :senyum: )

@Michael-DST Saya sepenuhnya setuju dengan Anda. Baru-baru ini tim saya dan saya sedang meninjau suka/tidak suka/keinginan untuk Workflow dan hampir semua yang ingin kami lihat ditingkatkan ada di sekitar desainer dan belum tentu inti WF itu sendiri. Saya pikir Microsoft telah melakukan pekerjaan yang fantastis dengan apa yang telah mereka bangun di WF dan saya pikir beberapa perbaikan dan beberapa penginjilan kita bisa melihat kehidupan baru dihembuskan ke dalamnya. Saya pikir itu adalah alat yang PERLU ada dan saya mendapatkan banyak nilai dari WF dan saya ingin melihatnya terus untuk waktu yang PANJANG.

Perusahaan kami telah melakukan investasi yang cukup besar di WF dan sekarang menjadi teknologi penting bagi bisnis kami. Mengingat komitmen terbaru MIcrosoft untuk open source dan .NET Core, porting WF tampaknya merupakan langkah terbaik berikutnya untuk teknologi ini. Kami membutuhkan ini!

Alur kerja telah menjadi alat dengan banyak manfaat bagi kami sebagai pengembang dalam organisasi kami. Jika Microsoft akan menyatukan kerangka kerjanya, itu akan membuat hidup kita lebih mudah untuk memiliki WF dalam kerangka inti.

Haha @MelbourneDeveloper apakah Anda pernah bertemu pengembang perangkat lunak? Atau benarkah, ras manusia? ;P

Haha, saya seorang pengembang perangkat lunak. Ras manusia tidak penting bagi saya.

Michael-DST

Saya pribadi merasa desainer visual WF dan alat yang ada telah merugikan XAML, karena file yang terlalu bertele-tele yang dihasilkan untuk alur kerja MSBuild benar-benar memberi Xaml nama yang buruk dalam hal ini. Itulah yang benar-benar diasosiasikan pengembang dengan Xaml ("file kembung") dan telah membantu menelurkan penerbangan ke file JSON "lebih sederhana" dan file build "berskrip"

Kamu mungkin benar. Tapi, saya pribadi berpikir bahwa ada terlalu banyak penekanan pada Xaml di sini. Ketika saya mencoba WF (sebelum menyadari bahwa kami tidak dapat menggunakannya karena tidak ada di Silverlight), saya membuat aplikasi WPF. Aplikasi itu terhubung ke layanan WCF kami dan menyimpan Xaml untuk WF dalam sebuah tabel di database kami. Ini adalah bagaimana kami mencapai pengkodean lunak WF.

Tapi, Xaml dimanipulasi seluruhnya dengan menggunakan alat desainer WPF WF. Pengguna tidak pernah melihat Xaml. Xaml tidak relevan bagi pengguna. Anggap saja seperti markup HTML di belakang halaman web. Ini bisa sangat berbelit-belit, tetapi selama pengguna akhir menyukai halaman web, itu tidak masalah. Saya pikir jika Anda memanipulasi Xaml secara langsung sebagai teks, Anda sebenarnya tidak menggunakan WF dengan cara yang dimaksudkan ...

Ras manusia tidak penting bagi saya.

Bagus. B)

Tapi, Xaml dimanipulasi seluruhnya dengan menggunakan alat desainer WPF WF. Pengguna tidak pernah melihat Xaml.

Benar. Ini persis bagaimana MSBuild bekerja dan pengguna akhir membencinya karena seberapa besar file yang dihasilkannya (terutama ketika Anda membandingkannya dengan file "skrip" sederhana yang sangat mendasar dan linier). Saya setuju dengan Anda bahwa ini adalah masalah perkakas/perancang, dan saya juga akan mengatakan bahwa perkakas/perancang dapat sangat ditingkatkan dengan WF.

Contoh kasus: posting blog dan salin/tempel kode (atau sebenarnya, salin/tempel _workflow_ :smile :). Ada beberapa kali di mana saya telah melakukan beberapa pencarian online untuk WF, dan menemukan posting blog yang bagus yang menunjukkan beberapa langkah yang harus dilakukan untuk memasukkan komponen alur kerja (kemungkinan besar untuk MSBuild). Nah, untuk melakukan ini, pada dasarnya saya harus menduplikasi banyak langkah. Biasanya pada posting blog coding, kode tersedia untuk copy/paste sederhana. Tidak demikian dengan WF. Anda harus melakukannya selangkah demi selangkah sampai terlihat di mesin Anda persis seperti yang terlihat di posting blog. Ini jelas sangat membosankan dan rawan kesalahan (dan benar-benar terasa seperti mengambil langkah mundur, dari perspektif C#).

Masalah lain yang kami hadapi dengan MSBuild adalah ukuran file, tidak hanya dalam byte tetapi juga dalam perancang itu sendiri: sangat sulit untuk menavigasi alur kerja yang kompleks. Ini sepertinya sesuatu yang harus diperhitungkan dengan cara yang sangat komprehensif (dan intuitif).

Akhirnya, saya ingin menyelesaikan masalah ukuran file. Saya tidak yakin apakah Anda mengetahui WordML dan/atau MSFT Frontpage sejak dulu. Tapi itu akan membuat HTML paling membengkak di dunia. Meskipun pengguna umumnya tidak meletakkan tangan mereka di markup yang dihasilkan, mereka suka meletakkan hidung mereka di dalamnya untuk merasakan seberapa "bersih" itu. Hal pertama yang mereka lihat adalah ukuran pada disk, dan kemudian membuka file untuk melihat bagaimana formatnya, dll.

Sekali lagi, saya setuju bahwa bagaimana file-file ini dibuat benar-benar merupakan masalah perkakas/perancang, tetapi pengembang memang penasaran dan ini harus diperhitungkan juga. :)

Ya. Semua poin bagus. Saya pikir perancang perlu dibersihkan agar tidak membuat Xaml yang bertele-tele seperti itu.

Siapa yang sebenarnya memiliki kekuatan untuk membuat keputusan apakah WF akan di-porting ke .Net Core, atau UWP? Apakah ini hanya kasus beberapa pengembang di suatu tempat yang menulis kode, dan kemudian mengirimkan tambalan itu ke administrator repo basis kode .Net Core? Apa politik di sekitar ini? Bukankah ada tim inti pengembang yang dipengaruhi oleh Microsoft? Apakah karyawan Microsoft? Saya masih belum benar-benar mendapatkan seluruh pengaturan. Siapa yang harus kita yakinkan?

Sebenarnya @MelbourneDeveloper hanya dengan berpartisipasi di utas ini, Anda membantu membuat argumen. Ada tim di MS yang memiliki WF, saat ini milik saya, tetapi kami tidak membuat keputusan untuk merilis WF di Core. Kita harus membuat kasus bisnis. Diskusi di sini membantu saya melakukan itu.

Ini benar-benar mengesankan bagaimana orang-orang mulai 2016 mendukung utas ini :)

Juga https://github.com/dotnet/corefx/issues/5766 dari @terrajobst menjadi jauh lebih sibuk akhir-akhir ini :)

@dmetzgar Saya harap Anda mendapatkan umpan balik sebanyak yang Anda bisa/butuhkan dari diskusi itu sehingga Anda memiliki cukup banyak kasus untuk OSS itu.

Saya cukup yakin jika repo dotnet/WF dibuka jika ditambahkan ke corefx, orang pasti akan mengembangkannya dengan sangat cepat.

Sebenarnya @MelbourneDeveloper hanya dengan berpartisipasi di utas ini, Anda membantu membuat argumen

Itu membuatku merasa hangat dan kabur.

Just FYI dmetzgar - Saya sangat senang untuk mendokumentasikan pengalaman kami dan mengajukan kasus persuasif untuk membantu membangun bukti untuk kasus bisnis pelabuhan.

Saya telah mendalami teknologi Microsoft sejak tahun 2000. Saya telah menyaksikan semua teknologi utama yang relevan dengan utas ini berkembang dan menghilang. Sementara saya tenggelam dalam teknologi Microsoft, saya masih melihatnya dari sudut pandang objektif dan berpikir bahwa WF adalah salah satu teknologi kunci yang akan membantu untuk mengembangkan bisnis/pemerintah membeli ke .Net Core, dan platform Windows UWP.

Tidak ada yang membuat pelanggan lebih bersemangat daripada diagram alur! Tidak!

Saya juga harus mengatakan bahwa teknologi Microsoft berada di puncak sesuatu yang besar.

Selama bertahun-tahun, saya telah menyaksikan teknologi bagus naik, dan turun. Alasan utama mengapa teknologi jatuh di pinggir jalan adalah karena lanskap perangkat yang berubah. Di masa lalu, strateginya adalah membangun platform untuk setiap keluarga perangkat. Tidak ada yang salah dengan pendekatan ini. Tapi, itu berarti porting teknologi antar platform. Itu berat, dan tidak jarang teknologi jatuh di pinggir jalan karena platform tiba-tiba menjadi tidak enak (batuk - Silverlight).

Microsoft sekarang berada di belakang .Net Core, dan UWP. Sementara saya berpikir bahwa kedua platform ini harus menjadi satu dan sama, saya masih sangat optimis bahwa ketika teknologi tertentu dibuat atau dipelihara, itu akan bekerja di banyak platform. Xamarin semakin meningkatkan optimisme saya.

Tampaknya untuk pertama kalinya dalam sejarah, kita mungkin menatap kosong pada kumpulan teknologi yang bekerja di berbagai CPU, dan lingkungan operasi yang sangat luas. Jika Microsoft mendorong ini dengan keras, WF akan menjadi bagian dari itu.

Itu membuatku merasa hangat dan kabur.

:+1: pada @MelbourneDeveloper dan @dmetzgar itu. Ini adalah jenis keterlibatan dan dialog yang saya pribadi suka lihat dari MSFT, daripada permohonan yang diabaikan dan panggilan tak terjawab dari basisnya yang penuh gairah ( itu hanya kejam, itu kejam, man ).

Di samping acak di sini: menurut saya NodeJS menjadi satu-satunya kasus/ancaman bisnis yang Anda butuhkan, artikel acak yang saya temukan belakangan ini .

Akhirnya, menurut pendapat saya "jika .NET Core cukup baik untuk EF, itu harus cukup baik untuk WF" ... jika WF memang pergi ke .NET Core, apakah ada cara untuk mengintegrasikannya dengan EF sehingga EF berfungsi sebagai backendnya entah bagaimana? Itu adalah kasus yang menarik di sana, jika demikian. Jika tidak, masih layak untuk dipikirkan (lihat: diskusi/dialog/brainstorming/dll). :)

Akhirnya, menurut pendapat saya "jika .NET Core cukup baik untuk EF, itu harus cukup baik untuk WF" ... jika WF memang pergi ke .NET Core, apakah ada cara untuk mengintegrasikannya dengan EF sehingga EF berfungsi sebagai backendnya entah bagaimana? Itu adalah kasus yang menarik di sana, jika demikian. Jika tidak, masih layak untuk dipikirkan (lihat: diskusi/dialog/brainstorming/dll). :)

Itu pemikiran yang menarik. Apa kasus penggunaan Anda untuk mengintegrasikan EF dan WF? Bisakah Anda memberi contoh? Apakah ini untuk ketekunan?

Bisakah Anda memberi contoh? Apakah ini untuk ketekunan?

Setidaknya itu bisa digunakan sebagai model pendukung yang alur kerja bekerja dengan dalam domain aplikasi. Paling-paling itu benar-benar bisa berfungsi sebagai mekanisme penyimpanan untuk alur kerja itu sendiri (tapi saya tidak akan merekomendasikan ini - Xaml jauh lebih cocok untuk ini).

Saya dapat melihat paradigma WPF-esque di sini di mana Anda dapat mendefinisikan alur kerja di Xaml dan kemudian mengikatnya ke properti elemen alur kerja, menggunakan data dari entitas model yang ditentukan, dimodifikasi, dan disimpan di EF.

Memang, pengalaman saya dengan WF terbatas di sini (mereka yang memiliki pengalaman luas mungkin ikut campur di sini). Tapi, jika berhasil untuk WPF, itu bisa bekerja untuk WF. Sebenarnya, saya menggunakan paradigma yang sama (yaitu, pengembangan berbasis WPF-esque Xaml) untuk aplikasi konsol yang saya gunakan untuk proyek saya saat ini . Memang, itu tidak menggunakan pengikatan data seperti yang saya sarankan (belum), tetapi itu mudah diproduksi, seperti yang ditunjukkan OmniXaml/Perspex kepada kita. :kacamata hitam:

@Michael-DST Saya lebih suka menghindari terlalu banyak integrasi. WF harus menjadi paket NuGet yang berdiri sendiri. Mengintegrasikan WF dan EF bersama-sama harus menjadi proyek yang terpisah. Mulai menggabungkan terlalu banyak hal dan Anda bisa berakhir dengan Oslo .

Saya setuju dengan @dmetzgar :+1:

EF adalah penyedia penyimpanan/persistensi. Itu harus berupa paket NuGet diff dan disuntikkan saat runtime. WF hanya harus menyediakan satu set antarmuka dan itu saja.

Kami melakukannya dengan cukup baik dengan Penyedia Penyimpanan di Microsoft Orleans.

@dmetzgar (dan @galvesribeiro) setuju. Saya tidak menyarankan integrasi yang diperlukan, tetapi kemungkinan penggunaan kasus/proposisi nilai. (Lihat: brainstorming. :senyum :)

Apa kasus penggunaan Anda untuk mengintegrasikan EF dan WF? Bisakah Anda memberi contoh? Apakah ini untuk ketekunan?

Saya ingin berpadu dengan yang satu ini! Sekali lagi, ini berkaitan dengan pengalaman perusahaan saya. Pada akhirnya, kami ingin menggunakan EF untuk persistensi data dalam database inline seperti SQLite untuk aplikasi yang terkadang terhubung. Pada akhirnya, UWP/.Net Core akan memiliki EF, SQLite, Azure Mobile Services, dan WF yang semuanya bekerja secara harmonis. Saya akan mengulangi sendiri jika saya menjelaskan mengapa kami ingin ini terjadi, tetapi saya dapat menjelaskan mengapa EF dan WF akan bekerja sama dengan baik. Meskipun, kami telah menemukan satu batasan di EF yang telah menghentikan kami di masa lalu - dan itulah alasan lain kami harus membuat ORM kami sendiri.

Kami memiliki sistem di mana akses data memicu peristiwa seperti "BeforeLoad", "BeforeSave", dll. Kami meninggalkan kait dalam peristiwa ini sehingga ketika jenis catatan tertentu disimpan, kami dapat menempatkan logika bisnis khusus di sana. Saat ini, kami telah melakukan ini dengan menautkan ke DLL logika bisnis kustom. Setiap pelanggan memiliki rangkaian acara khusus mereka sendiri. Kami juga menerapkan panggilan ke WF. Jadi, misalnya pada event BeforeSave, kita bisa melakukan validasi dengan melakukan panggilan ke WF yang memvalidasi field wajib. Dengan cara ini, logika validasi diberi kode lunak untuk pelanggan tertentu. Dalam jangka panjang, kami harus meninggalkan WF untuk tujuan ini karena tidak pernah diterapkan di Silverlight, tetapi akan lebih baik untuk memilikinya di sana sebagai opsi.

Bagaimanapun, saya merasa bahwa ini adalah persyaratan yang cukup universal untuk aplikasi apa pun. Secara umum, Anda akan selalu menginginkan lapisan tepat di atas lapisan data yang memvalidasi data yang masuk ke database, atau melakukan logika bisnis umum. Misalnya, kami memiliki logika bisnis untuk beberapa pelanggan yang mengirim email saat catatan jenis tertentu ditambahkan ke database. Ini bisa dilakukan di WF. Akan sangat bagus untuk menerapkan sesuatu seperti ini dengan EF dan WF yang bekerja secara harmonis.

Sayangnya, saya tidak pernah menemukan cara untuk melakukan ini dengan EF bahkan di .Net. Masalah yang saya temukan, adalah EF tidak memberi tahu Anda kapan catatan dari jenis tertentu akan disimpan. Jadi misalnya, jika Anda membuat objek "Tugas" baru dan mempertahankannya ke database dengan EF, tidak ada peristiwa yang dipicu oleh EF yang memiliki sesuatu seperti "RecordInserted". Ini akan memungkinkan kami untuk membangun kait ke akses data sehingga bisnis kustom dapat dimasukkan. Jadi, ini adalah salah satu alasan kami tidak pernah pergi dengan EF. Sangat disayangkan karena membangun ORM kami sendiri membutuhkan waktu bertahun-tahun untuk disempurnakan.

Berbicara tentang "kasus bisnis" NodeJS: Bagaimana NodeJS Mendominasi .NET dalam 3 Bagan Mudah

Sabar menunggu repo GitHub itu. Baru menyadari bahwa WF belum di-porting ke .NET Core yang cukup banyak membunuh viabilitasnya untuk produk kami. Yang memalukan karena kami menyukai perubahan yang datang ke inti ASP.NET dan seluruh lintas platform, ramping, ide modular dari .NET Core tetapi kami membutuhkan WF karena ini adalah dasar dari seluruh produk kami.

Saya kira saya sejujurnya tidak terlalu peduli apakah ini WWF, atau jika ini adalah mesin alur kerja lain yang didukung dengan baik, tetapi saya pikir untuk tujuan perpanjangan, alur kerja semacam itu bisa sangat besar.

+1

Kami menggunakan pembuatan dinamis (berdasarkan aturan eksternal yang diimpor) dan pemuatan alur kerja sebagai layanan WCF. Akan sangat bagus jika kita bisa menggunakan model seperti itu di .net core!
BTW - apa masalah mengimpor rakitan .Net lengkap? jika sebagian besar kode IL, mengapa tidak berjalan di .net core?

+1

@dmetzgar Sangat menarik untuk melihat https://github.com/dmetzgar/corewf! Dari readme, saya terkejut melihat port oleh tim WF tidak mendapatkan banyak traksi. Terutama mengingat port Powershell baru-baru ini memiliki Powershell Workflow yang akan terbatas pada kerangka kerja penuh -- Linux dan Mac jelas bukan target utama, tetapi server Nano saya kira sangat penting untuk Powershell. Disebutkan juga di sana bahwa Anda sedang menjajaki alternatif untuk XAML apakah itu termasuk implementasi Xaml lain seperti Portable.Xaml misalnya sudah mendukung Profil 259 yang kompatibel dengan CoreCLR?

@watertree Portable.Xaml dan implementasi XAML lainnya dengan dukungan .NET Core yang saya lihat sejauh ini semuanya memiliki fitur yang hilang. Mereka tidak mengimplementasikan atribut x:Class="". Ini tidak perlu untuk WPF tetapi penting untuk WF. Alur kerja XAML biasanya memiliki

PowerShell Workflow memiliki cara yang sangat bagus untuk mendefinisikan alur kerja dalam skrip. Ini jauh lebih bersih daripada menulis hal yang sama di XAML atau C#. Namun, PSWF mengubah skrip itu menjadi file XAML di belakang layar. Agar PSWF dapat bekerja di Nano, mereka harus mengganti pipeline yang ada dan runtime WF agar tidak menggunakan XAML. Dan tidak ada cukup tekanan dari pelanggan untuk memiliki PSWF di Nano.

Mengenai alternatif XAML, saya punya banyak pendapat tentang ini. Masalah saya dengan XAML adalah bahwa itu tertanam di WF. Dengan WF lama yang dirilis dalam .NET 3.5, ada lebih banyak dorongan dari tim WF untuk mengubah format apa pun yang Anda inginkan menjadi alur kerja. Mereka menggunakan contoh mengubah diagram Visio menjadi alur kerja. Tetapi ketika WF baru tiba di 4.0, semuanya terfokus pada XAML. Pernahkah Anda mencoba menulis alur kerja di XAML dengan tangan? Tidak terjadi. Lalu ada simbol debug dan status tampilan. Dan coba bandingkan satu versi XAML dengan versi lain dengan alat pembeda.

Saya benar-benar berpikir menggunakan XAML untuk mendefinisikan alur kerja harus menjadi masalah termasuk paket NuGet. Menciptakan cara lain untuk menyimpan definisi alur kerja harus didorong. Mungkin Anda membutuhkan sesuatu yang dapat dikompres dengan baik. Mungkin Anda membutuhkan keamanan dan hanya mengizinkan serangkaian aktivitas terbatas. Saya lebih suka memiliki pilihan.

Mereka tidak mengimplementasikan atribut x:Class=""

Memang, Xaml yang dikompilasi (baml?) secara mencolok tidak ada di semua rasa Xaml yang saya lihat. Saya telah memikirkan untuk menyelami ini dengan waktu luang saya sendiri, tetapi saya merasa itu akan segera tersedia dalam beberapa kapasitas, mungkin tahun depan. Juga, sistem Xaml Xamarin mendukung ini, tetapi ditutup dan tidak dapat diperluas/diakses sama sekali.

Pernahkah Anda mencoba menulis alur kerja di XAML dengan tangan? Tidak terjadi.

Benar. Ironisnya WF adalah dermawan paling komprehensif (sejauh ini) dari setiap integrasi Xaml. Untuk suatu kesalahan, mungkin. Sayang sekali bahwa Xaml dibangun untuk menjadi sangat ramah desainer, namun perkakas di sekitar WF agak menghalangi untuk skenario tulisan tangan, dan bahkan untuk desainer itu sendiri. Tampaknya mereka benar-benar bertujuan untuk menjadikannya bahasa pemrograman visual, tetapi tanpa dukungan/sumber daya yang signifikan diperlukan untuk berhasil.

Saya benar-benar berpikir menggunakan XAML untuk mendefinisikan alur kerja harus menjadi masalah termasuk paket NuGet.

Saya suka cara Anda berpikir! 👍

BTW, jika Anda belum melakukannya, silakan masuk ke permintaan/masalah port System.Xaml dan upvote masalah jika Anda bisa. Saya benar-benar ingin melihat sistem Xaml lintas platform open source baru yang mengambil yang terbaik dari semua sistem yang dikenal dan menyediakannya sebagai satu rasa resmi dan berwibawa. Bukankah itu bagus? 😛.

Bagaimanapun, itu hingga 74 suara sekarang. Yang cukup bagus mengingat pemungutan suara dimulai sebelum reaksi GitHub tersedia:
https://github.com/dotnet/corefx/issues/5766

17 hati juga cukup keren. :)

Terima kasih atas dukungan apa pun (dan umpan balik yang berkelanjutan)!

@dmetzgar Terima kasih atas usaha Anda! Beri komentar saja tentang XAML -- Saya dulu memiliki pandangan yang sangat negatif tentang XAML karena sebagian besar file yang saya tangani dibuat dengan dialek XAML yang pertama-pertama desainer visual.

Itu semua berubah ketika saya mulai memprogram dengan Xamarin.Forms yang memiliki C# API deklaratif yang sangat bagus selain XAML. Tidak ada desainer visual (hanya previewer yang datang lebih lambat dari rilis XF). Anehnya, saya lebih suka bekerja dengan dialek XAML daripada kode C#! Mereka melakukan pekerjaan yang sangat bagus, dan Anda tidak memiliki banyak metadata desainer yang mencemari makna markup. Kerangka kerja pendukung seperti Prism.Forms juga membantu mengarahkan skala secara drastis ke XAML juga karena membantu menulis kode tanpa kode di belakang dengan sangat mudah.

Jadi saya tidak berpikir XAML per se adalah masalahnya, tetapi dialek yang dirancang untuk mendukung desainer terlebih dahulu -- XF adalah bukti yang cukup meyakinkan bagi saya.

Adakah pembaruan tentang topik itu?

Nah CoreWF masih hidup dan ada di https://github.com/dmetzgar/corewf

Perlu dilihat apakah DynamicActivity sekarang dapat di-porting dengan API Komposisi baru yang ditambahkan ke inti dan standar .net 2.0.

Akan lebih bagus jika kita mendengar dari tim WF.

Ada banyak komentar menarik dan bermanfaat yang dibuat tentang topik ini. Untuk bagian saya, saya percaya bahwa ada nilai hanya dalam runtime WF dan pelacakan peristiwa (yaitu tanpa XAML, Transaksi, atau bit WCF) yang di-porting ke .NET Core dan saya senang bahwa ini (semacam) dilakukan.

Saya setuju bahwa WF.Core harus ada secara resmi. Jika ada kemampuan untuk menciptakan cara yang lebih fleksibel dalam mendefinisikan alur kerja yang bekerja untuk pengembang, saya yakin itu akan menjadi pendekatan terbaik. Saya setuju bahwa XAML sulit untuk dipecahkan jika MS mengatakan bahwa mereka tidak akan mem-port System.XAML, tetapi saya benar-benar ingin melihat WF.Core di proyek .NET Core Web API saya.

Saya pikir gajah besar di ruangan ini adalah bahwa tidak ada daya tarik yang cukup untuk menyelesaikan proyek ini karena MS dan yang lainnya sangat membungkam informasi tentang WF. Tentu ada beberapa sampel di MSDN, tetapi hanya ada sedikit informasi di luar sana dalam bentuk buku atau bahan padat lainnya (diperiksa).

Saya pasti bersedia meluangkan waktu untuk membantu mewujudkan ini.

Jadi OmniXAMLv2 (ada di cabang di repo github), yang masih dalam pengembangan, harus mendukung atribut x:Class (https://github.com/SuperJMN/OmniXAML/issues/12). Mungkin kita bisa menggunakannya untuk (Core)WF?

@ewinnington Terima kasih telah menunjukkan hal itu!
Itu pasti sebagian besar. Juga, .NET Standard 2.0 memiliki banyak tipe System.ComponentModel yang digunakan oleh WF. System.Transactions sudah ada di corefx. Satu-satunya hal yang hilang adalah WCF ServiceHost.

ServiceHost WCF bisa menunggu IMHO. Model hosting harus agnostik seperti yang lainnya di dunia .Net Core/Asp.Net saya pikir ...

@galvesribeiro Saya setuju dengan ini, mengingat fakta bahwa ada banyak cara lain agar WF dapat bekerja di dunia .NET Core, termasuk Web API.

Ya. Namun, saya setuju dengan @dmetzgar bahwa ada banyak pelanggan yang saat ini menggunakan WCF sehingga mendukungnya adalah suatu keharusan tetapi sekali lagi, itu dapat ditunda ...

Sebenarnya hosting dan "bahasa desain" harus diabstraksi dari runtime inti ...

Kami menggunakan WCF dengan WF tetapi dengan senang hati akan beralih ke sesuatu seperti WebAPI jika WF berada di Core. Sebenarnya kami telah maju dan beralih dari WCF ke alternatif RESTful. Kami mendapatkan TON nilai dari Workflow dan itu adalah teknologi .NET favorit saya!

Saya juga berpikir WF pada inti tidak harus bergantung pada xaml atau wcf, hanya memiliki mesin wf dan model objek akan sangat berharga. Anda kemudian akan menjalankannya sebagai middleware pada inti asp.net, terutama dengan pekerjaan pipeline/non-http baru yang akan datang ke kestrel.

+1 untuk memiliki dan mendukung mesin WF dan model objek di Core. Kami dapat bekerja di sekitar XAML dan WCF juga.

XAML keren - memungkinkan Anda membuat konfigurasi dinamis - dalam satu proyek kami memuat alur kerja xaml dari file dan mereka direpresentasikan sebagai titik akhir WCF. Dan file XAML ini dibuat secara otomatis dari registri layanan yang tersedia. Jadi layanan wcf mendapatkan endponts:
https://[base]/wcf/[service_id1]
https://[base]/wcf/[service_id2] ...
Akan menyenangkan memiliki fungsi seperti itu di .Net core :)
Oh... Saya sudah menulisnya di sini sebelumnya ... :)))

Ya karena saya semakin akrab dengan tanah di sini Dukungan Xaml di WF tidak begitu penting, melainkan benar-benar membuat System.Xaml porting di atas itu adalah bagian penting. Karena itu jelas ditangkap di yang lain -- dan saya cukup senang untuk mengatakan cukup populer (tapi jangan biarkan hal itu menghentikan Anda dari upvoting, @freerider7777! :smile:) -- masalah, saya mendukung menjadikan WF sebagai ketergantungan sebebas mungkin untuk memastikannya masuk ke .NET Core. 👍

@Mike-EEE Saya sudah lama memberikan suara di sana!! :)

Melihat bahwa Alur Kerja dapat dibuat melalui kode, apakah penggunaan Fluent API yang mirip dengan EF Core menjadi opsi yang valid untuk menghidupkan WF Core? Kemudian serialisasi/deserialisasi untuk runtime dapat dibangun setelahnya dan lebih mudah diimplementasikan?

FluentAPIs... sangat panas saat ini. Atau setidaknya, sejak mereka dibentuk. 😄.

FluentAPIs, Builder Pattern, keduanya pada dasarnya sama. Menyediakan cara berbasis kode yang dapat dirantai dan mudah digunakan, saya percaya harus menjadi prinsip yang kuat di balik ini.

Tanpa desainer itu semua tidak berguna. Tentu saja kami dapat mengkodekan semuanya sendiri - semua logika, semua rantai, dan seterusnya (dengan lancar atau tanpa itu). Tapi apa yang keren di WF - Anda dapat melihat alur pemrosesan secara visual. Ini adalah penghubung antara manajer (dan 'pemangku kepentingan' lainnya) dan pengembang! Manajer tidak memahami kodenya, tetapi diagram tingkat tinggi ini dapat dimengerti oleh semua orang. Dengan WF Anda tidak memerlukan diagram terpisah (visio atau lainnya) jika terpisah - diagram biasanya tidak sinkron dengan kode asli :)

@freerider7777 Definisi WF serialisasi tidak terbatas pada xaml (lihat https://github.com/dmetzgar/corewf dari @dmetzgar ). Itu bisa diimplementasikan untuk JSON juga .. dan ini akan membuka kemungkinan untuk mengintegrasikan/membagi proyek yang ada seperti NodeRed http://nodered.org/ , yang dalam banyak hal menyerupai fitur WF Designer dan UX (+ itu juga akan berjalan di browser web, membuka kasus penggunaan baru untuk WF)

Saya pikir yang terbaik adalah mem-port WF ke .NET Standard dan bukan hanya .NET Core. Runtime WF yang ditautkan sebelumnya sudah berfungsi pada .NET Standard 1.3 (kita bisa lebih rendah jika kita menghentikan aktivitas WriteLine). Dengan standar 2.0 yang segera keluar, kami akan memiliki kemampuan untuk mengisi banyak celah fitur seperti cachemetadata otomatis, DynamicActivity, dan cakupan transaksi. Kita harus memisahkan komponen ke dalam paket yang berbeda sehingga ada model bayar untuk bermain: jika Anda hanya ingin runtime maka Anda dapat tetap menggunakan standar 1.3, tetapi jika Anda menginginkan DynamicActivity, Anda memerlukan standar 2.0 dan Anda membatasi platform Anda.

Pasti ada banyak ruang untuk perbaikan dalam kode runtime WF. Misalnya, saya akan mengganti ekstensi aktivitas dengan injeksi ketergantungan. Fluent API akan menarik untuk menulis alur kerja dalam kode (dan sepanjang garis itu lihat https://github.com/knat/Metah oleh @knat) tapi saya setuju dengan @freerider7777 bahwa kemampuan untuk berkomunikasi dengan manajemen dan BA Anda menggunakan diagram dihasilkan dari apa yang sebenarnya digunakan dalam produksi adalah nilai tambah yang besar. @helmsb memiliki banyak pengalaman dengan ini (lihat http://dotnetrocks.com/?show=1236).

Seorang desainer baru harus menjadi aplikasi web. Menargetkan WPF atau UWP akan membatasi audiens. Jika OmniXAML berjalan dengan baik, orang dapat membuat/mengedit alur kerja menggunakan alat yang sama yang mereka lakukan hari ini (VS atau solusi yang di-host ulang). Masalahnya adalah karena desainer saat ini dibangun ke dalam .NET Framework, fitur atau perbaikan apa pun harus menunggu rilis .NET Framework. Ini cukup baik untuk memulai tetapi bukan solusi jangka panjang. @erikcai8 melakukan beberapa eksperimen dengan desainer web, mirip dengan nodered. Saya akan melihat apakah saya dapat meyakinkan dia untuk berbagi.

Untuk front-end desainer alur kerja, ada upaya pertama yang tersedia di github: https://github.com/gary-b/WF4JSDesigner dan Anda dapat menggunakannya langsung http://gary-b.github.io/WF4JSDesigner/

Ini adalah apa yang sudah terlihat seperti:

@ewinnington : Senang melihat POC desainer alur kerja web. Saya juga telah membangun yang lain seperti gambar di bawah ini.

SEGERA AWWWWW!!! INI WF POC-OFF!!! 🎉.

Hehe. Hei @erikcai8 mana Ekspor ke Xaml??? Ha ha. Hanya membalik kesedihanmu. Agak. 👼.

Kedua upaya tampak hebat. Senang melihat mereka berdua. Ini terlihat jelas sekarang, tetapi betapa hebatnya memiliki desainer visual berbasis web di WF asli? Semuanya terkunci dan dimuat, siap digunakan, Anda cukup mengunjungi URL. Saya pikir itu akan sangat membantu dengan branding dan adopsi. Sayangnya semua orang tampaknya telah mendarat di editor berbasis TFS yang sangat sulit untuk diatur dan menyebabkan Xaml yang sangat bertele-tele. Ini adalah pengalaman yang buruk bagi pengembang biasa yang harus menghadapinya dan memberikan nama yang buruk untuk pengalaman (WF atau Xaml).

Ini, OTOH, sepertinya pendekatan yang bagus. Biarkan kebangkitan dimulai!

@Mike-EEE Eksperimen E2E saya meningkatkan Mesin Inti Alur Kerja untuk memuat alur kerja JSON secara asli sehingga format XAML tidak diperlukan. Alur kerja XAML dapat diekspor dari Mesin Alur Kerja setelah memuat alur kerja JSON.

Itulah intinya. Kita tidak boleh mengikat runtime dan model objeknya ke desainer dan format serial seperti di WF 4.5...

@galvesribeiro Mengerti maksudnya. Eksperimen mengasumsikan bahwa format JSON didukung sebagai opsi lain untuk Workflow Core. Seperti dibahas di atas, XAML belum ramah untuk teknologi Web terbaru.

Kami menyukai WF, silakan port ke .NetCore.

Kami membutuhkan desainer alur kerja berbasis web. Dukungan untuk .NET core, untuk menjalankan alur kerja akan sangat luar biasa. pergi pergi

Daniel Gerlag sedang mengerjakan mesin alur kerja yang kompatibel dengan inti ringan yang sangat bagus di sini:

https://github.com/danielgerlag/workflow-core

Daniel telah datang jauh dalam waktu yang sangat singkat. Saya sangat menganjurkan Anda untuk melihatnya dan berpartisipasi dalam proyek ini jika Anda menemukan manfaat di dalamnya.

Dengan semua minat ini, mengapa tidak membangun mesin yang kompatibel dengan Net Core dari awal?

@ccpony Karena Anda dapat menggunakan CoreWF di dot net core sekarang -> https://github.com/dmetzgar/corewf . Komponen pusat porting dan bekerja. Beberapa hal menunggu standar .net 2.0.

@ewinnington Terima kasih telah menanggapi, tetapi saya tidak mengerti. WF bukanlah produk MS yang sukses dan MS tidak melakukan apa pun untuk meningkatkannya selama bertahun-tahun. Komunitas penuh dengan kesaksian tentang implementasi yang dicoba dan gagal. Itu belum diadopsi secara luas di perusahaan. Ini berat, berfitur berlebihan, sulit dipelajari dan (masih) bermasalah. Antarmukanya difitnah secara luas. Itu gagal menjadi teknologi ramah pengguna akhir. Bagian dalamnya pada dasarnya adalah kotak hitam yang tidak dapat dengan mudah ditingkatkan. SLOW dengan apa pun selain alur kerja sederhana. Sangat sulit untuk diuji. Ini didasarkan pada teknologi lama (WCF, XAML). Sejak Ron Jacobs sakit, WF merana dan tidak punya teman di MS.

Menurut perkiraan saya, WF berusaha menjadi segalanya untuk semua orang dan ternyata menjadi kecil bagi siapa pun. Microsoft memiliki segalanya kecuali menjatuhkannya. Mengapa kita ingin membangkitkan sesuatu seperti itu? Jika ada teknologi penting yang membutuhkan pemikiran ulang dan penulisan ulang, INI ADALAHNYA.

Lihatlah proyek baru Daniel Gerlag. Ini baru dan belum matang. Tetapi dibutuhkan pendekatan modern untuk alur kerja yang akan mudah ditingkatkan. Jika semua orang di sini akan berhenti mencoba untuk memperbaiki proyek yang kompleks, ketinggalan zaman dan, terus terang, proyek yang direkayasa berlebihan dan, alih-alih menempatkan upaya mereka menjadi sesuatu yang baru dan lebih baik, maka kita akan memiliki peluang untuk berakhir di tempat yang berharga - - secara bertahap membangun mesin alur kerja kelas dunia alih-alih mencoba menulis ulang raksasa sejak awal. Sejujurnya, saya mengagumi semua orang di sini yang ingin terlibat dalam upaya yang SANGAT bermanfaat - - menciptakan, AKHIRNYA, alat alur kerja lintas platform yang dirancang dengan baik, fungsional, ringan, timur untuk dipelajari, lintas platform (mesin negara?). Tapi, saya minta maaf untuk mengatakan, jika Anda semua terus mengikuti jalan ini, maka semua upaya Anda akan sia-sia. MO.

@ccpony Terima kasih telah berbagi pendapat Anda. Maukah Anda menjelaskan bug apa yang Anda maksud? Jika ada sesuatu yang dapat kami lakukan untuk memperbaiki masalah di .NET Framework, saya akan senang mengetahuinya.

@dmetzgar Terima kasih telah menanggapi, Dustin. Selama periode waktu yang mencoba mengembangkan aplikasi WF, saya menemukan bug. Bukan hanya perilaku yang tidak terduga, tetapi ada beberapa kali WF yang kompleks akan "meledak" dan menghasilkan kesalahan di UI XAML yang sulit diperbaiki dalam kode XAML. Saya tidak pernah benar-benar mengembangkan kepercayaan diri yang besar dalam teknologi WF. Sungguh, itu baru saja sampai pada titik di mana saya merasa seperti sedang bergulat dengan gorila seberat 800 pon - - untuk setiap satu langkah ke depan, saya akhirnya akan mundur dua langkah.

Saya tahu bukan itu yang Anda cari dalam permintaan baik Anda agar saya menguraikan bug. Terus terang, saya bisa mengatasi bug itu. Tapi saya akhirnya meninggalkan WF karena semua alasan lain yang saya sebutkan di posting saya sebelumnya.

Anda adalah ujung tombak upaya ini dan saya salut untuk itu. Tapi pasti ada saatnya ketika mencoba untuk memperbaiki teknologi yang kompleks menjadi kontraproduktif. Mengikuti seluruh utas ini, saya tidak bisa tidak merasa bahwa kemajuannya sangat lambat - - jika sama sekali - - dan akhirnya tidak ada yang akan terlihat dari semua ini. Saya merasa sangat tidak mungkin bahwa alur kerja lama akan portabel untuk apa pun yang diproduksi di sini. Orang-orang di utas ini berbicara tentang alur kerja berbasis klien (yaitu JavaScript), kompatibilitas REST, mengurangi ketergantungan, lintas platform, dll. Misalnya, XAML adalah bagian penting dari teknologi WF lama, apa gunanya porting WF ke inti XAML tidak akan menjadi bagian darinya?

Jadi Dustin, saya perlu menanyakan ini kepada Anda: di sini kita berada dalam 18 bulan dalam proyek ini dan tampaknya tidak ada konsensus bahwa kemajuan nyata sedang dibuat. Saya menghargai upaya Anda dan saya dapat melihat bahwa Anda adalah pembuat kode yang hebat - - tetapi inilah pertanyaan saya: bukankah jauh lebih masuk akal untuk mengumpulkan semua energi dan antusiasme ini dan menciptakan sesuatu yang baru?

@ccpony Pembahasan dalam topik ini adalah untuk mendukung WF .Net Standard dan bukan sebaliknya.

Hanya ingin tahu... Pernahkah Anda menggunakan atau melihat penerapan Sharepoint beraksi? Jika ya, Anda akan melihat bahwa itu sangat berat di WF. Pernahkah Anda melihat penerapan BizTalk? Sama.

Itu adalah produk MSFT utama di dunia perusahaan, jadi ya, ada pengguna yang peduli dengan WF dan ada gunanya. Ini bukan proyek yang ditinggalkan/dijatuhkan seperti yang Anda katakan.

Dengan demikian, jika Anda melihat @dmetzgar repo, Anda akan melihat bahwa beberapa hal serupa atau mewarisi beberapa perilaku dari inkarnasi lama WF, Anda juga akan melihat bahwa itu didesain ulang menjadi ringan. Kegigihannya dipisahkan dan orang-orang dapat dengan mudah membuat yang baru. Perancang dipisahkan dan orang-orang sudah membuat beberapa tes.

Saya mengerti rasa frustrasi Anda karena menginginkan sesuatu yang baru. Percayalah, saya juga ingin itu terjadi. Tetapi Anda harus memahami @dmetzgar dan timnya. Ini bukan prioritas karena 95% pelanggan adalah pengguna WF lama yang pada dasarnya berjalan di BizTalk dan Sharepoint seperti yang saya sebutkan. Saya menggunakan WF lama selama bertahun-tahun di lingkungan tps yang sangat tinggi (transaksi perbankan dan keuangan) dan itu sangat membantu saya.

Teknologi baru saya bekerja dengan .Net Core, dan satu-satunya alasan saya tidak menggunakannya lagi sekarang, adalah karena kami belum memilikinya untuk .Net Core.

Apa yang sudah saya sarankan ke @dmetzgar , adalah membawa repo WF ke .Net Foundation, menentukan pencapaian, meletakkan kode di sana dan menambahkan tugas sebagai Masalah dan menandainya sebagai up-for-grabs sehingga komunitas akan mulai melakukannya. Namun, itu masih memerlukan beberapa waktu dari timnya untuk menyelesaikan pekerjaan ini dan mereka mungkin tidak memiliki waktu itu (belum).

@galvesribeiro Saya mengerti maksud Anda. Ya, saya telah menulis penerapan SharePoint. Dan saya TELAH melihat penerapan BizTalk beraksi ( * shutter *). Saya memahami hubungan antara SharePoint dan WF. (Saya tidak tahu apa yang Anda maksud ketika Anda menyarankan bahwa BizTalk entah bagaimana bergantung pada WF. Tidak.)

Tetapi saya harus tidak setuju dengan Anda tentang satu hal penting: WF ADALAH proyek yang ditinggalkan/dijatuhkan. Saya benar-benar memahami kekhawatiran pengembang SharePoint saat ini. Tidak ada alasan untuk percaya bahwa MS akan meningkatkan kemampuan WF di SharePoint. Saya tidak mengerti mengapa Anda berpikir bahwa upaya @dmetzgar akan ada hubungannya dengan masa depan SharePoint (atau BizTalk). Ini tidak seperti MS akan me-retrofit SharePoint dengan kode @dmetzgar . Maaf, masa depan SharePoint tidak ada hubungannya dengan upaya yang dilakukan di sini.

Jadi, yang terpenting adalah apakah mesin alur kerja yang baik akan keluar dari semua ini. Dan menurut pendapat saya, mencoba memaksa raksasa seperti WF ke masa depan bukanlah tindakan terbaik. Lebih baik membangun dari awal.

@ccpony Saya ingin mengingatkan Anda bahwa ada banyak orang di sini yang secara aktif mencari untuk melihat proyek ini menjadi kenyataan, dan beberapa benar-benar meluangkan waktu untuk mewujudkannya. Meskipun Anda secara pribadi mungkin melihat WF sebagai produk gagal dari Microsoft, WF tetap menjadi bagian dari .NET dan digunakan oleh lebih dari sekadar kami di sini.

Utas ini harus untuk kritik dan masukan yang membangun untuk membuat transisi menjadi kenyataan dan bukan membanting orang lain atau produk itu sendiri. Meskipun pandangan Anda dihormati, perhatikan bahwa itu adalah milik Anda dan bahwa orang lain mungkin berpikir berbeda tentang pentingnya WF bagi mereka.

Kami secara aktif menyambut masukan Anda tentang cara meningkatkan produk dan cara terbaik untuk membantu mereka yang secara aktif berpartisipasi dalam upaya tersebut.

Terima kasih =^_^=

@ccpony

(Saya tidak tahu apa yang Anda maksud ketika Anda menyarankan bahwa BizTalk entah bagaimana bergantung pada WF. Tidak.)

Maaf, saya mengekspresikan diri saya dengan buruk (saya menggunakan ponsel). Saya memiliki aplikasi yang menggunakan keduanya bersama-sama dan saya tahu banyak yang lain juga.

Tidak ada alasan untuk percaya bahwa MS akan meningkatkan kemampuan WF di SharePoint.

Saya tidak mengatakan itu akan. Saya mengatakan bahwa tim yang bekerja dengan WF Today, benar-benar fokus pada dukungan penyebaran Sharepoint. Bahkan Sharepoint versi terbaru menggunakan versi WF yang sama/saat ini.

Saya tidak mengerti mengapa Anda berpikir bahwa upaya @dmetzgar akan ada hubungannya dengan masa depan SharePoint (atau BizTalk).

Saya tidak mengatakan itu akan mempengaruhi masa depan Sharepoint. Saya mengatakan tim sibuk mendukung Sharepoint jika saya mengerti dengan benar. ( @dmetzgar dapat mengoreksi saya jika saya salah)

Ini tidak seperti MS akan me-retrofit SharePoint dengan kode @dmetzgar . Maaf, tapi masa depan SharePoint tidak ada hubungannya dengan upaya yang dilakukan di sini

Apakah MS akan menggunakan atau tidak WF vNext pada Sharepoint vNext, hanya mereka yang bisa memastikannya. Sekali lagi, masalahnya adalah tim WF tidak mampu menangani keduanya.

Jadi, yang terpenting adalah apakah mesin alur kerja yang baik akan keluar dari semua ini. Dan menurut pendapat saya, mencoba memaksa raksasa seperti WF ke masa depan bukanlah tindakan terbaik. Lebih baik membangun dari awal.

Tidak ada yang mem-portingnya apa adanya. @dmetzgar 's repo adalah bukti bahwa itu sedang didesain ulang dari bawah ke atas. Sekali lagi, masalahnya adalah backlog dan bandwidth yang harus dihadapi tim dengan kedua hal tersebut. Itulah mengapa saya menyarankan untuk "membukanya" di dotnet foundation dan menjadikannya sebagai upaya besar berbasis komunitas dengan bimbingan dan kurasi dari tim WF sehingga kami berusaha untuk mengurangi jadwal mereka.

Sekali lagi, seperti @InariTheFox dan saya sendiri yang disebutkan, utas ini adalah dorongan maju untuk port, yang tidak berarti mendorong paksa fersi lama dengan semua fitur ini ke versi baru. Namun, penting untuk dipahami bahwa orang-orang memberikan banyak usaha (dan uang) pada produk berbasis WF mereka saat ini, jadi @dmetzgar memperhatikan kompatibilitas sebanyak mungkin dengan alur kerja lama, memang sesuatu yang harus diperhatikan.

Baik. Saya melihat gairah di sini. Sebenarnya, jika ada pengganti yang baik untuk WF yang mengatasi semua masalah yang saya sebutkan sebelumnya, kami tidak akan melakukan percakapan ini. Sebagai catatan, banyak dari kita telah meninggalkan WF dan telah menunggu hal berikutnya yang akan datang. Itu tidak pernah terjadi. Sejauh pengetahuan saya, TIDAK ADA solusi saat ini, didukung, fungsional, alur kerja/mesin status berbasis .Net yang dianggap luas. Harap dipahami: Saya mendukung pendapat saya bahwa WF adalah teknologi mati dari sudut pandang Microsoft.

Tapi, setelah mengatakan itu, tolong bantu saya mengerti. Apakah repo @dmetzgar berfungsi apa adanya? Bagaimana cara menulis alur kerja dengannya? Saya tidak melihat kode contoh dan tidak ada dokumentasi. Bagaimana saya melanjutkan?

Saya pikir ada banyak produk / perusahaan di luar sana yang menjadikan WF sebagai pusat strategi produk mereka, ini bukan hanya ketergantungan Sharepoint dalam mode dukungan: di perusahaan saya saat ini, kami mengembangkan platform otomatisasi dengan WF sebagai teknologi pusat (dan saya tahu 2 pesaing lain dari pasar ini yang juga menggunakan WF dalam produknya); juga saya sudah berdiskusi dengan orang-orang yang menggunakannya di insurtech.. jadi saya sangat yakin bahwa penonton untuk WF masih ada.

Meskipun demikian, .net core tampaknya menjadi salah satu area fokus Microsoft dan banyak inovasi teknologi akan masuk ke dalamnya pada periode berikutnya; Saya pikir itu akan menjadi kerugian besar untuk tidak memiliki WF sebagai bagian dari itu.

Dari sudut pandang saya, jalan yang benar untuk mewujudkannya adalah membuat inti WF independen dari xaml dan membuatnya lebih mudah untuk (menghapus) serialisasi alur kerja dalam format lain juga (mis: json). Ini juga akan menyederhanakan implementasi skenario seperti desainer alur kerja yang dihosting di browser web. Dan dengan repo https://github.com/dmetzgar/corewf kami memiliki titik awal.

Bagi mereka yang tertarik dengan gambaran umum tentang keadaan WF saat ini (yang saya tidak melihat ditinggalkan oleh MS), beberapa waktu yang lalu saya memusatkan info yang tersedia mengenai WF dalam sebuah posting & presentasi http://andreioros.com/blog /windows-workflow-foundation-rehosted-designer/ ; Saya masih memperbaruinya

Kami dan pelanggan kami mengandalkan WF dan kami akan sangat senang melihatnya bekerja pada klien dan juga server. Sebuah WF bebas dari XAML dan ketergantungan lainnya, dirancang untuk menjadi ringan tetapi dengan ekspresi dari WF yang ada yang juga didukung komunitas dengan MS akan menjadi produk yang menarik dan berharga.

Sekali lagi, izinkan saya untuk bertanya: apa yang dilakukan dengan port @dmetzgar untuk menjalankannya? Apa statusnya saat ini?

Saya tidak tahu port @dmetzgar sebenarnya dapat digunakan dalam inkarnasinya saat ini ...

Dari @ewinnington , di atas:

"Karena Anda dapat menggunakan CoreWF di dot net core sekarang -> https://github.com/dmetzgar/corewf . Komponen pusat telah di-porting dan berfungsi. Beberapa hal menunggu standar .net 2.0."

Dalam hal ini saya juga ingin mendengar tentang penggunaannya...

Ya, ini adalah inti dari fungsionalitas inti. Anda dapat menjalankan alur kerja berbasis kode. Fitur yang hilang dari netstandard2.0 sebagian besar terkait dengan dukungan transaksi.

Itu lebih satu alasan saya masih menyarankan untuk memulainya terbuka dan membuat orang berkontribusi ke tempat sentral. Menyebarkannya akan membuat segalanya lebih sulit untuk dicapai dalam produk akhir suatu hari nanti di masa depan.

Suara untuk penulisan ulang WF dengan tes dan dukungan untuk fitur Roslyn modern sebagai bagian dari Core. Saya ingin melihat bagaimana serverless dan container dapat memengaruhi arsitektur, terutama penerapan dan penskalaan kumpulan aturan dalam konteks domain dan proses bisnis yang berbeda. Saya pribadi lebih suka DSL yang ringkas daripada desainer WYSIWYG. Saya pribadi menyukai desainernya, tapi rasanya aneh hampir sepanjang waktu. WF sendiri memiliki potensi untuk menjadi sangat solid, tetapi membutuhkan keahlian yang mendalam. Sebenarnya, peluncuran besar WF yang menyertakan WF Manager dan aliran berkelanjutan di SQL Server memerlukan konsultasi MS dan perbaikan bug. Meskipun saya sekarang mendukung tim Java selama beberapa tahun terakhir, saya suka mengawasi .NET setelah lebih dari 15 tahun terutama berfokus pada teknologi MS. Saya sedang membaca "Pembuatan Kode dengan Roslyn" oleh Nick Harrison (saya tidak memiliki ikatan dengan dia atau buku itu) dan bertanya-tanya tentang pendekatan kembali ruang Business Rule Engine sekali lagi, yang membuat saya bertanya-tanya tentang nasib WF sekali lagi... sejujurnya, saya akan berpikir bahwa Azure Functions bersaing dengan sumber daya MS serta kesediaan perusahaan secara umum untuk mendukung investasi mendalam di WF di mana saja. Tampaknya jelas mereka ingin Anda menggunakannya... jadi, mungkin solusinya adalah dengan fokus pada OpenWhisk versi .NET open source. Tapi, di dunia kemas, ... Saya hanya bisa menggunakan OpenWhisk sebagai layanan. Jadi...

PS hanya mendukung metode yang kuat untuk mengimpor ekspresi eksternal mungkin menyelesaikan 60% dari persyaratan aplikasi di luar sana yang berpikir mereka mungkin menginginkan WF. Apakah itu CSharpScript? Cara sederhana untuk mengimpor konfigurasi aturan bisnis dasar dengan API langsung akan sangat membantu (berbagai opsi persistensi, pengambilan, dan caching). Dengan infrastruktur virtual sekali pakai (otomatisasi melalui Infrastruktur-, Kontainer-, dan Platform-sebagai-Layanan), WF vNext dapat fokus pada penerapan perubahan versi sebagai layanan daripada mencoba memasukkannya ke dalam aplikasi (yaitu solusi yang lebih baik untuk WF di WCF)

Saya sangat tertarik dengan percakapan ini. Tim saya telah berurusan dengan frustrasi XAML juga. Dilema kami adalah bahwa kami membuat desainer UI kami sendiri untuk memungkinkan pelanggan kami membuat alur kerja mereka sendiri tanpa memerlukan Visual Studio atau desainer yang di-hosting ulang. Kami membutuhkan kemampuan untuk menyimpan potongan XAML menjadi bit yang dapat digunakan kembali sehingga pelanggan tidak selalu perlu menulis ulang bit tersebut (menganggapnya sebagai fungsi alur kerja). Ini mengharuskan kita untuk mengetahui bagaimana menggabungkan potongan XAML bersama-sama, yang telah kita pelajari sangat membuat frustrasi. Apa yang kami pikirkan untuk dilakukan adalah membuat abstraksi di mana kami hanya mengandalkan model database dari berbagai aktivitas kami dan keterkaitannya dan mengabaikan XAML sama sekali. Kami kemudian akan membuat aktivitas, dll secara terprogram setiap kali alur kerja dijalankan. Saat meneliti pendekatan ini, saya menemukan utas ini. Pertahankan percakapan, saya sangat tertarik untuk mendengar pendapat orang lain.

@erikcai8 Perancang alur kerja adalah Ide yang sangat bagus. Bisakah saya mendapatkan sumber desainer alur kerja Anda?

Saya telah menggunakan WF selama lebih dari 5 tahun sekarang dalam proyek otomatisasi saya dan itu luar biasa. Saya berharap banyak pengembang akan mendukung permintaan ini dan mewujudkannya. Saya selalu menggunakan teknologi .Net sejak saya mulai bekerja dan ingin terus melakukannya. Namun, mampu mendukung lintas platform adalah arahan perusahaan, jadi saya sangat menantikan untuk melihat WF penuh di .Net Core.

Dengan kedatangan standar bersih 2.0, akan sangat bagus untuk memiliki pembaruan tentang masalah corewf:

@dmetzgar
https://github.com/dmetzgar/corewf/issues/3
https://github.com/dmetzgar/corewf/issues/4

Bagaimana API yang ditambahkan membuka blokir proses porting dan apa yang dapat kami lakukan untuk membantu?

Saya pikir terlepas dari netstandard2.0 , port ini harus berjalan sebagaimana adanya IMHO... Dengan penulisan ulang... Menjadikannya ramah untuk penjadwal tugas eksternal, async/await/Task, dan hal-hal modern lainnya. Sama seperti saya menyukai WF, versi saat ini cukup ketinggalan jaman ...

Maksud saya ini tanpa rasa tidak hormat sama sekali. Sejujurnya. Tetapi apakah saya satu-satunya di sini yang mengerti bahwa proyek ini tidak ada harapan? Kami sangat membutuhkan mesin alur kerja yang baik untuk .Net, tetapi ini bukan itu. Bukankah kita harus mengubah pembicaraan di sini?

Saya terbuka untuk mesin alur kerja baru yang lebih baik. Intinya kita membutuhkannya di .NET Core. Kami telah menggunakan WF selama bertahun-tahun dan itu bekerja dengan sangat baik bagi kami, jadi lebih baik daripada tidak sama sekali jika itu adalah alternatifnya.

@kalokamgit , sumbernya tersedia di sumber referensi. Itu dalam dua majelis:
System.Activities.Presentation dan System.Activities.Core.Presentation .

Sayangnya, alat yang menerbitkan sumber referensi hanya melakukan kode C#. Itu tidak termasuk salah satu file XAML. Anda dapat memberikan umpan balik tentang ini ke [email protected] dan/atau memberikan suara pada masalah suara pengguna .

Kodenya ada di .NET Framework sehingga Anda bebas menggunakannya di alat Anda sendiri. Beberapa contohnya adalah proyek @orosandrei dan contoh proyek di sini .

Maksud saya ini tanpa rasa tidak hormat sama sekali. Sejujurnya. Tetapi apakah saya satu-satunya di sini yang mengerti bahwa proyek ini tidak ada harapan? Kami sangat membutuhkan mesin alur kerja yang baik untuk .Net, tetapi ini bukan itu. Bukankah kita harus mengubah pembicaraan di sini?

Nah jika Anda _benar-benar_ tidak bermaksud tidak hormat. :) Saya ingin tahu apa yang dipikirkan semua orang tentang Flow ? Itulah yang saya pikirkan ketika saya memikirkan "alur kerja" untuk "zaman modern" ...

SAYA BENAR-BENAR BENAR-BENAR bersungguh-sungguh :)

Tebak Aliran adalah jawaban untuk menumbuhkan Zapier? Saya tidak melihat bagaimana itu akan menggantikan WWF dengan cara apa pun.

Apakah WF dihentikan atau saya melewatkan sesuatu di sini? Itu akan sangat menyedihkan!

Di mana saya bisa memilih WF?

Posting teratas dari masalah ini adalah tempat terbaik.

Saya ingin tahu apa pendapat @rjacobs (guru WF) tentang masalah ini.

Apakah maksud Anda @ronljacobs?

@dmetzgar Mungkin ya. Dia adalah pahlawan WF sejati

Ini jawaban saya
https://github.com/danielgerlag/workflow-core

Ron Jacobs adalah orang yang menaruh hati dan jiwanya di WF selama bertahun-tahun. Dia tertular Penyakit Dercum dan meninggalkan Microsoft pada 2013. (di sini) Ketika dia pergi, itu untuk WF. Sekali lagi, dan semoga untuk terakhir kalinya: WF SUDAH MATI.

Dan sekali lagi - - Saya akan mendorong semua orang dan siapa saja untuk melihat proyek Dan Gerlag, di atas. Ini fasih, disusun dengan indah dan berjalan di Core. Siapa pun yang ingin berkontribusi pada solusi alur kerja yang layak perlu melihatnya.

Juga silakan lihat Kerangka Tugas Tahan Lama . Ini sedang ditambahkan ke Fungsi Azure, lihat Fungsi Tahan Lama .

@dmetzgar Kerangka kerja ini dalam popok dianggap sebagai alternatif untuk WF. Saya tidak berpikir serius bahwa Microsoft mengusulkan hal semacam ini. Bukankah lebih baik daripada menciptakan kembali roda, memigrasikan WF ke .NET Core dan menggunakannya kembali sebagai dasar di semua proyek Microsoft? Maaf atas kekasaran kata-kata saya, tetapi saya pikir itu mewakili sentimen banyak orang yang sangat kecewa dengan situasi WF saat ini.

@Suriman , poin yang adil

Saya memperbarui readme pada repo corewf untuk mendapatkan deskripsi yang lebih baik tentang apa yang terlibat dalam porting WF ke .NET Core. Maukah Anda melihat-lihat?

@dmetzgar Terima kasih atas klarifikasi dan dengan jelas menunjukkan jalan ke depan untuk port WF ke .NET Core. Saya mengerti dari apa yang Anda katakan bahwa Microsoft tidak akan melakukan semua pekerjaan migrasi ini dan berharap komunitas melakukannya, bukan? Jawaban atas pertanyaan ini adalah kuncinya, tergantung pada responsnya, perusahaan dapat memilih rute alternatif atau melakukan pekerjaan yang seharusnya dilakukan Microsoft.

Microsoft tidak akan melakukan port resmi WF ke .NET Core. Saya dan tim saya akan mengerjakan ini di waktu luang kami, tetapi tidak dalam kapasitas resmi atau dengan rilis terjadwal. Semua masalah yang terdaftar siap untuk diperebutkan. Ada kegunaan untuk port semacam itu untuk beberapa proyek yang kami lakukan. Dari situlah sebagian besar kontribusi kami berasal. Saya pikir adil untuk menutup masalah ini untuk saat ini dan mengarahkan orang ke repo corewf untuk mengikuti pekerjaan terbaru.

Hai,
Perubahan dari tonggak Masa Depan ke 2.1, apakah berarti Microsoft akan mem-porting WF ke .NET Core?

Perubahan tonggak untuk masalah tertutup hanya mencerminkan selama rilis masalah telah ditutup.
Masalah khusus ini pada dasarnya ditutup sebagai "Tidak Akan Memperbaiki" - lihat penjelasan di atas https://github.com/dotnet/corefx/issues/2394#issuecomment -316170275

@karelz Sayang sekali. Untuk sesaat, sepertinya lotere telah memukul kami.

Kami memiliki Solusi berdasarkan WF. Kami membuat langkah-langkah kegiatan menggunakan WF dan alur kerja ini akan dikirimkan ke semua pelanggan dan mereka akan memproses tindakan berdasarkan WF. Kami sangat menyukai WF. mendukung lintas platform adalah arah perusahaan kami. Kami sangat tertarik untuk memiliki WF di .NET CORE.

Ada CoreWF yang merupakan kode Workflow Foundation yang sebagian di-porting ke .net core. Anda dapat menggunakan platform lintas pondasi Workflow sekarang . Anda tidak dapat menggunakan alur kerja berbasis XAML saat ini.

Saya memiliki cabang tempat saya bekerja untuk menambahkan dukungan untuk Aktivitas Dinamis di atas Net Standard 2.0 .

Proses parsing XAML mengharuskan Microsoft untuk membuka System.XAML secukupnya agar kita dapat membuat progres parsing file dengan benar.

Anda dapat melacak kemajuan masalah ini di sini: https://github.com/dmetzgar/corewf/issues/6 dan dalam berbagai upaya saya untuk menyampaikan pemberitahuan tentang masalah ini:
Di CoreFX
Pada ReferensiSumber

Paket kompatibilitas .Net memiliki "Mungkin" di bagian depan System.XAML. Tetapi tidak ada berita yang disaring tentang penyertaannya. Masalah Ship .Net Framework Compatibility Pack saat ini mencantumkan "tidak ada rencana" untuk System.XAML.

Mungkin juga masalah Epic Adopsi Pelanggan dapat digunakan untuk menceritakan kisah Anda tentang bagaimana menambahkan Workflow Foundation (dan System.Xaml) akan memungkinkan perusahaan Anda mengirimkan produk.

Perusahaan saya juga berinvestasi di WF: Kami memiliki produk untuk perusahaan Energi di mana klien kami membuat alur kerja menggunakan Workflow Foundation.

Terimakasih atas balasan anda.
itu sangat berguna menghargainya.

Pada 2 November 2017 18:22, "Eric Winnington" [email protected] menulis:

Ada CoreWF https://github.com/dmetzgar/corewf yang merupakan kode
Workflow Foundation sebagian di-porting ke .net core. Anda dapat menggunakan Alur Kerja
pondasi lintas platform sekarang . Anda tidak bisa menggunakan alur kerja berbasis XAML
pada saat ini.

Saya memiliki cabang tempat saya bekerja untuk menambahkan dukungan untuk Aktivitas Dinamis
di atas Net Standard 2.0 https://github.com/ewinnington/corewf .

Proses penguraian XAML mengharuskan Microsoft untuk membuka System.XAML
cukup bagi kita untuk dapat membuat kemajuan parsing file dengan benar.

Anda dapat melacak kemajuan masalah di sini: dmetzgar/corewf#6
https://github.com/dmetzgar/corewf/issues/6 dan dalam berbagai upaya saya
dalam menyampaikan pemberitahuan tentang masalah ini:
Di CoreFX
https://github.com/dotnet/corefx/issues/5766#issuecomment-320724209
Pada ReferensiSumber
https://github.com/Microsoft/referencesource/issues/39

Paket kompatibilitas .Net
https://github.com/dotnet/designs/blob/d48425ffb2ba7d721acb82da61d7c6d4b320d6c7/compat-pack/compat-pack.md
memiliki "Mungkin" di bagian depan System.XAML. Tapi tidak ada berita yang disaring tentang itu
penyertaan. Masalah Kirim .Net Framework Compatibility Pack
https://github.com/dotnet/corefx/issues/24909 saat ini mencantumkan "tidak
rencana" untuk System.XAML.

Mungkin juga masalah Epic Adopsi Pelanggan
https://github.com/dotnet/corefx/issues/24751 dapat digunakan untuk memberi tahu
cerita Anda tentang bagaimana menambahkan Workflow Foundation (dan System.Xaml) akan memungkinkan
perusahaan Anda untuk mengirimkan produk.

Perusahaan saya juga berinvestasi di WF: Kami memiliki produk untuk perusahaan Energi
tempat klien kami membuat alur kerja menggunakan Workflow Foundation.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/dotnet/corefx/issues/2394#issuecomment-341377434 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AFernYlbmCQ4tnaOz4Hpv5rrVoEBeX9Bks5syZfxgaJpZM4FaQMY
.

Hai,
Ini adalah dunia layanan mikro dan semuanya dipecah menjadi beberapa komponen. Sekarang jika kita harus mengaturnya, kita harus bergantung pada aplikasi logika Azure atau vendor eksternal lain yang mengenakan biaya premium untuk alur kerja. Meskipun sangat sedikit produk non .NET WF seperti Konduktor Netflix, kami ingin memilikinya dalam versi inti .NET murni. Anda dapat mengambil petunjuk dari konduktor Netflix di https://github.com/Netflix/conductor dan mulai membangunnya dari sana. Ini akan menjadi keuntungan besar bagi pengembang cloud pribadi yang tidak memiliki akses ke Azure Stack yang tidak dapat menggunakan Aplikasi Logika.

Pikir saya akan memposting di sini demi kesadaran. Saya membaca dokumentasi berikut dan itu membuat saya memikirkan utas ini:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/custom-workflow-activities-workflow-assemblies

Sepertinya Dynamics365 dan PowerApps sedang melakukan perpaduan pikiran dan menggunakan Windows Workflow dalam beberapa kapasitas untuk penanganan alur kerjanya sekarang. Ini tentu saja semua hanya untuk Windows, tetapi di era baru lintas platform, dll... berapa lama ini akan bertahan?

Saya tidak tahu apa yang seharusnya saya gunakan. Saya berharap MSFT akan melakukan ini. Membawa kejelasan Microsoft.

@VenkateshSrini , Anda juga harus melihat irama: https://github.com/uber/cadence
Modelnya lebih seperti SWF Amazon tetapi open source. Belum ada klien .NET.

Mencari sebuah. Versi inti bersih

Tidak akan terjadi.

Dari: pemberitahuan [email protected]
Dikirim: Rabu, 26 September 2018 12:30
Kepada: dotnet/corefx [email protected]
Cc: Jeffrey Michelson [email protected] ; Sebutkan [email protected]
Subjek: Re: [dotnet/corefx] Port Workflow Foundation ke .NET Core (#2394)

Mencari sebuah. Versi inti bersih

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424581034 , atau nonaktifkan utasnya https://github.com/notifications/unsubscribe-auth/AVMP1qBfxwybd6ZxRkTuCurLahQ57ZZkNks

Sangat buruk

Jadi apa yang ditawarkan Microsoft untuk ifttt atau alur kerja di ekosistem non Azure. Ketika mereka ingin mengaktifkan hal-hal seperti ml dari Azure mengapa tidak alur kerja

Lihat karya Dan Gerlag.

https://github.com/danielgerlag/workflow-core

Dari: pemberitahuan [email protected]
Dikirim: Rabu, 26 September 2018 08:34
Kepada: dotnet/corefx [email protected]
Cc: Jeffrey Michelson [email protected] ; Sebutkan [email protected]
Subjek: Re: [dotnet/corefx] Port Workflow Foundation ke .NET Core (#2394)

Jadi apa yang ditawarkan Microsoft untuk ifttt atau alur kerja di ekosistem non Azure. Ketika mereka ingin mengaktifkan hal-hal seperti ml dari Azure mengapa tidak alur kerja

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424697799 , atau matikan utasnya https://github.com/notifications/unsubscribe-auth/AVMP1h2zWn4luwdz0QFNH- Jsl8L_4hIkks5ue3Q5gaJpZM4FaQMY .

Ada CoreWF yang merupakan port dari Workflow foundation ke .net core. Pelabuhan ini sedang berkembang. Kami mencari orang untuk membantu.

Batu loncatan utama berikutnya adalah mengkompilasi alur kerja yang dimuat dengan Roslyn sehingga kita dapat menggunakan kode dalam parameter alur kerja, ini diperlukan untuk alur kerja yang ditentukan XAML. Jika Anda menentukan alur kerja di inti Imperatif, Anda dapat menggunakan CoreWF sekarang.

Terima kasih atas kerja Anda @ewinnington dan @dmetzgar ! Dukungan XAML melalui Portable.XAML di CoreWF adalah masalah besar untuk upaya itu. @dmetzgar Apakah Anda berencana menerbitkan versi baru ke NuGet segera?

Halo semua,

Apakah ini semua produksi siap. Kami sedang menghitung definisi alur kerja yang harus dilakukan dari Ui eksternal. Tetapi mesin harus dapat memuat definisi dan bekerja dari mereka. Lebih dari jenis iffft

@VenkateshSrini , saya rasa Microsoft tidak perlu menyediakan kerangka kerja alur kerja lintas platform. Pada hari-hari .NET Framework Microsoft menyediakan segalanya, yang merugikan komunitas secara keseluruhan. Saya ingin melihat lebih banyak perpustakaan sumber terbuka .NET yang diadopsi oleh organisasi dan membuat "siap produksi".

@watertree , saya sedang menunggu rilis baru Portable.Xaml. Ada perbaikan penting yang diperlukan untuk dukungan CoreWF XAML.

Apa alternatif untuk alur kerja yang berjalan lama untuk saat ini (dengan ketekunan)? Hanya yang berbayar?

@freerider7777

FYI: https://github.com/danielgerlag/workflow-core

Kami menggunakannya di perusahaan kami dengan hasil yang sangat baik.

Bagi mereka yang masih mengikuti, proyek CoreWf baru saja mencapai tonggak penting dengan integrasi Roslyn untuk memungkinkan eksekusi alur kerja XAML yang dimuat secara dinamis. Jika Anda masih membutuhkan Workflow Foundation pada inti dotnet, periksa.

Hai ,
Apakah itu berarti saya dapat mengambil alur kerja XAML yang ada dan menggunakannya apa adanya. Apakah kita memiliki batasan?

Apakah kita memiliki batasan?

Penyimpanan instans belum di-porting, perancang tidak berada di inti dan Layanan WCF tidak tersedia karena server WCF belum berada di inti.

Silakan buat masalah pada repo CoreWf dan cantumkan persyaratan yang Anda miliki. Kita bisa melanjutkan percakapan disana.

Nuget saat ini untuk corewf sudah kedaluwarsa dan tidak termasuk eksekusi Xaml runtime berbasis Roslyn yang baru saja digabungkan. Kami masih mencari umpan balik untuk melihat apa yang berhasil dan apa yang tidak.

Apakah ini berarti bahwa itu tidak akan pernah terjadi?

Ini tidak akan terjadi. Itu tidak akan pernah terjadi - - jangan tersinggung bagi mereka yang melakukan upaya terbaik mereka. Lihat proyek Dan Gerlag (https://github.com/danielgerlag/workflow-core) atau gigit peluru dan lompat ke kereta Azure LogicApps.

Halo, ini panggilan oktober 2020. Adakah berita/pembaruan/rilis tentang Workflow Foundation di .NET Core?

atau haruskah kita semua pindah ke Elsa? https://elsa-workflows.github.io/elsa-core/

@wstaelens Saya pikir jawaban MS cukup jelas : WF tidak akan secara resmi porting ke .Net Core. Alternatif yang disarankan adalah CoreWF .