Açık konuşayım: Visual Studio’nün Developer Community sayfasında yıllardır en çok oy alan isteklerden birini sonunda hayata geçirmişler. C++ tarafına PackageReference desteği gelmiş, hem de şimdilik deneysel olarak, Insiders kanalında (ciddiyim). 18.7 sürümünden itibaren. Siz ne dersiniz? Küçük bir adım gıbı duruyor ama değil; çünkü native tarafta çalışanlar olarak biz uzun süre packages.config denen o garip XML’le uğraşıp durduk.
Şunu fark ettim: Bu yazıda yeniliğin teknik tarafını anlatacağım, ama asıl mesele başka — sahada bunun neye denk geldiğini, hangı senaryoda işinizi gördüğünü, hangı durumda hâlâ vcpkg’ye dönmeniz gerektiğini konuşacağız. Bir de Türkiye’deki kurumsal müşterilerde sık gördüğüm “interop” gerçeğine değineceğim; hani şu C++ ve.NET’i aynı solution içinde koşturan şirketler var ya, işte onlardan bahsediyorum.
Çok konuştum, örnekle göstereyim.
Önce Hızlı Bir Geri Bakış: packages.config Neden Sınır Bozucuydu?
Hatırlıyor müsünüz packages.config dosyasını? Solution’ın yanında duran şu küçük XML. Native bir C++ projesine NuGet paketi eklediğinizde, — en azından ben öyle düşünüyorum — Visual Studio genelde işi şöyle yürütüyordu: önce solution dizini altına bir packages klasörü açıyor, paketi oraya indiriyor, sonra packages.config‘e bir satır ekliyor, en sonunda da.vcxproj dosyasına o paketin .targets. .props dosyalarını import eden satırları gömüyordu.
İtiraf edeyim, Sonuç biraz can sıkıcıydı. Her solution kendi packages klasörünü taşıyordu; diskte aynı paketler defalarca duruyordu, üstüne bir de transitive (dolaylı) bağımlılıkları elle takıp etmeniz gerekiyordu. Yanı A paketi B’ye bağlıysa, B’yi de ayrıca yazıyordunuz. Kısacası iş büyüyordu..NET tarafı bunu 2017’de çözdü, biz native tarafta işe 8 yıl bekledik. Sekiz. Yıl.
Geçen sene Logosoft’ta bir savunma sanayi müşterisinde tam da bu yüzden başımız ağrımıştı. CI sunucusu her build’de bir düşüneyim… nuget restore çalıştırıyordu ama bazı paketler restore ölmüyor, build kırılıyordu; sebep de şuydu: bir geliştirici packages.config‘i güncellemiş ama .vcxproj‘a karşılık gelen Import satırını eklememişti. İki gün gitti. İşte PackageReference, bu “iki yerde tutulan tek gerçek” meselesini baya toparlıyor.
Çok konuştum, örnekle göstereyim.
Aslında, Evet.
Peki PackageReference Ne Yapıyor?
Lafı gevelemeden söyleyeyim: PackageReference paketi proje dosyasının içine taşımıyor, sadece referans olarak tutuyor. Yanı paketleri çözme işini daha temiz yapıyor; dependency graph’i merkezî şekilde hesaplıyor ve restore sırasında doğru sürümü bulmaya çalışıyor. Bu kulağa kuru geliyor olabilir ama pratikte fark ediyor, çünkü artık her proje kendi küçük ada ülkesi gıbı davranmıyor.
Burada hoşuma giden taraf şu öldü: bağımlılık zinciri daha okunur hâle geliyor (özellikle büyük solution’larda), ayrıca gereksiz kopya paket kalabalığı azalıyor. Ama dür bir saniye — her şey güllük gülistanlık değil tabi; eski projelerde geçiş yaparken bazı custom build adımları ve özel target kullanımları yüzünden ufak sürprizler çıkabiliyor. Yanı kolay mı? Kimi yerde evet, kimi yerde “bak şimdi neden bozuldu?” dedirtiyor.
Evet, doğru duydunuz.
Siz ne dersiniz? Ben açık konuşayım, PackageReference çoğu senaryoda daha az uğraştırıyor gıbı duruyor.
C++ Projelerinde Asıl Fark Nerede Hissediliyor?
Neyse uzatmayalım, asıl kritik nokta şu: C++ tarafında NuGet uzun süre biraz yamalı bohça gıbı kullanıldı; çünkü package management ile MSBuild entegrasyonu aynı rahatlıkta değildi. Tahmin eder mısınız? PackageReference gelince restore davranışı daha düzenli hâle geliyor ve proje dosyası da şişip saçma sapan satırlar arasında kaybolmuyor.
Size bir şey söyleyeyim, Ayrıca transitive dependency konusu burada ciddi rahatlatıyor insanı. Mesela bir kütüphane başka birkaç pakete dayanıyorsa, bunları tek tek kovalamak yerine çözümleme işini NuGet’e bırakabiliyorsunuz (tabi sürüm çakışmaları yine büyük ölçüde sihirli biçimde yok ölmüyor). Hmm, yanı sorunlar bitmiyor ama en azından elle hata üretme ihtimali azalıyor.
İşte tam da bu noktada devreye giriyor.
Kısacası işin aslı şu: eski modelde hem bakım yükü vardı hem de restore akışı kırılgandı; yeni modeldeyse proje daha sade kalıyor ve ekipler aynı şeyi iki farklı yerde düzeltmek zorunda kalmıyor.
PackageReference Nedir, Pratikte Ne Değişiyor?
Lafı uzatmadan kodla gireyim. Eskiden packages.config tarafında iş şöyle dönüyordu, yanı paketler ayrı bir XML dosyasında tutuluyordu ve her bağımlılığı tek tek yazıyordunuz:
<!-- packages.config (eski yöntem) -->
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Microsoft.Windows.CppWinRT" version="2.0.240405.15" targetFramework="native" />
<package id="boost" version="1.83.0" targetFramework="native" />
<package id="boost_system-vc143" version="1.83.0" targetFramework="native" />
</packages>Şimdi işe tablo biraz değişti. Paket işi doğrudan .vcxproj içine giriyor, MSBuild diliyle yazıyorsunuz, hem de condition kullanabiliyorsunuz; mesela Debug için ayrı paket eklemek gıbı, küçük görünüyor. Peki bunu neden söylüyorum? Pratikte baya iş görüyor:
<!--.vcxproj içinde (yeni yöntem) -->
<ItemGroup>
<PackageReference Include="Microsoft.Windows.CppWinRT" Version="2.0.240405.15" />
<PackageReference Include="boost" Version="1.83.0" />
</ItemGroup>
<!-- Hatta condition de kullanabilirsiniz -->
<ItemGroup Condition="'$(Configuration)'=='Debug'">
<PackageReference Include="Microsoft.VisualStudio.Debugger.Engine" Version="*" />
</ItemGroup>Araya gireyim: Gördüğünüz gıbı boost_system-vc143‘ü ayrıca yazmadım. Daha açık söyleyeyim, peki neden? Çünkü artık transitive resolution var, yanı dolaylı bağımlılıkları NuGet kendi çözüyor; açık konuşayım, bu detay küçük gıbı duruyor ama on binlerce satırlık bir solution’da insanın nefesini açıyor.
Evet, doğru duydunuz.
Evet.
Önemli Farkları Tabloyla Görelim
Burada işin özünü bir tabloda görmek daha rahat oluyor. Şey, uzun uzun anlatınca kafa karışabiliyor ama tabloya bakınca fark hemen çıkıyor ortaya:
| Özellik | packages.config | PackageReference |
|---|---|---|
| Bağımlılık tanımı | Ayrı XML dosyası | Doğrudan.vcxproj içinde |
| Transitive bağımlılık | Elle yazılır | Otomatik çözülür |
| Paket deposu | Solution başına klasör | Global cache (tek nokta) |
| MSBuild condition | Desteklenmiyor | Tam destek |
| Disk kullanımı | Tekrarlı, şişkin | Tek kopya, yalın |
| CI/CD entegrasyonu | Sorunlu, hassas | Düz, predictable |
Neyse uzatmayayım, asıl mesele şu: PackageReference ile proje dosyanız daha toparlanmış oluyor, bağımlılık yönetimi de daha az el emeği istiyor. Az önce dedim ya, transitive tarafı burada oyunu değiştiriyor; siz sadece doğrudan ihtiyacınızı yazıyorsunuz, gerisini sistem hallediyor.
Peki eski yöntem tamamen çöpe mi gitti? Tam da öyle değil ama yeni projelerde ben açıkçası PackageReference tarafını tercih ederim.
Küçük bir detay: Tam da öyle.
Nasıl Aktif Edilir? (Insiders Kanalı Şart)
Bir şey dikkatimi çekti: Şimdi pratik tarafa geçelim. Bu özellik experimental, yanı henüz tam oturmuş değil. Visual Studio Insiders Channel kurmanız gerekiyor, sürüm 18.7 ve üstü istiyor. Stable VS 17.x tarafında bu iş şu an çalışmıyor. Sabırlı olun; birkaç ay sonra mainstream’e düşer muhtemelen.
Etkinleştirme adımları kabaca şöyle: Bu konuyla ilgili Copilot Spaces API GA Oldu: Otomasyonun Kapısı Açıldı yazımıza da göz atmanızı tavsiye ederim.
- Visual Studio Insiders’ı kurun (yan yana yüklenebiliyor, mevcut VS’ınızı bozmaz)
- Tools → Options → Preview Features altından “Use PackageReference for C++ projects” seçeneğini açın
- VS’i kapatıp açın
- Yeni bir
.vcxprojoluşturduğunuzda ya da mevcut bir projeye NuGet paketi eklediğinizde artıkPackageReferenceformatı kullanılacak
Mevcut packages.config projelerini taşımak isterseniz, NuGet ekibinin migration aracı.NET projeleri için yıllardır var; C++ tarafına da benzer bir mekanizma geliyor. Solution Explorer’da packages.config‘e sağ tıkladığınızda “Migrate packages.config to PackageReference” seçeneği çıkacak. Geçen hafta küçük bir test projesinde denedim, gayet temiz dönüştürdü. Ama açık konuşayım — büyük bir kurumsal solution’da körlemesine basmayın. Bu ne anlama geliyor? Önce branch açın, bir deneyin, sonra karar verin (şaşırtıcı ama gerçek)
“Yeni bir teknoloji preview’dan çıkmadan önce production’a almak, kasıtlı bayrak yakmaktır. Önce yan dallar, sonra ana dal — bu sırayı bozarsanız üretim de bozulur.”
Peki vcpkg Ne Oluyor? PackageReference’a Kuyu mu Kazıldı?
Hayır, kazılmadı. Bunu özellikle net söyleyeyim, çünkü sahada en çok dönen soru bu oluyor; Microsoft’un tavsiyesi de zaten aynı yere çıkıyor: C++ kütüphaneleri için hâlâ vcpkg. Yanı Boost, OpenSSL, fmt, spdlog, Eigen gıbı şeyleri NuGet’ten çekmeye çalışmak, açık konuşayım, 2026’da pek oturmuyor.
O zaman PackageReference kime göre? Şu senaryolarda bayağı iş görüyor:
- C++/.NET interop projeleri: Hem managed hem native kod taşıyan solution’lar. Tek bir dependency düzeniyle ilerlemek işleri epey sadeleştiriyor. — ciddi fark yaratıyor
- Binary SDK paketleri: Mesela Windows SDK uzantıları, Azure Mobile binary’leri, CppWinRT gıbı paketler. — bunu es geçmeyin
- İç paket akışları (private feed): Şirket içinde ürettiğiniz native bileşenleri dağıtmak. Bir bankada müşteri tarafında “ortak şifreleme kütüphanesi” gıbı paylaşımlı SDK’ları NuGet feed üzerinden dağıtıyorduk — orada gerçekten kullanışlıydı.
- Tooling paketleri: Statik analiz araçları, kod jenerasyonu yapan MSBuild target’ları içeren paketler.
Yanı vcpkg ile NuGet arasında “ya o ya bu” durumu yok, daha çok görev paylaşımı var. Açık kaynak C++ kütüphanesi mi lazım? vcpkg. Binary SDK, internal paket ya da MSBuild tooling mi? NuGet PackageReference. İkisini aynı projede birlikte kullanabiliyorsunuz, burada bir çatışma çıkmıyor.
Türkiye Perspektifi: Bu Bizim İçin Niye Önemli?
Şimdi biraz farklı bir yerden bakalım (ki bu çoğu kişinin gözünden kaçıyor). Türkiye’de kurumsal C++ kullanımı, Batı’daki tabloya pek benzemiyor; Avrupa’da bu iş daha çok game dev, embedded ya da finance HFT gıbı dar alanlarda dönüyor, bizde işe savunma sanayi, telekom altyapı yazılımı, bankacılık core sistemler. Kamu projeleri tarafında hâlâ epey C++ kodu var.
Üstelik işin garip kısmı şu: bu projelerin çoğu 10-15 yıllık legacy mimarı üstünde yaşıyor. Evet, tam da öyle. Hepsinde C++ ve.NET kodu yan yana duruyor; mesela bir telekom OSS/BSS sisteminde core processing C++ olurken yönetim arayüzü WPF ya da ASP.NET olabiliyor, bir savunma simülasyonunda motor native kalırken operatör konsolu.NET ile yazılıyor (baya tanıdık bir manzara). Böyle senaryolarda packages.config ile PackageReference‘ın birlikte çalışması açık konuşayım baş ağrıtıyordu.
Şimdi tek bir dependency modeliyle ilerlemek mümkün oluyor. Küçük bir detay gıbı duruyor ama değil. Hele bir de de karmaşık kurumsal yapılarda, paket yönetimini sadeleştirmek ekiplerin elini ciddi rahatlatıyor; hem bakım tarafı toparlanıyor hem de aynı çözüm içinde farklı proje tiplerini idare etmek biraz daha az sınır bozucu hâle geliyor.
Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de benimsenme hızı da muhtemelen biraz farklı olacak. Peki, peki neden? Çünkü bizde “preview” özelliklere geçiş süresi Batı’ya göre genelde 1-2 yıl gecikiyor; bankacılık denetimleri, KVKK uyumluluk dokümantasyonu ve iç güvenlik testleri derken iş uzuyor da uzuyor. Yanı “Insiders kanalında geldi” diye hemen atlamak pek kolay değil.
Bence stable’a inmesi için Q2 2026’yı beklemek daha gerçekçi duruyor. Emin değilim ama sanırım çoğu ekip (söylemesi ayıp) o zamana kadar bunu deneme ve öğrenme aşaması olarak ele alır; yanı prod’a basmaktan çok, laboratuvarda kurcalayıp neyin ne olduğunu anlamaya çalışır. Bu kadar mı? Şimdilik evet. Kubernetes v1.36: Service ExternalIPs Tarihe Karışıyor yazımızda bu konuya da değinmiştik.
Peki neden?
dotnet add package benzeri CLI komutları C++ projeleri için de çalışabilir hâle gelebilir. Şu anki Insiders sürümünde komut satırı desteği biraz sınırlı, ama yön belli.
Pratik Bir Senaryo: Adım Adım Geçiş Planı
İşin garibi, Diyelim orta ölçekli bir C++ projeniz var. 20-30 tane NuGet paketi dönüyor, işler de öyle uzaktan bakınca idare eder gıbı duruyor. Geçişe karar verdiniz mi, ben açık konuşayım, önce panik yapmadan sırayı kurarım. Yoksa bir yerde restore patlıyor, başka yerde build sapıtıyor, sonra insan “biz neyi kaçırdık” diye ekrana bakıp kalıyor.
1. Önce Envanter Çıkarın
İlk iş bu. packages.config içindeki paketlere tek tek bakın; hangisi gerçekten C++ kütüphanesi, hangisi sadece tooling ya da SDK tarafında kalıyor, bunu ayırmadan ilerlerseniz kafa karışıyor. Mesela Boost ya da OpenSSL gıbı kütüphaneleri bu fırsatta vcpkg tarafına taşımak baya iş görüyor,. Hem doğru aracı kullanmış oluyorsunuz hem de geçiş sırasında gereksiz yük azalıyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Peki neden? Çünkü aynı paketi iki farklı yerden yönetmeye çalışınca işin rengi değişiyor.
2. Test Branch’inde Migration Aracını Çalıştırın
Solution Explorer içinde packages.config‘e sağ tıklayın, sonra Migrate to PackageReference deyin. Evet, olay bu kadar basit görünüyor; ama hani şu “basit” dediğimiz şeyler vardır ya, bazen tam tersine en çok orada sürpriz çıkarır. Otomatik dönüşüm sonrası build alın ve çıkan hataları genelde loglayın (özellikle ilk denemede), çünkü sonradan dönüp bakmak kurtarıcı oluyor.
E sonra? Eğer burada sessizce geçerse şanslısınız.
3. Transitive Bağımlılıkları Sadeleştirin
Migrasyon bittikten sonra listede fazladan yazılmış paketler görmeniz normal. Mesela boost zaten referanslandıysa, boost_system-vc143 gıbı ayrı satırlar çoğu zaman gereksiz kalıyor. Eski alışkanlıkla yazılmış şeyleri temizlemek gerekiyor. Hani ne farkı var diyorsunuz, değil mi? Bunları silip tekrar build edin, çünkü bazen asıl sorun paket sayısı değil, o paketlerin birbirine dolanmış hâli oluyor. Copilot CLI Uzaktan Kontrol: Telefondan Terminal Yönetimi yazımızda bu konuya da değinmiştik.
Neyse uzatmayalım, burada biraz temizlik şart.
4. CI/CD Pipeline’ını Güncelleyin
Azure DevOps ya da GitHub Actions tarafında restore adımı için kullandığınız yapı artık güncellenmeli; NuGetRestore@1 yerine NuGetCommand@2, bazı senaryolarda da doğrudan dotnet restore daha düzgün sonuç veriyor. Yukarıda bahsettiğim o değişiklikler var ya, benim Azure DevOps Server Mayıs Yamaları: Sahadan Notlar yazısında restore davranışındaki son oynama noktalarına değinmiştim; oradaki notlar burada da birebir işinize yarar.
Açık konuşayım, pipeline tarafı bazen migrasyondan daha çok vakit yiyor.
5. Lock Dosyası Aktif Edin
Ne yalan söyleyeyim, Tutarlı bir build istiyorsanız RestorePackagesWithLockFile property’sını açın ve packages.lock.json‘un oluşmasına izin verin; böylece sürümler sabitleniyor ve bugün çalışan şey yarın da aynı şekilde ayağa kalkabiliyor. Production’a giden kod (söylemesi ayıp) için bunu kapalı bırakmak bana pek mantıklı gelmiyor, (yanlış duymadınız). Küçük bir sürüm kayması bile sonra boş yere saat yediriyor.
Tam da öyle.
Karşılaşabileceğiniz Sorunlar ve Çözümleri
Geçen hafta bir test projesinde kurcalarken şu hatayla karşılaştım: NU1605: Detected package downgrade. Kısa cevap şu; eski projeden kalma elle yazılmış transitive paket girdileri, yeni resolver ile çakışıyordu. Garip ama oluyor. Çözüm de öyle çok süslü değildi: packages.config‘den gelen fazla satırları temizledim, NuGet de işi kendi hâline bırakınca sorun dağıldı.
Aslında, Bir başka can sıkıcı nokta da şu: bazı eski NuGet paketleri sadece packages.config için yazılmış install.ps1 scriptleri taşıyor. Bu scriptler PackageReference modelinde çalışmıyor, yanı kağıt üstünde paket var ama o küçük PowerShell numarası ortada yok gıbı davranıyor. Eğer kullandığınız paket build sırasında bu tür tetikleyicilere yaslanıyorsa, paketin modern bir .targets tabanlı sürüm alması gerekiyor; popüler paketlerde genelde sorun çıkmıyor,. Niş kütüphanelerde insanın eli havada kalabiliyor.
Ha, bir de şu yol meselesi var — bazı eski tooling paketleri $(SolutionDir)\packages yolunu direkt içine gömmüş oluyor. Global cache’e geçince bu adres hâliyle patlıyor (inanın bana). Paketin .targets dosyasını açıp $(NuGetPackageRoot)$(PackageId)\$(PackageVersion) stiline çevirmek gerekebiliyor; biraz uğraştırıyor ama işin aslı bu. .NET 10’da NuGet Package Pruning: Sahadan Notlar yazısında benzer bir refactor sürecini anlatmıştım, oradaki yaklaşımı buraya da rahatça uyarlayabilirsiniz.
Bence Bu Doğru Bir Adım, Ama Eksik
Açık konuşayım: bu özellik kağıt üstünde fena değil, ama ben hâlâ “bekle ve gör” tarafındayım. Neden mi? Birkaç sebep var, hem de öyle tek satırlık sebepler değil; işin içine biraz tarih giriyor, biraz ortam giriyor, biraz da “neden bunu daha önce yapmadınız?” hissi giriyor.
Eksik 1 — Geç kalınmış bir hamle..NET tarafı 2017’de bu işi çözdü. C++ tarafı işe 2026’da preview’a aldı. Bakınca insanın aklına şu geliyor: Microsoft’un native developer’lara verdiği önem ile managed developer’lara verdiği önem arasında hâlâ gözle görülür bir fark var, yanı mesele sadece teknik değil, biraz da öncelik meselesi gıbı duruyor.
Eksik 2 — vcpkg ile entegrasyon yok. Açıkçası en temiz senaryo şuydu: PackageReference ile vcpkg manifest’i (vcpkg.json) aynı projede daha sıkı çalışsaydı, işler baya toparlanırdı. Şu an iki ayrı dünya gıbı bir düşüneyim… duruyor; biri MSBuild tarafında kendi yolunda gidiyor, diğeri paket yönetiminde başka bir kulvarda koşturuyor. Belki ileride birleştirirler, bilemiyorum, ama bugün için kopukluk hissi var.
Eh, Eksik 3 — CMake desteği yok. PackageReference MSBuild’e özel kalıyor. CMake tabanlı C++ projelerinde işe pek işinize yaramıyor, bu kadar net. Modern C++ dünyai zaten yavaş yavaş CMake’e kayarken böyle bir sınırlama can sıkıyor; Microsoft’un buradaki cevabı muhtemelen “CMake için vcpkg kullanın” olacak, ama açık konuşayım, bu bana tam çözüm gıbı gelmiyor.
Yanı özet şu: güzel başlangıç, ama tam çözüm değil. Ben yine de Insiders’da deneyeceğim; (söylemesi ayıp) hatta Logosoft’taki bazı iç araçlarımızı buna taşıma fikrim var. Sahada ne çıkacak, önü da zaman gösterir. Visual Studio 2026’da Segment Heap: C++ İçin Yeni Dönem yazımda da benzer bir “C++ tarafında uyanış var” temasına değinmiştim — bence Microsoft son 1-2 yıldır native ekosisteme ciddi şekilde yükleniyor, bu da o hikâyenin bir parçası.
Sıkça Sorulan Sorular
PackageReference, vcpkg’nın yerini mi alıyor?
Hayır, almıyor. Microsoft’un resmî tavsiyesi de zaten bu yönde değil. Yanı Boost, OpenSSL, fmt gıbı C++ kütüphaneleri için vcpkg kullanmaya devam edin (bu konuda ikircikliyim). PackageReference aslında daha çok binary SDK paketleri, MSBuild tooling ve C++/.NET interop senaryoları için anlamlı — bence ikisi birbirini gayet güzel tamamlıyor.
Mevcut packages.config projemi otomatik dönüştürebilir mıyım?
Evet, yapabilirsiniz. İşte, visual Studio Insiders 18.7’de Solution Explorer’da sağ tıklayınca “Migrate packages.config to PackageReference” seçeneği çıkıyor. Ama açıkçası büyük projelerde doğrudan denemeyin — önce bir test branch’i açın, hani transitive bağımlılıklarda manuel temizlik gerekebiliyor, tecrübeme göre bu kısım biraz vakit alabiliyor.
Bu özelliği production projelerimde kullanabilir mıyım?
Henüz hayır. Şu an Insiders kanalında deneysel olarak yayınlanıyor. Stable Visual Studio sürümüne gelmeden production kodda kullanmak açıkçası riskli. Test ve değerlendirme projelerinde deneyin yeterli — 2026’nın ortalarına doğru stable çıkması bekleniyor.
CMake tabanlı C++ projelerinde PackageReference çalışıyor mu?
Şunu söyleyeyim, Hayır, çalışmıyor. PackageReference MSBuild’e özgü bir özellik, yanı sadece.vcxproj projelerinde işe yarıyor. CMake projelerinde NuGet bağımlılıkları için farklı bir mekanizma gerekiyor — pratikte bence CMake kullanıcıları için vcpkg ya da Conan çok daha uygun zaten.
Global package cache nerede tutuluyor, disk yönetimi nasıl yapılıyor?
Varsayılan olarak %userprofile%\.nuget\packages altında tutuluyor. NUGET_PACKAGES ortam değişkeniyle istediğiniz yere taşıyabilirsiniz. Zamanla ciddi şişebiliyor bu klasör — periyodik olarak dotnet nuget locals all --clear komutuyla temizlemek mantıklı, özellikle CI sunucularında bence bu bir zorunluluk hâline geliyor.
Kaynaklar ve İleri Okuma
Dürüst olmak gerekirse, Microsoft C++ Team Blog — NuGet PackageReference for C++ Projects (orijinal duyuru)
PackageReference Resmî Dokümantasyonu — Microsoft Learn
packages.config’den PackageReference’a Geçiş Rehberi
vcpkg GitHub Reposu — C++ Kütüphane Yönetimi
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.
