WinApp CLI ile .NET Uygulamalarına Paket Kimliği Vermek

Bir şeyi baştan söyleyeyim: Windows tarafında.NET uygulaması geliştiriyorsanız, bir gün “şu bildirım işini eklesem” ya da “AI API’lerini kullansam” dediğiniz anda büyük ihtimalle aynı duvara çarpmışsınızdır. Package identity. Yanı paket kimliği. Konsol ya da WPF gibi klasik masaüstü uygulamalar bunu kendiliğinden taşımıyor; taşımak istediğinizde de manifest dosyaları, sertifikalar, build ayarları derken zamanınızı yiyen bir uğraşa dönüyor. Kısa cevap bu. Bir bakıma, peki neden?

Kendi deneyimimden konuşuyorum, Neyse. Uzatmayayım. Microsoft bu işi biraz olsun toparlamak için yeni bir CLI aracı çıkardı: WinApp CLI. Açık konuşayım, yıllardır böyle bir şey bekleniyordu; ama işin aslı şu ki araç güzel dürüyor diye hemen her sorunu çözecek sanmayın (öyle olsa zaten hayat fazla kolay olurdu), çünkü bazı senaryolarda hâlâ elle kurcalama gerekiyor. Bir bakıma, tam da öyle.

Package Identity Nedir, Neden Umurumuzda Olsun?

Dürüst olmak gerekirse, Package identity’yi bazı kaynaklar gereksiz yere uzatıyor,. Işin özü baya basit: uygulamanızı Windows’a “resmî” şekilde tanıtıyorsunuz (ciddiyim). Kimlik kartı gibi düşünün. Bu kimlik yoksa Windows sizi tam tanımıyor, sonra da bir bakıyorsunuz kapılar tek tek kapanmış.

Hangi kapılar mı? İlk akla gelenler şunlar:

• Push ve toast bildirimleri
• Arka plan görevleri (background tasks)
• Share target — yanı başka uygulamalardan sizin uygulamaya içerik paylaşımı
• Dosya ilişkilendirmeleri (file handlers) — bunu es geçmeyin
• Windows AI API’leri — bu taraf son bir yılda iyice kritik öldü

Yanı mesele şu: modern Windows’ta “gerçek” bir uygulama gibi davranmak istiyorsanız, bu kimlik işi olmadan iş yürümüyor. WPF ile şirket içinde kullanılan bir muhasebe aracı yazıyorsanız belki çok takılmazsınız. Ama kullanıcıya bildirım göndereceğim, Copilot+ cihazlarda yerel AI modellerini çağıracağım, dosya türlerini handle edeceğim diyorsanız — işte o zaman bu konu direkt karşınıza çıkıyor. Burada, peki neden? Çünkü Windows burada biraz seçici davranıyor.

Evet.

Kimliksiz bir.NET uygulaması, Windows’un yeni özelliklerinin büyük çoğunluğuna dokunamaz. Bu bir bug değil, tasarım. Ve WinApp CLI çıkana kadar bu tasarımın etrafından dolaşmak bayağı sancılıydı.

Açık konuşayım, ilk duyduğumda ben de “tamam ya, ne var bunda” demiştim. Sonra gerçek senaryoya girince tablo değişiyor. Paket kimliği sadece bir etiket değil (bildirimden dosya eşleştirmeye kadar birkaç yerde kilit rol oynuyor), yanı Windows’un sizi nasıl gördüğünü doğrudan etkiliyor. Neyse, çok dağıtmayayım, asıl nokta şu: bu mekanizma olmadan bazı modern yetenekler ya hiç açılmıyor ya da yarım yamalak kalıyor.

Bu kadar mı?

Eski Dünya: Manifest Yazma Çilesi

WinApp gelmeden önce tablo biraz can sıkıcıydı. Bir.NET konsol uygulamanız var, buna identity vermek istiyorsunuz. Peki ne yapıyordunuz?

