WUIC ← Back to downloads

Release Notes — WUIC Framework v1.7.10

Date: 19 September 2026 Previously published version: 1.7.9 (18 September 2026) Backend: .NET 10 + IIS / Linux nginx Frontend: Angular 21


This version comes out of a full round of end-to-end installs on clean machines: sixteen combinations, the four distribution packages against the four supported engines, each time starting from the published zip and following the documentation the way a first-time user would. Almost everything it surfaced affects those who do not use SQL Server: reports printing an empty page, a scaffolding call that failed, indexes that were never created. All of them silent — no message on screen, just a feature that did not work.


📊 Reports print their data again on MySQL and PostgreSQL

Opening a tutorial report on MySQL or PostgreSQL, the viewer drew the page — header, frame, "page 1 of 1" — and printed not a single row. The same report worked on SQL Server.

The reason is that a report scaffolded by the framework carries its own query, and that query is written with the identifiers of the engine it was generated on. The .mrt file, however, ships inside the package and is the same for all four engines: the tutorial one holds unquoted uppercase identifiers. On SQL Server that passes, because comparison is case-insensitive there; on PostgreSQL an unquoted identifier is folded to lowercase and no longer matches the columns, which the tutorial creates quoted in PascalCase.

Now, before rendering, reports generated by the framework — recognisable by the marker they carry in the SELECT — have their query rebuilt from the metadata for the engine of the current installation, with the right quoting rules. Reports written by hand in the designer are left alone: their query stays the one you wrote.

🧱 Scaffolding a table from the UI on PostgreSQL

On PostgreSQL, scaffolding a table from the interface answered HTTP 500 with a foreign key violation on _metadati__colonne, and the generated route stayed empty.

The real defect was upstream, and it was twofold. The identity sequence of the menu table falls behind whenever rows are inserted with an explicit key — which the framework does when it adds its own system entries: from then on the first insert that relies on the sequence asks for a key that is already taken. And when the menu entry failed to be created, the code deleted the metadata table row it had just inserted, leaving the columns without their parent: the error that reached the user therefore talked about foreign keys and a table that had nothing to do with it.

The sequence is now realigned after every insert with an explicit key, and a menu that fails to be created no longer takes the table metadata with it: at worst the menu entry is added from the designer.

⚡ Metadata indexes are actually created now

The schema migrations that create the indexes on the metadata hot paths — route name, columns per table, scheduler — were not applied on a fresh installation, for two different reasons.

The first: when a freshly installed application boots, the connection strings are not there yet, so the migrations failed; and because the attempt was considered spent, they were never retried within the process. On a new installation, where nobody restarts the service right away, those indexes were never created. The "database not configured yet" condition no longer consumes the attempt, and the migrations run as soon as the first-run wizard has written the connection strings.

The second, on Oracle only: the index script referenced the columns quoted in lowercase while the schema creates them in uppercase, so it answered ORA-00904 and the migration stopped there.

What this means in practice is on the pages that depend on those indexes: opening a list from the menu, going back into a list already visited, the first entry of the Administration menu. Without the indexes those operations reached tens of seconds on PostgreSQL.

🤖 The VS Code assistant answers questions instead of writing code

Asking the assistant "which columns does route X have?" — even adding "do not modify files" — made it scaffold a component and answer by describing what it had written. The question stayed unanswered and the project was modified against the instruction.

A request that is a question, or that explicitly forbids changes, now puts the assistant in read-only mode: the tools that touch the project are refused, and the answer is built with the query tools (route columns and metadata, code and documentation search).

🔧 Installations that tolerate transient hiccups

📚 Documentation

📦 Updated packages

Package From To
WuicCore 1.7.9 1.7.10
Wuic.Webcore 1.7.9 1.7.10
WuicOData 1.7.9 1.7.10
RuntimeEfCore 1.7.9 1.7.10
Wuic.MySqlProvider 1.7.9 1.7.10
Wuic.PostgresProvider 1.7.9 1.7.10
Wuic.OracleProvider 1.7.9 1.7.10
wuic-framework-lib (npm) 1.7.9 1.7.10
  1. No configuration change: the appsettings.json keys are unchanged.
  2. On PostgreSQL and Oracle installations already in production, the missing indexes are created at the first start with 1.7.10: that first start can take a few seconds longer, once.
  3. If you have scaffolded reports on MySQL, PostgreSQL or Oracle that printed blank, just open them again: there is nothing to regenerate, the query is rewritten at render time.
  4. If one of your controllers opens its own connections on Oracle, check that it moves the session to the data schema or qualifies the tables: see the note on the patterns page.