(also, this attempts to fix the nugets generated by "dotnet pack" - which is not yet the official way of generating nugets for gRPC. Analogous steps are needed to fix the old .nuspec based nugets).

Pushed 2 more commits with a fix for the mono 32bit vs 64bit version problem described above.

Not quite sure how this PR relates to my one at #7282. That has a significant set of changes for getting it working on Windows which I don't believe are in this PR.

I don't think Grpc.Core itself should have the Microsoft.NETCore.Platforms dependency, because we don't want it pulled in for users using csproj files. It's just a final application-user dependency. Admittedly if we could make it so the end user didn't need to know about it, that would be better... we should see what that dependency does on non-dotnet-cli environments.

I suspect your issue running on OSX between 32-bit and 64-bit is related to the one I've been encountering trying to run the 32-bit CLR on Windows; I believe the tooling for dotnet run just doesn't take note of the architecture properly. If you run dotnet build -a x86 does that help? I'd expect that to copy the right file into the output directory. (That much works for me on Windows, but running it doesn't - it still uses the x64 CLR.)

Retiring this PR in favor of #7282.

On Fri, Jul 8, 2016 at 11:43 PM, Jon Skeet [email protected] wrote:

Not quite sure how this PR relates to my one at #7282
#7282. That has a significant set of
changes for getting it working on Windows which I don't believe are in this
PR.

yes, windows tests are actually broken in my PR. Your fix seems reasonable.

I don't think Grpc.Core itself should have the
Microsoft.NETCore.Platforms dependency, because we don't want it pulled
in for users using csproj files. It's just a final application-user
dependency. Admittedly if we could make it so the end user didn't need to
know about it, that would be better... we should see what that dependency
does on non-dotnet-cli environments.

I added dependency on Microsoft.NETCore.Platforms, because that's what
"libuv" nuget package does. Also, the neat trick they are using it that the
Microsoft.NETCore.Platforms dependency is specified for targetPlatform
"netstandard1.0" so if you have older version of nuget, the dependency is
just ignored. If you have a net45 project depending on libuv, the
dependency is resolved correctly. Unfortunately, because we target net45
and netstandard1.5 separately, that trick probably won't work for us.

I suspect your issue running on OSX between 32-bit and 64-bit is related
to the one I've been encountering trying to run the 32-bit CLR on Windows;
I believe the tooling for dotnet run just doesn't take note of the
architecture properly. If you run dotnet build -a x86 does that help? I'd
expect that to copy the right file into the output directory. (That
much works for me on Windows, but running it doesn't - it still uses the
x64 CLR.)

A quick fix is I make Microsoft.NETCore.Platforms copy both x86 and x64
libraries by adding them under /runtimes/osx (and the right variant is
chosen by gRPC loader code at runtime). Making that change to your PR would
be good I think.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#7295 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AJeq5Mj2JY30jZiecjw6lyp_79rtGSrkks5qT0MYgaJpZM4JIhuB
.

I added dependency on Microsoft.NETCore.Platforms, because that's what
"libuv" nuget package does.

Mmm. Microsoft.Dia.SymReader.Native doesn't though. I shall see if I can get a question into the community standup.

A quick fix is I make Microsoft.NETCore.Platforms copy both x86 and x64
libraries by adding them under /runtimes/osx

Yes, that would be simple. I'll do that across the board for the moment.