Vallahi, Önce Package.appxmanifest dosyasını elle yazıyordunuz. XML, hem de öyle üstünkörü değil; şemasını da akılda tutmanız gerekiyordu. Sonra .csproj‘a Microsoft.WindowsAppSDK referansını ekliyordunuz, target framework’ü de net8.0-windows10.0.19041.0 gibi bir şeye çekiyordunuz (bak şimdi, işin orası zaten başlı başına ayrı dert) (yanlış duymadınız). Ardından Assets klasörüne ikonları tek tek koyuyordunuz — Square44x44Logo, Square150x150Logo, StoreLogo, Wide310x150Logo… liste uzayıp gidiyor, sonra bir bakmışsınız saat kaç olmuş belli değil. Sertifika üretip pfx dosyasını ekliyordunuz; sonra da MSIX Packaging Tool ile mi paketlersiniz, yoksa makeappx mi çalıştırırsınız diye düşünürken sabahı görüyordunuz.

Küçük bir detay: Kısacası iş yorucuydu. Evet.

Açık konuşayım, çoğu geliştirici bu noktada bırakıyordu; ben de dahil. Bir müşteri “sadece bir tane toast notification atalım” dediğinde bile, arka tarafta yarım gün giden işi anlatmak zorunda kalıyorduk (ve bu bazen hiç ikna edici olmuyordu) (ki bu çoğu kişinin gözünden kaçıyor). Neyse uzatmayalım, mesele şu: küçük görünen ihtiyaçlar bile gereksiz yere büyüyordu.

Tam da öyle.

WinApp CLI sahnede: iki komutla iş bitiyor

WinApp’in olayı aslında şu, yukarıdaki pek çok boilerplate’i tek bir komuta sıkıştırıyor. Kurulum da winget üzerinden gidiyor, yanı lafı gevelemeden şöyle:

winget install Microsoft.winappcli --source winget

İlk bakışta “bu kadar mı?” diyorsunuz. Evet, bu kadar. Ama işin asıl hoş tarafı kurulumdan sonra başlıyor, çünkü iki ayrı senaryo var ve ikisi de baya iş görüyor.

1. Kimlikli şekilde debug etmek

Projenin kök dizinine geçip şu komutu çalıştırıyorsunuz:

winapp init. --use-defaults

Vallahi, Bak şimdi, bu komut arka tarafta birkaç işi sessizce toparlıyor; TargetFramework‘ünüzü uygun bir Windows platformuna göre ayarlıyor, Microsoft.WindowsAppSDK ile Microsoft.Windows.SDK.BuildTools.WinApp paketlerini .csproj‘a ekliyor. Package.appxmanifest ile Assets klasörünü de kendi hallediyor.

Neyse, çok uzatmayayım, bundan sonra bildiğiniz akışa dönüyorsunuz: dotnet run. Uygulama package identity ile kalkıyor ve sız de F5’e basıp Visual Studio içinde debug edebiliyorsunuz; breakpoint koyuyorsunuz, step över yapıyorsunuz, her şey normal geliştirme ritminde akıyor. Açık konuşayım, en sevdiğim tarafı da bu.

Bi saniye — Peki neden? Daha fazla bilgi için GitHub Copilot Artık JetBrains AI Assistant’ta Yerli Ajan yazımıza bakabilirsiniz.

2. MSIX olarak paketlemek

Dağıtım tarafında işler daha da kısa sürüyor. MSIX üretmek için artık tek satır yeterli:

winapp pack

Bitti gitti. Önceden MSIX Packaging Tool açılacak, sürücü seçilecek, tetiklenecek, izlenecek derken insanın canı çıkıyordu; şimdi o uğraşın çoğu kenara atılmış durumda.

Ne Değişti, Sahada Ne Goruuyoruz?

Garip gelecek ama, Şimdi biraz da işin bize dokunan tarafına gelelim. Kurumsal müşterilerde.NET tarafında son beş yılda gördüğüm en yaygın sorun şuydu: eski WPF veya WinForms uygulamalarını modernize etme projeleri. Şirketin 2015’ten kalma masaüstü uygulaması var, hâlâ çalışıyor ama modern Windows özelliklerinden faydalanamiyor. IT ekipleri de bunu görüp “bari MSIX olarak dagitsak da SCCM/Intune ile daha temiz push edebilsek” diyor.

Bak şimdi, Bu göç projelerinde eski dünyada takıldığımız yer hep manifestti. Şimdi WinApp CLI ile bir günlük is, yarım saate iniyor. En azından teoride. Pratikte hâlâ pürüzler var — birazdan geleceğim.

Türkiye’deki Şirketler Için Ne Anlama Geliyor?

