Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 22:56:55 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Narrow development guidance to provisional contract

Browse source 
Keep plan enrichment internal and read-only pending consumer agreement and runtime pilot evidence. Move knowledge to its independent PR and remove the consumer-owned forensic evaluator.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 638b66d2-9f06-4f60-8781-808709e1485c
This commit is contained in:
Jesper Schulz-Wedde 2026-09-18 15:46:52 +02:00
parent 8f025ac679
commit fa7eb750c6
40 changed files with 294 additions and 2053 deletions
Download patch file Download diff file Expand all files Collapse all files

26
microsoft/knowledge/upgrade/appversion-meaning-depends-on-execution-context.md
View file

@ -1,26 +0,0 @@
---
bc-version: [all]
domain: upgrade
keywords: [appversion, dataversion, moduleinfo, install-codeunit, upgrade-codeunit, version-context]
technologies: [al]
countries: [w1]
application-area: [all]
---
# `ModuleInfo.AppVersion` changes meaning with execution context
## Description
`ModuleInfo.AppVersion()` is the installed version during normal operation, the version being installed inside install code, and the target version inside upgrade code. It is therefore not the source data version during an upgrade. In upgrade code, `DataVersion()` describes the version of the existing data, whether from the currently installed app or the version most recently uninstalled.
## Best Practice
Interpret `AppVersion()` as the code package entering the context and `DataVersion()` as the existing data state. Prefer upgrade tags for controlling individual migration steps; when version information is needed for diagnostics or preconditions, name variables so target app version and source data version cannot be confused.
## Anti Pattern
Reading `AppVersion()` from an upgrade codeunit and treating it as the version being upgraded from. The comparison actually observes the target package and can skip or misroute migration logic.
## Reference
[Create proper installation and upgrade codeunits](https://learn.microsoft.com/en-us/training/modules/easy-application-upgrade/3-installation-upgrade-codeunits)

28
microsoft/knowledge/upgrade/install-and-upgrade-codeunits-have-no-order.bad.al
View file

@ -1,28 +0,0 @@
codeunit 50641 "Sample Upgrade Part One"
{
Subtype = Upgrade;
trigger OnUpgradePerCompany()
begin
CreateUpgradeState();
end;
local procedure CreateUpgradeState()
begin
end;
}
codeunit 50642 "Sample Upgrade Part Two"
{
Subtype = Upgrade;
trigger OnUpgradePerCompany()
begin
// This can run before Part One; object IDs do not sequence upgrade codeunits.
MigrateDataThatRequiresUpgradeState();
end;
local procedure MigrateDataThatRequiresUpgradeState()
begin
end;
}

18
microsoft/knowledge/upgrade/install-and-upgrade-codeunits-have-no-order.good.al
View file

@ -1,18 +0,0 @@
codeunit 50640 "Sample Upgrade Good"
{
Subtype = Upgrade;
trigger OnUpgradePerCompany()
begin
CreateUpgradeState();
MigrateDependentData();
end;
local procedure CreateUpgradeState()
begin
end;
local procedure MigrateDependentData()
begin
end;
}

30
microsoft/knowledge/upgrade/install-and-upgrade-codeunits-have-no-order.md
View file

@ -1,30 +0,0 @@
---
bc-version: [all]
domain: upgrade
keywords: [install-codeunit, upgrade-codeunit, execution-order, subtype-install, subtype-upgrade, sequencing]
technologies: [al]
countries: [w1]
application-area: [all]
---
# Separate install or upgrade codeunits have no execution order
## Description
An extension can contain multiple `Install` or `Upgrade` codeunits, but Business Central does not guarantee the order in which codeunits of the same subtype execute. Upgrade trigger phases are ordered globally, yet one codeunit's `OnUpgradePerCompany` must not assume another codeunit's same-phase trigger already ran. Object ID and source-file order do not provide sequencing.
## Best Practice
Keep separate install or upgrade codeunits independent. When two steps have a real dependency, coordinate them from one owning trigger in the required order; use upgrade tags to make each completed step idempotent.
See sample: [`install-and-upgrade-codeunits-have-no-order.good.al`](install-and-upgrade-codeunits-have-no-order.good.al).
## Anti Pattern
Splitting dependent steps into separate codeunits and relying on names, object IDs, or declaration order. The dependent codeunit can run first and fail or observe partially migrated data.
See sample: [`install-and-upgrade-codeunits-have-no-order.bad.al`](install-and-upgrade-codeunits-have-no-order.bad.al).
## Reference
[Create proper installation and upgrade codeunits](https://learn.microsoft.com/en-us/training/modules/easy-application-upgrade/3-installation-upgrade-codeunits)