Dibangun dengan menggunakan kontrol Infragistics, aplikasi sampel ini memberi pengguna spreadsheet seperti Excel, dengan fitur seperti visual dan gaya yang terinspirasi oleh perangkat lunak, pola dan praktik MS Office dari perpustakaan Microsoft Prism, pola dan prinsip desain umum seperti MVVM (Model-View - ViewModel), IOC (Inversion of Control), DI (injeksi ketergantungan), teknik pembuatan agregasi, komando, navigasi, dan modular. Aplikasi contoh ini memberi pengguna antarmuka pengguna terinspirasi Microsoft Word yang familiar yang dibangun dengan kontrol Infragistics. Fitur dari aplikasi ini mencakup visual dan gaya yang terinspirasi oleh perangkat lunak, pola dan praktik MS Office dari perpustakaan Microsoft Prism, dan pola dan prinsip desain umum seperti MVVM (Model-View-ViewModel), IOC (Inversion of Control), DI (ketergantungan Injeksi), agregasi acara, komando, navigasi, dan teknik pengembangan aplikasi modular. Aplikasi tampilan IG Outlook memberikan panduan bagaimana membangun aplikasi yang diimpikan Microsoft Outlook dengan menggunakan pustaka Prilaku Praktik Microsoft. Showcase ini menunjukkan penggunaan pola dan prinsip umum seperti MVVM (Model-View-ViewModel), IoC (Inversion of Control), DI (injeksi ketergantungan), teknik pengembangan aplikasi agregasi, komando, navigasi, dan modular yang dikombinasikan dengan Kontrol infragistics. Kontrol Infragistics berikut digunakan di etalase xamDataGrid, xamRibbon, xamRichTextEditor, xamOutlookBar, xamDataCards, xamMaskedInput, xamComboEditor, xamOutlookCalendarView, xamDayView, xamMonthView, xamScheduleView, xamDateNavigator, xamDataTree dan XamRibbonWindow. Map Browser adalah aplikasi interaktif yang menyoroti kemampuan kontrol Peta Geografis Geografis yang memungkinkan pembuatan peta gabungan dengan memplot data geospasial pada ubin citra dari sumber Bing Map, OpenStreetMap, CloudMade, ESRI, dan MapQuest. Aplikasi ini menyediakan sumber data semua negara di dunia, kota terbesar di dunia, gempa bumi, lalu lintas penerbangan dan curah hujan di Amerika Serikat, dan ratusan ribu lokasi geo di Australia. Setiap kumpulan data divisualisasikan dengan menggunakan lapisan peta geografis yang dapat diedit untuk tampilan dan juga dilapisi pada lapisan peta lain yang diplot dalam kontrol Peta Geografis. Misalnya, lokasi gempa dapat digambarkan di atas lapisan peta dengan lokasi kota terbesar untuk memberikan konteks geografis bagi peta yang memvisualisasikan berapa banyak tempat berpenduduk padat di dunia yang terkena dampak gempa bumi. Dashboard Keuangan adalah aplikasi interaktif yang menunjukkan kemampuan Diagram Data Infragistics dan kontrol Peta Pohon yang diterapkan pada industri Jasa Keuangan. Tampilan Stock Chart dari aplikasi dibangun menggunakan Data Chart, yang telah dioptimalkan untuk charting data kecepatan tinggi. Data Chart mendukung dataset besar dengan jutaan titik data dan update real time. Selain itu, kontrol ini memungkinkan indikator statistik dan teknis utama serta perbandingan dengan pesaing utama. Pilihan tampilan meliputi 1 bulan, 3 bulan, 6 bulan, 1 tahun, 5 tahun, 10 tahun dan Max dengan zoom bar. Sebagai tambahan, analisis komparatif memetakan harga saham perusahaan dengan pesaing utama. Tampilan Peta Panas yang baru menggunakan kontrol Treemap dan Grid untuk secara visual mewakili keadaan Pasar saat ini dalam tata ruang yang efisien. Aplikasi dunia nyata dari sampel ini dapat mencakup dimasukkan ke dalam aplikasi lini bisnis atau aplikasi yang dihadapi oleh pelanggan eksternal. Aplikasi EarthQuake menyoroti penggunaan volume tinggi, data streaming real time dari layanan Survei Geologi AS, yang disajikan baik dalam bentuk geografis maupun kronologis. Dengan tampilan peta, aplikasi memplot lokasi aktivitas seismik baru-baru ini pada kontrol Peta Geografis dengan fungsi zoom dan panning. Pengguna juga dapat memfilter informasi tentang gempa berdasarkan wilayah, lokasi, dan besarnya. Dengan tampilan timeline, pengguna dapat memilih rentang waktu, menggunakan kontrol slider. Dengan kedua tampilan aplikasi ini, pengguna bisa mendapatkan informasi lebih rinci tentang kejadian seperti longitudelesitude, time dan data ilmiah lainnya. Auto Sales Dashboard adalah aplikasi interaktif yang menyoroti kemampuan kontrol Peta Geografis, Data Chart, Sparkline, dan Bullet Graph, yang digabungkan menjadi satu aplikasi. Dasbor menyediakan informasi penjualan dan pendapatan yang relevan dalam sekejap dalam format yang dirancang untuk manajer bisnis dalam pemasaran, manajemen produk, operasi dan penjualan. Bergantung pada pertanyaan bisnis, para manajer dapat memperoleh data agregat tingkat tinggi atau menelusuri spesifikasi penjualan berdasarkan wilayah, model, dealer, dan lini produk di berbagai interval waktu. Penjualan dan pendapatan dapat dilacak dari waktu ke waktu dan diukur terhadap tujuan yang ditetapkan. Aplikasi Equity Trading menyoroti penggunaan kontrol Infragistics yang diterapkan pada skenario yang sering terlihat di industri Jasa Keuangan. Aplikasi ini adalah platform perdagangan ekuitas dasar yang mencakup interaksi khas yang mungkin dilakukan trader dalam perjalanan kerja mereka dari penggunaan peta panas untuk meninjau kinerja industri dan sektor, menjelajah data harga saham real-time dengan presentasi data yang kaya, menganalisis historis Data harga saham menggunakan grafik yang sangat interaktif yang menampilkan indikator keuangan, dan akhirnya membeli dan menjual ekuitas sambil melihat grafik dengan harga saham potret secara real-time. Fungsi ini disampaikan dalam kontrol tata letak fleksibel yang disebut kontrol Manajer Tile, yang memungkinkan pengguna untuk mengubah ukuran dan mengatur berbagai modul aplikasi agar sesuai dengan alur kerja dan preferensi mereka. Pengguna juga dapat memaksimalkan ubin yang ingin mereka fokuskan, dengan sisa ubin yang diperkaya dengan rapi di satu sisi. Transisi antara perubahan genteng animasi memberikan pengalaman pengguna yang kaya dan interaktif. Aplikasi Bagan Pelabuhan Bagan menggambarkan penggunaan kontrol peta di luar solusi geografis yang khas. Kontrol peta memungkinkan implementasi yang mudah dari bagan tempat duduk maskapai interaktif yang menggunakan file bentuk yang disesuaikan. Bagan tempat duduk memberikan pandangan rinci tentang fasilitas penerbangan serta lokasi tempat duduk, kualitas dan ketersediaan. Selain hanya memetakan pesawat terbang, sampel InfraAir juga menyertakan grafik kepuasan pelanggan dalam aplikasi. Aplikasi Denah Lantai Rumah Sakit dirancang untuk menyoroti bagaimana file dan filter bentuk kustom dapat digunakan dalam lingkungan kesehatan untuk membangun sebuah aplikasi yang mendorong efisiensi dalam memantau pasien dan sumber daya. Aplikasi ini secara visual menggambarkan satu lantai rumah sakit, memberikan informasi rinci dan relevan tentang pasien dan staf mengenai kontrol Peta Geografis dengan mengubah elemen bentuk rumah sakit dari Cartesian menjadi sistem koordinat geografis. The Media Timeline adalah aplikasi yang ditargetkan konsumen yang menyoroti penggunaan hiburan dalam penggunaan lembur. Aplikasi ini menggunakan kontrol Timeline Infragistics untuk memungkinkan pengguna menjelajah dan memilih klip video. Mengambil umpan data dari sumber data YouTube publik, aplikasi ini secara visual menampilkan popularitas klip video berdasarkan berapa kali mereka telah dilihat. Klip tersebut dipesan berdasarkan kapan diterbitkan. Pengguna dapat memfilter relevansi, jumlah tampilan, tanggal yang dipublikasikan, atau melakukan pencarian kata kunci. WPF yang mati: masa sekarang dan masa depan WPF Introduction Sebagai pengembang WPF selama bertahun-tahun, saya baru-baru ini prihatin dengan arah baru yang dipilih oleh Microsoft pada platform kliennya. Dengan bangkitnya kerangka kerja baru WinRT. Saya prihatin dengan alasan yang bagus: Saya menderita kerusakan agunan akibat kegagalan Silverlight, dan seperti yang dikatakan pepatah yang digigit, dua kali tidak tahu apa-apa. Sejak 2009 saya telah menempatkan investasi pribadi dan profesional yang besar di WPF, menggunakannya untuk mengembangkan aplikasi LOB di industri keuangan, dan sekarang I8217m bahkan memberikan pelatihan mengenai topik ini. Jadi, sebagai pengembang dan pelatih profesional, masa depan WPF sangat penting bagi saya sehingga saya mempelajari masalah ini dengan lebih teliti. Pada artikel ini, saya akan berbagi temuan saya dengan Anda, secara objektif dan transparan, dan saya harap Anda bisa memberikan fakta Anda sendiri, sehingga masyarakat dapat memiliki visi masa depan WPF yang lebih baik. Pada bagian akhir artikel ini saya memberikan beberapa strategi untuk bisnis dan pengembang perorangan. Beberapa alasan untuk khawatir Pertama-tama saya akan mulai dengan menunjukkan tanda-tanda yang mengkhawatirkan saya, dan juga harus khawatir jika Anda adalah pemangku kepentingan WPF. Tim WPF team8217s menganggur Karena setiap tim teknis Microsoft, tim pengembang WPF memiliki sebuah blog tempat anggota tim saling berbagi pengetahuan tentang WPF dengan masyarakat. Artikel terakhir dari blog ini adalah tanggal dari Mei 2011 jadi lebih dari 3 tahun yang lalu. Tepatnya saat WinRT mulai muncul sebagai hal besar berikutnya. Sebuah blog yang menganggur bisa berarti banyak hal tapi tidak ada yang baik bagi IMHO: mungkin tim tersebut direduksi menjadi minimal dan menghidupkan blog ini bukanlah prioritas, mungkin anggota tim terbaik telah dipindahkan ke proyek lain seperti WinRT, dan mungkin Hal ini disengaja untuk mengirim sinyal ke masyarakat8230 Dalam hal hubungan masyarakat sebuah blog yang aktif sangat penting karena menunjukkan teknologinya berkembang dan dikembangkan oleh pengembang antusias untuk bangga dengan pekerjaan mereka dan bersedia membaginya dengan masyarakat. Perhatikan bahwa seringkali blog MSDN tidak terlalu aktif, blog Entity Framework menjadi salah satu pengecualian, berkat Rowan Miller yang secara teratur menerbitkan posting baru, dan ini adalah salah satu alasan utama mengapa saya menyukai teknologi ini: ini sedang dikembangkan oleh Orang yang brilian dan berkomitmen Toolkit WPF resmi tidak berfungsi WPF Toolkit adalah proyek sumber terbuka dan gratis yang dikembangkan oleh tim Microsoft dan dirancang sebagai anteroom dari rilis WPF resmi. Sebagai contoh, DataGrid tidak hadir dalam rilis awal (WPF 3.0 dan 3.5) namun tersedia di toolkit, dan akhirnya ditambahkan ke WPF 4.0. Toolkit resmi memainkan peran ini sampai 2010, namun sejak saat itu proyek ini menganggur, jadi sepertinya tidak ada lagi barang yang tersedia untuk rilis berikutnya. Tanda dari ketidakaktifan ini: untuk pencarian Toolkit8221 8220WPF Google menempatkan toolkit WPF resmi kedua setelah yang tidak resmi (lebih pada yang ini di bagian kedua). Tidak ada sertifikasi lagi Sertifikasi WPF resmi (70-511) tidak akan dilanjutkan dan akan berakhir pada musim panas 2015. Ini adalah tanda eksplisit yang kuat yang diberikan kepada pengembang bahwa mereka seharusnya tidak menginvestasikan lebih banyak waktu dalam teknologi ini dan malah mencurahkan waktu mereka ke WinRT yang mendapatkan keuntungan dari jalur sertifikasi khusus baru. Mungkin Microsoft akan mundur dan menunda penghapusan ini seperti halnya dengan sertifikasi lainnya setelah komunitas pengembang mengeluh, namun hal itu tidak mengubah faktanya WPF bukanlah prioritas lagi. Secara pribadi I8217m masih ragu untuk menyampaikannya karena saya tidak menjamin waktu dan uang (ya sebagai pengusaha saya membayar sertifikasi saya sendiri) layak dilakukan. Sebagai gantinya saya lebih memilih untuk mempersiapkan sertifikasi WinRT yang seharusnya ada di sana selama beberapa tahun. Tidak ada integrasi Windows 8 Jika Anda mengingat rilis WPF 4. Sebagian besar perangkat tambahan didedikasikan untuk integrasi Windows 7 seperti kustomisasi item taskbar (daftar loncat, kemajuan, overlay8230). Tidak ada hal seperti itu di WPF 4.5 untuk memungkinkan integrasi penuh ke fitur Windows 8 seperti bar pesona dan banyak kontrak aplikasi meskipun ada beberapa kemampuan antar-muka. Jadi, jika Microsoft tidak menginvestasikan integrasi ini, jelas sekali bahwa WPF bukan lagi warga kelas satu di Windows dan lebih suka mendedikasikan semua angkatan kerjanya kepada WinRT, dan menurut saya ini adalah keputusan yang masuk akal. Tidak ada dukungan untuk Windows RT Microsoft, yang secara historis merupakan vendor softwares. Melakukan diversifikasi bisnisnya dengan menjadi vendor perangkat keras. Menirukan pesaingnya Apple dan Samsung. Untuk tujuan ini, Microsoft telah mengakuisisi Nokia untuk mendapatkan keuntungan dari kehadirannya yang lama di pasar ponsel. Di sisi tablet dan laptop, untuk bersaing dengan tablet iPad dan laptop MacBook Pro, Microsoft telah meluncurkan seri Permukaan. Ada 2 versi Permukaan 1 dan 2 tergantung pada arsitektur perangkat keras: x86 dan ARM. Kemudian mendapatkan keuntungan dari versi Windows yang berdedikasi: Windows RT (jangan dikelirukan dengan WinRT yang merupakan lapisan perangkat lunak). Tapi Windows RT tidak mendukung (setidaknya secara resmi) API yang lebih tua seperti Win32 tua yang baik. Maka tidak mendukung semua 8220wrappers8221 seperti WinForms dan 8230 WPF. Jadi Anda tidak bisa menjalankan aplikasi WPF Anda di semua versi Permukaan. Dan jika Microsoft tidak menginvestasikannya hanya karena ia mencoba menyingkirkan Win32 untuk menggantinya dengan WinRT yang disesuaikan secara khusus untuk tren TI yang baru. Strategi Microsoft8217 yang baru Pada bulan februari 2014 Microsoft menamai seorang CEO baru. Satya Nadella. Yang berasal dari divisi cloud dari Microsoft. Dia menggantikan Steve Ballmer, yang tidak mengerti pasar ponsel baru (iPhone dan Android pertama) dan mungkin salah satu alasan Microsoft benar-benar merindukan kapal tersebut dan sekarang berjuang keras untuk mendapatkan tempat mengambil pangsa pasar ke pesaing (Apple, Samsung ) Persen setelah persen. Berlawanan dengan strategi global pendahulunya Satya Nadella8217s untuk Microsoft adalah 8220 cloud pertama dan mobile 8220 pertama, jadi keluar dari model desktop tradisional, dan sekali lagi ini adalah strategi yang sangat waras. Tapi justru WPF dirancang untuk model 8220old8221: aplikasi desktop gemuk, sedangkan WinRT menggunakan model yang sama sekali berbeda, dengan mempertimbangkan kebutuhan mobile baru. Tentu pasar desktop dan PC tidak mati, jauh dari itu, tapi bukan model predominan lagi. Dan Microsoft telah mempertimbangkan hal ini saat membangun WinRT karena sekarang Anda dapat menggunakan keseluruhan tumpukan HTMLCSSJS, termasuk kerangka kerja seperti Angular and Knockout, untuk mengembangkan aplikasi desktop sebuah tanda kuat yang memastikan bahwa teknologi web benar-benar menjadi ada di mana-mana (setelah Node di server). Toko Windows Agar bisa menangkap sebagian dari pendapatan vendor aplikasi, sebagian besar pemilik platform seperti pemilik Apple dan Microsoft telah membuat 8220 toko 8221 yang harus Anda gunakan untuk menerbitkan dan membeli aplikasi. Dan sayangnya AFAIK aplikasi Windows Store harus berbasis pada WinRT, jadi aplikasi WPF Anda tidak dapat digunakan melalui toko. Perhatikan bahwa ini bukan masalah bagi bisnis yang menerapkan aplikasi mereka secara internal dan tidak memerlukan toko, atau vendor aplikasi besar seperti ERP yang menggunakan saluran komersial mereka sendiri untuk menjual aplikasinya, namun ini adalah masalah jika Anda adalah vendor kecil yang Perlu visibilitas toko, sebelum pesaing makan saham pasar Anda. Semakin banyak orang menggunakan toko secara naluriah untuk mencari aplikasi baru sehingga hampir tidak ada jalan lain di sekitar mereka. Jadi jika Anda berniat mengembangkan aplikasi baru Anda di WPF, Anda akan mengalami kesulitan mendistribusikannya dan lebih sulit lagi jika Anda berniat menjualnya, jadi sebaiknya Anda menggunakan WinRT. Anda mungkin mengkonsumsi sebagian besar konten harian Anda melalui ponsel Anda menggunakan aplikasi web atau asli sehingga Anda dapat memahami betapa pentingnya saat ini untuk hadir di pasar ini: Anda harus menyediakan versi mobile aplikasi Anda. WPF tidak pernah menjadi platform pengembangan mobile dan bukan pemain di pasar ini, dan selama bertahun-tahun jawabannya adalah Silverlight untuk Windows Phone dan itu adalah toolkit referensi sampai Windows Phone 7. Namun menggunakan satu toolkit per platform tidaklah ideal, Meskipun Anda bisa berbagi sebagian besar kode prosedural dan markup. WinRT adalah jawaban untuk masalah ini karena ini adalah toolkit umum yang dirancang untuk memudahkan pengembangan pada semua platform Windows yang lebih dan lebih bersatu di tingkat OS dengan Windows 8. Perhatikan bahwa untuk pengembangan cross-platform yang benar-benar juga menargetkan Android et IOS Microsoft tidak menyediakan alat apapun, jadi Anda harus beralih ke Xamarin yang merupakan proyek yang sangat menjanjikan. Biaya pemeliharaan Jika Anda bekerja dengan teknologi Microsoft selama bertahun-tahun, Anda tahu bahwa Microsoft menghabiskan uangnya dengan hemat, dan untuk alasan yang bagus: pertama, sebagai perusahaan, perusahaan harus menghasilkan uang untuk bertahan dan pemegang saham saat ini meminta lebih banyak, jadi sepeser pun adalah satu sen, Kedua menerapkan bahkan fitur kecil itu mahal karena ada banyak langkah yang melibatkan Eric Lippert memberikan gambaran umum di posting blog ini: Berapa banyak karyawan Microsoft yang dibutuhkan untuk mengganti bola lampu. Jadi ketika masyarakat meminta perbaikan bug atau fitur baru, ini hanya diimplementasikan jika benar-benar hebat: 8211 sangat penting seperti pelanggaran keamanan, sehingga bahkan beberapa pengguna yang terkena dampak akan memicu implementasi 8211 atau yang kecil tapi mengganggu Banyak orang Mengembangkan WPF dan WinRT akan menyiratkan untuk menjawab kedua permintaan alat dan permintaan kedua toolkit1217 bug, ini jelas bukan pilihan, terutama karena Microsoft saat ini mengurangi tenaga kerjanya. Portabilitas Apa yang bisa dilakukan oleh WPF 8.220saved8221 adalah beberapa relung. misalnya Sebagai teknologi portable untuk mengembangkan aplikasi client, namun sayangnya hal ini tidak terjadi. Ada versi portabel (untuk menjadi bertele-tele, dari CLI): Mono. Yang berjalan di Windows tentu saja tapi juga di Linux. Unix dan Mac Dan Mono bukanlah teknologi mainan, itu benar-benar bekerja, dengan itu saya telah membangun server integrasi Jenkins di Ubuntu Server. Mono mendukung sebagian besar kerangka kerja stack tapi salah satu dari sedikit komponen yang hilang adalah WPF jika saya ingat dengan baik bahwa ada proyek bernama 8220Olive8221 untuk menerapkannya tetapi tidak pernah benar-benar dimulai karena karya besar yang diwakilinya, terutama pada lapisan rendering tingkat rendah . Satu-satunya teknologi UI yang diimplementasikan Mono adalah WinForms. Jadi ironisnya WinForms bisa bertahan WPF berkat portabilitasnya. Sindrom Silverlight yang pernah saya lakukan adalah pengembang Silverlight dan saya menemukan bahwa teknologi dapat lenyap lebih cepat daripada yang pernah saya duga sebelumnya. Kembali di 20082009: RIA adalah kata buzz, Microsoft mencitrakan kerangka kerjanya sendiri, Silverlight, di manajer bisnis melihatnya di acara Microsoft dan menginginkannya di ekosistem TI mereka. Jadi pada 2010 dan kuartal pertama tahun 2011 kami mulai mengembangkan aplikasi Silverlight. Tapi di suatu tempat pada tahun 2011 di salah satu acara teknis, mengenai web, Microsoft berhenti menempatkan Silverlight dalam sorotan, dan malah mulai mempromosikan ekosistem HTML5 (dengan CSS dan JS). Secara resmi, ceritanya tidak berubah untuk Silverlight, tapi saya cukup curiga, melaporkannya, dan tim kami memutuskan untuk menghentikan perkembangan Silverlight, yang sejauh ini tidak menyampaikan manfaat yang diharapkan (misalnya Silverlight bukan plug and play karena Anda memerlukannya Untuk menjadi administrator untuk menginstal pemain Silverlight :), malah berkonsentrasi pada WPF 8220traditional8221. Mudah-mudahan sebagian besar (mungkin 85) kode XAML dan C dibagikan dengan WPF, jadi tidak terlalu banyak yang benar-benar hilang, dan kami berhenti saat kami tidak terlalu banyak berkomitmen. Dan ini adalah pilihan yang tepat karena pada tahun 2013 kematian Silverlight diumumkan secara resmi, dan lebih dari satu pemangku kepentingan TI terkejut karena mereka tidak melihat tanda peringatan. Saya kira hal-hal yang akan menjadi kekerasan bagi WPF, tapi ketika Anda merasa kecewa, Anda berhenti menjadi naif dan cenderung menjadi tidak percaya, yang menurut saya merupakan kualitas dalam konteks TI saat ini. Beberapa alasan untuk tidak panik Setelah membaca bagian pertama Anda mungkin mulai panik tapi karena sering hal-hal tidak benar-benar hitam, warnanya abu-abu, sedikit lebih abu-abu gelap. Bagian kedua ini akan membantu Anda mencampur warna putih dengan warna hitam, jadi teruslah membaca8230 Masih tim yang aktif Menurut Greg Levenhagen (Apakah WPF Dead NO) masih ada tim pengembangan aktif yang didedikasikan untuk WPF. Greg tidak memberikan angka yang sulit sehingga sulit mengukur usaha pengembangan. Meski jelas, Microsoft tidak akan meninggalkan teknologi yang digunakan jutaan orang, karena pengembang yang berdedikasi, tidak bergabung dalam tim lain, adalah hal yang baik. Dan tetap menurut Greg tim ini tidak hanya didedikasikan untuk pemeliharaan versi yang ada tapi juga menyiapkan setidaknya rilis berikutnya (WPF 5). Tanpa perubahan-perubahan versi ini, sulit untuk terlalu optimis: mungkin ini hanya versi perbaikan bug dan peningkatan kinerja tanpa fitur utama. Masih merupakan upaya pengembangan Update 2014-11 Pada bulan november 2014 tim WPF menerbitkan sebuah artikel, The Roadmap for WPF. Menunjukkan bahwa WPF masih aktif dikembangkan. Tim ini terutama mengerjakan isu-isu penting seperti pertunjukan, yang terus ditingkatkan sejak dimulainya WPF, dan perkakas terintegrasi sepenuhnya ke dalam Visual Studio. Mungkin perangkat tambahan yang lebih penting adalah dukungan penuh layar sentuh dan high-density. Mengapa begitu signifikan. Karena ini adalah fitur perangkat seperti tablet dan ponsel, dan WPF dijatuhkan pada WinRT justru karena nantinya telah dirancang khusus untuk perangkat tersebut. Ini mungkin bukan omong kosong lengkap dari Microsoft yang mendukung WPF, namun ini menunjukkan bahwa Microsoft telah mendengar dan memperhitungkan klaim komunitas tersebut. Untuk informasi lebih lanjut, periksa video yang bagus ini dengan dua pengembang WPF: Masa Depan WPF di Saluran 9. Alat baru versi I8217 melihat tanda positif pada sisi perkakas resmi: Prism. Seperangkat alat dan praktik terbaik untuk mengembangkan aplikasi XAML, telah diperbarui ke versi 5 dan bersamaan dengan versi WinRT, ia menyediakan versi baru untuk WPF. Seperti yang dikatakan di bagian pertama, toolkit WPF resmi tidak berfungsi tapi proyek lain mengambil obor: Extended WPF Toolkit. Ini sedang dikembangkan oleh vendor extension8217 yang terkenal, Xceed. Jadi oleh para ahli WPF (dan teknologi Windows lainnya), dan ini sangat kaya dengan banyak kontrol tambahan, dan yang terpenting proyek ini dikembangkan secara aktif, versi terbaru mulai Juni 2014, jadi kurang dari 3 bulan yang lalu pada Tulisan ini Akhirnya dua kerangka MVVM teratas. MVVM Light Toolkit dan Caliburn. Micro. Aktif, versi baru berumur 3 bulan. Jadi ekosistem alat WPF masih hidup dan berkembang yang sangat meyakinkan bagi bisnis karena tidak ditinggalkan dengan serangkaian proyek yang tidak terawat. Perubahan manajemen Pada akhir tahun 2012 Steven Sinofsky. Saat ini menjabat Presiden Divisi Windows. Meninggalkan Microsoft Mengapa ini pertanda positif bagi WPF Karena Steven Sinofsky terkenal karena membenci dan tidak bermain baik dengan tim lain (mungkin alasan utama kepergiannya). Dan ini sebagian akan menjelaskan, bersama dengan beberapa alasan teknis yang nyata, mengapa tidak digunakan sebagai fondasi dari versi Windows berikutnya, padahal ini adalah salah satu perangkat lunak terbaik yang pernah dibuat oleh Microsoft. Dari luar sulit untuk mengevaluasi bagian dari gosip dan perasaan sebenarnya dari Steven Sinofsky dan dampaknya terhadap keputusan desain untuk Windows 8. Inertia pasar OS Hal lain yang bagus untuk WPF adalah kenyataan bahwa bisnis dan individu tidak segera bermigrasi ke setiap merek. Versi OS baru Dan karena banyak alasan bagus: harganya mahal, butuh beberapa waktu, itu berisiko, dan seringkali tidak berguna. Migrasi ke OS baru adalah tugas yang sangat menakutkan karena kebutuhan untuk memastikan kompatibilitas aplikasi: yang disediakan oleh vendor eksternal seperti Microsoft dengan Office dan yang dikembangkan oleh tim internal, dan dari pengalaman saya itu adalah proses yang dapat dengan mudah dilakukan. 2 tahun. Saat ini (pertengahan 2014) pangsa pasar WinRT di pasar PC cukup berkurang: 8211 Windows 8 8.1. Windows 7 8211 Windows 7. 55 8211 Windows 7. 5 8211 Windows XP. 25 Jadi untuk lebih dari 80 PC Anda tidak dapat menggunakan WinRT dan tidak memiliki pilihan lain selain WPF. Dan dalam beberapa hal ini paling buruk untuk Windows 8: di perusahaan yang saya kenal di sektor keuangan di Prancis, ini hanya 0, migrasi ke Windows 7 bahkan tidak selesai di mana-mana, dan saya tahu beberapa masih berjalan dengan Windows XP karena penyiapan Aplikasi tidak sepele. Mengingat siklus pembaharuannya sekitar 5 tahun WPF harus menjadi pilihan unik bagi banyak bisnis hingga akhir dekade ini. Inertia ALM Seperti yang mungkin Anda ketahui, aplikasi pensiun mahal. Pertama Anda memiliki studi pendahuluan dengan sekelompok pertemuan untuk menilai dampaknya terhadap bisnis ini, dan Anda harus bekerja keras untuk meyakinkan beberapa pengguna yang kadang-kadang akan memasukkan joker berisiko tinggi ke meja maka Anda harus menggantinya dengan merek. Aplikasi baru dan Anda harus memastikan tidak ada regresi, sering kali menjalankan versi lama dan baru berdampingan selama periode waktu tertentu sebelum benar-benar beralih apalagi Anda mungkin harus memanggil tim DB Anda untuk memigrasikan data, tim jaringan ke Menyesuaikan peraturan firewall8230 It8217s mengapa bisnis memigrasikan aplikasi hanya jika ada alasan bisnis yang valid, dan lapisan teknis baru bukanlah satu, jadi aplikasi WPF yang ada sekarang. Dan ada banyak, di sini untuk tinggal. Dan itu berarti keterampilan WPF akan dibutuhkan di masa yang akan datang, lihat saja jumlah aplikasi WinForms yang masih ada di alam liar, dan yang baru dikembangkan setiap hari, sedangkan WPF tersedia untuk menggantikannya sejak tahun 2006. Dan dari sebuah aplikasi Sudut pandang teknis, sementara WPF dan WinRT sangat mirip, tidak sepenuhnya kompatibel: masih ada fitur yang hilang di WinRT 8.1 dan beberapa keunikan: untuk memetakan namespace ke XAML Anda menggunakan namespace clr di WPF dan menggunakan di WinRT, ini Cukup untuk memecahkan kompatibilitas XAML dan mencegah kemauan yang sulit untuk melompat WPF sudah matang Penurunan penting yang nyata dari upaya pengembangan WPF dapat mengkhawatirkan tapi IMHO hanya mengikuti jalan alami yang telah dilakukan setiap pengembang: upaya besar untuk mengembangkan yang pertama Lepaskan, maka tetaplah upaya berkelanjutan untuk rilis berikut yang mendapat manfaat dari umpan balik masyarakat, dan akhirnya usaha minimal untuk mempertahankan aplikasinya. Ini adalah jalur yang diikuti oleh WPF dengan versi pertama (WPF 3.0 (untuk saya lebih merupakan versi beta) dan 3.5) membawa cara baru untuk mengembangkan aplikasi Windows, lalu WPF 4 memperkenalkan beberapa kontrol baru yang dipindahkan dari toolkit, seperti Datagrid Dan peningkatan kinerja, dan akhirnya WPF 4,5 memperkenalkan Ribbon dan masih beberapa peningkatan kinerja. Jadi teknologi yang lebih matang adalah usaha pengembangan yang kurang yang dibutuhkannya, dan setelah 8 tahun WPF adalah teknologi yang benar-benar matang, kebutuhan akan fitur baru dan perbaikan bug berkurang. Dan mungkin WPF sekarang memasuki tahap pemeliharaan siklus hidupnya sehingga tidak mengharapkan perkembangan ingar-bingar. Ceruk LOB Jika ada domain dimana WPF bisa bertahan dan bahkan terus bersinar ini adalah aplikasi LOB (Line of Business). Pertama karena sebagian besar keahlian untuk mengembangkannya didasarkan pada platform dewasa yang dimiliki banyak perusahaan yang menggunakan Windows untuk mengembangkan aplikasi LOB mereka dan tidak lagi memanfaatkannya, namun memanfaatkannya sebaik mungkin. Dan beberapa alat utama belum tersedia untuk WinRT. misalnya ORM seperti NHibernate atau Entity Framework. Yang diperlukan untuk sebagian besar aplikasi LOB untuk mengakses data relasional mereka. Kedua untuk beberapa aplikasi LOB besar seperti platform perdagangan, tidak ada gunanya menggunakan WinRT karena Anda tidak perlu dan bahkan tidak menginginkannya, karena alasan keamanan, mobilitas. Dan aplikasi besar semacam ini bahkan bertentangan dengan pedoman resmi Microsoft untuk merancang aplikasi WinRT: mereka harus fokus dengan seperangkat data minimal di layar. Windows Forms integration Selama lebih dari 10 tahun banyak bisnis telah menciptakan banyak aplikasi WinForms. Dan aplikasi baru masih dikembangkan dengan WinForms, meski WPF berada di sana selama 8 tahun sebagai penggantinya. Tentu saja bisnis tidak ingin membuang semua aplikasi, komponen dan keahlian ini hanya untuk menggunakan mainan baru, mereka ingin memanfaatkan investasi mereka sebanyak mungkin. Dan AFAIK WinRT belum bisa mengintegrasikan komponen WinForms. Jadi menggunakan WinRT bukanlah pilihan jika Anda ingin mendapatkan keuntungan dari investasi WinForms Anda. Sebaliknya WPF telah dirancang sejak awal untuk memungkinkan integrasi WinForms. Menggunakan WindowsFormsHost Anda dapat menanamkan komponen WinForms di dalam aplikasi WPF Anda. Dan lebih baik lagi, Anda bahkan bisa mengintegrasikan komponen WPF di dalam aplikasi WinForms menggunakan ElementHost. Sehingga Anda bisa bermigrasi perlahan ke WPF untuk menghindari efek big-bang. Kurva belajar Jika Anda adalah pengembang WPF berpengalaman tanpa menyadarinya, Anda mungkin sudah menjadi pengembang WinRT di kelas 80, dan jika Anda adalah bisnis, Anda sudah memiliki 80 keahlian untuk mengembangkan aplikasi WinRT yang tersedia. Alasannya adalah bahwa sebagian besar alat dasar untuk mengembangkan aplikasi WPF sama untuk WinRT: 8211 bahasa prosedural yang sama: C, VB8230 8211 bahasa markup yang sama: XAML, 8211 cara yang sama untuk menghubungkan tampilan ke data: pengikatan data, DataTemplates8230 8211 arsitektur serupa Aplikasi, struktur global, sumber daya8230 8211 pola dan implementasi pola yang sama: MVVM, INotifyPropertyChanged, INotifyCollectionChanged, ICommand8230 Jadi, sebagian besar investasi Anda di platform XAML lainnya seperti WPF dan Silverlight dapat dimanfaatkan untuk WinRT, mengurangi kecuraman kurva belajar (ingatlah Salah satu WPF saat Anda masih pemula)) WPF kaya WinRT bukanlah tiruan WPF dan beberapa fitur belum diimplementasikan, jadi jika Anda hanya mengembangkan aplikasi desktop dari segi kemampuan teknis WPF masih lebih baik. Tapi saya memasukkannya sebagai yang terakhir karena IMHO tidak begitu penting, dan karena WinRT akan melanjutkan evolusinya, celahnya akan menjadi lebih kecil dan lebih kecil, tapi saya kira beberapa pengembang dengan kebutuhan spesifik pasti tidak dapat berkembang dengan WinRT dan akan membutuhkan WPF. Tapi sekali lagi nilai tambah WinRT tidak dalam kekayaan teknis intrinsiknya namun lebih pada model pengembangan yang ditawarkannya dengan akses ke platform mobile dan toko Windows. Strategi untuk masa depan Apakah Anda seorang bisnis atau pengembang individual, Anda harus mempertimbangkan secara serius untuk memperlambat investasi teknis Anda di WPF, dan mulai membangun keahlian Anda di WinRT. Bisnis Sebagai bisnis, Anda bisa menghentikan perkembangan WPF Anda selama Anda memiliki beberapa versi Windows yang lebih tua, termasuk Windows 7. Mengenai aplikasi Anda yang ada, jangan khawatir, Anda tidak perlu memigrasikannya ke WinRT, kecuali jika Anda ingin mendapatkan keuntungan dari Kemampuan baru sebagai penggelaran melalui toko Windows. Memang Microsoft harus memastikan dukungan untuk WPF untuk kompatibilitas ke masa depan yang akan datang ke depan adalah sesuatu yang benar-benar dibutuhkan Microsoft. Sebagai contoh sementara mungkin lebih sulit untuk mensetup lingkungan VB6 di versi Windows yang baru, hal itu masih mungkin dan, karenanya penyiapan, aplikasi Anda harus terus bekerja dengan lancar. Depending on your available IT workforce, you should devote time to technology intelligence and have some developers starting to think about WinRT: how you could benefit from it, typically to broaden your audience, how new applications should be developed, how the existing tools and code can be reused, what are the potential issues to anticipate8230 For the applications that could benefit from WinRT for mobile and tablet you can start building some migration path, which is not that obvious because WinRT is missing many features from WPF. Start to develop proof-of-concept applications to validate the new technology in your particular context and see for yourself if it delivers. Developers As developers we don8217t want to have technical skills nobody needs, and instead we generally must build a large enough portfolio of skills to accommodate the more businesses and projects we can to reduce the risk of being left behind. So if you are an experienced WPF developer and you have to choose between extending your WPF skills to become an expert or starting to gain new skills for WinRT development then IMHO you should choose the second option. Of course you8217ll probably be able to do both like me, but WinRT should be somewhere on your TODO list but not your priority either. Or you could continue in WPF waiting for the market to lack WPF developers, like is the case for older technologies like COBOL and VB6, but I fear you8217ll have to wait a decade before it happens, because, with the important development of IT in businesses, for any technology there is a lot of developers on the market, particularly for mainstream technologies like WPF, so I wouldn8217t count on it. Don8217t be demoralized or upset by this nth brand new technology, this is the business model of our industry: it needs to create new things all the time (remember SOA that poured a ton of money from businesses to the pockets of IT companies, their employees, their shareholders and contractors) to sell them to customers just as Apple does with its iPhone 1, 2, 3, 8230 and now 6 and soon 42, this is how it works and fortunately we, as developers, are on the good side of the barrier, we can make a living from this entropy, and objectively all these new technologies enhance the life of businesses and individuals. Conclusion I think that the sum of all these facts is pretty clear: WPF is past and present . in the near future it will be in direct competition with WinRT, but later if WinRT gets some traction and enough market shares then WPF may become kind of deprecated like VB6 or WinForms . Above all don8217t be in denial, and have a clear picture of what happens, do not eliminate the pessimistic facts from your mind. Do not expect a revival of WPF, there is no such thing in IT (well OK COM is kind of back in WinRT )), WPF is objectively not tailored for the new trends, the brand new stuff is. Of course the picture is not all black: WPF is not dead and obsolete nor dying and obsolescent . it has just reached its peak and might slowly fade as the businesses migrate their infrastructure to Windows 8 allowing them to choose WinRT for their future developments. Be pragmatic and transparent . use WPF while it brings value to your clients and warn them about these facts, and help them prepare for the future. I8217ve myself updated my training material by interleaving WinRT chunks in my WPF training, and adding a slide with a summary of these facts, highlighting them depending on their significance. But IMHO you should not invest too much in WinRT either. Why Because the more I play with WinRT and think about it the more I see it less and less useful: if you develop a LOB application, your only target is probably Windows PC, and you need to be compatible with pre Windows 8 systems, at least Windows 7, so WinRT is clearly not an option, and you must use WPF, if you want to target tablets and phones you can8217t forget about 90 of the market, iOS and Android, so WinRT is not an option, and you must use either the web stack (JavaScriptHTMLCSS) or native cross-platform frameworks like Xamarin (C) or QT (C). So for most use-cases WinRT is not an option. Moreover you should note that Microsoft is heavily investing in the later technologies. It8217s probably too early to ask yourself 8220 Is WinRT (as a final developer platform) dead 8221 but I would be quite surprised if WinRT manages to get some traction and becomes a major development platform. IMHO WinRT is only a good platform for the Microsoft teams because it allows them to share code between the different flavors of the Windows OS, mimicking the effort of Apple but for the final developer the use-cases for WinRT are way too limited: sharing some code between PC, tablets and phones but only for Windows devices. Probably some businesses may need only that but I doubt there is many because nowadays applications are often accessed from personal employees8217 devices (BYOD) which can be anything and probably some iOS or Android. 107 thoughts on ldquo Is WPF dead: the present and future of WPF rdquo Thanks for writing on this subject. You8217re spot on. What Microsoft learned from VB6 depreciation was to not announce the end of software in public. So instead of officially depreciate any software they downsize the group of developers, release some maintenance version and perhaps some fixes and slowly abandon the software and move on. Unlike in the past the life cycle for software have dramatically been shorter and it seems to continue to decrease. For individual developers who put time, money and efforts to learn to use various development tools the situation is quite challenging. The only advice I see is to learn a new languagedevelopment platform enough to ship reliable customers8217 solutions but don8217t dig deeper. Thanks for your feedback Dennis. Knowing multiple technologies without being an expert in each is indeed a sane strategy but I don8217t think it8217s the only one. Mine is to become an expert in a few technologies that are widely used. Of course it is far from perfect: I am overqualified for some services, and sometimes I have to renounce to good opportunities because I feel too weak on some subject. My hope is that the current web stack (HTMLCSSJS) will become the universal platform and that somewhere in the future we8217ll be able to concentrate on only this one. Well I don8217t think this will happen tomorrow. Too bad the current web stack is so unpleasant to work with. It was true 3 years ago but now you have : 8211 mature frameworks like AngularJS Bootstrap 8211 powerful IDEs like WebStorm and soon Visual Studio 8211 a lot of production-ready libraries 8211 testing and profiling tools integrated in IDEs or web browsers So IMHO now you can be really productive and develop seamlessly using the web stack and benefit from its portability. I can only agree with You. Looking around the web stack has the highest possible ROI. I8217ld like to offer my 2p here8230 Will WPF one day become as obsolete as VB6 Off course. Is WinRT any different Or any other currently widespread technology Here8217s the thing, ALL dev technology deprecates over time. WPF still has years of life ahead. Easily another decade. I know you didn8217t declare 8220wpf is dead8221 (eventhough you kind of announce it for the not-so-distant future), but lot8217s of people do. How many years ago did we see articles like this concerning WinForms Is WinForms dead today Most people indeed will go for WPF when doing a desktop app. Yet, WinForms still is pretty much a viable alternative and indeed is used a lot more then most people think. The only msft tech today that is truelly abbandoned (concerning this family of languages) is VB6. And even that took a long time. Silverlight is somewhat of an exception here. And probably msft is to blame for that. They announced pretty boldly themselves that the tech was dead. Which is why it died so fast. STILL, I am aware of new projects being developed today using the language. All this, just to say that every time someone announces such a death, I take it with plenty of grains of salt. Having said that, let8217s look at the future of computing. No matter what the current hype is, the desktop really isn8217t going to go away any time soon. In fact, the entire buzz about windows 9, is that it will give plenty of love to the traditional desktop user. In fact, we barely hear anything about 9 and hybrids or tablets or whatever. It8217s all about the desktop. WinRT apps will run in windows on the desktop, true. But let8217s be serious here8230 WinRT still has a long, long way to go in order to match the power, flexibility and feature richness of a mature technology like WPF. Not to mention the freedom one has in WPF world compared to the closed sandbox that is the WinRT app. While it is clear indeed that just about any and all effort these days at msft is going into the whole cloudstoreWinRT stuff, the fact of the matter is that today, there is no viable alternative to WPF if your app requires the power that it provides. And I don8217t see that changing any time soon either. I also feel like the whole WinRT platform is still in some kind of RampD stage. It doesn8217t feel mature at all. So to sum up8230. in terms of WPF becoming obsolete (which, again, is inevitable, just like it is inevitable that WinRT will become obsolete one day as well). I think that won8217t be happening for at least another decade. And to close off, as a developer, the worst thing you can do imo, is to put all your eggs in a single basket. Thanks for your feedback DogmaHunter . I agree on all your points I too believe WPF is here for at least another decade, as for WinRT I too think it is still not finalized and Microsoft did what it always does: it named the alpha version 1.0 (WinRT 8) with a lot of missing features, then the beta was named version 2.0 (WinRT 8.1) with almost all the features but changing a bunch of stuff from the previous one, the final version should be the next one. WinRT is not ready for the LOB applications, WPF is still king diversifying its technical investment is critical for businesses and individuals The STL, Win32 and Boost take issue with your position. It was clear from the beginning that WPF was going to be another Microsoft failure. It was never really needed 8211 probably a bunch of new intakes that wanted to try something new and replace other established and OK Windows runtimes, not because it was needed but because they could (or some may argue couldn8217t). Company made the decision to stick with the old tried and tested GDI, Runtimes and MFC if using C instead of c. Nice thing is we can also support other operating systems if not using totally Microsoft technology. With Microsoft technology avoid being a first adopter, in fact often best not to adopt at all 8211 Wait awhile and you will realize it was the right decision not to adopt Thanks for your sarcastic feedback. I8217ve worked in a team that progressively adopted WPF quite lately (2010), coming from all WinForms (and was still developing a new application with it in 2012). And while the initial effort was important due to the richness of WPF, it finally paid. One of the best benefit is how it has changed the way of building the UI: with WinForms I was the only one to never use the VS designer because it generates bunch of useless code and make versioning your files harder and sometimes simply a mess, but with WPF everybody started to write XAML code directly as it is quite instinctive and was less in panic when the VS designer crashed. Moreover WPF came with some patterns and best practices like MVVM so every project has a similar aspect: I8217ve seen a lot of projects from different companies and industries and they often look the same: put your views here, your VMs there, set your DC this way, bind this way8230 Finally the easy customization was really useful: we didn8217t do any fancy animations or stuff like that but needed some minor visual adjustments, with WinForms it was a pain in the a, often overriding OnRender, whereas with WPF we could do them in a clean and quick way (yes traders are often impatient people )) I don8217t say that what was true for this team would be true for all other teams, but WPF can be a really profitable investment for a development team. Excellent article. I8217d go a step further and say that WinRT is NOT going to be a major player in the future. As much as I don8217t like JavaScript I think it8217s the future. Microsoft has spent too much time following the industry instead of leading it. 10 years from now Windows XX could be a thing of the past also. Looks to me like the browser is the future for LOB and not Windows. Even C looks to be headed for the back-end just like C amp C. The only MS tool we are currently using for new projects is Visual Studio with the Nodejs beta plug-in (and it8217s really nice). A few years ago we were 100 MS house. Tepuk tangan. Thanks Charlie for sharing your perspectives. The success of WinRT will greatly depend on the success of Microsoft in the mobiles and tablets market. And yes concerning these markets Microsoft is following trends, initiated by the competition, it has no control on. As for LOB I think we are at a turning point: JS client frameworks, like Angular, are now offering most of what desktop technologies can offer like data-binding so they effectively become credible alternatives. But there is some limits like interop with the Office suite. Moreover there is few developers knowing both LOB development and web development, these are two worlds that are just starting to meet, so we are years from a massive adoption of the web stack for LOB application development. 8220Moreover there is few developers knowing both LOB development and web development, these are two worlds that are just starting to meet82308221 Beautifully said. This is why I8217m currently on the fence and am reading your articles 8211 I don8217t want to learn web technologies beyond ASP and webservices for what I do. If that8217s where things are headed, however, then it8217s something I8217m just going to have to do. Back to research, thanks all for this great topic Investing in the HTMLCSSJS stack is a safe bet, it8217s the only one I expect to be there and flourishing in the long term. As of now native mobile technologies have a lot of success due to the limitations of the web stack but as the latter evolves I see no reason it wouldn8217t replace native platforms and become universal. Personally I think WinRT is so fully gimped it will be impossible to save. I8217ve ported one of our WPF apps over to it and it was one of the most horrible experiences in recent memory. I really did feel like I was back in the 1990s doing COM programming in MFC8230 the fact that it used XAML was kinda irrelevant because they forced you to use their boiler plate generated code and heaven help you if you try to deviate from it. I tried to use an MVVM pattern and create my own ViewModel as I would in WPF and all kinds of horrible things happened because their navigation was partially unloading resources on me. The only way we finally got things to work was to go back with the unchanged generated code. MFC was the same way, lots of code generated for you, and you better FULLY understand the inner workings if you planned to do anything other than say 8220I believe8221 and take what they had. Long and short of it is that I hated every minute of my WinRT experience. If MS decides this is the future, then once WPF finally goes to pasture I8217ll switch to JavaScript or something, but I doubt I will ever go into the horrible WinRT world ever again. Thanks John for sharing this experience. Indeed WinRT is not yet a mature and LOB ready platform, and you8217ve paid the price for being an early adopter. On the longer term your decision to switch to the web stack is the right one, and a lot of WPF developers I know are going this way too. Because we all want and need a stable, rich and interoperable platform to develop our future applications, and neither WPF nor WinRT have all these qualities. I know only 3 platforms that can pretend to be this universal platform: the web HTMLCSSJS stack (the king IMHO), Xamarin (for C developers) and Qt (for C developers). Your statement: 8220While its obvious Microsoft wouldnt abandon a technology used by millions of people, having dedicated developers, not merged in other teams, is a good thing.8221 already happened to VB6. They killed VB6 used by untold more millions with no easy migration path. I will never use anything Microsoft for development. Not that I think VB6 is the pinnacle of languages, it gets the job done and quickly. The rewrite of working code would cost my company a lot of time to get back what I started with. Big negative ROI on that task so I cross my fingers that it keeps working every 8220service pack8221 and OS release. When I am finally forced to rewrite there will 0 Microsoft content. Just updating PCs from XP to Win 7 requires a complete install of apps, tool chains and everything. If you are going to support something for the long run, MSFT is not your friend. Thanks for your feedback Dave. VB6 has never been completely abandoned by Microsoft which at least takes care of ensuring the old applications can still run on new Windows versions, though it8217s true the setup can be difficult. I completely understand your disenchantment concerning Microsoft technologies but IMHO this is true whatever the technology, the proprietary vendor or the open-source community: sometimes technologies don8217t match the current people needs anymore so they fade replaced by better technologies. Well at least for open-source technologies it8217s true that stakeholders can maintain the product themselves without relying on the good will of another company. I8217ve never been a VB6 developer but from what I8217ve seen and heard is way better as a development platform, and C is a better language than VB. Yes, WPF is dead. I didn8217t go down that path because there8217s nothing really useful in WPF from a conventional line of business app development perspective. There8217s nothing it does that benefits significantly over Winforms and the learning curve is steep and unnecessary. Silverlight I avoided also. Have you noticed how Microsoft does not have ANY RELEVANT UI strategy right now HTML5 is not a strategy. It is a 8220following along behind everyone else8221 non-action and is a disastrous path that gives up any and all GUI and application leadership. They8217ve deprecated the desktop also, which is quite stupid, and are busily running around in 8220me too8221 circles. When is this going to end. Thanks for sharing your opinion Grant but I disagree on the added value of WPF. As a former WinForms developer I8217ve found a lot of useful features in WPF like XAML, generalized data-binding support, templating, easier customization8230 As for Microsoft strategy times are hard for them because they8217ve missed the boat of web and mobile, the main invoked reasons is a poor management that didn8217t understood what was happening just in front of their window (pun intended )) The question is more 8220how is this going to end8221, because in an open environment like the current web ecosystem there is some competition so only the best will survive. With C it was easy to be the best when you are the creator and owner of the technology only time will tell if there is still some innovation abilities inside Microsoft: if so they will take a big share of the web IDEs markets with Visual Studio. I think that Microsoft has some savoir-faire in this domain it could leverage, but for sure in the web environment it will be the end of easy money with customers having no alternatives. And it8217s probably a good thing because when you are an annuitant you don8217t need to innovate and let your customers with old tools, IE has started to evolve only when some competition was created with Firefox. Wait and see8230 A great post, thanks for taking the time to put it together. I am in the position at the moment of choosing technology for a range of LOB applications and have been having this discussion with myself. WinRT seems desirable in many ways but is still so very embryonic. I can8217t really see how it could support a true heavyweight application 8211 yet 8211 so I feel compelled to use WPF and it makes me a bit uncomfortable. Great read though 8211 food for thought. Thanks for your kind feedback Marcus. You are right, WinRT is not ready for prime-time in the LOB market, and this is not its current target. As of now WinRT is relevant only if you want to reach the Windows mobile market. So unless your applications are not too complicated or the mobile market is a prerequisite you probably should use WPF. Knockout js. written by a microsoft person is what wpf could have been. Sederhana. useful, intuitive. Compare the plumbing for a button command for example. With WinRT you can now use the whole HTMLCSSJS stack, including frameworks like Knockout, to develop desktop applications. So it8217s a sign web technologies are really ubiquitous (after Node on the server). Why do you keep specifying 8220after Node on the server8221 Sorry, little new to the web-side of things. I mean that JS is everywhere: on the web client side of course, then with Node on the server side, and now with WinRT even on the desktop client side. Coding for 15 years. I never work in the same arena more than a year or two. That8217s enough to keep fresh with each tech change. Hell, don8217t even stay doing mobile, eCommerce or web advertising too long. Once you8217ve used a dozen or so languages, everything becomes the same. This is a way of working in the IT industry but not the only one, becoming an expert in a popular technology is another sane one. And I agree practicing many languages and technologies is excellent to put things in perspective. I was surprised to encounter this article tonight, because I would8217ve sworn I8217d read four or five years ago that WPF was discontinued-and-deprecated by Microsoft. Maybe I misremember. Chris I think the only sensible hypothesis to explain this is that you are a time traveler. Bonne analyse, le constat est bien vu. Sinofsky, dans son mpris pour tout ce qui est , a t le principal responsable des affres de WPF. Je doute en revanche que WinRT soit la voie du futur pour les applis LOB. Les botes qui ont lourdement investi en dv MS se dirigent plus vers des applis asp MVC avec le plus possible de composants open source (micro-ORM pour les donnes, js framework pour le client) Merci du feedback Henri. Au vu de son volution rapide il est difficile de vraiment anticiper ce que sera WinRT dans le futur, peut tre deviendra t8217il finalement dans quelques annes une alternative crdible WPF8230 Quant au remplacement par des applications web, notamment ASP MVC, je pense qu8217on est encore loin d8217un mouvement de masse, en grande partie parce que le savoir-faire web n8217est pas le mme, et si en plus on veut avoir une exprience riche il faut partir sur du RIA avec HTMLCSSJSAngular et l c8217est encore plus spcifique. Autant quand le dveloppement est externalis il 8220suffit8221 de demander d8217autres profils pour changer de voie, autant pour les dveloppements raliss en interne il faut dpenser pour se mettre niveau, notamment en formations. Taking a step back and looking at the whole desktop picture, my feeling is that Microsoft has been slowing abandoning the desktop. I sell COM add-ins for Excel, and when you8217re an small ISV you strive to reach as wide a market as possible. I would analyze my log files and generate data on the market penetration levels of the NET framework versions for my visitors (extrapolated from IE users). It wasn8217t until a few years ago that I felt comfortable moving beyond 2.0. The varying availability of various framework versions, the soft dropping of Winforms, the hard dropping of Silverlight, the questionable future of WPF, and the introduction WinRT all point to an inconsistent approach to providing desktop development tools that span the Windows versions seen out in the world. The kicker, though, is when they dropped setup projects from Visual Studio 2012. Microsoft8217s new strategy is mobile cloud first. The desktop is an afterthought, which is sad because it8217s one of Microsoft8217s core strengths, and instead of playing to it, they are trying to be a market follower in the areas that other companies excel at. Thanks for your feedback Nicholas, I completely agree with you. Times will be harder for Microsoft: the model where it was king, desktop, is losing ground, and it understood the rise of the newcomer, mobile, too late. But there is still some niches where Microsoft is king like spreadsheets with Excel. I wonder if there is any chance one day you could deploy your addins through the Windows Store8230 Nice succinct article, sums up the situation very well. We8217ve been developing a massive system in Silverlight for the last 3.5 years, had only just begun to commercialise the damn thing when Microsoft started killing poor wee Silverlight off, slowly and painfully, like dragging an outlaw through the desert using a turtle that has a benzo habit. It has been an exercise in frustration for us 8211 Silverlight is essentially the perfect platform for our system as it works in a browser, has very low cost of ownership and supports both cloud and internal deployment models on a very wide variety of operating systems. The sophistication of C XAML combined with extensive 3rd party libraries (Telerik, ComponentOne, Xceed, etc) has enabled us to develop an application with very complex features. I8217m also a web developer of 10 years and have plenty of experience with the browser stack, and the thought of trying to rebuild this thing using JavaScript CSS HTML scares the living crap out of me. Yes, we have already prototyped using Angular Kendo LESS TypeScript, and for me, the reality is that web development is just not good enough yet 8211 the number of technologies that you need to be proficient with to achieve highly complex results is staggering, and even then we still can8217t do everything we can do in Silverlight just with XAML and C. WinRT is just not an option 8211 if we limited ourselves to Windows 8.1 market share in the enterprise, well, we might as well just turn the lights off, sell up and move to Bermuda. That8217s before even looking at the capabilities of the platform itself. We8217ve looked at WPF as a mitigation strategy, simply because it would not be an enormous job to enable WPF compatibility, even though it is certainly not part of our long term strategy because we ultimately intend to be a cloud-based service provider and WPF simply doesn8217t fit into this world. If Silverlight was no longer an option and we were struggling then WPF could at least help us out while we transitioned to other platforms. So right now we are sticking to our guns on Silverlight for the next 4-5 years, and in the meantime we really have no choice but to start re-developing the client layer using a browser stack, with the view that it will take many years to gain traction due to the sheer size of the project, the limited resources we have, and the fact that we have to try and replicate all the features of the current system. Xamarin is interesting, but not really on the table at the moment as we are not marketing to mobile or tablet-based audiences. As a Microsoft developer, I8217m extremely disappointed by the way Microsoft is handling its UI platform strategy 8211 they have really dropped the baby on its face here. I8217ve loved seeing the innovation coming out of releases, and how the UI story has advanced so quickly, with the introduction of XAML and associated platforms. I felt like it was a real paradigm shift, onwards and upwards from the cesspool that was cross-browser web development. Yes, web development has improved immeasurably over the last few years but it8217s still just HTML, JavaScript and CSS at the end of the day, evolutionary, not revolutionary 8211 there are basic flaws with these technologies that will never go away. I know that as a developer I have to go where the industry goes, and I8217m fine with that 8211 at least I already know how to develop on browsers, so it8217s not a huge leap for me personally to return to it, but I am so frustrated that a perfectly decent technology with a great ecosystem has been gutted, and there is no decent succession strategy in place. That8217s life, and my snowflake has well and truly been pissed on. Sorry for the rant, you can tell I need to vent. I8217m sure you understand how I feel. Thanks Sam for sharing your testimony. I completely understand how you feel because I8217ve lived a similar situation, but less critical because our Silverlight commitment was not as important as yours. A lot of developers feel regularly betrayed by this kind of turnaround: one day you8217re said that 8220this thing is the future, you MUST use it NOW8221 and the day after 8220this thing is the past, here is the new thing you MUST use NOW8221. Some find it ridiculous that Apple produces a new iPhone every year or so, whereas others are happy to buy them all. The same for Microsoft technologies, some are frustrated by this entropy (especially software vendors like you), others are happy to adopt them all (especially cynics: 8220Coooool A new thing I can sell to my customers to get more money from them8221 )). As for your particular technical situation have you considered using XBAP for deploying and running your WPF applications XBAP gives you the deployment experience of ClickOnce and the runtime experience of Silverlight in the browser8217s sandbox . The issue is that AFAIK it only runs in IE and FF, and of course only on Windows. And I strongly believe that what you live is a blessing in disguise because web technologies is really what matters now, you find them everywhere (even on the server with Node and the desktop with WinRT). Now you can reach a broader audience and the technical experience you get is applicable to far more use-cases than XAML, and this time you know the technology won8217t disappear next year because the vendor has created yet another thing. The only issue you8217ve discovered yourself is that the web technologies are not yet ready for prime time on the LOB market, but I strongly believe that they will be in 2 or 3 years. Be happy to be an early adopter of web technologies for LOB We8217ve looked at XBAP ClickOnce deployment for WPF, it8217s on the table as a number of options for WPF adoption, but the most likely one we will go with (only if we have to) is to deploy the client as a desktop application via our existing MSI package, as that is what our current clients are used to, and we had some concerns about how easy it is to get XBAP applications running in enterprise environments (certificates, IE 9 permissions, etc). Concerning XBAP you have reasonable concerns, but some quick tests should be enough to evaluate the impact, especially if you need higher permissions than what the sandbox allows by default. - Moving from Silverlight to HTMLCSSJS, sucks big time. It is much harder to style, and inconsistency across browsers is still a major issue. 8211 For complex LOB apps, WPF to 8220Metro8221, is a joke, can8217t have multiple windows open, cant use multiple screens 8211 WPF to web browser HTMLCSSJS is impossible if you need to integrate into other systems via COM APIs The CEO was so pissed with the death of Silverlight, that he has barred MS tech from the next stack and the primary browser is now Safari. The backed will be moving to Node or GO or. anything but Microsoft. - true, Silverlight, as Flex, was excellent to quickly develop web LOB applications, but finally the HTMLCSSJS strategy is better: slowly but surely it has crunched all the competitors, and is quietly evolving to be LOB capable. 8211 true, WinRT is far from ready for prime time on the LOB market, and I fear the day it will then the HTMLCSSJS stack will be too, making WinRT a useless technology, or only useful for some specific Windows niches : 8211 true, especially for Office COM addins that are great tools to extend VBA apps I completely understand your CEO8217s reaction, especially if the Silverlight failure has impacted his credibility towards business. For the backend Node is great to have a uniform stack with client apps in HTMLCSSJSAngular but the issue is the ecosystem: when you work with these new technologies you realize how powerful is Visual Studio, and how it greatly impacts your productivity. This is only a question of years before the web stack has enough power (especially IDE and libraries) to run big LOB applications8230 WebStorm (especially version 9) is already there IMHO. 8220Whether you are a business or an individual developer you should seriously consider slowing down your technical investment in WPF, and start to build your expertise on WinRT.8221 No we wont. If someone wants to make an investment, M is not the place to put it. M8217s moves are a complete disaster lately. Win8 was a step back (in UX, in quality, in application reliability), so was the WPF discontinuity. And most (if not all) MetroPhone new programming tools don8217t even work on Win7. So, you have to use the crappy, unproductive Win8. That8217s not gonna happen. Now, even in Win10 seems promising to fix some things, my long experience is that M never fixes anything that annoys me. Thanks for your feedback. Yes I agree with you the situation of Microsoft is quite critical and 8220copy what the others do8221 is indeed not a viable strategy on the longer term. I8217ve recently changed my mind about WinRT because the more I learn and think about it the less optimistic I am about its future outside Microsoft. Probably WinRT is great for Microsoft8217s developers to increase the productivity of the different Windows teams by sharing a common platform. But for final developers I see less and less use cases for WinRT: useless on the mobile market because it can8217t target Android and iOS, useless on the desktop because WPF is richer, more mature and compatible with all the Windows OS from XP. I8217m personally slowing down my investment in WinRT and seriously thinking switching to web where I8217m sure my investment will pay for at least a decade. I have never liked WPF. It is one of most complex platform to localize. Because XAML is so flexible you can have very complex XAML that relate to several other files. If WPF is going to go away I am just happy. How I see this there are two ways to make LOB applications. The first is plain old WIN32. However I do not use MS tool but Delphi. It is a superior tool to make LOB application. MS can not drop WIN API support from any upcoming Windows version (see what happened WinRT table without WIN API). Second is HTML5CSSJS stack that will come better day by day. Most of the logic will anyway stay in servers and thin clients (desktop, browser or phone) all access them using REST. I have see some pretty impressive UI developed on HTML5CSSJS. When I create anything that use JS it actually use Visual Studio and TypeScript. It is a great language It won8217t even take long that HTML5CSSJS will be so powerful that there is no need to platform specific API such as iOS, Android OS or WinRT. Thanks for sharing your opinion Jaska. Yes WPF is quite hard to localize because Microsoft has not provided any good tool to do this task but the community has come up with really good solutions including the use of the good old resx and the newer resource dictionaries . For LOB applications I8217ve developed with Win32, WinForms and WPF and IMHO there is no debate: WPF is by far the easiest platform to work with once you understand it well (3 months is enough to be highly productive). As for the web stack taking more and more importance I completely agree, there is simply no other alternative if you want to target all the platforms. In less than 5 years I strongly believe that this stack will become as productive as the native stack with the added benefit of being fully portable. Using the other technologies won8217t make a lot of sense in the general case, though of course a lot of specialized use-cases won8217t be addressed by the web stack. Great article, thanks. I also have worries like you since I8217ve been developing in WPF for the past 4 years and haven8217t seen much coming out of MS on the subject during this time. I was just reading an article the other day on a rumour that a future windows app store will support windows desktop apps. wpcentraldeleted-microsoft-blog-post-claims-windows-10-support-desktop-apps This might possibly give a bit more push internally within MS to update WPF, since it is after all still their recommended UI platform for desktop apps. Thanks for your kind feedback. I8217ve heard of this rumor too and this is really bad news for WinRT because the use of Windows Store was one of the main added benefit of WinRT against WPF. Without that WinRT is just becoming less interesting and almost pretty useless. So strangely seems like WPF may have a better future than WinRT8230 I think the future technologies are the JavaScript libraries like KendoUI or AngularJs. You can combine these technologies with MVC and build awesome apps, that you can then optimize for mobile devices (responsive web design8230). The world of desktop client applications seems to be already dead, making place for web apps and mobile apps. I agree with you that the web stack is the future. But the world of native desktop development is far from dead, and it8217s the same for native mobile development. I think that less than 5 years should be enough for the web stack to become as productive and powerful as the native technologies. But there is a lot of native applications to maintain and businesses tend to reuse their native skills for new applications. Thanks for a great article I found the following framework really helpful for those of us who still use WPF but need to produce apps that seem at home in Windows 8. I thought I8217d share it (I8217m not affiliated): mahapps It8217s like the WPF toolkit, but for Windows 8. Very useful Apps like Github for Windows have this kind of feel. I think you8217re right 8211 WPF is just in it8217s 8220middle age8221. There8217s still plenty of activity out there. For example, the Reactive UI Extensions have support for WPF. See spin. atomicobject20130822reactive-extensions-wpf and others. Thanks for the kind feedback Graham, and for referencing MahApps. There is another similar toolkit: Modern UI for WPF And yes WPF is still alive and as mentioned in other comments I8217m not really confident in the future of WinRT whose main benefit is portability 8230 but only on Windows. I am kind of new to WPF8230 I think I like XAML for many things 8230 its layout control, the capability to nest elements, and etc. Data binding the data template is really the strongest point of XAML. However, what I don8217t like is the code syntax. XAML itself is not too bad 8230 but the C code is horrendous. The class names are just too long, the concept is simply too abstract 8230 e. g. DependencyProperty and its related declarations, all these stuff are just not intuitive. In comparison MFC becomes so much simpler. I have to say even someday I master these things in my heart I will still be a hater. If you are new to WPF take some time to more deeply understand it, because as you8217ve experimented WPF can be quite frustrating at first. Not because WPF is complex but because WPF is rich compared to older and rawer (closer to the OS) approaches like Win32, MFC and WinForms, where you had less concepts to grasp. As for longer class names this is not specific to WPF or , but is a general trend in programming: since we now have good development tools, like VS with IntelliSense, we can use explicit, hence longer, names because we will not have to type them entirely very often. As for DependencyProperties I like the way it is implemented in WPF because there is not too much magic in there, things are relatively transparent, contrary to more abstract implementations of the same features like the Flex framework which uses a black-box approach. And as a whole is not perfect for sure, but to judge it fairly you have to try other platforms like native C, Java and Web (including Node. js on the server), and suddenly will appear as yet another unperfect platform that does the job pretty well, not better and not worst than others. I agree with what you have said. Let us be optimistic that more people will learn WPF and adopt it for LOB application. especially with a mature set of controls and components provided by third party vendors, who have taken the cause upon them-self and produced some remarkable component. that if used in a proper manner can produce modern and better UI that would have taken normal teams years to develop. Vendors like Infragistics, Telerik. Intersoft, Devcomponent. DevExpress have enterprise class WPF components. And not to mention Xceed with the best WPF Grid Engine that can actually scale. So you cannot say that WPF is dead. Its there and good for what it is. replacement of WinForm and a modern UI. Try doing those with any other frameworks available. These along with properly architecture applications will surely excel. Well there are performance trade offs using WPF of other things in some areas.(e. g jeremiahmorrill. wordpress20110214a-critical-deep-dive-into-the-wpf-rendering-system ), well one only need to be concerned about this if you want to use it for graphical performance. In this area WPF needs catching up with GPU in some way or other if subsystems where enhanced. There are teams that have taken things into their own hands and reaped the rewards. have a look at the works of ab4d or NoesisGUI. The Start Menu is making a come back. But the death of Microsoft will not happen since Laptops at least will not be replaced for productivity reasons. PC may be proclaimed declined, but not dead. Yes WPF is still king on the LOB market and that8217s a good thing. Thanks for sharing the article about the performance 8220issue8221, but this kind of low level stuff is not relevant for most LOB applications even big. In my previous team we8217ve built a really big one and the only issue we had was with the DataGrid which was damn slow when it had to manage thousands of cells with data-binding and triggers. Optimizing both these points gave us decent performance. As for the future of Microsoft it won8217t be bright but IT has such a huge inertia that I8217m really confident for the next decade. Moreover a lot of Microsoft8217s customers are captive and won8217t be able to use tools from competitors even if better andor cheaper. hi, firstly am not an expert programmer. I have just learn a vb and sql so I can play around with LOB applications as I do for almost 5 years. can you please explain what is 8216The official WPF certification (70-511) will not be continued and it will expire at summer 2015.8217 I was in windows forms and when I wanted to know whenever wpf is the future all the comments and post almost. they directing me to use wpf for new desktop application. so for 2 months now am trying to learn and play with wpf. believe me is hard when you learn something to try forget and learn something new. But to be honest I am afraid that change because when ever I hit google 8216is wpf dead8217 some say will. some say NO. I cannot move back and forward all the time. is there any official statement or something about that technology thank you very much for your post. Glad this article was helpful to you Stelio. As for the WPF certification, Microsoft will simply remove it from its offer so you won8217t be able to become a certified WPF developer after summer 2015. But if you get it before it expires this is still good. Concerning new developments, if you only target Windows PC, which is almost always the case for LOB applications, then WPF is your best choice and with WinRT the story has not changed. Maybe in the future WinRT will be a good LOB platform, and maybe businesses will all migrate to Windows 8, but until both happen, at best in 5 years, you should continue to use WPF. And in the long term you should stop using Microsoft client technologies because they are not mobile capable and instead use Xamarin if you want to leverage your C knowledge and be native, or JSHTMLCSS if you want to leverage your web skills. On the server side the ASP stack is quite good, so as long as it is supported you can use it. What a great conversation. I have been prototyping a C app using WinForms, and I know this is not the right path forward. While there is interest in porting to the web, the requirements are rather complex that I8217m comfortable making the decision to focus on running on the desktop for now. But what I wasn8217t entirely comfortable with was whether WPF would be a useful investment of my time and energy. Based on your article and subsequent comments, it seems like WPF, despite Microsoft8217s lack of pushing the technology, is the best choice. Glad this article has helped you take the right decision Brian. I8217m less and less confident in WinRT future, so I8217m in standby mode waiting for communication from MS. The web stack is clearly a safer investment for companies and developers in the long term. But until it is plainly ready for LOB applications if your only target is Windows PC then WPF is indeed your best choice. Nice summary of where we are today For those that have spent serious amounts of time in different Microsoft technology stacks (MFC, Winforms, ASP, Silverlight, etc.) and compare these to WPF, you will have to agree that WPF is a productivity monster when you couple it with things like Caliburn. Micro and Telerik8217s WPF control suite and a well tuned development environment with snippets and plugins tune for WPF development. Complex applications that used to take a seasoned team of developers months to create can be made in under a month by a skilled solitary developer. Sadly, Microsoft is trying to deprecate their own technology with a significant measure of success. When the enemy is also your friend, paranoia is what we8217re left with. Thanks for your feedback Mario. Yes WPF is a highly productive platform but it must be earned as it is quite rich. As for paranoia this is a quality for an IT professional because we must often take care of long term maintainability. you should give your expert feedback Thanks for your suggestion. I8217ll update the article too. Hi there, I ve read enough comments and although an old XAML 8211 bound 8211 things lover with absolutely no fear for the future of. NET style apps, i am putting a smile on my face as i find my self at the time being working with, believe it or not 8230 ASP WebForms with a more mature view of things, giving my customers really really great results, really really fast (with some help of 4.5 and DevExpress ). I even do MVVM with the FormView and ModelBinding and almost no state headaches. Of course i speak for the LOB part of the conversation. Good luck to all. Yes for sure on the long term the web world is a safer bet than the desktop world but IMHO we still have a decade of active desktop development with technologies like XAML. Of course, but i mention it for the goodies residing on the server that bring a good dev experience, rather for the innevidable htmljs output that is just 8230 hmm a necessity. Still hard working humans behind the scenes Anyway i could not imagive what else could MS do to both support its products and also follow standards, but to gather best active tools and languages and try make them more 8220universal8221. I think that at the end of the day what we don8217t emprase so match is the market place requirement. We 8216ll see soon. MS is trying to become a standard technologies vendor by incorporating more web and FOSS capabilities inside Visual Studio. I strongly believe in this effort because though MS is losing the technologies battle it is still really good in tooling (IMHO the best vendor of IDE). But having good tools, even the best, is only a first step, and MS will have to gain the trust of the FOSS community which is not easy task because historically MS has always tried to kill FOSS initiatives and only when it lost the war it embraced FOSS. I am the author of this Visual Studio Uservoice request: Perhaps I could suggest a few ideas for consideration. The way in which Microsoft like any large company employs words to convey a brand for marketing purposes can sometimes obscure the underlying unity from a technical perspective. Silverlight, WPF, WinRT and Xamarin Forms all use XAML with a high degree of compatibility and also a significant amount of divergence, yet no more divergence than can really be expected over the time period involved and for which developers are traditionally used to managing for other platforms. The method by which the various changes came about was horribly communicated to the developer community due to internal Microsoft politics. The largest single complaint about WPF has been various performance issues and the obvious technical solution would be to reduce the API to essentials, convert a lot of code to C and integrate it with the underlying operating system8230 And that is exactly what Microsoft did by taking the huge step of including XAML into the Windows API. The XAML API therefore became native to C, C (and VB) and Javascript. XAML has been made lean and fast and accessible to every type of Windows programmer. This was a huge leap forward that was completely lost in the negative publicity surrounding something as trivial as changing from a Start Menu to a Start Screen With Windows 10, this updated XAML will be able to run on the normal desktop inside a normal resizable Window and provide a fast modern interface across a range of Windows devices. From an Enterprise LOB point of view, Windows 10 and XAML will be a great LOB deployment vehicle with all the security advantages of a sandboxed App environment. For the huge installed base of Windows 7, the obvious solution is to make WPF as compatible as possible with WinRT through a layered architecture design, third party libraries andor hopefully some sort of thoughtful design by the newly revived 8220WPF team.8221 (which as far as I can tell is an internal task force using the Windows API XAML team along with others which explains why the WPF blog remains silent since it is really a virtual team) For IOS and Android, there is Xamarin Forms which is yet another variant of XAML. For a LOB App to target every client, there is for the very first time a base of XAML across every possible target of Windows 7, Windows 8, Windows 10, Windows Phone 8, Windows Phone 10, XBox One, Android and IOS. For sure you have a design and architecture task to achieve the maximum in common code but there is no other platform that can deliver a completely Native code App experience across all these devices that an Enterprise LOB might be expected to deploy to. Rather than being negative on the future of WPF, it is more accurate to be extremely positive on the future of XAML. It is certainly possible to put some effort into complaining about the large number of XAML dialects causing some nasty IFDEF in the code base, but compared to the current all-too-common practice of an Objective C codebase and a Android Java codebase and a Windows desktop C Winforms or WPF codebase, the XAML solution is the right choice moving forward for a huge percentage of LOB deployments. The alternative choice of JavascriptCSSHTML for LOB will certainly appeal to some but comes with a different set of headaches. The important point is that XAML is now part of the Windows API which will now be baked into the 1.3 billion desktop computers over the next few years and will be supported by Microsoft for many decades to come. That is as future proof as anything gets in this industry Thanks for sharing your thoughts Don, you make some really good points, and you get my 3 for your UserVoice suggestion. But I fear unifying the Microsoft development platforms is a huge task that Microsoft won8217t do because it8217s cheaper to instead reuse what others have made like the web stack and sell tools to leverage it. Moreover there is a timing issue. The web technologies are more and more capable and nowadays with frameworks like AngularJS, production-ready libraries, IDEs like WebStorm, testing and profiling tools, you get a rich and productive experience. So the productivity gap between native and web technologies is getting smaller and smaller every year. So if Microsoft really engages in an effort to unify all these technologies it will take some years before it delivers and in the meantime the web stack will be as powerful as the result of this effort and will have other advantages like a better compatibility. As for this figure of 1.3 billions of PCs this is huge indeed but is now only a part of the billions of devices like tablets, phones and watches. So I feel Microsoft has surrendered and it8217s why it8217s now promoting the web stack since 2011, just before killing Silverlight. My advice is: do not wait for Microsoft and instead you8217d better get on the web train to ensure a successful future as a developer for your customers and you. most of the LOB applications already exist and are mostly client side with DB in the local network. Companies can then choose between: 8211 Stay on the client only. In this case the choice must and can only be WPF, in fact in the release of WPF5 many improvements have been made to support the touch. No coincidence that Microsoft has deprecated practically Windows RT and in all new tablet runs version of Windows where can run standard applications (WPF). By doing all LOB applications, with some improvement graph, can run on windows tablet. But always remain client applications and so this is not a big advantage (only for BYOD). If companies were to think of cloud applications must re-develop from scratch applications, with server side and client side (web applications). 8211 Go to the cloud. In this scenario, companies need to write from scratch the LOB application, and then give a new structure to the application. In this scenario obviously the only way forward is HTML5 CSS3 JS but I see a big problem: most of the LOB application uses the F1 F12 buttons which are not practically usable in the browser. So how you can bring your LOB applications on the cloud You can not tell the customer that if he wants to go to the cloud takes twice as long to make a bill since it must use the mouse instead of the keyboard, right Apart from that I see also a difficult migration step of LOB application from Winforms WPF to HTML5 how I can make coexist in a WinForms application WPF components HTML5 also working locally with the DB and perform operations on the disk Hi Stefano, indeed migrating from desktop technologies like WinForms or WPF to the web stack is costly, partly because this is often an all or nothing process, contrary to migrating from WinForms to WPF which can be done component by component, view by view. It must then be justified by a real competitive advantage like reaching more customers on the mobile platforms. As for cloud, AFAIK, you can use it to deploy WinFormsWPF applications too using ClickOnce, though you won8217t benefit from a wider audience, just an easier way to reach desktop customers. It8217s kinda funny the way people cling to their BS. even after being proven wrong, RT is would be Dead except it was never alive, anyone who bought into that crap deserves what your getting. calling WPF or Dead isn8217t going to improve anything. look at the blogs. msdnbdeveloper-tools and the WPF alternatives, RT, Ligthswitch, Silver Light are Dead. store apps lost there spot on the platforms menu, the Lightswichters are all teary eyed and getting silence. I just wonder if the are gonna get one last shot with the Universal app thing or not, when 85 can8217t use, the some of the tiny army rabid Rtards will buy in, not enough to amount to anything, it8217s all over but the ringing of hand and mashing of teeth, the modern best in breed webstacks can achieve at least as good and better in some cases, as far as WPF goes, your so far off base it8217s hard to express, it8217s the only came in town when it comes to modern real world, mission critical applications and is a fundamental component much of the worlds newest infrastructure, and guess what, no one looking to the commentator bloggasphere for guidance, and guess what else, they don8217t blog about the fact they are using WPF, the fantasy bubble created by the blathering of random self appointed pseudo experts is laughed at, it8217s a different class of developers, aka professional software engineers not app devs, that doesn8217t change the fact that WPF can also do a way better job on co nsumer apps as well. I have one question for you might WPF expert, what would you say to the young developer who listened to the RT, and other future predictors said three years ago, who can8217t find anyone looking for RTModernStoreUniversal experience, and yet lot of WPF jobs paying top dollar. big on the smug all knowing response, can8217t wait. I agree with what you say Dave and it8217s precisely my conclusion: keep up with WPF, avoid WinRT which is probably useless and instead bet on the web stack. As for your question I would say: 8220Being an early adopter of any technology is always risky, especially when the technology comes from a vendor that has shown a clear lack of understanding of the new trends in the last few years and missed a lot of boats like smartphones.8221. The real deal with WPF is all the people doing it wrong, with all the blogging as they learned by the self-promotional social network oriented app builder class to the point where anti-patterns became the perceived best practices, MS poured fuel on the fire with their stupid separation of concerns non-sense, Bring in the Don blend designer types that let them think they were actually providing a useful service, ignoring all the real developers who were saying that Blend and VS where generating mountains of useless XAML, the truth is blend is utterly useless, proper WPF is a terse handle written affair, it should make it easy to see the structure of the UI, everything except name, event and as little else as possible. with everything else include layoutsize handled by Style8221 There is no stopping WPF on X86 phone, the smart people know max reach html5CanvasbootstrapReact, max rich WPF, the sputtering of a few uninformed, like the Blogger tim. A of the Register who tweeted some BS like WPF touch may never work, are writhing away, I like seeing the Wolf Pack Foundation that tweets WPF, its ironic, MS threw the WPF devs to the wolfs, now they have a wolf pack on their hands, and the promosocialstoremodern crowd are where milk bone adult onesies. Where are Barness, Browns and all the other Bs. Dead end roads, thats where, dont even think of coming back to WPF boys, we dont need help picking colors or drawing UI, we can have the users pick their own colors and use VSM, thanks anyway, bubbye. Separation of concerns is pretty useless in simple apps indeed but it can help in building bigger apps, at least to offer a common language for all WPF developers which enhances maintainability. MS has given up on Blend as it did not succeed in selling it to designers, including it 8220freely8221 with MS now. The future of WPF highly depends on MS investment in it: if MS decides to go all web then WPF will quickly disappear. Yes MS should buy Xamarin and promote it as it is a great way of building native apps. But in the long term, when the web stack will catch up, Xamarin will probably itself become kind of deprecated. Xamarin. I quess you didn8217t sense the sarcasm, that whole section was a joke I can do more with HTRML5Canvas already, Xamarin is weak. hell even Chuck Pertshold admits it can8217t do graphics for shit, along with admitting, her wrote the books on the fly and isn8217t a graphics expert, but in perception land. he is worlds leading expert, 8220Separation of concerns is pretty useless in simple apps indeed but it can help in building bigger apps, at least to offer a common language for all WPF developers which enhances maintainability.8221 I can8217t make any sence of this statement, 8220Separation of concerns8221 is a trainwreck, I know of a local shop that where soo gullible that they hired a designer who I know for a fact had zero WPF experience. I hand to bite my tounge to stop from laughing in there faces when they ranted about how invaluable if was to have a real WPF designer on the job. Blend is worse than useless and not at all how it8217s done, I may give the appearance of accomplishing something, which I think is worse than doing nothing. Ms has made massive investments in vast array of things failed, yet where proclaimed as the future, the 82208221RT Big Bet8221 being the latest, they aren8217t calling the shots, the adoption rate of WPF is Huge, where it matters, the endless speculation of what will be the next big thing, I really enjoy listening to all their xarerfans regurgitating back and forth, yet haven8217t seen anything even descent, what a bunch of hot air, no xamarin apps in top 10,000 apps on any platform, has about as bright a future as Windows Phone, Fanboy Hype even MS exec fanboys are just making noise, blog opinion commentators don8217t buy MSDN subscriptions. it8217s the developers call the shots. not MS, 25,000 xamrites is rounding error in the real world, where is even a competitive xararin app anyone who needs more than toy level phone would go with somthing like this. alphasoftware multi palform from the guy who invented the spreadsheet and some other MIT heavy hitters, not warmed over freeware. Concerning Xamarin, as for any technology, not only its inherent capabilities matter but also how it is perceived and promoted by the community. And there is a lot of projects using it and a lot more coming, and I was really surprised by this success when talking with a key stakeholder (a service and software company). Not sure it will get enough traction to last 5 more years, again it will highly depends on MS promoting it (even buying it) or ignoring it and promoting the web stack. By a common language I mean you can more easily grasp any WPF app if the devs have made the effort to respect common patterns like MVVM: you directly know where to find things and don8217t get lost too much in custom plumbing. It makes a huge difference with big projects with a lots of developers and a lot of turnover. SoC is good but as a lot of things it must be used wisely and a lot of noobs abuse it, uncoupling too much, making the result more complex instead of simpler. I8217m all for defining the View aka Presentation Layer in XAML, that in effect is what WPF is, I8217m just saying the best practice is too keep not use tooling generated XAML in the Window View XAML, it8217s make a unmanageable mess. I dont care if your talking 1 to 1000s of devs small or enterprise, Blend and the VS designer are a menace to good WPF, period. there is no designer role in good WPF. periode. it anti-pattern only nooblets or designers don8217t get it, MMVM is a good great pattern. but what I talking about is more fundamental principles. and what gives WPF the Edge with 8220inherent capabilities 8221 that are simple superior, and very very few a aware. as far as Xamarin you can8217t just ignore the lack of 8221 inherent capabilities8221 the Web community is x1000 larger already has greater 8221 inherent capabilities8221 Xamarin is may look like a nice bridge to the store app crowd, but it8217s really like an extension on the Santa Monica peer, store app3rs are surely some of the most gullible wannabees on the planet and are sure to be happy with the 8221 inherent capabilities8221 so Miguel may make a few bucks, it8217s a hype fest, do you really think metro crowd can build anything even half way descent, tick tack toe, the fact you can8217t point to anything but potential, when I already have kiss ass WPF on Win10 99 quadcore, it looks absurdly pointless, doesn8217t sound like you are gonna get suckered in, cross platform frameworks are coming out of the wood work, it8217s gonna be cutthroat. is is shocking how much hoopla their is over vaporware, I guess when a blogger can be MS VP anything seems possible just not very likely. you really can8217t name a single good xamarin app, mee too, hmmmmmm. I agree that XAML should be written by the developer and that the designer is only good at showing the result not creating the view. Just to be accurate the view is not only XAML but XAMLcode-behind. The main point of using Xamarin is to reuse existing C code base and to ease the migration to the world of mobile. This is totally relevant for a lot of teams in many companies that have already deeply invested in and C, especially for developing WPF applications for their desktop needs. But in the long term I think it8217s better to invest in the web stack, reimplementing some parts in JS so that it can be run on any client. 8221 the view is not only XAML but XAMLcode-behind.8221 is exactly right, its all the people who try to make it the whole application and then bitch about performance when they stall the dispatcher thread and worse, thats WPFs biggest issue, Ignorance, thankfully it8217s only a problem for the ignorant and their victims who are the fools buy there less than useless BS. like have been saying WPF is DEAD for years, go silverlight, silverlight is dead go metro, we can8217t call it metro, go RT, aRmTablet is flop, go Modern Store, store is digital land fill, go universal, no universal on Win7,,WP is well review by some really creditable bloogers, go WP, WP is zombie rat hole, sound the trumpets, datdadadaaaaa, go Xamarin 8230.8221. whats Dead. everything they said was the future. including the stupid UX expert do nothing designer role. and there careers, meanwhile a WPF Dev one of the most in demand, so me anywhere in the world where they want store app experts, it8217s an oxymoron anyway and a painful dead end for the foolish, some of which are going around posing as WPF experts because they try it back when it was in fashion, ignore the fact they fail at everything before and after because they are losers, 8220I think that the sum of all these facts is pretty clear: WPF is past and present, in the near future it will be in direct competition with WinRT, but later if WinRT gets some traction and enough market shares then WPF may become kind of deprecated like VB6 or WinForms. Above all dont be in denial, and have a clear picture of what happens, do not eliminate the pessimistic facts from your mind.8221 it would seem at this point, based on your conclusion, on Sep12, that your abilities as a future predictor leave a bit to be desired, I guess old habit are hard to break. I wonder what you would say to the hoop jumpers above, in say 3 three years, after they jump though the Xamarin hoop, then the Universal One Core Open source Core hoops, when they can8217t get employment or are they supposed to finance their fantasy freeware empire, that will one day monetize into their long term goal of world domination. you miss way to many points to pull off WPF expert. you8217ve mentioned Xamarin to many times to be considered for junior cub status so I8217m afraid we don8217t have a spot for you in the wolf pack, my favorite user voice is the own where they want to change the name of WPF to silverlight, cause they told everyone WPF is DEAD, I can8217t wait to see twait banes next WPF was dead, this time we nail the lid and dig a deeper whole. good luck on your Xapp, oooohh. that8217s catchy and good luck on your socialpromodeving. why is p ball pete when you need him The conclusion has been updated to reflect the latest news: 8211 MS has restarted to 8220promote8221 WPF in november, 8211 WP market shares are still weak and even diminishing. As a result I8217ve changed my perspective on WinRT from slightly optimistic to deeply pessimistic. As for the people that have invested in these platforms they can reuse 90 of what they have learned: the procedural language is the same (C), the UI language is the same (XAML), the patterns are the same (MVVM). And again it8217s not the inherent quality of a technology that makes its success and adoption by end users like big companies (SOA is the best example of the gap between added value and 8220success8221) so a lot of these people are working on WinRT projects and for the other (most) they are better WPF developers. Others have even made some money by developing apps for the Windows Store. I think projects like NW. js (githubnwjsnw. js ) make the web stack viable for LOB today. 8220NW. js is an app runtime based on Chromium and node. js. You can write native apps in HTML and JavaScript with NW. js. It also lets you call Node. js modules directly from the DOM and enables a new way of writing native applications with all Web technologies.8221 Thanks for sharing Andrew. Indeed the web stack is seriously threatening 8220standard8221 technologies even in the LOB market. But from my own (limited) experience the developmentdebuggingtesting experience is not as streamlined as with CWPF. Of course it8217s only a question of time before tooling becomes as good and even better. Finally will remain some more specific LOB niches (yes a niche in a niche :)) like Excel addins which are heavily used in finance for example. As a former developer and current iOS hobby dev I am astonished how well Apple improved and supported its own legacy technology Objective-C and the NextStep classes. Now you have a modern language (swift) and a super effective native UI runtime in iOS. Almost all legacy problems of the past, like reference counting and a somewhat obscure Objective-C syntax are solved. This is totally in contrast with the Microsoft Strategy to reinvent a UI Technology every 2-3 years. If Microsoft had chosen the Apple way, C and MFC or maybe COM would be evolved into an highly effective platform agnostic technology stack. Thanks for sharing your thoughts Andr. I don8217t know the iOS development stack so I won8217t compare. I think you8217re a bit harsh with Microsoft As for the timing: WinForms has appeared in 2002, WPF in 2006 and WinRT in 2012, so you can double your numbers: a new UI technology every 4-6 years. But the important point is that each one has appeared for 8220good8221 reasons: 8211 WinForms because needed a UI development stack above Win32 to make it more appealing for native developers, 8211 WPF because it introduced a cleaner, and sometimes more productive, way to develop UIs, 8211 WinRT because the new Windows needed a refresh of the internal UI layer Of course there had also internal political issues with members of the Windows team willing to kill , hence promoting other technologies like native C and COM for WinRT. So it8217s pretty sure Microsoft could have done better but I8217m not sure Apple has done better with its stack: if Microsoft had not developed WPF and WinRT UI then we would have stability but a less powerful and productive stack. Apple has done much better. Since you obviously don8217t do much (any) OS X development and don8217t really seem to be following things there, you8217re out of the loop on it. A big issue with Windows Forms was bad Graphics Acceleration. It8217s one of the things that WPF was supposed to solve. Apple didn8217t need to redo their entire UI Technology to add that to Macs. They just made the necessary changes, and developers didn8217t have to learn XAML or whatever to reap the benefits. Apple even had mechanics to translate OpenGL calls to subroutines so that their graphics acceleration worked on Intel GMA cards for a performance boost. Apple takes a much cleaner approach to improving their platform from that perspective, and this is part of the reason why so many startups and entrepreneurs are now targeting OS X and completely ignoring Windows as a client platform. Windows will always be king for LoB because of its Enterprise Marketshare, but it is already starting to look like a dead end to people developing consumer GUI applications, and a royal PITA because Microsoft is constantly developing, ignoring, dropping, deprecating, and even just failing completely with various technologies. GUI isn8217t the only area where Microsoft had reinvented the wheel multiple times. Look at their Embedded Database Solutions over the years. In and out, multiple times. They8217ve had multiple development language in and out, multiple times. For native development, Microsoft should have developed tooling and frameworks similar to Borland8217s VCL (DelphiCBuilder), but they went all in with . I switched form Windows to OS X development. Users email me somewhat regularly asking me if I8217m going to port to Windows. Jawabannya adalah tidak. There is 0 chance because I don8217t trust Microsoft. They way they handle their tooling is too selfish these days, and way too political. It8217s a virtual minefield and I got tired of spending more time learning than actually doing stuff. Apple is paradise compared to that B. S. Thanks for your feedback and perspectives. It8217s true I have never worked with iOS so I won8217t be able to compare. 1) Graphics acceleration is only one of the driver for the creation of WPF: WinForms direct acceleration would not have added a lot of value, for me XAML added much more, 2) Desktop development is not the future, web development is already a big part of present and I expect most of the applications to be web-based in the future (even if running in a desktop mode), and this is not specific to the MS stack, 3) As for the lake of consistency and long term vision at MS I completely agree, during years MS was not an innovative company, lazily exploiting its dominant position on the OS and office softwares markets, which IMHO could explain a part of the the constant changes in strategy and technologies, and sometimes the absence of changes like with I. E., 4) Native development has indeed been laid aside for but this has changed recently and AFAIK MS is now offering decent tooling for it, 5) If you and other startupscompanies can develop applications without caring about Windows, Linux and Android users this is fine, but most of companies need these market shares so they can8217t restrict them to iOS even if the development tools are as amazing as you say: they must at best use the web stack to reach all the potential customers. At the end of 2015 I made the decision to cease any new developments with WPF. It8217s fairly obvious that Microsoft has stopped investing in WPF given there are now only 2 developers left on the 8220WPF team8221. WinRT on Win 8.08.1 was a bust for me. When you spend 2x or 3x more time doing the same thing with the shiny new thing, it8217s time to move to the sidelines and wait. I started tinkering with UWP at the end of 2015 and immediately noticed that some tasks were getting done 2x faster with the remainder starting to be on par with where I was at with WPF. Performance is much bettersmoother. The samples provided for UWP are now several orders of magnitude beyond what Microsoft initially provided for WPF when it was the shiny new thing. There8217s a lot to like in UWP. No more MSI drama with AppX, a real super duper browser control, access to DirectX, native code that is brutally difficult to reverse engineer, significant performance boost, much better audiovideo support with transcoding made trivially easy, 8230, native bindings, updated cooler versions of things like tab controls, listlistviews, desktoptabletphonegame consoleiot with the same binary8230. it8217s a pretty long list. There are still a few rather deep pot holes, no DataGrid, no TreeView, nascent third party tooling, etc. Nonetheless, I was surprised to see a couple recent projects wiz through very quickly thanks to old standbys like Caliburn. Micro working nicely with the new tooling and surprises with how well some of the new controls worked for visualizing good old db tables. It8217s become a no-brainer, time to switch, before others are woken up by the bright lights. Thanks for your interesting feedback. I8217m not sure UWP has a great interest outside of the world of LOB applications. IMHO as of now the best bet are truly universal (AndroidLinux, iOSMac OS and Windows) web applications developed with HTMLCSS and a JS framework like Angular. As for LOB applications the existing technologies (WinForms and WPF) do a perfect job and are mature with a wealth of tooling. So I don8217t see the point in yet another Windows UI technology and I8217m pretty sure this new stuff will suffer the same fate as WinForms, WPF, Silverlight and WinRT. Time will say8230 I share your good experiences with UWP. It kind of finishes a lot of things appearing half-baked in WPF. The performance is much better. At lot of repeating boilerplate code is not needed anymore. But currently, there is one big deal-breaker with UWP for LOB: I does not run in Windows 7. You even cant develop for UWP on Windows 7, because you can only build, but not debug. So not only we can8217t switch to UWP because all our customers are running Windows 7 and dont even have plans to upgrade, we also can8217t take some spare time to investigate the possibilities of UWP for potential future applications. Because our Company also runs Windows 7, and most of us know what it means to get a Windows 10 workstation for a developer in an IT environment where only Windows 7 8220is supported8221. I can see why MSFT is trying to push customer towards Windows 10 by adding artificial barriers for current technologies. But not supporting UWP on Windows 7 was a stupid decision, regarding the market shares. Especially for LOB customers. And worst of all, it needs a message to LOB developers and their customers: 8220We don8217t care about your needs anymore, we are cool know and your stuff is boring8221. They are harming the only market where MSFT is still successful. Let8217s face it: If there is one thing MSFT can8217t do, than it8217s being cool. The lame attempts to look cool by putting hipster-looking guys on to the presentation stages is just embarrassing. My late-teenage kids (15 8211 19 yo) are just plane laughing at MSFTs lame attempts to be cool for them. The say MSFT adds are looking like 8220old people tried to do something looking cool to young peoples and miserable failed.8221 thanks for your feedback. Probably Microsoft has decided not to support Windows 7 for development cost reason. Seems like 8220the cheaper the better8221 is the motto of Microsoft management. - Microsoft is trying to save what it can still save, everyday many developers and software companies switch to the profitable market of the mobile platforms, and drop completely the Microsoft8217s technologies. Because Microsoft has lost the mobile war, the only way to keep the developers using its technologies is to make them cross-platform, but to do that it has to drop everything that is Windows specific. Core 1.0 is the last resort of Microsoft to keep as many developers as possible, you don8217t need to be a clairvoyant to see the end of the desktop era. It is enough to take a look to the market share of desktops and mobiles, the former are dropping and the latter are gaining. The buzz of these years is IoT, and desktop aren8217t in that category. If Microsoft don8217t want to end with a niche market, which is slowing dying, has to find a new way to survive, which is not Windows. Sad but true Microsoft is running behind all the new trends and technologies, but it arrives always when it is too late. Look at the new Windows 2016, what is the best new feature Containers, which are available for unix since many years. Microsoft was late in everything, it was late on mobile, it was late on cloud, it was late on NoSQL, it was late in BigData. Raise an hand who is using Bing, the same for the new super assistant Cortana. Microsoft is building its last ship. Net Core 1.0, there is the safest place to be, if you want to stay on the Microsoft8217s ship. Indeed Microsoft has missed a lot of boats since 10 years. But as technologies are tending to stabilize Microsoft has the opportunity to catch up. As for desktop, in professional context it is well alive. And indeed the web is the best bet for some years now. Software development and consulting in , C, C, Silverlight, Foxpro, SQL G-Track is a distributed application that allows you to acquire and track geographic points via GPS enabled smartphone and follow the work stage of every point. The system includes: The smartphone program, used to phisically acquire points via GPS. The desktop program that manage the geographic data, creating list and maps for intervention and keeping track of the work in progress. The internet database server that keep synchronized all the clients (mobile and desktop).
No comments:
Post a Comment