Aslında — hayır dur, daha doğrusu, Türkiye’de bulut ve modernizasyon konusunda ilginç bir tablo var. Bir taraf çok hızlı ilerliyor — fintech, e-ticaret, bazı büyük bankalar. Diğer tarafta işe devasa bir “legacy.NET masaüstü” ortamı var. Muhasebe yazılımları, sigorta broker araçları, üretim tarafındaki MES entegrasyonları… Bunların çoğu WPF veya WinForms.

Doğrusu, Bu uygulamaların çoğu için “cloud-native SPA’ya geçelim” cevabı gerçekçi değil. Bütçe yok, yeniden yazacak insan kaynağı yok, zaten çalışan bir şeyi bozma iştahı da yok. Böyle durumlarda WinApp CLI gibi araçlar altın değerinde. Çünkü mevcut kod tabanına dokunmadan, sadece build pipeline’a birkaç adım ekleyerek uygulamayı modern Windows dünyasına dahil ediyorsunuz.

Şöyle bir senaryo düşünün: Anadolu’da bir üretim tesisi için yazılmış WPF tabanlı vardiya takip uygulaması. Su anda kimliksiz. Windows AI API’lerini kullanarak vardiya (belki yanılıyorum ama) raporlarını yerel bir modelle ozetletmek istiyorsunuz — verileri şirket dışına cikarmadan (yanlış duymadınız). Bunun için package identity şart. WinApp CLI olmadan bu is bir sprint, WinApp CLI ile yarım gün.

Bunu biraz açayım.

Enterprise vs Küçük Ekip Karşılaştırması

Bir tablo çizelim, çünkü senaryoya göre iş baya değişiyor:

Küçük ekipseniz, hızlıca identity alıp toast notification ya da dosya handler gibi şeyleri kurcalayın; baya iş görüyor. Büyük tarafta işe durum biraz farklı, hatta bazen can sıkıcı bile oluyor, çünkü WinApp CLI’ı bir hızlandırıcı gibi kullanırsınız ama üretime çıkmadan önce güvenlik ekibi manifesti satır satır bakar (özellikle capability ve extension tarafı), yoksa sonra sertifika ile izinler birbirine giriyor. Bu konuyla ilgili Data API Builder 2.0: REST Yolunu İş Yapına Göre Kurmak yazımıza da göz atmanızı tavsiye ederim.

Evet.

Şunu söyleyeyim, Neyse uzatmayalım: küçük ekipte amaç çabuk ayağa kalkmak, enterprise’da işe aynı işi daha kontrollü yürütmek. Sız ne dersiniz?

Peki Ya Eksikler? Her Şey Toz Pembe Değil

Açık konuşayım, WinApp CLI şu an fena değil ama olgun da değil. Preview bir araçtan ne bekliyorsan aşağı yukarı önü veriyor, hatta bazı yerlerde biraz geri de kalıyor; beklediğim kadar pürüzsüz değil yanı. Şu taraflarda hâlâ eksik var:

• MAUI desteği şimdilik tam net değil, WPF ve konsol tarafında daha rahat akıyor
• Manifesti elle özelleştirdikten sonra winapp init‘i tekrar çağırırsanız üstüne yazma davranışı biraz kaba oluyor — dikkat etmek lazım
• CI/CD entegrasyonu için hazır, oturmuş bir GitHub Actions template’i yok, bunu çoğu senaryoda sız kuruyorsunuz (bu kritik)
• Signing tarafı hâlâ ayrı bir mesele, WinApp bu kısmı tek başına halletmiyor

Yanı bugün itibariyle tablo şu: prototipleme. Local development için baya iş görüyor, ama üretim pipeline’ına koymak istiyorsanız biraz daha pişmesini beklemek lazım (en azından benim deneyimim böyle). Ama yol doğru görünüyor. VSIX Yayınını GitHub Actions’a Devretmek: Sade ve Tekrar Edilebilir Bir Yol yazımda anlattığım mantığı ben MSIX paketleme tarafına da taşıyorum — winapp pack komutunu Actions içinde koşturup, imzalama ile store submission adımlarını ayrı stage’lere bölmek bence daha temiz dürüyor.

Pratik Bir Yol Haritası: İlk Denemeniz İçin

