While configuring some of our gitlab runners - some Windows, others Linux - I noticed something I find curious. The artifacts created by Linux runners include some libraries that are not included in the artifacts created by Windows runners.
The files in question are:
System.Collections.Immutable.dll
System.ComponentModel.Annotations.dll
System.Diagnostics.DiagnosticSource.dll
This happens no matter if a target runtime has been specified or not, e.g.
dotnet publish ./Project/Project.csproj -c Release
will include the three files mentioned above when run under Linux, but not when run under Windows (SDK 3.1.300). The project runs just fine without these.
Can anyone explain what's happening here? I was under the impression the result of a dotnet publish command is always the same regardless of the OS.
Related
I upgraded Visual Studio Community to the final release, and it stopped working. Specifically, I could generate a new project, but when I try to load it, it gave me an error
Critical Project 'SdkTest' load failed| [MSB4236] The SDK 'Microsoft.NET.Sdk.Web' specified could not be found. ...\SdkTest.csproj
Even though build and run worked fine
I ran "repair" on VS2022, and it seems to be working now from Visual Studio. However, dotnet --info doesn't show any SDKs; only runtime; and dotnet build or dotnet new give an error:
C:\Code>dotnet new console -o myapp
Could not execute because the application was not found or a compatible .NET SDK is not installed.
Possible reasons for this include:
* You intended to execute a .NET program:
The application 'new' does not exist.
* You intended to execute a .NET SDK command:
It was not possible to find any installed .NET SDKs.
Install a .NET SDK from:
https://aka.ms/dotnet-download
I even reinstalled .NET 6 and I see it in the list of applications (along with older SDKs). I checked the path, and I see everything that I expect to see:
C:\Program Files (x86)\dotnet\
C:\Program Files\dotnet\
C:\Users\me\.dotnet\tools
I am running Windows 11.
It's known bug in VS2022 installation.
Problem is that dotnet you access is located inside Program Files(x86)/dotnet, but all sdk's are located in Program Files/dotnet. You simply need to edit PATH environment variable so Program Files/dotnet goes before Program Files(x86)/dotnet. If you don't see Program Files(x86)/dotnet in user environment variable (which is likely to happen) then edit system environment variable (located below)
Example with screenshots: https://stackoverflow.com/a/44272417/10339675
This is what I see when I do a dotnet --info on my Windows 10 system:
It says:
.NET Core SDK (reflecting any global.json)
I honestly don't understand what "reflecting any global.json" would mean. Before posting this question, I did several searches and could not find any explanation.
When one runs the dotnet command, and multiple SDK version are installed on the system, the exact version used can be set in a global.json.
So I believe it means that the version printed in console is what may come from global.json, if there is such a file.
You can try this by creating global.json in the current directory via dotnet new globaljson --sdk-version 2.1.600 (referring to versions available on your machine). When you use dotnet --info (or any other dotnet <verb> command), the CLI in version 2.1.600 will be used.
global.json file is searched for in the current directory and upwards the hierarchy, so I think it's just saying "watch out, the version you see may be different than you expected because of this global.json somewhere".
To confirm it's nothing extra you can even take a look at .NET Core CLI sources - here and here. There are no special conditions why "reflecting any global.json" is printed.
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.
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.
I'm trying to get an old project to run on the new .NET VM, I've gotten through a few obstacles at this point. For a while I couldn't get DNVM to recognize my project as a .NET project, until I added a couple missing files from a sample project, and used dnvm . kestrel instead of dnvm . web and then I got back about 80mb worth of C# errors...
So I went from not being recognized as a project, to being recognized as a shitty one :/
Anybody beat this level yet? Thank you in advance.
Two questions for you
When you say that you tried dnvm . kestrel, do you mean that you tried dnx . kestrel?
Did you run dnu restore to download dependencies before running dnu . kestrel?
Three command line programs
There are three command line programs that you will use to run a .NET 5 app, and it's easy to confuse them. dnvm is the version manager, dnu is the utility, and dnx is the runtime. It's the runtime not the version manager that you use from your project's root folder to start the kestrel web server.
Startup up an app
Here's the very short version of how to start up a .NET 5 app. After using dnvm to install .NET 5, and after creating a project (and optionally a solution,) you need to use both dnu and dnx in this sequence.
From your solution's folder, run dnu restore. This will download your project's dependencies. If you have only a project and no solution, run this from your project's folder instead.
From your project's folder, run dnx . kestrel to run the web application in the browser.
It sounds like you did number (2) without having first done number (1).
Let me know whether you're able to reach the next level. Also, have you read these articles?
http://docs.asp.net/en/latest/getting-started/installing-on-mac.html
http://docs.asp.net/en/latest/tutorials/your-first-mac-aspnet.html