Net core arch linux

Arch Linux

Split Package Details — dotnet-core (x86_64)

7 packages found.

Arch	Repo	Name	Version	Description	Last Updated	Flag Date
x86_64	Community	aspnet-runtime	5.0.8.sdk205-1	The ASP.NET Core runtime	2021-07-27	2021-08-11
x86_64	Community	aspnet-targeting-pack	5.0.8.sdk205-1	The ASP.NET Core targeting pack	2021-07-27	2021-08-11
x86_64	Community	dotnet-host	5.0.8.sdk205-1	A generic driver for the .NET Core Command Line Interface	2021-07-27	2021-08-11
x86_64	Community	dotnet-runtime	5.0.8.sdk205-1	The .NET Core runtime	2021-07-27	2021-08-11
x86_64	Community	dotnet-sdk	5.0.8.sdk205-1	The .NET Core SDK	2021-07-27	2021-08-11
x86_64	Community	dotnet-targeting-pack	5.0.8.sdk205-1	The .NET Core targeting pack	2021-07-27	2021-08-11
x86_64	Community	netstandard-targeting-pack	5.0.8.sdk205-1	The .NET Standard targeting pack	2021-07-27	2021-08-11

The Arch Linux name and logo are recognized trademarks. Some rights reserved.

The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a world-wide basis.

Источник

Arch Linux

You are not logged in.

#1 2020-06-06 10:02:28

The sad state of C# (and .NET Core) on Arch Linux

I’m a big fan of the language C#. Sure, I can develop in C++ or Python too, but I have a fondness for C#. Since Microsoft released .NET Core, the language is free and open-source and supports all three major operating systems (Win, Mac, and Linux).

Sadly, it’s really difficult to develop C# on Arch. In order to write a simple console application, you have to install the .NET Core SDK, which is understandable as you need to do this for any language. Microsoft, as said in Arch Wiki, recommends you to use Visual Studio Code (VSCode for short) to develop C# (you need the MS branded release from the AUR to debug C#), which makes sense because it is the closest to a full IDE that you can get on Linux. In VSCode you need to install the Omnisharp extension too. Finally, you need MSBuild, Microsoft’s compiler, to actually compile C#, more on this later on.

Ideally, this is all you need to do. In reality, if you have Mono installed too, you need to disable it in VSCode’s settings, otherwise, everything is unrecognised and underlined by a squiggly red line. This is buried deep in a GitHub issue and would be helpful to have on the Arch Wiki. It seems like the Arch Wiki doesn’t want to have a separate article for C# and instead just one for .NET Core, so this could be added under the troubleshooting section.

Next, you actually can’t install the msbuild-stable package. You see, Omnisharp requires MSBuild >16.3, and the msbuild-stable package on the AUR is stuck on 16.0 since over half a year ago (August 2019). This means that you need to edit the PKGBUILD manually to download the 16.5 .deb package instead (I mean, you could use the 16.3 package, but why not use the latest stable version?). This should be fixed by orphaning the package and having someone adopt it soon since it’s a critical package for developing C#, not a small and unknown language at all.

So to conclude, yes you can develop C# on Arch, but it took me at least two full days of trying to find out why things weren’t working when it could have been prevented through more care at many different ends. I do want to edit the Arch Wiki, but you can’t really write «The required package is out of date, so the PKGBUILD will need to be edited manually,» I feel like once the msbuild-stable package is up-to-date, then the Wiki can be updated too.

#2 2020-06-06 13:29:31

Re: The sad state of C# (and .NET Core) on Arch Linux

This seems like a complete non-issue honestly.

You can update the wiki no problem.
There is no reason why the troubleshooting step i.r.t. mono can’t be put on the wiki page for .NET Core already, nor why you couldn’t add a note mentioning that MSBuild should be 16.3 or higher. You don’t really need to add more information than that because information on how to work with ABS, the AUR and PKGBUILDs is well written and available on the wiki already.

At the same time/after that you try to contact the maintainer of the AUR package. You can try with a comment or maybe try to contact the user with the contact info on the AUR profile or locate his forum account (if he has one) and send a message there. If there is no contact information available or you’ve not been able to get a response in a week or 2, just put in an orphan request and take over as maintainer.
Until then you could drop a patch in the comments of the current package to help people out in the mean time.

That said, afaik Omnisharp isn’t a requirement for development though. Yes, it would be very handy and helpful but it’s completely optional isn’t it?
Which would make the second (both??) problem irrelevant at all for very minimal development. Though if stable is 16.5, the package should be updated so you might still want to take over and at that point you can remove the note again.

