Skip to content

SCMU does not set ServiceControlQueueAddress when only adding audit instances bug fix#5637

Open
cquirosj wants to merge 7 commits into
masterfrom
SCMU-4753-bug-fix
Open

SCMU does not set ServiceControlQueueAddress when only adding audit instances bug fix#5637
cquirosj wants to merge 7 commits into
masterfrom
SCMU-4753-bug-fix

Conversation

@cquirosj

Copy link
Copy Markdown
Contributor

Feature: Audit Instance ServiceControl Queue Address

As an operator adding instances through ServiceControl Management Utility (SCMU), I want every audit instance to be connected to a ServiceControl (error) instance so that messages the audit instance sends to the error instance always have a valid destination.

Bug: #4753 — SCMU does not set ServiceControlQueueAddress when only adding audit instances.
When the ServiceControl.Audit/ServiceControlQueueAddress setting is missing from
ServiceControl.Audit.exe.config, the audit instance fails at runtime with
"no destination specified for message".

Rules and Examples

Rule 1: Must address the audit instance to the error instance installed in the same session

When the user installs an error instance and an audit instance together, the audit
instance's queue address is the name of the error instance being installed — never an
already-installed one.

  • Example: The one where both instances are installed together and the audit
    instance's queue address is the new error instance's name.
  • Counter-example: The one where other error instances already exist on the
    machine, yet no choice is offered — the error instance being installed always wins.

Rule 2: Should auto-detect the existing error instance when adding an audit instance alone

  • Example: The one where exactly one error instance exists on the machine and its
    name is used as the queue address without any user input (no dropdown shown).

Rule 3: Must require an explicit choice when multiple existing error instances are found

Auto-detection cannot guess between several error instances — picking one silently
risks routing messages to the wrong instance. The choice dropdown is shown only in
this case.

  • Example: The one where two error instances exist and the dropdown offers both.
  • Example: The one where Save is blocked until the user picks one of the detected
    instances, and unblocked once a choice is made.

Rule 4: Must block installation when no error instance exists to connect to

An audit instance without a reachable error instance is misconfigured by definition;
SCMU must not produce it.

  • Example: The one where no error instance exists, the user adds an audit instance
    alone, and a validation error prevents the installation from proceeding.
  • Counter-example: The one where only an error instance is being installed — the
    queue address does not apply and no validation error is raised.

Resolved decisions (for implementation)

  • Auto-detect source: installed Windows error instances, discovered via
    InstanceFinder.ServiceControlInstances(); exposed on the view model through a
    GetInstalledErrorInstanceNames function seam (mirrors the existing
    GetWindowsServiceNames pattern) so tests can substitute it.
  • Multiple instances found: user must choose from a dropdown that is visible only
    when adding an audit instance alone and more than one error instance is detected.
  • No instance found: Save is blocked by a validation error; deploying with
    PowerShell remains the path for advanced scenarios.
  • Acceptance tier: view model + validator observed through INotifyDataErrorInfo
    — the same mechanism the UI uses to block Save. A full SCMU end-to-end test (install
    a Windows service, inspect the written config file) is not automatable in this
    repository's test suites.
  • Out of scope: registering the new audit instance as a remote of the existing
    error instance (AddRemoteInstance is only called when both instances are installed
    together) — candidate for a follow-up issue.

cquirosj and others added 7 commits July 21, 2026 17:51
Covers issue #4753, where SCMU does not set
ServiceControl.Audit/ServiceControlQueueAddress when only adding an audit
instance. The tests describe the expected behavior of
ServiceControlAddViewModel:

- Error + audit installed together: the queue address is the name of the
  error instance being installed, and no selection dropdown is shown.
- Audit only with a single existing error instance: the address is
  auto-detected from it, no dropdown.
- Audit only with multiple existing error instances: the dropdown is
  shown with all of them and Save is blocked until one is picked.
- Audit only with no existing error instance: Save is blocked by a
  validation error.
- Error instance only: no queue address validation error.
Replaces the initial ServiceControlQueueAddressTests with an executable
specification organized as feature > rule > examples, mirroring the new
docs/specs/audit-instance-servicecontrol-queue-address.md.

The spec captures the four rules for bug #4753 (SCMU does not set
ServiceControl.Audit/ServiceControlQueueAddress when only adding an audit
instance): the instance installed in the same session always wins,
auto-detect when exactly one error instance exists, require an explicit
choice when several exist, and block Save when none exist.

These are outer-loop TDD tests and reference members that do not exist
yet: GetInstalledErrorInstanceNames, ServiceControlQueueAddress,
ServiceControlQueueAddressOptions, ShowServiceControlQueueAddressSelection.
… same session

ServiceControlQueueAddress resolves to ErrorInstanceName when an error
instance is being installed. Adds the GetInstalledErrorInstanceNames seam
(mirrors GetWindowsServiceNames) and naive stubs for the members Rules 2-4
will drive. Suppresses IDE0017 in the test project: executable specs assign
properties after construction to mirror user interaction order.
…instance alone

When no error instance is being installed and exactly one is detected on
the machine, its name is used as the queue address without user input.
…ock when none exist

The dropdown options and its visibility (audit-only + 2 or more detected)
come from the installed-instance seam. A NotEmpty validation rule on
ServiceControlQueueAddress blocks Save for audit-only adds until an address
resolves - covering both the multiple-instances case (until the user picks)
and the none-found case. Error-only installs are exempt.
The attachment writes viewModel.ServiceControlQueueAddress instead of the
null-conditional expression that produced an empty string for audit-only
adds - the root cause of #4753, since empty values are silently skipped
when writing the config file. The audit section gets a ComboBox (visible
only when multiple error instances are detected) and a warning for the
none-found case. Explicit change notifications are raised for the derived
computed properties because the install checkboxes live on the base class,
outside Fody's dependency analysis.
The constructor runs the name-uniquing convention against the machine's
real Windows services before tests can substitute the GetWindowsServiceNames
property seam, so screen-loaded tests asserting convention-derived paths
failed on any machine with actual ServiceControl instances installed. An
optional constructor parameter lets those tests inject a fake service list;
Autofac supplies the default (real) implementation in production since the
parameter is unresolvable and optional.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant