Welcome to Metalama, a Roslyn-based framework for code generation and validation, designed to enhance your code quality and productivity in C#. Metalama stands on three foundational principles:

• Boilerplate Reduction: Harness the power of aspect-oriented programming to dynamically generate repetitive code during compilation. This ensures your source code stays concise and clear.
• Architecture as Code: Receive real-time validation of your code against your architectural guidelines, patterns, and conventions. Say goodbye to waiting for code reviews.
• Tailored Coding Assistance: Arm your team with personalized code fixes and refactorings.

• 🌐 Metalama Website
• 📖 Documentation
• 📝 Annotated Examples
• 🎥 Tutorial Videos
• 🐞 Bug Reports
• 💬 Discussions
• 📜 Detailed Changelog
• 📢 Release Notes
• ✨ Visual Studio Extension

Here is a graph of the dependencies between the principal packages in this repository:

flowchart LR
    
Metalama.Compiler --> Metalama.Framework

subgraph Metalama repository
Metalama.Backstage --> Metalama.Framework
Metalama.Framework --> Metalama.Extensions
Metalama.Extensions --> Metalama.Migration
Metalama.Framework --> Metalama.LinqPad
Metalama.Extensions --> Metalama.Patterns
end

Metalama.Extensions --> Metalama.Samples
Metalama.Framework --> Metalama.Community
Metalama.Migration --> Metalama.Documentation
Metalama.Samples --> Metalama.Documentation
Metalama.Patterns --> Metalama.Documentation

Metalama.Framework --> Metalama.Premium

This repository contains several components that compose the main parts of Metalama.

There are also other supporting repositories:

To build Metalama, you will need:

• Windows
• PowerShell
• .NET SDK (see the exact version in global.json).

To build Metalama, execute this script from PowerShell:

./Build.ps1 build

The packages are then placed into the artifacts/publish/private directory.

This command creates development builds, designed to be consumed on your development machine only. Every time you call Build.ps1 build, a new package version is created.

To use a local build in a project:

1. Add the following code to your Directory.Build.props:

   <Import Path="path/to/Metalama/Metalama.Imports.props">
   

2. Use $(MetalamaVersion) property to reference the version number of any package produced by this repo:

   <PackageReference Include="Metalama.Framework" Version="$(MetalamaVersion)"/>

3. Do a dotnet restore every time you complete a new local build.

Execute this script from PowerShell:

./Build.ps1 test

We use Docker as a reference build environment, to make sure that all dependencies are made very explicit.

The Metalama build requires .NET Framework, which requires a Windows Server Core image.

Follow these steps:

1. Switch to Windows containers.

2. Create the artifacts directory:

   md artifacts

3. Create the build-metalama image:

   docker build . -t build-metalama  

4. Run the build:

   docker run -v ".\artifacts:c:/src/artifacts" build-metalama pwsh ./Build.ps1 build

The packages are then placed into the artifacts/publish/private directory.

• We don't use the master nor the main branch.
• We are generally concurrently working on three versions, numbered YYYY.N. Typically, one is stable and maintained, the other is rc and the third is preview.
• You should generally check out the release/YYYY.N branch.
• Our continuous integration branches are develop/YYYY.N. They generally depend on unpublished build artifacts of dependencies and therefore cannot be easily built by the public except by building the dependencies locally. Our develop/YYYY.N builds can occasionally be broken.
• When we publish artifacts (for instance to nuget.org):
  • We update the version of package references to the ones just uploaded to nuget.org.
  • We mark the released commit with the precise package version, e.g. /release/2023.4.1-preview.
  • We merge the develop/YYYY.N branch into release/YYYY.N.
• We work on branches named topic/YYYY.N/whatever and generally do PRs to develop/YYYY.N.
• After any merge to an "old" develop/YYYY.N, the "old" develop/YYYY.N is automatically merged into the newer develop/YYYY.N+1. A merge commit, named merge/YYYY.N+1/commit-123456 is automatically created, tested, if possible merged, then deleted.
• We use a private TeamCity service for our continuous integration.

The following schema illustrates our workflow. It shows two public builds, 2023.4.1-preview and 2023.4.2-preview, each including two bug fixes.

%%{init: { 'gitGraph': { 'mainBranchName':'develop/2023.4', 'mainBranchOrder': 1, 'showCommitLabel': false }} }%%

gitGraph:
    commit
    branch release/2023.4 order:0
    branch topic/2023.4/1234-bug-1 order:1
    checkout topic/2023.4/1234-bug-1
    commit
    commit
    checkout develop/2023.4
    merge topic/2023.4/1234-bug-1
    branch topic/2023.4/1235-bug-2  order:2
    checkout topic/2023.4/1235-bug-2
    commit
    commit
    checkout develop/2023.4
    merge topic/2023.4/1235-bug-2 tag:"release/2023.4.1-preview" type:HIGHLIGHT
    checkout release/2023.4
    commit 
    merge develop/2023.4
    branch topic/2023.4/1236-bug-3 order:3
    checkout topic/2023.4/1236-bug-3
    commit
    commit
    checkout develop/2023.4
    merge topic/2023.4/1236-bug-3
    branch topic/2023.4/1237-bug-4 order:4
    checkout topic/2023.4/1237-bug-4
    commit
    commit
    checkout develop/2023.4
    merge topic/2023.4/1237-bug-4 tag:"release/2023.4.2-preview" type:HIGHLIGHT
    checkout release/2023.4
    merge develop/2023.4
    
commit