Catel (https://github.com/catel/catel) is an application development platform with the focus on MVVM (WPF). The goal of Catel is to provide a complete set of modular functionality for Line of Business applications written in any .NET technology, from client to server.
Catel.Fody is a Fody add-in that provides Catel specific post compilation IL weaving.
These rules are non-negotiable. Violating them causes broken builds, crashes, or downstream breakage.
Files matching *.generated.cs, *.generated.xaml are auto-generated.
- NEVER manually edit these files
This project maintains stable ABI / API. Breaking changes break downstream apps.
| Allowed | Never |
|---|---|
| Add new overloads | Modify existing signatures |
| Add new methods | Remove public APIs |
| Add new classes | Change return types |
Building alone is NOT sufficient. Run tests before claiming completion (see Commands).
Direct commits to protected branches are a policy violation.
| Protected Branches |
|---|
master |
develop |
Required workflow:
- Create a feature branch FIRST — Use naming convention:
feature/issue-NNNN-description - Make all commits on the feature branch — Never commit directly to protected branches
- Submit a Pull Request — Changes must be reviewed by a human before merging
# CORRECT — Always create a feature branch first
git checkout -b feature/issue-1234-fix-description
# NEVER DO THIS — Policy violation
git checkout develop && git commit # FORBIDDEN
# NEVER DO THIS — Policy violation
git checkout master && git commit # FORBIDDENThe repository has protected branches that must be respected.
Single source of truth for all commands:
| Task | Command |
|---|---|
| Build | dotnet cake --target=build |
| Test | dotnet cake --target=test |
| Build and test | dotnet cake --target=buildandtest |
Catel.Fody => Source code for the Fody weaver
Catel.Fody.Attributes => Attributes assembly referenced by the component that uses Catel.Fody for specific features
| Directory | Editable? | Notes |
|---|---|---|
*.generated.cs |
No | Leave as-is |
*.generated.xaml |
No | Leave as-is |
deployment |
No | Deployment / build scripts |
doc/dev/ |
Yes | Architecture guides |
doc/docfx/releases/ |
Yes | Website release notes (template-formatted) |
doc/docfx/releases/TEMPLATE.md |
Yes | Template for AI formatting |
| Anti-Pattern | Why |
|---|---|
| Modifying method signatures | ABI breaking |
Manual edits to *.generated.cs, *.generated.xaml |
Overwritten on regenerate |
| Using default parameters in public APIs | ABI breaking |
| Skipping failing tests | Unacceptable — tests must pass |
dotnet cake --target=testNON-NEGOTIABLE: Tests must PASS before claiming completion.
- Do NOT skip failing tests
- Do NOT claim completion if tests fail
- Do NOT use
SkipExceptionto work around failures
- Use NUnit to write tests
- Create a Facts class for a feature
- Combine Pascal / Snake case for test methods (e.g.
Feature_Does_Work)
[Test]
public void Feature_Does_Work()
{
var result = 47 - 5;
Assert.That(result, Is.EqualTo(42));
}Philosophy: Tests FAIL when wrong, never skip (except missing hardware).
- Establish baseline — What's the known-good state?
- One change at a time — Verify each change before proceeding
- Track changes in a table — Log what you changed and the result
- Platform differences are signals — If X works and Y fails, the difference IS the answer
- Revert if worse — Don't pile fixes on top of failures
| Topic | Document |
|---|