Skip to content

Installed Chorus Hub fails on first request: System.Diagnostics.DiagnosticSource.dll not shipped #405

Open

Description

@imnasnainaec

Problem

An installed Chorus Hub fails on the first client request. ChorusHub.wxs doesn't ship System.Diagnostics.DiagnosticSource.dll, which LibChorus has required since tracing was added in #360 (af6e5c0).

The service starts normally. The first WCF call faults:

GetRepositoryInformation FAILED: FaultException`1: Could not load file or assembly
'System.Diagnostics.DiagnosticSource, Version=9.0.0.2, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies.

The channel is then faulted, so every later call fails too.

No release contains #360 yet, so no shipped installer is affected.

Why CI doesn't catch it

ChorusHubTests run from the full build output folder, which contains every dependency. Nothing tests the installer's file set.

How it was found

While reviewing #404, the hub was run with only the files the installer ships:

  1. Copy those files into an empty folder, with no ChorusHub.exe.config, as installed.
  2. A small harness starts ChorusHubServer with hg serve.
  3. It calls each IChorusHubService operation against a real repo.
  4. Whenever a file fails to load, add it from the build output and repeat.

The results:

Build Files the installer is missing
master (libpalaso 18.0.0-beta0046) System.Diagnostics.DiagnosticSource
#404 System.Diagnostics.DiagnosticSource

With that one file added, every operation succeeds in both.

Suggested fix

  • Add a System.Diagnostics.DiagnosticSource.dll component to src/Installer/ChorusHub.wxs.
  • Also consider adding its net462 dependencies, System.Memory and System.Runtime.CompilerServices.Unsafe. The probe never loaded them, but tracing paths the probe didn't exercise may.

Related

  • Missing config file: the installer doesn't ship ChorusHub.exe.config, so the build's binding redirects (System.Resources.Extensions, System.Memory, System.Buffers, System.Runtime.CompilerServices.Unsafe) are absent in an installed hub. That didn't cause a failure in the probe, but it could once one of those assemblies loads.
  • Possible follow-up: a CI smoke test that runs the hub from the installer's file set would catch this kind of gap.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions