I am trying to run a simple GRPC client-server code in raspberri Pi running Raspbian os.
Language that i am using -C# dotnet core (2.1)
I downloaded a sample project from here.
This is a dotnet core project . I am able to run it in Windows environment, i am also able to modify .proto file in this code and run successfully.
I published the solution as it is with command
{ dotnet publish -r linux-arm }
When tried running same on Rpi, i am getting exception. Attached screenshot has the details of it.
Any help to get through this would be of great use
tl;dr The problem is the libgrpc_csharp_ext native library which currently does not get compiled and built for the arm7 processor. I've compiled it (on a pi) for arm7 and released a nuget package to bridge the gap until they support it all the way: https://www.nuget.org/packages/libgrpc_csharp_ext.arm7/
I'll update with a link to a blog post when I finish getting the rest of the tooling and template finished I'm working on.
fuller explanation: the Grpc.Core nuget package contains the native libgrpc_csharp_ext library that the dotnet implementation of grpc loads in NativeExtensions.cs then maps with PInvoke in NativeMethods.Generated.cs. Inspecting that package, you'll see a version of that library in each /runtimes/[win, osx, linux]/native folder. Unfortunately, no linux-arm version of the library is included. However, in the code, if the platform is linux, it will try to load the static library using the name as formatted here. Dissect that a little and you'll see that as of right now, any 'linux' platform that isn't '64bit' (which despite the proc on the pi being 64 bit, the distro of linux you're using on there, including raspbian, likely isn't) will look for libgrpc_csharp_ext.x86.so. When you dotnet publish -r linux-arm, you'll see that library there in the build output, but unfortunately, it's the wrong one (I think publish just grabs 'the closest one' when it can't find a specific library in the runtimes folder).
The nuget package I created above is compiled for arm7 - I actually cloned the grpc repo onto a pi and peeled away enough of the /csharp build to just cmake the libgrpc_csharp_ext. The 'trick' the package uses is to put the library in runtimes/linux-arm/native folder within the package, which dotnet core recognizes when publishing and pulls into the build output - but the library is still named libgrpc_csharp_ext.x86.so because of the way NativeMethods.cs formats the library name.
Related
I have solution with following projects:
Api
Application
Infrastructure
Tests
Api is WebApplication (entry point) and has ProjectReferences to libraries Application and Infrastructure.
Tests is a xunit test project and has ProjectReferences to Api / Application / Infrastructure.
I want consistent package versions both during publishing main (Api) project and during running tests.
I added following properties to Api.csproj:
<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
<RestoreLockedMode Condition="'$(CI)' == 'true'">true</RestoreLockedMode>
And it generated Api/packages.lock.json - and it seems that this file also tracks versions of dependencies of referenced projects.
Here is how I publish application (Api):
RUN dotnet restore ./Api/Api.csproj
RUN dotnet publish Api -c Release -o out --runtime alpine-x64 --self-contained true /p:PublishTrimmed=true
So if CI=true env var is set, then commands above should either restore packages according to package.lock.json or fail.
However before publishing Api I run tests like this:
dotnet test ./Tests/Tests.csproj
My question is how to ensure that exactly same package versions will be used suring testing as in Api/package.lock.json? Because if I add <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile> to Tests project then it will have separate Tests/package.lock.json file which may not be same as the one in Api/package.lock.json, right? On the other hand when Tests project references Api project then from what I understand Api/package.lock.json is ignored (when running Tests project)?
Is it possible to have one package.lock.json for solution (same for all projects in solution)?
I feel a bit bad for making this an answer and possibly getting rep votes, when mu88 beat me by 12 hours in the comments to the question, but Central Package Management is the answer. There's also a blog post about it.
Currently, neither Visual Studio, nor dotnet add package support installing or upgrading packages, so you will need to hand edit all the xml (csproj, props) files. But support should be coming in VS 2022 17.4, .NET SDK 6.0.400.
I wrote a test project using .NET Core and assembled the self-contained deployment for Ubuntu 16.04 as described here (see Self-contained deployment without third-party dependencies).
But when I run the app I get the following error:
An assembly specified in the application dependencies manifest (Test.deps.json) was not found:
package: 'runtime.linux-x64.Microsoft.NETCore.App', version: '2.0.0-preview2-25407-01'
path: 'runtimes/linux-x64/lib/netcoreapp2.0/Microsoft.CSharp.dll'
I am using .NET Core 2.0 Preview 2, VS2017 Preview.
I will be grateful for any help!
This is an old question, but I just ran across this when I was trying to run a .Net Core application on Linux and wanted to share the solution. If you are getting the error above, you are likely trying to execute the wrong binary. For those following along from scratch, follow these steps:
On Windows, open a command prompt in the directory of the project you want to run on Linux.
Build the project for Linux using dotnet publish -r linux-x64
I chose to target linux-x64, but you can target a specific runtime if you'd like. Runtime identifiers can be found here.
Copy the published files to the Linux workstation. Because the above command omitted the configuration flag -c, the configuration defaulted to debug. The published files will be in Debug\netcoreapp2.0\linux-x64\publish
Note: there will be binaries in Debug\netcoreapp2.0\linux-x64\ too. These are not the binaries you want to copy to your Linux workstation. If you run these binaries, you will get the error described in the OP. Copy all the files in the publish directory instead. Ignore whatever files might be in linux-x64.
On the Linux workstation, give execute permission to the binary file. My project was named ConsoleUI, so I used chmod 764 ConsoleUI
Execute the binary using ./ConsoleUI
Keep in mind that you will need to at least have the .Net Core runtime installed on your Linux workstation.
Recently, I created an asp.net core project using Visual Studio Code on Windows and pushed it to GitHub. When I cloned the repo from GitHub and attempted to do a dotnet restore on the project on Ubuntu, an error message stating there was no project.json file was returned. Can anyone point me to a resource that will show me how to properly restore a .net core project from a Linux machine? Thanks!
So it seems like on each of your machines you are running different versions of the .net core SDK.
A big caveat with what you are trying to do. Are you trying to use Project Rider from Jetbrains on Linux? This only works with project.json (As of the time of this post) so be wary of that.
Now there are two ways to do this. If you are wanting the very latest on Linux and don't care about using Rider, then you can go here : https://github.com/dotnet/core/blob/master/release-notes/download-archive.md and download the latest release for both Linux and Windows, install on both and you should be good to go.
If you do care about using Rider or you aren't ready to be strapped in for the wild ride of the latest release. Then you can do the following.
Find what version of the SDK you have on linux by typing into a terminal the following :
dotnet --version
This will spit out what version you have on linux. Go here and download the same version for windows and install it on your windows machine (https://github.com/dotnet/core/blob/master/release-notes/download-archive.md).
Now BEFORE you create a project, create a solution folder and create a file in it called global.json. Inside that put the following :
"sdk": {
"version": "1.0.0-preview2-003131"
}
Where the SDK version matches what you got from your linux terminal. Now create a folder for your project inside the solution folder. Run "dotnet new -t web" or a similar command to create your project. It will inspect the SDK version of the global.json and create a project with the tooling that matches. You should then be able to shift this project around any machine that has the same SDK installed, even if it also has the latest SDK's also.
If you do not create the global.json, it defaults to the latest version (Atleast on Windows).
Read a bit more about it here : http://dotnetcoretutorials.com/2017/02/17/developing-two-versions-net-core-sdk-side-side/
I have made an application using QtWebKit, Qt4. I have the binary generated in Fedora 16. Now, I want to run that application on another PC (running some other Fedora version), where Qt is not installed. How can I package my Qt application so that it can run on a platform where Qt is not installed? Is there any command line utility as well as QtCreator utility to do so. I have tried "deploy all" command, but it didn't have any affect.
Create an Installer with the Qt Installer Framework and just supply all needed shared libraries (Win/OSX) or compile statically. Under Linux there is always the problem between system-wide libraries or bundled libraries. The documentation https://qt-project.org/doc/qt-5.0/qtdoc/deployment.html should give you a good start
Obviously, you need to have access to the qt libraries, which are exactly the same version that you used to compile your application.
There are two options :
link qt libraries statically
create a RPM package (see this how)
Also check Deploying Qt Applications.
Since you're deploying using rpm, to systems where Qt 4 rpms are available, you don't need to do anything besides simply adding a dependency on the qt to your rpm's specfile. The user installing your package using yum localinstall will get the Qt dependencies automatically installed. That's the correct way of doing it - it will keep your package size small.
Of course you need a separate rpm build for every fedora/centos major version out there, but that's almost always a requirement.
If your package needs newer Qt version than the one provided by the platform packages, you can still make a specific version dependency (say qt >= 4.7.0) and have a readme that indicates that newer packages can be obtained from a 3rd party repository (epel etc.)
For deployment under Linux I've used Bitrock Installer Tool.
The main thing before deploying is to check your dependencies. You can do that by using command:
ldd appName | grep libQt
After that you'll see list of dependencies. You'll have to set environment variable LD_LIBRARY_PATH to let linker know where're your libraries. To do that:
export LD_LIBRARY_PATH=.
. means current directory
And after that:
./appName $*
After that you'll be able to use your executable with Bitrock Installer Tool.
I have developed a TideSDK application and am now ready to package it, but I'm having problems with the network type installer.
It always gives me code 404 on the Application first run:
Could not query info: Invalid HTTP Status Code (404)
I presume the installer is having difficulty with reaching the correct servers and downloading the needed runtime, but I have run through most solutions on this forum, and none have worked.
So I tried a bundle packaging, as it should include such runtime, but I must be doing something wrong, since it does not bundle within the MSI.
The code I'm executing is as follows:
C:\TideSDK\sdk\win32\1.2.0.RC6d\tibuild.py -p --type=BUNDLE --os=win32 "C:\path_to_app\app_dir"
I also tried:
C:\TideSDK\sdk\win32\1.2.0.RC6d\tibuild.py -p -t bundle --os=win32 "C:\path_to_app\app_dir"
And all the uppercase/lowercase combinations. Also tried version 1.2.0.4, without sucess. Am I doing something wrong?
the network type installer is not available anymore, since appcelerator has canceled their services for titanium desktop.
So you can only do bundle packaging. Try the following command:
python tibuild.py --dest=. --type=bundle --package=. "c:\path\to\your\app\dir"
This should build and package your app and create a installer for it.
Change "dest" and "package" to the directories where you want to have the built app and installation package.
You can omit the OS parameter, since the builder can only generate builds for the current OS.