6

Mam przenośny projekt biblioteki klas docelowej .NET 4.6 i Universal Windows Platform. Biblioteka ta klasa zawiera tylko jedną klasę z poniższej linii kodu w jego konstruktora:Jak mogę odwoływać się do przenośnej biblioteki UWP + NET46 z aplikacji konsoli .NET 4.6?

Directory.CreateDirectory(Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString())); 

Teraz tworzę nowy projekt aplikacji .NET 4.6 konsoli w tym samym roztworze i dodaj odwołanie projektu do przenośnego klasy biblioteki. Wywołanie metody zawierającej powyższy wiersz kodu powoduje następujący wyjątek w czasie wykonywania:

Could not load file or assembly 'System.IO.FileSystem, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. 

Co ja tu robię źle? Nie ma błędów ani ostrzeżeń podczas kompilacji.

Co próbowałem: dodać brakujący pakiet Nuget ręcznie

Wydaje się, że System.IO.FileSystem jest biblioteką dostarczane poprzez Nuget, jako część Microsoft.NETCore mega-pakietu (?). Okej, być może muszę dodać ten pakiet do dowolnego projektu, który używa mojej przenośnej biblioteki klas. Próbuję to zrobić.

Could not install package 'Microsoft.NETCore.Platforms 1.0.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.6', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author. 

Brak szczęścia w tym podejściu.

Czego próbowałem: Utwórz plik project.json

Choć nie ma jednoznacznych informacji w internecie, czytałem kilka ciekawostki o nowym project.json oparciu uprząż Nuget lub systemu budowania. Aby eksperymentować, utworzyłem następujący plik project.json w moim projekcie aplikacji konsolowej:

{ 
    "dependencies": { 
    }, 
    "frameworks": { 
    "net46": { } 
    }, 
    "runtimes": { 
    "win-anycpu": { } 
    } 
} 

Działa! Błąd runtime zniknie! Wkrótce jednak odkryłem, że nie jest to właściwe rozwiązanie, a nie kompletne rozwiązanie. Zacząłem pisać jakiś kod do odczytu wartości sekcji konfiguracji, które zaangażowane wykorzystanie interfejsu IConfigurationSectionHandler i uzyskałem następujący błąd kompilacji:

error CS0246: The type or namespace name 'IConfigurationSectionHandler' could not be found (are you missing a using directive or an assembly reference?) 

Interfejs ten jest częścią zespołu System. Widzę odwołanie do tego zestawu, ale ma żółty wykrzyknik ikonę, a pojawi się ostrzeżenie w oknie ostrzeżeń:

The referenced component 'System' could not be found. 

To gdzie ja zabrakło pomysłów. Czy brakuje mi czegoś całkowicie oczywistego?

+0

Cóż, nie jest trudne do repro. Kierowanie do dnx jest teraz dość odważne, jest to jakość beta. Mógłbyś utykać, kopiując pliki System.IO.FileSystem.dll i System.IO.FileSystem.Primitives.dll z katalogu runtime dnx, ale jest to znacznie mniej niż idealne rozwiązanie. Po prostu [zgłoś błąd] (https://github.com/aspnet/dnx/issues), aby mogli go naprawić. –

+0

@HansPassant DNX nie jest wymagany do odtworzenia, więc nie ma związku DNX. Wszystko jest takie samo, nawet jeśli wybieram system docelowy DNX. Zmieniłem moje pytanie, aby usunąć ten potencjalny punkt dezorientacji. – Sander

Odpowiedz

1

Znalazłem rozwiązanie. Pierwszą próbą było zainstalowanie pakietu Microsoft.NETCore w aplikacji konsoli, co spowodowało błąd pokazany w moim oryginalnym wpisie.

Jednak jeśli zainstaluję tylko pakiety o wąskim zakresie, np. System.IO.FileSystem, wtedy osiągam sukces, a aplikacja działa poprawnie. Najwyraźniej jest coś wyjątkowego w "pakiecie głównym" Microsoft.NETCore, który uniemożliwia prawidłowe instalowanie w zależnych projektach.

+0

Nie wiem, dlaczego poprzednio został odrzucony. Pracował jak urok dla mnie. – RubberDuck

+0

Mam podobny problem, gdy nie mogę odwołać się do projektu biblioteki Win 8.1 z aplikacji .NET 4.6 - czy ta odpowiedź może być tutaj odpowiednia? –

Powiązane problemy