VSTest Newtonsoft.Json Bağımlılığını Atıyor: Ne Değişiyor?
Bir haber düştü, açık konuşayım pek çok kişinin gözüne çarpmadı ama.NET tarafında baya beklenen bir temizlik bu. Microsoft, VSTest’i — yani dotnet test ve Visual Studio Test Explorer’ın arkasında çalışan platformu — Newtonsoft.Json bağımlılığından çıkarıyor..NET 11 Preview 4 ve Visual Studio 18.8 ile geliyor.
Açıkçası, Kulağa küçük bir teknik detay gibi geliyor, değil mi? Ama değil (buna dikkat edin). Bunun arkasında yıllardır biriken bir hikâye var ve sahada can sıkan noktayı nihayet toparlıyor (evet, doğru duydunuz)
Hadi baştan alalım: Neden bu değişiklik lazım oldu?
VSTest, Newtonsoft.Json’ı uzun süredir.NET SDK’nın ve Visual Studio’nun içinde taşıyordu (ciddiyim). Başta mantıklıydı, çünkü System.Text.Json ortada yokken Newtonsoft.Json zaten herkesin alıştığı şeydi. İlginç, değil mi? Hatta bugün bile NuGet dünyasında en çok indirilen paketlerden biri.
Sorun şu: Newtonsoft.Json’ın 13.0.0 altındaki neredeyse tüm sürümleri NuGet.org’da artık “vulnerable” diye işaretleniyor. Yani güvenlik araçları (Snyk, Dependabot, GitHub Advanced Security) bu sürümleri görünce hemen alarm veriyor, sonra siz de “ama ben kullanmıyorum ki” diye kalıyorsunuz.
Geçen ay bir bankacılık müşterimde tam buna takıldık (inanın bana). Pipeline’da Snyk taraması açıktı ve VSTest’in transitive olarak çektiği eski bir Newtonsoft.Json sürümü yüzünden build kıpkırmızı oldu. Halbuki proje kodunda bizim Newtonsoft.Json kullandığımız tek satır yoktu! Ekip günlerce bu transitive bağımlılığı izlemeye uğraştı, sonunda NoWarn ile susturduk ama açık konuşayım bu çözüm değil; biraz halının altına süpürmek gibi.
Test platformunuzun, sizin hiç dokunmadığınız bir kütüphane yüzünden CVE listesinde görünmesi — bak şimdi, modern DevSecOps düzeninde pek savunulur bir durum değil. Microsoft’un attığı bu adım da yıllardır ötelenen borcun kapanması gibi duruyor.
Yerine ne geliyor? İki ayrı yol seçilmiş
İşin ilginç kısmı şu: Tek bir alternatif yerine iki farklı çözüm seçmişler. Sebep de gayet net.NET ile.NET Framework’ün ihtiyacı aynı değil.
Hmm, bunu nasıl anlatsamdı…
- .NET tarafında: System.Text.Json kullanılacak. Zaten BCL’in parçası, ekstra paket derdi yok.
- .NET Framework tarafında: JSONite adında küçük, gömülü bir JSON kütüphanesi gelecek. Bu da dış bağımlılık eklemiyor.
JSONite ismini ben de ilk kez gördüm, hani şaşırdım biraz. Microsoft’un içerde tuttuğu minik bir parser gibi duruyor. Mantık basit:.NET Framework’te System.Text.Json’ı paket olarak getirmeye kalksanız yeni bağımlılık zinciri çıkıyor ortaya (inanın bana). Onun yerine kendi yazdıkları küçük parser’la işi kapatmışlar. Fena değil.
Wire format aynı kalıyor — burası kritik
Durun bir saniye, çünkü önemli nokta burada. VSTest’in test host’larıyla konuştuğu protokol — yani wire format — değişmiyor. Mesajlar Newtonsoft.Json, System.Text.Json ya da JSONite ile serileştirilmiş olsa da sonuç aynı byte dizisi oluyor.
Bir şey dikkatimi çekti: Bu ne demek? Eski testhost’lar yeni platformla, yeni testhost’lar eski platformla konuşmaya devam edecek. Geriye uyumluluk korunuyor. CI/CD pipeline’larında karışık sürüm kullanan ekipler için (ki enterprise tarafında bu baya yaygın) ciddi rahatlık sağlayan bir karar bu.
Kim etkilenmez? Çoğunluk büyük ihtimalle dahil
Açık konuşayım: Çoğu test projesi bu değişiklikten hiç etkilenmeyecek (evet, doğru duydunuz). Üç gruptan biriyseniz oturduğunuz yerden devam edin: Daha fazla bilgi için
Peki kim etkilenir, nasıl toparlanır?
Üç ayrı senaryoda kırılma olabiliyor. Tek tek bakalım; hata mesajları birbirine benzese de çözüm aynı değil gibi görünüyor ama aslında epey ayrışıyor.
1. Senaryo: Build hatası — eksik referans
Test projeniz JObject, JsonConvert gibi Newtonsoft.Json tiplerini kullanıyor ama paketi kendi .csproj‘unuza eklememişsiniz. Şimdiye kadar derlenmesinin tek sebebi VSTest’in NewtonSoft.Json’ı arkadan sızdırmasıydı. Güncellemeden sonra build patlayacak.
Çözüm tek satır:
<PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
Bak şimdi, Bunu büyük kod tabanlarında çok gördüm ben. En çok da de de eski projelerde biri zamanında JObject kullanmış oluyor, sonra “build geçiyor ya tamam” deyip bırakıyor işi öylece gidiyorlar. Halbuki altyapıda ödünç alınmış bir bağımlılık varmış meğer.
2. Senaryo: Runtime’da FileNotFoundException
Bu daha sinsice geliyor. Şöyle bir tanımınız varsa:
<PackageReference Include="Newtonsoft.Json" Version="13.0.3">
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>
Daha doğrusu derleme zamanında referans var ama runtime asset bilerek hariç tutulmuşsa… Bazı ekipler bunu “Visual Studio veya VSTest (belki yanılıyorum ama) zaten taşıyor, tekrar kopyalamaya gerek yok” diye yapıyordu (şaşırtıcı ama gerçek). Güncellemeden sonra şu hatayı görmeniz muhtemel:
System.IO.FileNotFoundException: Could not load file or assembly
'Newtonsoft.Json, Version=13.0.0.0, Culture=neutral,
PublicKeyToken=30ad4fe6b2a6aeed'.
Bi saniye — Çözüm basit: ExcludeAssets satırını silin ya da en azından runtime‘ı hariç tutmayın.
3. Senaryo: Test adapter veya data collector yüklenemiyor
Burası en tatsız olan grup olabilir. Özel yazılmış test adapter’larınız ya da data collector’larınız varsa ve bunlar Newtonsoft.Json kullanıyor ama bağımlılığı açıkça beyan etmiyorsa yükleme sırasında tökezleyecekler.
2022’de bir telekom projesinde özel bir performance data collector yazmıştık biz de aynı şekilde metrik topluyordu ve JSON serileştirme için Newtonsoft.Json kullanıyordu. Ama .csproj‘da referansı yoktu, çünkü VSTest’ten “miras” alıyordu diyelim artık ona da… İşte böyle bir kod güncellemeden sonra şu tarz bir mesajla duvara toslayacak:
Data collector 'SampleDataCollector' threw an exception during
type loading, construction, or initialization:
System.IO.FileNotFoundException: Could not load file or assembly
'Newtonsoft.Json, Version=13.0.0.0...'
Şunu söyleyeyim, Çözüm yine aynı: Adapter veya collector projenizde Newtonsoft.Json’ı açık PackageReference olarak tanımlayın.
Kısa karar tablosu
Lafı dolandırmadan özeti tabloya dökelim; kim ne yapacak belli olsun:
| Durum | Etkilenir mi? | Aksiyon |
|---|---|---|
| Newtonsoft.Json hiç kullanmıyorum | Hayır | Yok |
| PackageReference olarak ekledim | Hayır | Yok |
| Kullanıyorum ama referansım yok | Evet (build hatası) | PackageReference ekle |
| ExcludeAssets=runtime kullanıyorum | Evet (runtime hatası) | ExcludeAssets’i kaldır |
| Cusom adapter/collector geliştiriyorum | Büyük ihtimalle evet |
Sıkça Sorulan Sorular
VSTest’in Newtonsoft.Json bağımlılığını kaldırması performansı etkiler mi?
Microsoft’a göre serileştirme performansı aynı kalıyor, hatta daha iyi bile olabilir. Hani System.Text.Json zaten Newtonsoft.Json’dan genelde daha hızlı çalışıyor. JSONite de minimal bir parser olduğu için onun yükü de düşük. Açıkçası pratikte bir fark hissetmenizi beklemiyorum.
Eski.NET Framework projelerimde JSONite otomatik mi gelecek?
Vallahi, Evet. JSONite, VSTest’in içine gömülü geliyor, yani manuel olarak paket eklemenize gerek yok. Aslında tek dikkat etmeniz gereken şey şu: kendi kodunuzda Newtonsoft.Json kullanıyorsanız önü açıkça referans etmeniz gerekiyor.
Newtonsoft.Json’ı tamamen projeden kaldırmalı mıyım?
Hayır, gerek yok. Kodunuz Newtonsoft.Json kullanıyorsa kullanmaya devam edin, mesela sadece sürümü 13.0.3 veya üstüne çekmeniz yeterli. System.Text.Json’a geçiş bence ayrı bir proje olarak ele alınması gereken bir konu, VSTest’in bu değişikliğiyle doğrudan alakası yok.
Bu değişiklik.NET 10 LTS’i etkiler mi?
Kendi deneyimimden konuşuyorum, Hayır. Değişiklik.NET 11 Preview 4 ve VS 18.8 bir düşüneyim… ile geliyor..NET 10 LTS kullanıcıları mevcut davranışlarını korumaya devam ediyor. Yani tecrübeme göre LTS’de kalmak isteyen kurumsal müşteriler bu konuda hiç acele etmek zorunda değil.
CI/CD pipeline’larımda farklı VS sürümleri var, sorun olur mu?
Olmaz. VSTest wire format’ı korunduğu için eski testhost’lar yeni platformla, yeni testhost’lar eski platformla uyumlu çalışmaya devam ediyor. Kademeli geçiş yapabilirsiniz, güvenli.
Kaynaklar ve İleri Okuma
VSTest is Removing its Newtonsoft.Json Dependency —.NET Blog (McKenna Barlow)
System.Text.Json Resmî Dokümantasyonu
İşte, bi saniye — .NET Test Etme Rehberi — Microsoft Learn
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