2017-06-30 57 views
11

dosya veya derleme "System.ValueTuple, Sürüm = 0.0.0.0" veya bağımlılıklarından biri yüklenemedi ve test sırasında bir istisna yakalamak var:Ben .NET Standard 2.0 projemi güncellemeye çalıştık

System.IO.FileLoadException: 'Dosya veya derleme yüklenemedi' System.ValueTuple, Sürüm = 0.0.0.0, Culture = neutral, PublicKeyToken = cc7b13ffcd2ddd51 "veya bağımlılıklarından biri. Bulunan montaj bildiriminin tanımı, montaj referansına uymuyor.

Bu asambly package.config bulunmaktadır ve paketin klasörü vardır. System.ValueTuple paketinin bazı sürümlerini denedim, sonuç bir.

Neden bağımlılık sürümü «0.0.0.0»?

Sorunla ilgili bir fikri olan var mı?

VS 2017 Önizleme, BirimTestApp, .NET Framework 4.7.

Birim test uygulamasında EF modeli oluşturuyorum (Microsoft.EntityFrameworkCore, Microsoft.EntityFrameworkCore.SqlServer 2.0.0-preview2-final, .NET Standard uygulamasında olması gerekir). Birim test yöntemi - EF db modelini kullanarak bazı satırları tabloya ekleyin ve bu istisnayı attıktan sonra 'savechanges' (çağırma) çağırın.

EntityFrameworkCore 1.1.2'yi (EF modeli ile dll - Standart 1.4, birim testi Framework 4.6.2) kullandığımda - bu test iyi çalıştı.

+0

Netstandard2.0 projesi + 4.6.1 projesi kullanılarak VS15.3.2 ile benzer bir sorunum var. Çalışma zamanında bir ValueTuple işlevi kullanmak istisnayı atar. Hatta 4.6.1'den 4.7'ye geçiş yapmadım. netstandard2.0, yalnızca Microsoft.NETCore.Platforms> = 1.1.0'a bağlı olan NETStandard.Library-2.0'a bağlıdır. Microsoft.NETCore.Platforms herhangi bir bağımlılık göstermez, ama bu paketin bir şekilde bozuk olduğunu düşünüyorum. – Henk

+0

Ayrıca buna da eğilimliyim. NETStandard 2.0 hala ham olduğunu düşünüyorum. NETStandard 2.0'ı kullanmak için biraz beklemeniz gerekiyor. – DmitrySpb

cevap

0

Benzer bir şeyle güreş oldum - dll, inşa edildikten sonra webapi2 sln'in bin klasöründe. Her zaman dll'lerin bir listesini sildim ve her seferinde yeniledim - hata farklı bir dll'ye geçer. Son olarak, 8 dll sildikten sonra site düzgün bir şekilde patlar. Bir sonraki adım, bu dll'leri bin klasöründen silmek için bir post-build komut dosyası yazmaktır. Bir kesmek biraz ama zarif bir çözüm daha sonra gelebilir.

+0

Uygulama hala başvurulan DLL'ler olmadan çalışır? Bunun nasıl çalıştığına dair biraz kafam karıştı. Güvende olmak için bunu yapar ve sonra başvurulan DLL'lerden birinin, her şeyin yolunda olduğunu doğrulamak için kullanıldığını bildiğiniz bir sayfaya gidin. – Cityonhill93

+0

Net olmak gerekirse - bin çıkış klasörlerinden çıkardığım dll'ler GAC'deydi. GAC'den doğru şekilde yüklendiler, ancak bin klasöründe bulunduklarında yüklenemedi. Yani dll yükleyici, bin klasöründen yükleme başarısız olsa bile bin klasörüne bakmaya başlar. Tümü garip görünüyor - ya da tersine, .NET diyarında normal bir gün :-) :-) – badcop666

6

Bu sorunu, .NET Framework 4.7 projemde Automatic Binding Redirection etkinleştirerek çözdüm (.NET Standard 2.0 kitaplığı ile ilgilidir).

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
    <dependentAssembly> 
    <assemblyIdentity name="System.ValueTuple" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" /> 
    <bindingRedirect oldVersion="0.0.0.0-4.0.2.0" newVersion="4.0.2.0" /> 
    </dependentAssembly> 
</assemblyBinding> 
: inşa sırasında sonra

<PropertyGroup> 
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> 
    <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType> 
</PropertyGroup> 

Visual Studio buna benzer bir proje en app.config için gerekli montaj yönlendirmeler, oluşturur: Bağlama yeniden yönlendirme elle projenin .csproj dosyasını düzenleme ve Addind izleyerek Project elemanın çocuk pasajı etkinleştirilebilir Doğru montajın yüklenmesine izin veren

.

+0

FYI: "AutoGenerateBindingRedirect" inizde, kapatma etiketindeki> eksik. – Cityonhill93

+1

@ Cityonhill93: Teşekkürler, düzeltildi. –

+0

Teşekkürler! Aynı düzeltme, .NET 4.6.2 projesi için de benim için çalıştı. –

İlgili konular