Package Details: jetbrains-resharper-commandlinetools 2024.2.6-2

Git Clone URL: https://aur.archlinux.org/jetbrains-resharper-commandlinetools.git (read-only, click to copy)
Package Base: jetbrains-resharper-commandlinetools
Description: JetBrains ReSharper Command Line Tools
Upstream URL: https://www.jetbrains.com/resharper
Licenses: custom:jetbrains
Submitter: walwe
Maintainer: walwe
Last Packager: walwe
Votes: 0
Popularity: 0.000000
First Submitted: 2024-10-16 06:56 (UTC)
Last Updated: 2024-10-24 06:27 (UTC)

Latest Comments

xentropic-dev commented on 2025-06-06 09:17 (UTC)

That makes sense. Thank you for the clarification.

walwe commented on 2025-06-05 18:30 (UTC)

Yeah, I agree — if you want the JetBrains Global Tools, the recommended way is to use dotnet tool install, which gives you jb inspectcode. This package, however, intentionally provides the classic ReSharper Command Line Tools (inspectcode), which are still very commonly used in CI/CD pipelines. I originally maintained this PKGBUILD locally for exactly that reason — having inspectcode available system-wide makes it much easier to match local runs with what's happening in CI. I can see how the difference could be confusing — JetBrains doesn’t really make it obvious that the Global Tools (jb inspectcode) and the classic CLT ZIP (inspectcode.sh / .exe). Since this package is clearly named jetbrains-resharper-commandlinetools, it’s targeting the classic CLT ZIP. Installing it as jb inspectcode would actually be incorrect here. And while the two tools are quite similar in purpose, they aren’t identical in behavior — so it’s definitely useful to have both available depending on your needs.

xentropic-dev commented on 2025-06-05 13:06 (UTC) (edited on 2025-06-05 13:09 (UTC) by xentropic-dev)

In what scenarios might someone choose to install the ReSharper Command Line Tools through the AUR instead of using the dotnet CLI method recommended by JetBrains here (https://www.jetbrains.com/help/resharper/ReSharper_Command_Line_Tools.html#-40t6uh_21).

I ask because it might cause down-stream issues if other systems expect the command to inspect code be jb inspectcode

This tool appears to install the CLI command as inspectcode instead of jb inspectcode

walwe commented on 2024-10-24 06:29 (UTC)

Added your suggestion

Thank you

MarkusG commented on 2024-10-23 20:22 (UTC) (edited on 2024-10-23 21:49 (UTC) by MarkusG)

Package is broken. /usr/bin/cleanupcode and /usr/bin/inspectcode call shells scripts that do not exist. It looks like they're supposed to reside in /opt/jetbrains-resharper-commandlinetools but the directory is empty. Here is a functioning PKGBUILD

# Maintainer: walwe <aur@walwe.de>
# Contributor: Mark Gross <mark.gross2001@gmail.com>

pkgname=jetbrains-resharper-commandlinetools
pkgver=2024.2.6
pkgrel=2
pkgdesc="JetBrains ReSharper Command Line Tools"
arch=('x86_64')
url="https://www.jetbrains.com/resharper"
license=('custom:jetbrains')
depends=('dotnet-sdk')
source=("https://download-cdn.jetbrains.com/resharper/dotUltimate.${pkgver}/JetBrains.ReSharper.CommandLineTools.${pkgver}.zip")
sha256sums=('b71d9d2c4793ef293107d1c01fdaa887179311a9a3b44c81e7f42328b1689447') 

prepare() {
    # patch scripts to reference the correct directory
    sed -Ei 's/\$\(dirname "\$0"\)/"\/opt\/'"$pkgname"'"/g' "$srcdir/cleanupcode.sh" "$srcdir/inspectcode.sh"
}

package() {
    install -d "$pkgdir/opt/$pkgname"
    cp -r "$srcdir/"* "$pkgdir/opt/$pkgname"

    # create symlinks in /usr/bin
    install -d "$pkgdir/usr/bin"
    ln -s "/opt/$pkgname/cleanupcode.sh" "$pkgdir/usr/bin/cleanupcode"
    ln -s "/opt/$pkgname/inspectcode.sh" "$pkgdir/usr/bin/inspectcode"
}