Skip to main content

Pattern: Shared Library (Nugetization)

Description​

The Shared Library pattern involves extracting reusable business logic, utilities, or contracts from the Monolithic application into separate Class Library projects that are then packaged and distributed as NuGet Packages.

In the context of WepNG, this is the primary strategy for sharing the Kernel between the Legacy Monolith and the New Microservices.

Context in WepNG​

  • Candidates: Common, EITWEP.WepUtils, EITWEP.Model (DTOs only).
  • Strategy: Instead of referencing projects by File Path (..\EITWEP.Common\EITWEP.Common.csproj), we publish EITWEP.Common to an internal NuGet feed (Azure Artifacts / GitHub Packages) and reference it by version (e.g., 1.0.4).

Benefits​

  1. Versioned Contract: The Monolith can run on v1.2 while the new Service tests v2.0.
  2. Decoupling: Forces "Physical Separation". You cannot accidentally call a method in OMGT from Common if Common is a compiled NuGet package.
  3. Reuse: Enables new .NET 8 Apps to use existing logic without duplicating code.

Risks​

  1. DLL Hell: Managing transitive dependencies (e.g., Common depends on Newtonsoft v10 but WepAPI needs v13).
  2. Development Friction: Changing a shared library requires: Code -> Commit -> Build -> Push NuGet -> Update Package in Main App.
    • Mitigation: Use "Project References" locally during development, switch to NuGet for Release.