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.
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.
Ç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.
2 comments