I have created a very simple program which should list the topics available in a Google Cloud project. The code is trivial:
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);
}
}
}
When I run this from a "regular" msbuild project targeting .NET 4.5, it works fine. When I try to use dotnet cli (1.0.0-preview2-003121) with the following project.json
file:
{
"buildOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Google.Pubsub.V1": "1.0.0-beta01"
},
"frameworks": {
"net45": { }
}
}
... I see an exception:
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 ...
I'm not trying to target .NET Core, so shouldn't this be supported?
This is currently a limitation in gRPC 0.15, which Google.Pubsub.V1 uses as its RPC transport. Under msbuild, the build/net45/Grpc.Core.targets
file in the Grpc.Core
package copies all the native binaries into place. Under DNX, the packages weren't copied and gRPC tries to look for the file in the right place with the local package repository. Under dotnet cli, we need to use the "runtimes" root directory in the package to host the libraries.
We've implemented a fix for this in gRPC, but we didn't manage to get it into the beta-01 release. We're hoping to fix it for beta-02.
It's possible to work around this by just manually copying the 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
... but that's obviously pretty fiddly. I'd suggest just using msbuild until the underlying issue has been fixed.
See more on this question at Stackoverflow