Hi,
Upgrading ProGet 2025.26 (Build 11) to 2026.12 (Build 24) fails on our external PostgreSQL database. We can reproduce it locally with a minimal setup.

Environment

• ProGet 2025.26 (Build 11) → 2026.12 (Build 24), Docker image
• External PostgreSQL 17.11 (Azure Database for PostgreSQL Flexible Server in production; postgres:17 for the repro)
• Database user proget, default search_path ("$user", public)

Error shown in logs

Executing tracked script DDL-DML/v26/26.x - Maintenance/PG-3367 IncreaseConnectorResponseContentType.sql...
0A000: cannot alter type of a column used by a view or rule
At least one script reported an error.

Every restart afterwards reports "Scripts not executed; at least one script has unresolved errors", and the schema stays at 25.0.26.11.
Cause, as far as we can tell
On our managed PostgreSQL, the proget user can't create objects in public (the PostgreSQL 15+ default), so a schema named proget (owned by proget) was created. Through the default search_path, ProGet installed all its objects there. During the upgrade, DDL-DML/0000. Untracked/10. Drop all procs, types, views.sql doesn't drop them. It has no logs like "drop cascades to ..." lines at all.
The old view proget."ConnectorResponses_Slim" therefore still exists, and PG-3367 can't alter ConnectorResponses.Content_Type. It looks like installation follows search_path, but the cleanup only covers public.
Minimal reproduction

1. Start postgres:17 with database proget and user proget.
2. Before ProGet's first start: CREATE SCHEMA proget AUTHORIZATION proget;
3. Start ProGet 25.0.26 with PROGET_POSTGRES_CONNECTION_STRING=Host=...;Database=proget;Username=proget;Password=.... All objects are created in schema proget.
4. Switch to image 26.0.12 and start it. PG-3367 fails with 0A000.

Question

1. Is installing ProGet into a non-public schema supported? If not, could the installer detect it and fail at install time, rather than at a later upgrade?