2017-06-30 43 views
11

Próbowałem zaktualizować projekt standardu .NET 2.0 i podczas testów mam złapać wyjątek:Nie można załadować pliku lub zestawu „System.ValueTuple, Version = 0.0.0.0” lub jeden z jego zależnościami

System.IO.FileLoadException: "Nie można załadować pliku lub zestawu" System.ValueTuple, wersja = 0.0.0.0, Culture = neutral, PublicKeyToken = cc7b13ffcd2ddd51 "lub jedna z jego zależności. Definicja znalezionego manifestu zespołu nie pasuje do odwołania do złożenia.

To assambly istnieje w package.config i istnieje w folderze pakietu. Próbowałem niektóre wersje pakietu System.ValueTuple, wynik jest jeden.

Dlaczego wersja zależności "0.0.0.0"?

Czy ktoś ma pomysł na temat problemu?

VS 2017 Preview, UnitTestApp, .NET Framework 4.7.

W aplikacji testowej urządzenia tworzę model EF (Microsoft.EntityFrameworkCore, Microsoft.EntityFrameworkCore.SqlServer 2.0.0-preview2-final, potrzebny w aplikacji .NET Standard). Metoda testu jednostki - wstaw do tabeli niektóre wiersze za pomocą modelu EF db i wywołaj "zmiany składowania", po czym wyrzuć ten wyjątek.

Kiedy użyłem EntityFrameworkCore 1.1.2 (dll z modelem EF - Standard 1.4, test urządzenia Framework 4.6.2) - ten test sprawdził się.

+0

Mam podobny problem z VS15.3.2 przy użyciu projektu netstandard2.0 + projektu 4.6.1. Korzystanie z funkcji ValueTuple w środowisku wykonawczym zgłasza wyjątek. Zmieniłem nawet z 4.6.1 na 4.7, bez rezultatu. netstandard2.0 zależy od biblioteki NETStandard.Library-2.0, która z kolei zależy tylko od Microsoft.NETCore.Platforms> = 1.1.0. Microsoft.NETCore.Platforms nie wykazuje żadnych zależności, ale myślę, że ten pakiet jest w jakiś sposób uszkodzony. – Henk

+0

Też mam tendencję do tego. Myślę, że NETStandard 2.0 jest wciąż surowy. Musisz trochę poczekać na użycie NETStandard 2.0. – DmitrySpb

Odpowiedz

0

Zmagałem się z czymś podobnym - pliki dll znajdują się w folderze bin webapi2 sln po kompilacji. Usunąłem listę bibliotek dll i odświeżam za każdym razem - błąd przechodzi do innej biblioteki dll. W końcu, po usunięciu 8 bibliotek DLL, strona uruchamia się poprawnie. Następnym krokiem jest napisanie skryptu post-build, aby usunąć te biblioteki DLL z folderu bin. Trochę hackowania, ale eleganckie rozwiązanie może nadejść później.

+0

Aplikacja nadal działa bez przywoływanych plików DLL? Jestem nieco zdezorientowany, jak to działa. Aby być bezpiecznym, zrobiłbym to, a następnie przejdź do strony, na której wiesz, że jedna z odwołanych bibliotek DLL jest używana do sprawdzenia, czy wszystko jest w porządku. – Cityonhill93

+0

Aby było jasne - biblioteka dll, którą usunąłem z folderów wyjściowych bin, znajdowała się w GAC. Zostały poprawnie załadowane z GAC, ale nie udało się załadować, gdy zostaną znalezione w folderze bin. Tak więc program ładujący biblioteki zacznie szukać w folderze bin, nawet jeśli ładowanie z folderu bin zakończy się niepowodzeniem. Wszystko wydaje się dziwne - lub, odwrotnie, normalny dzień w .NET land :-) – badcop666

6

Rozwiązałem ten problem, włączając Automatic Binding Redirection w moim projekcie .NET Framework 4.7 (który odwołuje się do biblioteki .NET Standard 2.0). Wiązanie przekierowania można włączyć poprzez ręczną edycję projektu .csproj plik i addind następujący fragment dzieckiem Project element:

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

Visual Studio następnie podczas kompilacji generuje neccessary przekierowań montażowe do projektu app.config, podobne do tego:

<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> 

umożliwiając załadowanie prawidłowego zestawu.

+0

FYI: W twoim "AutoGenerateBindingRedirects" brakuje> w zamykającym tagu. – Cityonhill93

+1

@ Cityonhill93: Dziękuję, poprawiono. –

+0

Dziękujemy! Ta sama poprawka działała dla mnie również w przypadku projektu .NET 4.6.2. –

Powiązane problemy