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-defaultsVallahi, 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
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.
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).
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
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.
3 comments