Bakın, Bu yazıyı okuyup “tamam ben de deneyeyim” diyorsanız, bence en temiz başlangıç şu. Önce boş bir WPF ya da konsol projesi açın, production koduna dokunmayın, hatta mümkünse yeni bir sandbox klasörü kullanın; sonra işin içine WinApp CLI’ı alın ve ufak ufak ilerleyin.

1. Boş bir WPF veya konsol projesi açın (production kodunuzla oynamayın, yeni bir sandbox)
2. winget ile WinApp CLI’ı kurun
3. winapp init. --use-defaults çalıştırın, .csproj‘un nasıl değiştiğine bakın
4. dotnet run ile ayağa kaldırın
5. Uygulamada basit bir toast notification tetikleyin — bu identity’nın çalıştığının en hızlı testi
6. Sonra winapp pack ile MSIX üretin, Add-AppxPackage ile yerel makinenize kurun — bunu es geçmeyin

İşin aslı burada çok büyütülecek bir taraf yok. İlk turda amaç kusursuz paket çıkarmak değil, akışa alışmak; çünkü winapp init sonrasında .csproj‘da neyin eklendiğini görünce taşlar yerine oturuyor, ardından dotnet run, sonra da küçük bir toast denemesi geliyor. Sız ne dersiniz? Olayın gerçekten çalıştığını anlıyorsunuz.

Doğrusu, Evet. Claude Sonnet 5 GitHub Copilot’ta: Sahadan Sonnet Notları yazımızda bu konuya da değinmiştik.

Neyse, bi saniye — Bu döngü tamam olduktan sonra gerçek projeye geçin (en azından benim deneyimim böyle). Zaten yarım saat sonra “aa, bu kadar basitmiş” diye söyleneceksiniz. Ben ilk denediğimde bunu söyledim, itiraf edeyim. Microsoft SQL 2026 Yol Haritası: Sahadan Süzülmüş Notlar yazımızda bu konuya da değinmiştik.

Maliyet Tarafı

Bir de finansal boyut var. WinApp CLI ücretsiz, Windows App SDK ücretsiz. Yanı araç tarafında cebinizden para çıkmıyor. code signing sertifikası kısmına gelince tablo biraz değişiyor, çünkü TL bazında düşünürseniz yıllık 2500-8000 TL aralığında bir masraf görebilirsiniz (tabiî sağlayıcıya göre oynuyor). Daha fazla bilgi için Outlook Add-in Mailbox 1.16: Şifreli Mesajlar ve EWS Kararı yazımıza bakabilirsiniz.

Eğer EV (Extended Validation) sertifikası isterseniz iş başka yere kayıyor. Kurumsal senaryolarda EV şart oluyor çünkü SmartScreen uyarısını sıfıra indirmeye en yakın yol bu; küçük projelerde işe standart code signing çoğu zaman yeterli kalıyor, kullanıcı ilk çalıştırmada uyarı görse bile “yine de çalıştır” diyerek devam edebiliyor.

Peki neden?

Eğer bütçeniz kısıtlıysa ve bu iş iç kullanım için bir toolsa, self-signed sertifika ile başlayıp domain policy üzerinden makinelere trust ekletmek de mümkün. Zarif mi? Pek değil. Ama açık konuşayım, bazen tam da gereken şey bu oluyor.

Genel Değerlendirme

Bakın şimdi, açık konuşayım: WinApp CLI, Windows üstünde.NET geliştirme tarafında yıllardır süren o can sıkıcı boşluğa baya bir çare gibi dürüyor. Package identity meselesi vardı ya hani, herkesin “bir ara bunu düzgün çözerler herhalde” deyip geçiştirdiği konu, işte oraya resmî bir çözüm gelmiş öldü (ve evet, dotnet tooling’iyle de sıkı sıkıya bağlı).