Last edited by Omar007 (2020-06-06 13:45:56)

Источник

.NET Core

.NET Core is a new FOSS software framework from Microsoft for C#, Visual Basic, and F#. It is designed to be cross-platform, modular and apt for modern applications, as opposed to its predecessor, the .NET Framework.

Contents

Installation

If you only want to run .NET Core managed applications, install the dotnet-runtime package.

To build apps with .NET Core, install dotnet-sdk as well.

Microsoft recommends using Visual Studio Code , their Electron-based IDE, to build & debug .NET Core apps.

/.dotnet/tools to PATH , otherwise dotnet tools will not work from shell.

Install multiple versions manually

You can install multiple versions of the .NET Core SDK or runtime side by side by using the dotnet-install.sh script provided by the .NET Foundation. You can find the documentation of the script here.

For instance, this command would install the latest version found in the «current» channel in /usr/share/dotnet :

You may want to simulate the installation first by using the -Dryrun flag.

Once installed, you can verify the SDKs available:

Uninstall manually installed version

You may want to remove outdated versions installed with dotnet-install.sh . The automated .NET Uninstall Tool does still not support Linux, so the desinstallation has to be done manually.

Desinstallation of the sdk:

Using dotnet-install.sh also dotnet host and shared packages are getting installed, which may have to get removed additionally depending on the release.

Complete deinstallation of the .NET Version (sdk, host, shared):

Install multiple versions via AUR

Some of the AUR dotnet packages are made to be installed alongside each other. Only one host package ( dotnet-host-bin AUR or dotnet-host ) is needed containing the command-line tool and you can install any of the available SDKs and Runtimes (latest packages of all major versions) next to it. List of compatible packages:

Install PowerShell Core

You can install PowerShell Core as a «global» tool also [1] [2]

to update to the current version

Telemetry

Telemetry is enabled by default but can be disabled by setting environment variable DOTNET_CLI_TELEMETRY_OPTOUT=1 .

Tab-Completion

All dotnet core programs that use System.CommandLine.Parser to parse their arguments have auto-complete support. Enabling it just requires adding a few lines to your .bashrc / .zshrc file, as described in their documentation. Instructions for standalone binaries are here.

Troubleshooting

It was not possible to find any compatible framework version

If you get the following error when you try to run a newly created project, you no longer need to set a DOTNET_ROOT variable as described in the solutions of various GitHub issues. Arch’s dotnet package (as of 3.1) installs it to the Microsoft recommended location of /usr/share/dotnet .

This is caused because the runtime is shipped as a separate package in Arch. You just need to make sure you have the aspnet-runtime package installed as well.

«the required library libhostfxr.so could not be found» error

Some of the dotnet SDK tools (for example libman, dotnet-watch etc.) may expect you to have the environment variable DOTNET_ROOT pre-configured. If it is not, an error like this one could be observed: [3]

The workaround is to manually export DOTNET_ROOT in your shell:

Error MSB4019: The imported project «/usr/share/dotnet/sdk/. /Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.Common.targets» was not found. Confirm that the expression in the Import declaration . is correct, and that the file exists on disk.

This happens after an update. The currently running shell / login session is storing environment variables for the dotnet SDK version different from one installed. Restarting the shell or logging in again should fix this.

Источник

How to distribute a .NET Core app in Arch Linux

In this post we’ll build a netcore CLI app called taskcore and learn about the interaction between makepkg and a self-contained .NET app. We start from a PKGBUILD file and examine what it does with this self-contained app.

What is a self-contained app?

In the .NET world this means that the published artifacts of the app will include everything to run without requiring .NET installed in the user’s system.

Building the app

This is the PKGBUILD for build the taskcore app in Arch Linux using the publish command:

The dependencies

The installation of .NET Core in Arch Linux is so easy:

We need the icu package (International Components for Unicode library) to run this app, otherwise we’ll get this error:

The makepkg options

We should use the staticlibs option in the PKGBUILD to tell Arch to leave static library files in the package, otherwise the makepkg will assume the libraries will be installed as a dependency package to avoid duplicated files in the OS.

The publish arguments

The -p:PublishTrimmed=true will remove unused libraries in the build output if they aren’t statically linked to our executable file.

The —self-contained true produces a platform-specific executable, so we should include the target platform with —runtime linux-x64 , other options are linux-arm64 , or linux-musl-x64 for lightweight distributions using musl like Alpine Linux.

We can publish the libraries inside the executable with -p:PublishSingleFile=true , but makepkg will strip all the libraries from the executable file. This optimization is useful to remove symbols (commonly used for debug) and get a lighter package, but for .NET we should use:

