Chapter 54 Components and CNA Integration

The runtime has 41 module directories, but those directories register 44 components. The registry produces the shape in Table 54.1.

Two extra names explain why a directory count cannot predict the component count. Core and Collections are compatibility umbrellas over narrower components, and Xml.XPath is the alias. The remaining names cover families such as Core.Base, Collections.Core, IO, Text.Json, Threading.Tasks, and Net.WebSockets. Consumers link the namespaced form, for example SharpRuntime::Core.Base, rather than guessing an archive filename.

The module CMake files do not each call add_library directly. They register their kind, dependencies, include directory, and optional test dependencies with a common registry. The registry later materializes targets in a consistent order. Production sources and module tests are globbed within the registered directory, while a source-partition validator and an empty dependency allowlist make accidental ownership leaks visible. The generated component catalogue measures 92 direct production dependency edges at the pin; this edge count is distinct from both the 41 physical modules and 44 selectable/compatibility names.

There is no SharpRuntime.hpp. If ported code needs System::IO::MemoryStream, it includes System/IO/MemoryStream.hpp; the IO component owns that public include directory. The component can in turn expose public dependencies needed by the header. Consequently, a consumer names its direct component and lets CMake propagate the remainder.

CNA directly includes 54 distinct sharp-runtime headers: 52 below System/ and two below SharpRuntime/. The latter count must not be misread as the total dependency. SharpRuntime/SharpRuntimeHelper.hpp supplies primitive aliases, while SharpRuntime/Prop.hpp supplies downstream property macros. Both belong to Core.Base; headers such as System/IO/BinaryWriter.hpp and System/Security/Cryptography/SHA256.hpp introduce other component needs.

When sharp-runtime is the top-level CMake project, it exposes SHARP_RUNTIME_COMPONENTS. A developer may select a subset, or leave the default All. The compatibility SHARP_RUNTIME interface target exists only for that complete selection; a deliberately partial build should use namespaced component targets.

That cache option is created only when the runtime is the top-level project. CNA adds the runtime with add_subdirectory, so the option is not created and selection falls through to All. Every component is therefore available in a normal CNA build. CNA’s narrow component lists reduce each target’s link interface; at this revision they do not prevent unrelated runtime components from being configured and compiled.

This distinction prevents two opposite mistakes:

• •

  a narrow CNA declaration is meaningful because it documents and enforces the target’s link boundary;

• •

  it is not yet a build-time pruning mechanism for the embedded sibling.

Sharp-runtime is CNA’s one unconditional sibling dependency. CNA first forces SHARP_RUNTIME_BUILD_TESTS off; otherwise embedding it would add 37 runtime test executables to every CNA build. It then resolves CNA_SHARP_RUNTIME_ROOT, whose default is the adjacent ../sharp-runtime checkout. A missing CMakeLists.txt is a configure-time fatal error with a clone remedy. There is no submodule, vendored copy, FetchContent fallback, or reduced internal substitute.

After add_subdirectory, CNA loads its 59-line SharpRuntimeConsumption.cmake adapter. The adapter recognizes two historical build shapes:

Modular

SharpRuntime::Core.Base exists, so requested component names are translated to namespaced targets. This is the authoritative shape for the audited siblings.

Monolithic

That target does not exist, so CNA links the legacy SHARP_RUNTIME archive. This is a compatibility path for older checkouts, not the architecture of current sharp-runtime.

The detection intentionally tests a target rather than a version string. That makes the seam describe the capability CNA needs and avoids teaching CNA the runtime’s release-numbering history.

Every CNA module calls cna_link_sharp_runtime(target visibility [Components...]). In a modular checkout, the helper prefixes each supplied name with SharpRuntime::; in a legacy checkout it falls back to the single archive. Omitting the optional names uses CNA’s default closure:

That list is not every transitive component. Dependencies such as Uri, TimeZone, ComponentModel, and Buffers arrive through the public edges of the named targets. Repeating the transitive closure in CNA would duplicate the runtime registry and make upgrades more fragile.

Eighteen CNA module call sites declare their own closure. Small modules can be genuinely narrow: math and input request only Core.Base. Graphics requests Core.Base, IO, Collections.Core, and Text. Networking adds Runtime and Threading; gamer services additionally needs Globalization. The renderer aggregation target uses the default closure because it spans more of the framework.

The helper is therefore more than syntactic convenience. It lets present-day modules state precise boundaries while retaining a controlled path to old sibling checkouts.

The modular test layout is part of the boundary design. Each component with tests gets a SharpRuntimeTests_<component> executable linked only to its component, gtest_main, and explicitly declared test-only dependencies. GoogleTest discovery adds the component name as a prefix. A test that accidentally reaches into an undeclared component can consequently fail to link; the old monolithic test executable could have masked the same dependency.

Thirty-six components currently contribute such an executable, and a separate integration executable brings the total to 37. Five module directories have no component tests: io-compression-zip, io-isolated-storage, security-cryptography-random, storage, and text-regular-expressions. The last is a 12-header interface component with no implementation and no tests, a concrete coverage gap rather than an implied success.

Outside GoogleTest, Python meta-tests validate boundaries and consumer fixtures exercise both positive and intentionally failing configurations. A negative fixture is successful when a forbidden dependency fails to compile or link; treating every non-zero compiler exit as a CI failure would invert the purpose of that test.

The safe upgrade procedure follows directly from the architecture:

1. 1.

   pin and identify both CNA and sharp-runtime revisions;

2. 2.

   configure through CNA_SHARP_RUNTIME_ROOT rather than moving sibling directories to satisfy a hidden assumption;

3. 3.

   confirm the shape-detection message and inspect unexpected fallbacks to the monolith;

4. 4.

   keep each CNA module’s direct component list narrow and let public dependencies close transitively;

5. 5.

   run runtime boundary fixtures when the registry changes, then run CNA’s normal build and tests with runtime tests still disabled in the embedded build;

6. 6.

   distinguish “all components were built” from “this CNA target links only its declared closure” in any verification report.

The final rule is the most important. Modularity has two observable layers here: what the parent configures and what an individual target consumes. At the audited revision CNA gets all 44 components from its sibling, but its module targets no longer pretend that they need all 44. That narrower declaration is the durable integration contract on which later build-time pruning can be based.