NuGet Paketlerini C++ Projelerinde Düzenlemek: PackageReference Dönemi
Visual Studio’da C++ tarafında NuGet işi yıllardır biraz “idare eder” seviyesindeydi. Çalışıyordu, evet. Ama paket yönetimi dediğiniz şey, proje dosyasının içine gömülü, okunması kolay. CI/CD’de sürpriz çıkarmayan bir yapıda olmalıydı. İşin aslı şu ki, PackageReference bu açıdan bayağı önemli bir eşik.
📋 İçindekiler
- C++ tarafında neden böyle bir değişim gerekiyordu?
- PackageReference ne kazandırıyor?
- Nerede kullanılır, nerede vcpkg daha doğru kalır?
- Bunu Türkiye’deki şirketler açısından nasıl okumalıyız?
- Sahada dikkat ettiğim birkaç ince nokta
- Nereden başlamalı?
- Sıkça Sorulan Sorular
- Kaynaklar ve İleri Okuma
- İlgili Yazılarımızdan Bazıları
Microsoft’un native C++ projeleri için <PackageReference> desteğini açması, ilk bakışta küçük bir özellik gibi görünebilir. Değil. Özellikle.NET ve C++’ı aynı çözüm içinde taşıyan ekiplerde, bağımlılık yönetimini tek mantıkta toplamak ciddi rahatlık sağlıyor. Ben bunu ilk kez — itiraz edebilirsiniz tabi — bir hibrit masaüstü projede denediğimde, build çıktısındaki tutarlılık farkını hemen gördüm. Hani bazen “küçük dokunuş” dersiniz ya — işte tam öyle ama etkisi büyük.
Kısa bir not düşeyim buraya.
Bir de şu var: Visual Studio Insiders Channel’da başlayan bu deneysel destek, bana eski günleri hatırlattı (ki bu çoğu kişinin gözünden kaçıyor). 2019’da Ankara’daki bir müşteri ortamında benzer bir dağınıklık yaşamıştık.NET tarafı modern dependency akışıyla ilerliyor, C++ tarafı işe ayrı klasörler ve ayrı kurallar yüzünden kendi kafasına göre takılıyordu. O zamanlar bunu (söylemesi ayıp) elle toparlamaya çalışmıştık (bizzat test ettim). Şimdi işe araç zinciri buna daha doğal yaklaşıyor.
C++ tarafında neden böyle bir değişim gerekiyordu?
Eskiden C++ projelerinde NuGet çoğunlukla packages.config ile yürüyordu. Yanı bağımlılıklar ayrı XML dosyasında dürüyor, çözüm bazında packages klasörü şişiyor, transitive bağımlılıklar da sizin yerinize değil, neredeyse sizin inatla uğraşmanızla yönetiliyordu. Küçük projede çok dert olmuyor ama ekip büyüyünce iş karışıyor.
Peki neden?
PackageReference burada oyunu değiştiriyor çünkü paket tanımı doğrudan .vcxproj içine giriyor (şaşırtıcı ama gerçek). Tek kaynak mantığı geliyor. Proje referanslarıyla aynı yerde durduğu için “hangi sürüm nereden geldi” sorusu biraz daha netleşiyor. Ben Azure danışmanlığı yaptığım kurumsal işlerde hep aynı şeyi görüyorum: belge başka yerdeyse hata da orada başlıyor.
Ne yalan söyleyeyim, Bence Microsoft’un bu özelliği en çok kullanıcı geri bildirimiyle şekillendirmesi de önemli. Visual Studio Developer Community’de en çok oy alan taleplerden biriymiş; yanı masa başında uydurulmuş bir özellik değil, sahadan gelen gerçek ihtiyaç. Bu bana güven veriyor açık konuşayım.
Hmm, bunu nasıl anlatsamdı…
PackageReference ne kazandırıyor?
Kazançların ilki basitlik. Paket bilgisi proje dosyasında olduğu için gözünüz sürekli tek yerde oluyor. İkincisi transitive dependency çözümü; yanı sız sadece doğrudan kullandığınız paketi yazıyorsunuz, gerisini NuGet hallediyor. Üçüncüsü de global cache konusu — disk kullanımında ciddi fark yaratabiliyor.
Geçen yıl İzmir’de bir üretim müşterisinde restore sürelerini ölçerken bunu net gördük. Aynı ürün ailesinde 18’e yakın C++ — kendi adıma konuşayım — bileşeni vardı ve bazı makinelerde gereksiz klasör kalabalığı yüzünden build alanı şişmişti. PackageReference benzeri modern modelle geçince restore davranışı daha öngörülebilir öldü. Tam mucize değil ama pratikte nefes aldırıyor.
E tabi her şey güllük gülistanlık değil — Deneysel olması önemli bir not düşürüyor buraya… Çünkü üretimde körlemesine geçilecek bir nokta değil henüz. Visual Studio Insiders Channel ile denemek güzel ama enterprise tarafta benim tavsiyem önce kontrollü pilot yapmak olur.
| Konu | packages.config | PackageReference |
|---|---|---|
| Paket tanımı | Ayrı XML dosyası | .vcxproj içinde |
| Transitive bağımlılıklar | Daha manuel yaklaşım | Otomatik çözümleme |
| Paket depolama | Söz konusu solution’a özel klasörler | Global cache |
| Sürüm koşulları | Daha sınırlı yapı | MSBuild koşullarıyla esnek kontrol |
Küçük ekipler için durum nasıl?
Küçük ekipseniz işin özü şu: sade olun. Bir ya da iki native bileşeniniz varsa ve.NET ile yan yana geliştiriyorsanız PackageReference size düzen getirir. Build betikleri daha okunur olur, yeni gelen arkadaşın projeyi kavraması kolaylaşır. Daha fazla bilgi için Copilot CLI’yi Telefondan Yönetmek: Benim Sahada Gördüğüm Etki yazımıza bakabilirsiniz.
Peki neden? Çünkü az dosya, az sürpriz demek oluyor; hele ki çözüm yapısı zaten karmaşıksa, tek tek packages klasörü kovalamak insanın canını sıkıyor. Sonra herkes “niye restore bu kadar yavaş” diye birbirine bakıyor (ki bu çoğu kişinin gözünden kaçıyor)
Büyük kurumsal yapılarda ne değişir?
Büyük organizasyonlarda mesele sadece teknik değil; süreç meselesi de var. Versiyon sabitleme politikaları, offline build agent’ları, onay mekanizmaları… Bunların hepsi devreye giriyor. Burada PackageReference iyi ama tek başına yeterli değil; governance katmanı şart.
Neyse, çok dağıttım gibi öldü ama konu tam da burada düğümleniyor: araç doğru olsa bile işletim modeli kötüysa sonuç yine yorucu çıkıyor ve ekip sonunda problemi pakette değil akışta aramaya başlıyor.
Nerede kullanılır, nerede vcpkg daha doğru kalır?
Microsoft’un önerisi bence gayet yerinde: C++ kütüphaneleri için hâlâ vcpkg dayanıklı seçenek olmaya devam ediyor (ben de ilk duyduğumda şaşırmıştım). Çünkü vcpkg tam olarak bu iş için tasarlanmış durumda; derleme bayrakları, platform uyumu ve native library dünyasının ince ayarları onda daha doğal dürüyor (eh, fena değil) Bu konuyla ilgili .NET ve .NET Framework Mayıs 2026 Güncellemeleri: Ne Değişti? yazımıza da göz atmanızı tavsiye ederim.
PackageReference, özellikle binary SDK paketleri veya C++ dışı payload’lar dağıtmak isteyen ekiplerde anlam kazanıyor gibi düşününce tablo netleşiyor. Yanı “her şeyi bununla yapayım” yaklaşımı yanlış olurdu zaten… Bizim sektörde böyle genelleme yapan sistemler genelde sonra duvara tosluyor.
Açık konuşayım: Bir finans kuruluşunda çalışırken benzer kararları verirken en kilit soru hep şu olurdu — “Bu araç bize standart mı getiriyor yoksa yeni karmaşa mı ekliyor?” Eğer repo içinde hem managed hem native bileşen varsa ve dağıtım modeli sadeleşecekse PackageReference mantıklı olabilir. Ama saf C++ bağımlılığı yoğun işe vcpkg hâlâ daha temiz dürüyor. Daha fazla bilgi için Model Router Evals: Doğru Modeli Seçtiğini Nasıl Kanıtlarsın? yazımıza bakabilirsiniz. Copilot cloud agent ile Kırık Actions İşini Tek Tıkta Çözmek yazımızda bu konuya da değinmiştik.
Benim kısa görüşüm şu: PackageReference güzel bir adım ama C++ dünyasının tamamını tek başına kurtarmaz; doğru araç kombinasyonu hâlâ en kritik konu.
Bunu Türkiye’deki şirketler açısından nasıl okumalıyız?
Bence Türkiye’deki şirketlerin büyük kısmı bu tür yeniliklere iki uçtan yaklaşıyor: ya hiç dokunmuyorlar ya da doğrudan üretime taşıyorlar… İkisinin de sıkıntısı var tabiî ki! Kurumsal müşterilerimde gördüğüm kadarıyla en sağlıklı yol pilot + ölçüm + kademeli yayılım oluyor. Bu konuyla ilgili Copilot Spaces API GA: Kurumsal ekipler için gerçek fark ne? yazımıza da göz atmanızı tavsiye ederim.
Çok konuştum, örnekle göstereyim.
Tam burada FinOps bakışı da devreye giriyor aslında — evet konu paket yönetimi ama dolaylı maliyet etkisi var. Restore süresi uzarsa pipeline süresi uzuyor, pipeline uzarsa çalışan saati boşa gidiyor (özellikle büyük takımlarda). TL bazında düşününce küçük görünen iyileştirme ay sonunda fena hâlde fark yaratabiliyor.
Yanı, Eğer bütçe dar işe ilk yatırımınız eğitim olsun derim ben.
Yanı ekipte herkes yeni modeli anlasın, package migration nasıl yapılıyor bilsin, sonra örnek bir modül üzerinde deneyin… Böyle giderse risk azalır.
İşte, bir de şu var: Azure DevOps kullanan ekiplerde artifact akışıyla package restore davranışını birlikte düşünmek lazım; yoksa sorun paket sistemi sanılır ama kök sebep çoğu zaman pipeline tasarımı çıkar.
Migrasyon için pratik yol haritası
- Pilot olarak düşük riskli bir.vcxproj seçin.
packages.configbağımlılıklarını listeleyip birebir karşılaştırın.- Create/restore adımlarını lokal makinede ve build agent’ta test edin.
- Sürüm sabitleme ve conditional reference ihtiyacınızı kontrol edin.
- Paketlerin gerçekten native mi yoksa binary SDK mı olduğuna karar verin.
Sahada dikkat ettiğim birkaç ince nokta
İlk denediğimde aldığım hata oldukça öğreticiydi: restore sonrası bazı referanslar görünmüyor sandım meğer target framework/condition eşleşmesi yüzünden asset seçimi beklediğim gibi çalışmıyormuş. Sız hiç denediniz mi? Kısacası sorun araçta değilmiş; benim MSBuild koşullarımı biraz fazla özgüvenle yazmamdaymış! Çözümü sadeleştirince düzeldi.
Aynı şeyi geçen mart ayında Gebze’deki bir otomotiv tedarikçisiyle yaptığımız çalışmada da gördük. Platform bazlı farklı paketler tanımlayınca proje dosyasının okunabilirliği düştü (evet, doğru duydunuz). Kontrollü yazınca gayet işler hâle geldi.. Hani ne farkı var diyorsunuz, değil mi? Yanı esneklik iyi fakat disiplin istemesi kötü haber değil; aksine profesyonel kullanımın bedeli bu biraz.
Neyse uzatmayalım: Eğer bugün yeni bir native proje açıyorsanız ve NuGet’i sadece binary dağıtım aracı gibi görüyorsanız PackageReference denenebilir bir yol sunuyor demektir. Ama mevcut büyük çözümleri taşırken acele etmeyin… Bazen “yenilik” dediğimiz şey sırf geçiş maliyetini artırabiliyor!
Nereden başlamalı?
Bence, Lafı gevelemeden söyleyeyim: önce kendi dependency haritanızı çıkarın. Hangi paket gerçekten gerekli? Hangisi transitif geliyor? Hangisi zaten vcpkg ile daha doğru yönetilir? Bu üç soruya net cevap vermeden migrasyona girmek pek akıllıca olmazdı (ki bu çoğu kişinin gözünden kaçıyor)
- Küçük proje: Doğrudan PackageReference deneyin ve sonuçları ölçün. (bu kritik)
- Büyük kurum: Pilot uygulama + CI testi + sürüm politikası belirleyin.
- Saf native kütüphane: Önce vcpkg’ye bakın, sonra gerekirse PackageReference düşünün. (bu kritik)
Ben bunu Azure DevOps pipeline’larında defalarca gördüm; standardizasyon küçük görünür ama etki büyüktür.
Sıkça Sorulan Sorular
C++ projelerinde PackageReference zorunlu mu?
Hayır, zorunlu değil. Hani modern seçeneklerden biri olarak geliyor. Mevcut projeler packages.config ile devam edebilir, ama yeni projelerde bence değerlendirmeye değer.
C++ kütüphaneleri için vcpkg yerine kullanılmalı mı?
Düz cevap: hayır. Native library yönetiminde vcpkg hâlâ daha özel ve güçlü. PackageReference işe daha çok NuGet tabanlı binary’lerde ya da hibrit senaryolarda anlam kazanıyor,. Kullanım alanı biraz farklı.
Bunu üretimde hemen kullanmak güvenli mi?
Bence, Aslında daha çok deneysel aşamada olduğu için önce test ortamında denemenizi öneririm. Küçük pilotlarla başlamak, tecrübeme göre, çoğu zaman daha güvenli oluyor.
.NET ile aynı solution içinde fayda sağlar mı?
Evet, hatta en güçlü taraflarından biri bu olabilir. Mesela hem.NET hem C++ projelerinde benzer dependency modeli kullanmak bakım yükünü azaltıyor (yanlış duymadınız). Açıkçası bu, ekipler için bayağı rahatlatıcı olabiliyor.
Kaynaklar ve İleri Okuma
Microsoft Learn — Package references in project files
Microsoft Learn — Migrate from packages.config to PackageReference
Tuhaf ama, GitHub — vcpkg Resmî Deposu
İlgili Yazılarımızdan Bazıları
NuGet Paket Budaması: Daha Temiz.NET Bağımlılıkları
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
2 comments