2016-07-13 44 views
17

Ho creato un programma molto semplice che dovrebbe elencare gli argomenti disponibili in un progetto Google Cloud. Il codice è banale:Perché Google.Pubsub.V1 beta01 non funziona con i progetti cli di dotnet?

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

Quando eseguo questo da un progetto di "regolare" msbuild mira .NET 4.5, funziona benissimo. Quando provo ad usare dotnet cli (1.0.0-preview2-003121) con la project.json seguente file:

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

... Vedo un'eccezione:

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

Io non sto cercando di obiettivo. NET Core, quindi non dovrebbe essere supportato?

+2

(Come una breve nota, il motivo principale per cui ho fatto questa domanda era di creare il tag 'google-cloud-dotnet', come tag centrale per i nostri clienti delle librerie client di Google Cloud .NET. qualcosa che potrebbe anche apparire naturale ...) –

risposta

14

Attualmente si tratta di una limitazione in gRPC 0.15, che Google.Pubsub.V1 utilizza come trasporto RPC. In msbuild, il file build/net45/Grpc.Core.targets nel pacchetto Grpc.Core copia tutti i binari nativi in ​​posizione. Sotto DNX, i pacchetti non sono stati copiati e gRPC prova a cercare il file nel posto giusto con il repository di pacchetti locale. Sotto dotnet cli, dobbiamo usare la directory root "runtime" nel pacchetto per ospitare le librerie.

Abbiamo implemented a fix for this in gRPC, ma non siamo riusciti a inserirlo nella versione beta-01. Speriamo di risolverlo per beta-02.

E 'possibile Per ovviare a questo, semplicemente copiando manualmente il file:

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 

... ma questa è ovviamente piuttosto laborioso. Suggerirei semplicemente di usare msbuild fino a quando il problema sottostante non sarà risolto.

+0

Immagino per 'dotnet' se la struttura del pacchetto fosse cambiata un po 'allora le librerie corrette verrebbero copiate durante la pubblicazione di dotnet e LoadLibrary/DllImport dovrebbe prenderle come per la ricerca ordine. Ho scritto un post sul blog per RC1 https://blog.3d-logic.com/2015/11/10/using-native-libraries-in-asp-net-5/ e durante il caricamento delle dipendenze native ora funziona diversamente se il pacchetto la struttura descritta in questo post è utilizzata, le cose dovrebbero funzionare. – Pawel

+1

@Pawel: sono riuscito a farlo funzionare localmente ... Ho solo bisogno di riordinarlo. –