Project 8: Side-by-Side Assembly (SxS) Demo

A solution to the classic “DLL Hell.” You’ll create two distinct versions of a DLL (e.g., version_lib.dll v1.0 and v2.0), each exporting the same function that returns a different version string. You will then build an executable that uses a manifest file to explicitly load and call the v1.0 DLL, even when v2.0 is in the same directory.

Quick Reference

Attribute Value
Primary Language C++
Alternative Languages C
Difficulty Level 3: Advanced
Time Estimate 1-2 weeks
Knowledge Area Deployment / OS Internals
Tooling Manifest files, SxS
Prerequisites Project 3, understanding of DLLs (how to create and export functions).

What You Will Build

A solution to the classic “DLL Hell.” You’ll create two distinct versions of a DLL (e.g., version_lib.dll v1.0 and v2.0), each exporting the same function that returns a different version string. You will then build an executable that uses a manifest file to explicitly load and call the v1.0 DLL, even when v2.0 is in the same directory.

Why It Matters

This project builds core skills that appear repeatedly in real-world systems and tooling.

Core Challenges

  • Creating application and assembly manifests → maps to writing the XML files that describe the application and its dependencies
  • Embedding a manifest into an executable → maps to using the mt.exe tool or linker settings (/MANIFEST)
  • Structuring the files correctly → maps to creating the specific directory layout that the SxS loader expects
  • Debugging loader issues → maps to using the Event Viewer’s “Application” log to diagnose manifest and SxS problems

Key Concepts

Real-World Outcome

/my_app/
  my_app.exe
  /MyOrg.MyLib.v1/
    version_lib.dll  (v1.0)
    MyOrg.MyLib.v1.manifest
  /MyOrg.MyLib.v2/
    version_lib.dll  (v2.0)
    MyOrg.MyLib.v2.manifest

> ./my_app.exe
Library version: 1.0.0.0

Implementation Guide

  1. Reproduce the simplest happy-path scenario.
  2. Build the smallest working version of the core feature.
  3. Add input validation and error handling.
  4. Add instrumentation/logging to confirm behavior.
  5. Refactor into clean modules with tests.

Milestones

  • Milestone 1: Minimal working program that runs end-to-end.
  • Milestone 2: Correct outputs for typical inputs.
  • Milestone 3: Robust handling of edge cases.
  • Milestone 4: Clean structure and documented usage.

Validation Checklist

  • Output matches the real-world outcome example
  • Handles invalid inputs safely
  • Provides clear errors and exit codes
  • Repeatable results across runs

References

  • Main guide: LEARN_WINDOWS_SYSTEMS_PROGRAMMING_CPP.md
  • “Advanced Windows Debugging” by Hewardt and Pravat (for context on loader issues)