install-local-module exits 0 with no effect and no log entry when the target is a host package

[benmassaoud]

Is there an existing issue for this?

• I have searched the existing issues

Description

abp install-local-module modules/ModCible/ModCible.abpmdl -t Probe.abpmdl

exits 0, writes no file (git status --porcelain stays empty), and leaves no line in ~/.abp/studio/cli/logs/abp-studio-cli-logs.txt, where the same call from module to module writes one.

A success reported without effect and without trace is the worst of the three possible outcomes: a loud failure gets fixed, a silent failure gets hunted, but a false success gets believed.

The cause is not the one you first assume. The command matches package roles, and it has no rule for a host.* role. The host package of the app-nolayers-modern template carries "role": "host.http-api"; a module's packages carry lib.application, lib.application-contracts and lib.test. With no match there is nothing to do, and nothing is said.

Proof, by mutating a single variable. In a sandbox produced entirely by the CLI, the role of the host .abppkg is the only thing that changes:

role of the host package	Result
host.http-api (the template's own value)	nothing; git status --porcelain empty
lib.application	Referencing <Mod> to <Host>..., then ProjectReference and [DependsOn] written

The command works perfectly. It simply does not recognise the role that its own template puts on the host project.

What is asked, in order of value, and the first would be enough:

1. that the command say so. "The target package carries role host.http-api, for which no install rule is defined" would make this diagnosable in a second instead of half a day;
2. that it exit non-zero when it did nothing;
3. that a host.* role be a valid target - this is the main use case: installing a module into the application you are building.

The three other paths, replayed and ruled out, so this report does not point at a road already travelled:

Path	What it does
abp add-package-ref	does not cross a module boundary - "Both reference and target projects must belong to same module" - and says so through an unhandled KeyNotFoundException instead of a message
abp add-module <Name>	queries remote sources, never the disk
abp add-module --new --add-to-solution-file	creates a classic DDD module of eleven projects, Blazor and MongoDB included, and touches neither the .csproj nor the module class of the host
abp new-module <Name> -o modules -csf -ts <sln>.abpsln	creates the module and records it in the .abpsln, but the .slnx carries no trace of it and neither does the packages block of the host .abpmdl

Reproduction Steps

A throwaway sandbox, git initialised so --porcelain has something to say:

abp new Probe -t app-nolayers --modern -u react
cd Probe && git init && git add -A && git commit -m base
mkdir modules
abp new-module Probe.Chantiers -t module:standard --modern -o modules -csf -sf modules
git add -A && git commit -m module
abp install-local-module modules/Probe.Chantiers/Probe.Chantiers.abpmdl -t Probe.abpmdl
echo "exit=$?"                                            # 0
git status --porcelain                                    # empty
tail -1 ~/.abp/studio/cli/logs/abp-studio-cli-logs.txt    # nothing from the command
grep '"role"' Probe/Probe.abppkg                          # "role": "host.http-api"

Expected - either the module is wired into the host, or the command says why it cannot be and exits non-zero.

Actual - exit 0, no file, no log line, no message.

Version

3.0.10 (Volo.Abp.Studio.Cli, the latest published at time of measurement). Behaviour is identical on 3.0.9 and 3.0.8.

Operation System

Windows (Default)

Solution Configuration

• Template: app-nolayers
• Created ABP Studio Version: 3.0.10 CLI
• Tiered: No
• UI Framework: react
• Database Provider: ef
• Public Website: No

Other information

The documentation is consistent with the observed behaviour and says so up front - docs/en/cli/index.md: "Installs one module to another. Project relations are created according the types of the projects." and "-t: Path of the target module".

Read that way, this is not a broken command but a missing function, plus a silent no-op where a message belongs. Point 1 above is what turns half a day of searching into one line of output.

[maliming]

Hi,

Your first two points are covered by the change I prepared. When nothing can be matched, install-local-module reports which package roles the target module has, exits with a non-zero code, and no longer records the module as installed.

The third one isn't. In your case - the packages of a standard module against a target that only has a host.http-api package - there is still no mapping, so the module is not installed; the change only makes that visible instead of reporting a silent success. Adding that mapping is a separate change, since the packages a module may be referenced from differ between a host API, a gateway, an auth server and a Blazor host.

The changes are under review, they are not part of 3.0.10.

Thanks