2016-07-13 13 views
17

Ich habe ein sehr einfaches Programm erstellt, das die in einem Google Cloud-Projekt verfügbaren Themen auflisten soll. Der Code ist trivial:Warum funktioniert Google.Pubsub.V1 beta01 nicht mit dotnet cli-Projekten?

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); 
     } 
    }  
} 

Als ich dies von einem "normalen" msbuild Projekt laufen Targeting .NET 4.5, es funktioniert gut. Wenn ich versuche, dotnet cli (1.0.0-preview2-003121) mit folgenden project.json-Datei zu verwenden:

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

... sehe ich eine Ausnahme:

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

Ich bin nicht zu versuchen, Target .NET Core, sollte dies nicht unterstützt werden?

+2

(Kurz gesagt, mein Hauptgrund für diese Frage war die Erstellung des Tags "google-cloud-dotnet" als zentrales Tag für unsere Kunden der Google Cloud .NET-Clientbibliothek. Aber ich erwarte, dass dies der Fall ist etwas, das natürlich ganz natürlich kommen könnte ...) –

Antwort

14

Dies ist derzeit eine Einschränkung in gRPC 0.15, die Google.Pubsub.V1 als RPC-Transport verwendet. Unter Msbuild kopiert die build/net45/Grpc.Core.targets-Datei im Grpc.Core-Paket alle nativen Binärdateien an ihren Platz. Unter DNX wurden die Pakete nicht kopiert, und gRPC versucht, die Datei am richtigen Ort mit dem lokalen Paket-Repository zu suchen. Unter dotnet cli müssen wir das Root-Verzeichnis "runtimes" im Paket verwenden, um die Bibliotheken zu hosten.

Wir haben implemented a fix for this in gRPC, aber wir haben es nicht geschafft, es in die Beta-01-Version zu bekommen. Wir hoffen, es für Beta-02 zu beheben.

Es ist möglich nur um dies zu umgehen, manuell kopieren Sie die Datei:

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 

... aber das ist natürlich ziemlich knifflig. Ich würde vorschlagen, nur msbuild zu verwenden, bis das zugrunde liegende Problem behoben wurde.

+0

Ich denke für 'dotnet', wenn die Paketstruktur ein wenig geändert wurde, dann würden die korrekten Bibliotheken während dotnet publish kopiert und LoadLibrary/DllImport sollte sie bei der Suche abholen Auftrag. Ich schrieb einen Blog-Post für RC1 https://blog.3d-logic.com/2015/11/10/using-native-libraries-in-asp-net-5/ und beim Laden nativer Abhängigkeiten funktioniert jetzt anders, wenn das Paket Struktur in diesem Beitrag beschrieben wird verwendet Dinge sollten funktionieren. – Pawel

+1

@Pawel: Ich habe es geschafft, es lokal arbeiten ... Ich muss nur aufräumen. –