What about the MSBUILDDISABLENODEREUSE=1 ? I found this error when I run the build several times:

Looks like the failed builds leave MSBuild processes lying around.

How to package the app

We should move all the build output to the /usr/lib/taskcore :

Then, we should make the taskcore command accessible by locally logged in users with a symlink:

And, it’s done! We’ve our first .NET self-contained app for Linux. Just build it:

More about .NET

If you want to start with .NET you could see this awesome video from Scott Hanselman

Источник

Visual Studio Code

Visual Studio Code is a cross-platform proprietary text editor (licensed under an End-User License Agreement) developed by Microsoft, built on top of a free and open-source project named Codium (licensed under the MIT License), written in JavaScript and TypeScript – the relationship between Codium and Visual Studio Code is more or less the same as the one between Chromium and Google Chrome; for an explanation of the mixed licensing, see this GitHub comment. Visual Studio Code is built on the Electron framework and is extensible using extensions, which can be browsed on the web or from within the text editor itself.

Contents

Installation

The following packages provide VSCode:

• code (open-source release)
• code-gitAUR (in-development open-source version)
• visual-studio-code-binAUR (Microsoft-branded release)
• visual-studio-code-insiders-binAUR (Microsoft-branded release, updated daily)
• vscodium-binAUR (community-driven fully open-source version of VSCode, with all Microsoft telemetry stripped out — latest release, binary package)
• vscodiumAUR (community-driven fully open-source version of VSCode, with all Microsoft telemetry stripped out — latest release, git build)
• vscodium-gitAUR (community-driven fully open-source version of VSCode, with all Microsoft telemetry stripped out — latest commit on branch master, git build)

The Microsoft ptvsd (Python Tools for Visual Studio Debug) server/module is available at python-ptvsd AUR .

Usage

Run code to start the application (or if you are using other releases, run code-git for code-git AUR or codium for vscodium-bin AUR / vscodium AUR / vscodium-git AUR ).

If for any reason you wish to launch multiple instances of Visual Studio Code, the -n flag can be used.

Configuration

code stores settings in

vscodium AUR and related packages store their settings in

When migrating from Code to Codium (or vice versa), the settings directory can be copied or moved, since they share most of their codebase, the settings are compatible.

Integrated Terminal

