Codebasis als Dateien ins Arbeitsrepo statt als Gitlink

QuellCode/CentronERP war nur als Gitlink (Submodul-Referenz auf 79c1142)
getrackt, ohne .gitmodules und ohne erreichbares Remote. Der
Untersuchungsgegenstand der Versuchsreihe war damit nicht reproduzierbar
gesichert: Ein Klon haette ein leeres Verzeichnis erhalten, und die Belege
der 3.287 Anforderungen waeren nicht ueberpruefbar gewesen.

Umstellung:
- Historie nach c:\DEV\CentronERP_git_snapshot_79c1142 ausgelagert
  (vollstaendig lesbar, enthaelt 79c1142 und Vorgaenger 89ccfd6)
- Gitlink aus dem Index entfernt
- Dateiinhalt aufgenommen: 24.557 Dateien, rund 333 MB

Die verschachtelte .gitignore der Codebasis gilt weiter, Build-Artefakte
bleiben ausgeschlossen. Details in Versuche/Versuch_01/_Codebasis-Nachweis.md
This commit is contained in:
Christoph Schwörer
2026-08-26 07:43:51 +02:00
parent 18edae75b6
commit f045b99a25
24664 changed files with 5846716 additions and 1 deletions
@@ -0,0 +1,72 @@
# AI and developer navigation (large repository)
This document helps **find code quickly** in a very large solution. It does **not** replace [CLAUDE.md](../../CLAUDE.md) (rules and patterns) or [general-structure.md](general-structure.md) (layering and ILogic details). Use it as a **map**: where to look before running broad searches.
## How this fits other docs
| Need | Primary doc |
|------|-------------|
| Mandatory patterns, Result, dual API, DB, encoding | [CLAUDE.md](../../CLAUDE.md) |
| Layering, ClassContainer, ILogic / BL / WS | [general-structure.md](general-structure.md) |
| Adding REST methods (legacy + modern) | [../guides/services/add-webservice-methods.md](../guides/services/add-webservice-methods.md) |
| MVVM, modules, UI | [../guides/ui/](../guides/ui/) and [../reference/architecture/mvvm-in-centron.md](../reference/architecture/mvvm-in-centron.md) |
## Top-level layout
| Path | Role |
|------|------|
| `src/backend/` | `Centron.BL`, `Centron.DAO`, `Centron.Entities`, `Centron.Interfaces`, `Centron.Common`, `Centron.Gateway` |
| `src/centron/` | WPF client (`Centron.WPF.UI`, `Centron.WPF.UI.Extension`) |
| `src/webservice/` | `Centron.WebServices.Core` (legacy REST), `Centron.Controllers` (ASP.NET Core API), hosts (`Centron.Host*`) |
| `src/nexus/` | Blazor Server portal (`CentronNexus`, hosts, Outlook add-in) |
| `src/apis/` | External integration assemblies (FinAPI, GLS, Shipcloud, ITscope, Icecat, etc.) |
| `src/shared/` | `Centron.Core`, `Centron.Controls`, reusable UI |
| `tests/` | Unit, integration, E2E, API tests, Playwright, Nexus tests |
| `scripts/` | `Centron.Scripts` build orchestration |
| `deployment/` | WiX / installers |
| `.claude/` | Claude Code agents, commands, hooks (not used by Cursor rules) |
Solution file: `Centron.sln` (groups many projects; not every folder under `src/` is listed above—search the `.sln` for exact project names).
## Find code by concern
| You need | Where to look |
|----------|----------------|
| **NHibernate entity** | `src/backend/Centron.Entities/` (namespaces like `Centron.Data.Entities.*`) |
| **FluentNHibernate mapping** | `src/backend/Centron.DAO/Mappings/` (mirrors domain folders, e.g. `Mappings/Accounting/`) |
| **Business logic (BL)** | `src/backend/Centron.BL/` (`*BL.cs`, script methods under `Administration/Scripts/ScriptMethods/Scripts/`) |
| **DAO / queries** | `src/backend/Centron.DAO/` |
| **ILogic interface** | `src/centron/Centron.WPF.UI/Services/Logics/**/I*Logic.cs` |
| **BLLogic / WSLogic** | Same tree: `src/centron/Centron.WPF.UI/Services/Logics/**/BL*Logic.cs`, `WS*Logic.cs` |
| **WebServiceBL + DTO mapping** | `src/backend/Centron.BL/` (often `WebServices/` or domain folders; AutoMapper profiles in `WebServices/ObjectMapperConfiguration/`) |
| **Legacy REST contract** | `src/backend/Centron.Interfaces/` (`ICentronRestService`), implementation `src/webservice/Centron.WebServices.Core/RestService/CentronRestService.cs` |
| **Modern REST controllers** | `src/webservice/Centron.Controllers/Controllers/` (`v1/{Domain}/`, `Unversioned/`) |
| **WPF module registration** | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs` |
| **Application settings IDs** | `src/backend/Centron.Interfaces/Administration/Settings/ApplicationSettingID.cs`, `ApplicationSettingDefinitions.cs` |
| **User rights constants** | `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs` |
**Search tip:** For a feature name (e.g. `Receipt`), search the **interface** name first (`IReceipt*Logic`, `*Receipt*WebServiceBL`, `Receipt*Controller`) to narrow the tree.
## Test projects (targeted runs)
Use `dotnet test Centron.sln` for everything; for **faster feedback** narrow to a project:
| Project path | Typical use |
|--------------|-------------|
| `tests/backend/Centron.Tests.BL` | Business logic unit tests |
| `tests/backend/Centron.Tests.DAO` | DAO / persistence tests |
| `tests/shared/Centron.Tests.Core` | Shared test utilities |
| `tests/Centron.Tests.Integration` | Integration |
| `tests/Centron.Tests.EndToEnd` | E2E |
| `tests/apis/*` | External API wrapper tests |
| `tests/CentronNexusTests` | Blazor portal |
| `tests/PlaywrightTests` | Browser E2E |
Example: `dotnet test tests/backend/Centron.Tests.BL/Centron.Tests.BL.csproj`
## Claude Code vs Cursor
- **`.claude/`** — agents and commands for Claude Code.
- **`.cursor/rules/`** — Cursor project rules; still follow **CLAUDE.md** as the canonical playbook.
Keeping behavioral rules in **one place** ([CLAUDE.md](../../CLAUDE.md)) avoids drift; this file only improves **orientation** in the tree.
@@ -0,0 +1,138 @@
# Documentation Organization and Maintenance
This guide explains how the documentation in the c-entron.NET project is organized and what steps to follow when adding new documentation files or directories.
## Documentation Structure
The project documentation uses a hierarchical directory structure to organize content by topic and purpose:
```
docs/
├── .order # Controls documentation ordering in some documentation viewers
├── README.md # Main navigation and documentation entry point
├── getting-started/ # Beginner guides and introductory material
├── guides/ # Step-by-step instruction guides
│ ├── development/ # Guides for development tasks
│ ├── database/ # Database-related guides
│ ├── ui/ # UI development guides
│ └── services/ # Web services guides
├── reference/ # Reference documentation
│ ├── architecture/ # Architecture specifications
│ ├── database/ # Database reference documentation
│ └── security/ # Security documentation
└── operations/ # Operational procedures and guides
```
### Directory Organization Rules
1. Use **kebab-case** for all documentation file and directory names (lowercase with hyphens)
2. Organize documentation into logical sections based on their purpose and audience
3. Keep documentation files focused on a single topic or task
4. Group related documentation files in appropriate subdirectories
## Adding New Documentation
### Creating a New Documentation File
When adding a new documentation file, follow these steps:
1. **Choose the right location** within the existing structure
2. **Name the file appropriately** using kebab-case (e.g., `how-to-configure-settings.md`)
3. **Create the file** with appropriate content, using Markdown format
4. **Update the README.md navigation file**:
- Open `docs/README.md` in your preferred editor
- Find the appropriate section corresponding to the directory where you added the file
- Add a new entry with a link to your documentation file following the existing pattern
- This step is **mandatory** to ensure discoverability of your documentation
5. **Update the Solution File**:
- Open `Centron.sln` in your preferred editor
- Find the appropriate solution folder section for the directory where you added the file
- Add a reference to your new file in the ProjectSection(SolutionItems)
Example of adding a file reference to the solution:
```
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "getting-started", "getting-started", "{01F71AAA-B574-490A-A241-E905C4E4F358}"
ProjectSection(SolutionItems) = preProject
docs\getting-started\general-structure.md = docs\getting-started\general-structure.md
docs\getting-started\landing-page.md = docs\getting-started\landing-page.md
docs\getting-started\your-new-file.md = docs\getting-started\your-new-file.md
EndProjectSection
EndProject
```
### Creating a New Documentation Directory
When adding a new documentation directory, follow these steps:
1. **Create the physical directory** in the appropriate location
2. **Create any initial documentation files** within the directory
3. **Update the Solution File**:
- Create a new solution folder entry for your directory
- Add references to any files in the directory
- Set up the proper nesting relationship in the NestedProjects section
#### Step 1: Add Solution Folder Entry
Add a new solution folder entry before the `EndGlobal` section:
```
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "your-new-folder", "your-new-folder", "{GENERATE-NEW-GUID}"
ProjectSection(SolutionItems) = preProject
docs\path\to\your-new-folder\file1.md = docs\path\to\your-new-folder\file1.md
EndProjectSection
EndProject
```
**Note:** Generate a new GUID for each new solution folder. You can use tools like Visual Studio's GUID generator or online GUID generators.
#### Step 2: Define the Nesting Relationship
In the `GlobalSection(NestedProjects)` section, add an entry that defines where your new folder belongs in the hierarchy:
```
{GUID-OF-NEW-FOLDER} = {GUID-OF-PARENT-FOLDER}
```
Example:
```
{A1B2C3D4-E5F6-1234-5678-ABCDEF123456} = {2F71ED3A-FF09-4148-BEBA-FE06257EFCE4}
```
## Documentation File Format
1. Use **UTF-8 with BOM encoding** for all documentation files
2. Start with a # heading that clearly describes the content
3. Use proper Markdown formatting for headings, lists, code blocks, etc.
4. Include links to related documentation when appropriate
5. For internal links, use relative paths to other documentation files
## Example: Adding a New Guide
Let's say you want to add a new guide for configuring database connections:
1. Determine the proper location: `docs/guides/database/configure-database-connection.md`
2. Create the file with appropriate content
3. Update `Centron.sln`:
- Find the "database" solution folder under "guides" (GUID: `6DB9540C-9A72-4494-81C3-254BC21214BF`)
- Add your file to its ProjectSection
- Ensure the path is correct relative to the solution file
## Updating Existing Documentation
When updating existing documentation:
1. Maintain the same file encoding (UTF-8 with BOM)
2. Follow the established formatting patterns
3. Check and update any internal references if needed
4. The solution file does not need to be updated if only modifying an existing file
## Best Practices
1. **Keep documentation up-to-date** when the code changes
2. **Use clear, concise language** that is easy for readers to understand
3. **Include examples** where appropriate to illustrate concepts
4. **Use screenshots** for UI-related documentation
5. **Link to external resources** when they provide valuable additional information
Following these guidelines will help maintain a well-organized, easily navigable documentation structure that enhances developer productivity and understanding of the c-entron.NET project.
@@ -0,0 +1,166 @@
# General structure of our c-entron<span>.NET for developers
*Lets get this out of the way first: there are tons of places where this general structure does not apply, places that use more or less layers, places that use the wrong type of object and all other sorts of horrific code. You're welcome to fix this wherever you think it needs to be fixed, but atleast all new code should follow this structure.*
layer|objectype|description
--|--|--
*UI*||*the UI with which the horrifiyng User interacts*
ViewModel|DTO/ViewModel|converting DTOs to ViewModels so they can be interacted with via Bindings or similar
ILogic/BLLogic/WSLogic|DTO|clientside interaction with the DB (BLLogic) or a remote webservice (WSLogic)
ICentronRestService/CentronRestService|DTO|the actual webservice methods that can be called from other apps
WebServiceBL|Entity/DTO|converting entities to DTOs
BL|Entity|interaction with [NHibernate](https://nhibernate.info/) and the database itself
*database*||*the horrifiyng land of the database*
## Client-Side Data Access (WPF UI)
The c-entron.NET WPF client uses a sophisticated data access pattern that supports both direct database access and web service communication through a unified interface system. If the naming guidelines are followed, the client will automatically register the ILogic with the corresponding BLLogic and WSLogic.
### ClassContainer and ILogic Pattern
The client accesses data through the `ClassContainer` singleton using the `ILogic` interface pattern:
```csharp
var result = await ClassContainer
.Instance
.WithInstance((IAccountContractsLogic logic) => logic.GetAccountContracts(filter))
.ThrowIfError();
```
This pattern provides:
- **Dependency injection** through ClassContainer
- **Unified interface** for data access
- **Error handling** with Result<T> pattern
- **Async/await support** for all operations
### Dual Implementation Architecture
**Every module MUST implement both data access methods:**
#### 1. ILogic Interface
Defines the contract for data operations:
```csharp
public interface IAccountContractsLogic
{
Task<Result<IList<AccountContractDTO>>> GetAccountContracts(GetAccountContractsFilter filter);
Task<Result<AccountContractDTO>> SaveAccountContract(AccountContractDTO accountContract);
// ... other methods
}
```
#### 2. BL Implementation (Direct Database Access)
```csharp
public class BLAccountContractsLogic : IAccountContractsLogic
{
private readonly ConnectionInfo _connectionInfo;
public Task<Result<IList<AccountContractDTO>>> GetAccountContracts(GetAccountContractsFilter filter)
{
return Task.Run(() =>
{
using (var session = new BLSession())
{
return session.GetBL<AccountContractWebServiceBL>()
.GetAccountContracts(this._connectionInfo.GetLoggedInUser(), filter);
}
});
}
}
```
#### 3. WS Implementation (Web Service Access)
```csharp
public class WSAccountContractsLogic : IAccountContractsLogic
{
private readonly ICentronWebServiceConnection _connection;
public Task<Result<IList<AccountContractDTO>>> GetAccountContracts(GetAccountContractsFilter filter)
{
return this._connection.CallWebServiceMethodWithListResultAsync(f =>
f.GetAccountContracts(this._connection.GetRequest(filter)));
}
}
```
### Connection Type Support
Modules declare supported connection types in their `AppModuleController`:
```csharp
public CentronConnectionType[] SupportsConnectionTypes => new[]
{
CentronConnectionType.CentronWebServices, // Uses WSLogic implementation
CentronConnectionType.SqlServer // Uses BLLogic implementation
};
```
### Benefits of This Architecture
- **Flexibility**: Same module works with direct database or web service
- **Testability**: Easy to mock ILogic interfaces for unit testing
- **Consistency**: Unified error handling and async patterns
- **Maintainability**: Clear separation of concerns
- **Scalability**: Can switch between local and remote data access
### Implementation Guidelines
1. **Always create the ILogic interface first** defining all required operations
2. **Implement both BL and WS classes** - this is mandatory for all modules
3. **Use consistent naming**: `I{Module}Logic`, `BL{Module}Logic`, `WS{Module}Logic`
4. **Return `Result<T>`** from all logic methods for consistent error handling
5. **Support async operations** using `Task<Result<T>>` return types
6. **Register in ClassContainer** to enable dependency injection
## Localization and UI Language Requirements
Because c-entron.NET is developed specifically for the German market, all user-facing content must adhere to the following guidelines:
### German-First Language Policy
- **All UI labels** must be written in German
- **All user messages** must be written in German
- **All documentation visible to end users** must be in German
- **Error messages** displayed to users must be in German
### Language Requirements
- **All documentation visible to end users** must be in German
- **Error messages** displayed to users must be in German
- **Multi-language Support**: The application supports both German (default) and English through separate resource files
- German text is stored in base resource files (`LocalizedStrings.resx`)
- English translations are stored in language-specific resource files (`LocalizedStrings.en.resx`)
- When adding new localized strings, provide translations for both languages
### Implementation Guidelines
For detailed information on implementing localization in the WPF client, including XAML usage, code-behind usage, and business logic integration, see the [Localization Guide](../guides/ui/localization.md).
- Use German terminology consistent with the business domain
- Maintain consistent capitalization and formatting according to German language rules
- For technical terms without direct German equivalents, prefer the established German technical term over creating a new translation
## File Encoding Requirements
To ensure consistent character representation and prevent encoding-related issues, the following encoding rules must be followed for all source files:
### Required Encoding
- **All C# source files (*.cs)** must use UTF-8 with BOM encoding
- **All XAML files (*.xaml)** must use UTF-8 with BOM encoding
### Benefits of UTF-8 with BOM
- Ensures proper handling of special characters and international text
- Prevents encoding-related merge conflicts
- Maintains consistent line endings across development environments
- Enables correct display of all characters in the IDE
### IDE Configuration
In Visual Studio:
1. Go to Tools > Options > Text Editor > [Language] > File Extension
2. Set "Encoding" to "Unicode (UTF-8 with signature) - Codepage 65001"
### When Creating New Files
When creating new files, always ensure the encoding is set to UTF-8 with BOM. This applies to all new source code files added to the project.