Tuhaf ama, Bence doğru yere basılmış bir adım bu. Ama dur bir saniye — eksik tarafı da var; tam kapsamlı dokümantasyon yok, gerçek dünya örnekleri de az, yanı elinizdeki parçalar fena değil. Biraz dağınık kalıyor. Microsoft Learn içeriği biraz kuru geliyor bana, community’den örnekler çoğaldıkça işin rengi değişir diye düşünüyorum.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Açıkçası, Bu arada Windows tarafındaki geliştirici araçları da garip biçimde hızlandı. VS Code’da Copilot Browser Tools GA: Ajanlar Artık Sörfçü yazımda da değinmiştim; ekosistem resmen gaz almış gidiyor. AI, tooling, deployment derken her ay yeni bir şey çıkıyor, insan bir yandan seviniyor bir yandan da “bunu kim takip edecek?” diye bakıyor. Bu tarz araçları erken kurcalamak iyi fikir gibi dürüyor; çünkü sonraki projede hazır yakalanıyorsunuz (ben öyle görüyorum en azından). GitHub Copilot Modernization C++ İçin GA: MSVC Yükseltmesi Artık Kolay gibi yazılarda anlattığım modernizasyon işi de. Aynı çizgide ilerliyor.

Sıkça Sorulan Sorular

WinApp CLI sadece WinUI 3 için mi?

Kısacası, garip gelecek ama, Hayır, öyle bir zorunluluk yok. WinApp CLI, aslında.NET masaüstü framework’lerinin hepsiyle gayet iyi anlaşıyor. Konsol uygulaması, WPF, WinForms, WinUI 3 — hepsinde çalışıyor. Yanı hani eski bir WPF projeniz varsa, önü da rahatlıkla identity’e kavuşturabilirsiniz.

Kısa bir not düşeyim buraya.

Package identity kazanmak uygulamamı Microsoft Store’a girmeye zorlar mı?

Zorlamıyor, merak etmeyin. Açıkçası bu iki kavramı birbirine karıştırmak çok yaygın bir hata. Identity kazandırdıktan sonra uygulamayı yine MSIX olarak kendi sitenizden dağıtabilir, Intune ile push edebilir ya da bir installer’a gömebilirsiniz. Store yalnızca opsiyonel bir dağıtım kanalı, yanı kimse sizi oraya gitmeye zorlamıyor.

Mevcut MSIX paketleme yöntemlerimi bırakıp WinApp’e geçmeli mıyım?

Şart değil. Eğer pipeline’ınız zaten işliyor ve bir düşüneyim… ekibiniz alışkınsa, bence en mantıklısı WinApp CLI’ı önce yeni projelerde denemek. Eski MSIX Packaging Tool ya da elle manifest yönetimi hâlâ geçerli — sadece biraz daha zahmetli, o kadar. Bir de şunu söyleyeyim: preview aşamasındaki bir aracı üretime almadan önce birkaç iterasyon test etmek gerçekten önemli.

Self-signed sertifika ile üretime çıkabilir mıyım?

Teknik olarak evet. Ama pratik olarak? Pek tavsiye etmem. Kullanıcı makinelerinde SmartScreen uyarısı fırlıyor ve tecrübeme göre çoğu son kullanıcı o ekranı görünce hemen geri çekiliyor. Şirket içi dağıtım için domain policy üstünden trust ekletmek bir çözüm olabilir, mesela kurumsal ortamlarda bu işe yarıyor. Ama halka açık bir dağıtım söz konusuysa standart veya EV code signing sertifikası şart.

WinApp CLI ile üretilen MSIX’i eski Windows sürümlerinde çalıştırabilir mıyım?

Desteklenen minimum platform Windows 10 sürüm 1809. Windows 7 veya 8 hedefliyorsanız bu yol size uygun değil, klasik installer’a (MSI, EXE) sadık kalmanız gerekiyor. Açıkçası bence 2026 itibariyle bu kadar eski sürümler için yeni özellik geliştirmenin pek bir anlamı da kalmadı zaten.

Bir dakika — bununla bitmedi.

Kaynaklar ve İleri Okuma

Packaging and Package Identity for.NET apps with WinApp CLI on Windows —.NET Blog

Windows App SDK Resmî Dokümantasyonu

MSIX Packaging Overview — Microsoft Learn

Windows App SDK GitHub Repository

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

GitHub Copilot for Eclipse Açık Kaynak Oldu: Bu Ne Değiştiriyor?22 May 2026

Outlook Add-in Mailbox 1.16: Şifreli Mesajlar ve EWS Kararı30 Haz 2026

.NET ile Vektör Veri: Yapay Zekâda Anlamı Gerçekten Nasıl Yakalarız?21 Mar 2026

Visual Studio’da Plan Agent: Kodu Yazmadan Önce Durup Düşünmek24 May 2026