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.SourceGenerators provides Roslyn source generators that help generate boilerplate code such as dependency injection for XAML controls.
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.SourceGenerators => Source code for the Roslyn source generators
| 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 |
|---|