2016-07-13 40 views
17

Stworzyłem bardzo prosty program, który powinien zawierać listę tematów dostępnych w projekcie Google Cloud. Kod jest banalny:Dlaczego Google.Pubsub.V1 beta01 nie działa z projektami dotnet cli?

using System; 
using Google.Pubsub.V1; 

public class Test 
{ 
    static void Main() 
    { 
     var projectId = "(fill in project ID here...)"; 
     var projectName = PublisherClient.FormatProjectName(projectId); 
     var client = PublisherClient.Create(); 
     foreach (var topic in client.ListTopics(projectName)) 
     { 
      Console.WriteLine(topic.Name); 
     } 
    }  
} 

Kiedy uruchamiam to z "regularnego" projektu msbuild kierującego na .NET 4.5, to działa dobrze. Kiedy próbuję użyć CLI dotnet (1.0.0-preview2-003121) z następującym project.json pliku:

{ 
    "buildOptions": { 
    "emitEntryPoint": true 
    }, 
    "dependencies": { 
    "Google.Pubsub.V1": "1.0.0-beta01" 
    }, 
    "frameworks": { 
    "net45": { } 
    } 
} 

... Widzę wyjątek:

Unhandled Exception: System.IO.FileNotFoundException: Error loading native library. 
Not found in any of the possible locations c:\[...]\Pubsub.Demo\bin\Debug\net45\win7-x64\nativelibs\windows_x64\grpc_csharp_ext.dll 
    at Grpc.Core.Internal.UnmanagedLibrary.FirstValidLibraryPath(String[] libraryPathAlternatives) 
    at Grpc.Core.Internal.UnmanagedLibrary..ctor(String[] libraryPathAlternatives) 
    at ... 

ja nie próbuję docelowy .NET Core, więc czy nie powinno to być obsługiwane?

+2

(W skrócie, głównym powodem zadawania tego pytania było utworzenie tagu "google-cloud-dotnet", jako głównego tagu dla klientów korzystających z naszej biblioteki klientów Google Cloud .NET, ale spodziewam się, że coś, co i tak może pojawić się naturalnie ...) –

Odpowiedz

14

Jest to obecnie ograniczenie w gRPC 0.15, które Google.Pubsub.V1 wykorzystuje jako transport RPC. W msbuild plik build/net45/Grpc.Core.targets w pakiecie Grpc.Core kopiuje wszystkie natywne pliki binarne na miejsce. Pod DNX pakiety nie zostały skopiowane, a gRPC próbuje wyszukać plik we właściwym miejscu w lokalnym repozytorium pakietów. W środowisku dotnet cli musimy używać katalogu głównego "runtimes" w pakiecie do hostowania bibliotek.

Mamy implemented a fix for this in gRPC, ale nie udało nam się wprowadzić go do wersji beta-01. Mamy nadzieję, że naprawimy go dla wersji beta-02.

To możliwe obejść to po prostu ręcznie kopiując plik:

mkdir bin\Debug\net45\win7-x64\nativelibs\windows_x64 
copy \users\jon\.dnx\packages\Grpc.Core\0.15.0\build\native\bin\windows_x64\grpc_csharp_ext.dll bin\Debug\net45\win7-x64\nativelibs\windows_x64 

... ale to oczywiście dość skomplikowanego. Sugerowałbym tylko użycie msbuild, dopóki nie zostanie naprawiony podstawowy problem.

+0

Chyba dla 'dotnet', jeśli struktura pakietu została trochę zmieniona, poprawne biblioteki byłyby kopiowane podczas publikowania w kropce i LoadLibrary/DllImport powinien je pobrać zgodnie z wyszukiwaniem zamówienie. Napisałem post na blogu RC1 https://blog.3d-logic.com/2015/11/10/using-native-libraries-in-asp-net-5/ i podczas ładowania natywnych zależności teraz działa inaczej, jeśli pakiet struktura opisana w tym poście jest używana rzeczy powinny działać. – Pawel

+1

@Pawel: Udało mi się uruchomić go na miejscu ... Po prostu muszę to uporządkować. –