Merge pull request #3 from joeloudjinz/dev

v0.9.1

Author: joeloudjinz

Documentations/Directory.Build.targets Documentation.md

@@ -120,14 +120,7 @@ Projects must define `IsModuleProject=true` to utilize the module-specific funct
 
 ## Implementation Notes
 
-### Assembly Loading Considerations
-The `CopyLocalLockFileAssemblies` property is crucial for plugin architecture because:
-- It ensures all transitive dependencies are available in the local directory
-- The `AssemblyDependencyResolver` can properly locate dependencies when loading modules at runtime
-- Without this setting, module loading may fail due to missing dependency references
-
 ### Build Performance Tips
-- Use `SkipUnchangedFiles="true"` to minimize deployment overhead
 - Consider using this only for actual module projects (with `IsModuleProject=true`)
 - Monitor build times when adding new module projects to the solution
 

Documentations/Directory.Packages.props Documentation.md

@@ -1,6 +1,7 @@
 # Directory.Packages.props Documentation
 
 ## Table of Contents
+
 - [Overview](#overview)
 - [File Type and Purpose](#file-type-and-purpose)
 - [Detailed Logic Analysis](#detailed-logic-analysis)
@@ -11,75 +12,89 @@
 
 ## Overview
 
-The `Directory.Packages.props` file is a MSBuild properties file that enables Central Package Management (CPM) across all projects in the HexInz solution. This file specifically addresses the "Diamond Dependency" problem by defining package versions in a single location, ensuring version consistency across all modules and projects.
+The `Directory.Packages.props` file is a MSBuild properties file that enables Central Package Management (CPM) across all projects in the
+solution. This file specifically addresses the "Diamond Dependency" problem by defining package versions in a single location, ensuring version
+consistency across all modules and projects.
 
 ## File Type and Purpose
 
 **File Type**: MSBuild properties file (XML-based)
 
 **Purpose**:
+
 - Implements Central Package Management (CPM) for the entire solution
 - Prevents the "Diamond Dependency" problem in plugin architectures
 - Defines package versions in a single, centralized location
 - Ensures consistent dependency versions across all projects
 
-The file leverages MSBuild's hierarchical property system to apply package version management automatically to all projects in subdirectories, eliminating the need to specify versions in individual project files.
+The file leverages MSBuild's hierarchical property system to apply package version management automatically to all projects in subdirectories,
+eliminating the need to specify versions in individual project files.
 
 ## Detailed Logic Analysis
 
 ### Central Package Management Enablement
+
 ```xml
 <PropertyGroup>
     <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
 </PropertyGroup>
 ```
 
 **Logic**:
+
 - Enables the Central Package Management feature introduced in .NET 6
 - Forces all projects to inherit package versions from this central file
 - Prevents individual projects from specifying their own package versions
 - Creates a single source of truth for package versions across the solution
 
 ### Package Version Definitions
+
 ```xml
 <ItemGroup>
     <PackageVersion Include="PackageName" Version="X.Y.Z"/>
 </ItemGroup>
 ```
 
 **Logic**:
+
 - Defines package versions that will be applied to all projects referencing these packages
 - Organized into logical groups (Core Dependencies, Third Party Dependencies, Test)
 - Each package version is defined once and inherited by all projects in the solution
 - Specific version numbers ensure compatibility and prevent conflicts
 
 ### Diamond Dependency Problem Mitigation
+
 The file specifically addresses:
+
 - **Scenario**: Module A uses Newtonsoft.Json v13 while Module B uses Newtonsoft.Json v9
 - **Result**: The first loaded module's version wins, causing MethodNotFoundException at runtime for the second module
 - **Solution**: Enforces strict version alignment across all modules through centralized version management
 
 ## Benefits of Using Directory.Packages.props
 
 ### Dependency Conflict Prevention
+
 - **Version Consistency**: All projects use the same version of each package
 - **Diamond Dependency Resolution**: Eliminates version conflicts in plugin architectures
 - **Runtime Stability**: Prevents MethodNotFoundException and other version-related crashes
 - **Predictable Behavior**: Modules are guaranteed to work with compatible dependency versions
 
 ### Centralized Management
+
 - **Single Point of Control**: Update package versions in one file to affect the entire solution
 - **Reduced Redundancy**: No need to specify versions in individual project files
 - **Easier Updates**: Version updates apply to all projects simultaneously
 - **Audit Trail**: All package versions visible in one location
 
 ### Solution-Wide Consistency
+
 - **Uniform Dependencies**: All projects use the same package versions
 - **Simplified Maintenance**: Package updates affect the entire solution consistently
 - **Developer Experience**: No need to remember to update versions across multiple files
 - **Build Reliability**: Eliminates version conflicts during builds
 
 ### Plugin Architecture Support
+
 - **Module Compatibility**: Ensures all modules use compatible dependency versions
 - **Assembly Loading**: Prevents conflicts when modules are loaded at runtime
 - **Dependency Resolution**: Supports reliable plugin loading and execution
@@ -88,18 +103,21 @@ The file specifically addresses:
 ## Drawbacks and Considerations
 
 ### Version Lock-in
+
 - **Limited Flexibility**: Projects cannot use different versions of the same package
 - **Upgrade Challenges**: Some packages may break when upgraded simultaneously across all projects
 - **Dependency Constraints**: May force upgrades on dependencies not ready for newer versions
 - **Risk of Breaking Changes**: A single package update affects the entire solution
 
 ### Maintenance Overhead
+
 - **Coordination Required**: All team members must be aware of the central package management
 - **Testing Burden**: Package updates require testing across all projects
 - **Update Planning**: Careful planning needed when updating package versions
 - **Conflict Resolution**: May need to resolve package conflicts when integrating new libraries
 
 ### Potential Compatibility Issues
+
 - **Breaking Changes**: New package versions may introduce breaking changes across multiple projects
 - **API Incompatibility**: Some projects might need older versions of certain packages
 - **Upgrade Dependencies**: Complex dependency trees may be difficult to update simultaneously
@@ -108,25 +126,31 @@ The file specifically addresses:
 ## Implementation Notes
 
 ### Required Project Configuration
+
 Projects must not specify package versions explicitly when using this central file:
+
 ```xml
 <PackageReference Include="PackageName" />
 ```
+
 The version is automatically inherited from Directory.Packages.props.
 
 ### Version Update Strategy
+
 - Thoroughly test all projects after updating package versions
 - Consider the impact on module compatibility in plugin architecture
 - Plan updates to minimize breaking changes across projects
 - Monitor for any conflicts introduced by updated dependencies
 
 ### Best Practices
+
 - Keep package versions aligned with the .NET version being used (e.g., v9.0.0 packages with .NET 9.0)
 - Group related packages together for easier updates
 - Add comments for packages that require specific version constraints
 - Regularly review and update packages to maintain security and functionality
 
 ### Troubleshooting Common Issues
+
 - **Version Conflicts**: Verify all projects are using the central package management
 - **Missing Dependencies**: Check that packages are defined in Directory.Packages.props
 - **Build Failures**: Ensure all required packages are properly versioned in the central file

InzDynamicModuleLoader.Core/InzDynamicModuleLoader.Core.csproj

@@ -6,9 +6,9 @@
         <Nullable>enable</Nullable>
 
         <PackageId>InzSoftwares.NetDynamicModuleLoader</PackageId>
-        <Version>0.9.0</Version>
-        <AssemblyVersion>0.9.0.0</AssemblyVersion>
-        <FileVersion>0.9.0.0</FileVersion>
+        <Version>0.9.1</Version>
+        <AssemblyVersion>0.9.1.0</AssemblyVersion>
+        <FileVersion>0.9.1.0</FileVersion>
         <Authors>Abdellah Addoun</Authors>
         <Company>InzSoftwares</Company>
         <Product>InzSoftwares.NetDynamicModuleLoader</Product>

InzDynamicModuleLoader.Core/README.md

@@ -83,7 +83,7 @@ This configuration ensures each dynamically loaded module includes all its depen
 dedicated `BuiltModules` directory in the solution directory where each dynamically loaded module's dependencies can be found and resolved correctly.
 
 For more details about this file and its purpose, see
-the [Directory.Build.targets Documentation](../Documentations/Directory.Build.targets%20Documentation.md).
+the [Directory.Build.targets Documentation](https://github.com/joeloudjinz/InzDynamicModuleLoader/blob/main/Documentations/Directory.Build.targets%20Documentation.md).
 
 ### 3. Create a Module Project
 
@@ -227,7 +227,7 @@ When using this approach, reference packages without specifying versions in your
 ```
 
 For more information about this file and its content, see
-the [Directory.Packages.props Documentation](../Documentations/Directory.Packages.props%20Documentation.md).
+the [Directory.Packages.props Documentation](https://github.com/joeloudjinz/InzDynamicModuleLoader/blob/main/Documentations/Directory.Packages.props%20Documentation.md).
 
 ## IAmModule Interface Explained
 
@@ -244,7 +244,7 @@ showcases a real-world scenario where database infrastructure can be switched at
 This architecture demonstrates how to build flexible applications where infrastructure concerns can be swapped out dynamically, maintaining clean
 separation of concerns while enabling maximum flexibility.
 
-For step-by-step instructions on how to run and understand the example, see the [Example Breakdown](../Documentations/Example%20Breakdown.md)
+For step-by-step instructions on how to run and understand the example, see the [Example Breakdown](https://github.com/joeloudjinz/InzDynamicModuleLoader/blob/main/Documentations/Example%20Breakdown.md)
 documentation.
 
 ## Troubleshooting

README.md

@@ -83,7 +83,7 @@ This configuration ensures each dynamically loaded module includes all its depen
 dedicated `BuiltModules` directory in the solution directory where each dynamically loaded module's dependencies can be found and resolved correctly.
 
 For more details about this file and its purpose, see
-the [Directory.Build.targets Documentation](../Documentations/Directory.Build.targets%20Documentation.md).
+the [Directory.Build.targets Documentation](https://github.com/joeloudjinz/InzDynamicModuleLoader/blob/main/Documentations/Directory.Build.targets%20Documentation.md).
 
 ### 3. Create a Module Project
 
@@ -226,7 +226,7 @@ When using this approach, reference packages without specifying versions in your
 <PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions"/>
 ```
 
-For more information about this file and its content, see the [Directory.Packages.props Documentation](../Documentations/Directory.Packages.props%20Documentation.md).
+For more information about this file and its content, see the [Directory.Packages.props Documentation](https://github.com/joeloudjinz/InzDynamicModuleLoader/blob/main/Documentations/Directory.Packages.props%20Documentation.md).
 
 ## IAmModule Interface Explained