View > Integrated Terminal or Ctrl + ` opens up an integrated terminal. By default, Bash is used with no additional arguments, although this can be changed. terminal.integrated.shell.linux sets the default shell to be used and terminal.integrated.shellArgs.linux sets the arguments to be passed to the shell.

You might face weird prompts after setting the integrated shell arguments with external terminal, remove the line to solve the problem or use an external terminal.

External terminal

If you are using Terminator as default terminal for Arch and you have an error on Visual Studio Code: Unable to launch debugger worker process (vsdbg) through the terminal. spawn truecolor ENOENT , you can change the terminal that will be used by Visual Studio to another terminal (e.g. gnome-terminal ).

«terminal.external.linuxExec»: «Your alternative terminal» sets the default terminal to be used for exec debug.

Running natively under Wayland

If you are using a Wayland-based WM or DE, you can force Visual Studio Code to run natively under Wayland (instead of under XWayland) by adding command-line options —enable-features=UseOzonePlatform —ozone-platform=wayland . For example, you can try launching VSCode using

These options can be automatically applied every time Visual Studio Code is launched by adding them to the file $/electron-flags.conf . (See Wayland#Electron.)

Troubleshooting

Global menu not working in KDE/Plasma

Visual Studio Code uses DBus to pass the menu to Plasma, try installing libdbusmenu-glib .

Unable to move items to trash

By default, Electron apps use gio to delete files. kioclient5 is automatically selected instead if Plasma is detected. Different trash implementations can be used by setting the ELECTRON_TRASH environment variable.

For example, for deleting files using trash-cli :

At the time of writing, Electron supports kioclient5 , kioclient , trash-cli , gio (default) and gvfs-trash (deprecated). More info is available at this documentation page.

Unable to debug C#

If you want to debug C#.NET (using the OmniSharp extension) then you need to install the Microsoft branded release (from the AUR). This is apparently because the .NET Core debugger is only licensed to be used with official Microsoft products — see this github discussion.

When using the open-source package, debugging fails fairly quietly. The debug console will just show the initial message:

For debugging with the open-source package netcoredbg AUR can be used. To run it in VS Code, add this configuration to .NET Core launch configuration of the project:

Unable to open .csproj with OmniSharp server, invalid Microsoft.Common.props location

You have to switch from mono to proper SDK version props.

Modify import to look like this:

Error from OmniSharp that MSBuild cannot be located

It is noted in the OmniSharp introduction that Arch Linux users should install the mono-msbuild package. Without it, you might get an error like:

You might be able to build anyway (possibly depending whether you have mono installed too).

Omnisharp ships with its own mono version, so, if it is unable to locate the installed one, if you want to tell omnisharp to look for a «global» mono installed in your machine, put this in your settings.json:

Saving with «Retry as Sudo» does not work

This feature does not work in the code package, because Microsoft does not support the way the Arch package is packaged (native instead of bundled Electron). See FS#61516 and the upstream bug report for more information.

The binary release visual-studio-code-bin AUR does not have this issue, and the feature works there.

Keyboard variants or keymappings do not map

Switching keyboard layouts under some Linux window managers does not result in a change in the low level X window APIs VS Code uses to read the current keyboard layout. This means that VS Code ends up sometimes reading one of the other configured keyboard layouts and not the current active one. PR welcome.

Per the wiki, there are two possible solutions:

1. make sure setxkbmap -query returns as the first keyboard layout the one you want to work with in VS Code.
2. use «keyboard.dispatch»: «keyCode» in your settings and restart VS Code. This will prevent VS Code from trying to determine your keyboard layout whatsoever.

Command «. » not found

In the official build of VS Code, a product.json file lists the extensions that are allowed to use certain proposed APIs accessed by extensions. However, the product.json is absent in the OSS build code . [1]

In the related issues below, some flags may be required to enable certain APIs. [2] You may either run code with these flags, or you can add the relevant entries to the extensionAllowedProposedApi section in the product.json file ( code installs this to /usr/lib/code/product.json ).

This can also be resolved by installing the code-features AUR package, which installs a pacman hook that patches the file on every package update. Alternatively, you may also consider installing the Microsoft branded packages: visual-studio-code-bin AUR , visual-studio-code-insiders-bin AUR .

VS Live Share missing API

Use either the solution above by editing the product.json , or open VS Code with:

Command ‘remote-containers.openFolder’ not found

Open VS Code enabling remote-containers API as commented in FS#63374:

Command ‘GitHub Pull Requests: Configure Remotes. ‘ resulted in an error (command ‘pr.configureRemotes’ not found)

Open VS Code with:

Git: ssh_askpass: exec(/usr/lib/ssh/ssh-askpass): No such file or directory

This error is a result of an encrypted ssh-key, and can be solved by installing a dialogue provider like SSH keys#x11-ssh-askpass or the alternatives listed there like ksshaskpass for KDE.

One thing to note is that for e.g. ksshaskpass you would need to link it from /usr/lib/ssh/ssh-askpass to get VSCode to find it:

No extensions found

There exist several differences between «vscode» (open-source) and «Visual Studio Code» (Microsoft product based on vscode), see: Differences between the repository and Visual Studio Code. The usage of Microsoft marketplace for extensions is restricted to products of the Visual Studio Code’s family. Consequently, it cannot be used by vscode (see FS#67780). The code and vscodium-bin AUR / vscodium AUR / vscodium-git AUR packages are configured to use the Open VSX registry instead of the Microsoft one. This explains why some extensions are missing from the vscode explorer while they appear to be listed online.

The workaround is to either install the visual-studio-code-bin AUR package instead, manually download and install the .vsix file from the web marketplace page, or ask the maintainer to upload its extension to OpenVSX.

Technically, one could also edit the product.json as shown in this Github comment, but that would not comply with the Microsoft Marketplace Terms of Use. Additionally, the changes would be overwritten during package update. This can be overcome by installing code-marketplace AUR / vscodium-bin-marketplace AUR / vscodium-marketplace AUR package, which installs a pacman hook that patches the file on every package update.

Cutoff characters in integrated Terminal

Characters that are too wide can end up clipping. For example the italic bold text of Deno stack-traces.

This can be avoided by setting «terminal.integrated.rendererType» to «experimentalWebgl».

Blurry text under Wayland

Visual Studio Code defaults to run under XWayland, which may cause blurry text if you are using HiDPI screens. To fix this issue, try forcing Electron to run under Wayland—see #Running natively under Wayland.

No such interface“org.freedesktop.Secret.Collection”

Authentification with Github failed while using VSCodium

When connecting a Github account, change «vscodium» to «vscode» in the URL as seen in this comment. Then copy the identification token into VSCodium. Should it still fail, install a keyring like gnome-keyring or create a new keyring as mentioned here in the Visual Studio Code docs and here on Github.

Источник