Compatibility Matrix
A deployable PPJ application is a combination of versions, not just a PPJ assembly. Record the source Team Developer version, Ice Porter build and options, PPJ packages, .NET target, operating system, process architecture, database provider, UI libraries, and report engines together.
This matrix was reviewed on September 20, 2026. Documented means a published release note or this guide establishes the capability. Source observed means a reviewed source project contains the target or dependency; it does not certify every shipped package. Validate means the complete application combination still needs a deployment test.
Release and Target Matrix
| PPJ line / target | Evidence | .NET and UI baseline | Deployment decision |
|---|---|---|---|
| PPJ 2023 Web | Documented in PPJ 2023. | The release introduced modern .NET 6/7+ and Linux support; its baseline referenced Wisej.NET 3.2 independently through NuGet. | Treat these as historical release capabilities. Choose an in-support runtime that the installed PPJ and Wisej packages actually target. |
| PPJ 2023 WinForms | Documented package availability in the same release note. | The installer provided a separate PPJ-WinForms package. The release note does not establish an exhaustive desktop target list. | Inspect the installed package and generated project; Web Linux support does not make WinForms portable. |
| PPJ 2025 / 5.0 Web source | Source observed in the reviewed runtime's Web build properties. | net48 and net8.0 target properties, with Wisej-4 package references. | Verify the exact distributed package assets, supported Wisej version, and installed template. A floating source dependency is not a tested version pin. |
| PPJ 2025 / 5.0 desktop source | Source observed in the reviewed WinForms Core project. | .NET Framework 4.8. | Validate Windows, process bitness, native clients, and control/report dependencies as one unit. |
| Earlier releases and other target combinations | No complete compatibility statement established by this matrix. | Historical chapters contain older assembly suffixes and tools. | Consult the installed release's documentation and support agreement before selecting the combination. |
The source observations identify implementation evidence, not a new support policy. A TargetFramework in a source tree does not prove an installer contains the corresponding assets or that every optional adapter works on that target.
Microsoft's runtime lifecycle is a separate constraint. .NET 6 and 7 are out of support; .NET 8 reaches end of support on November 10, 2026 according to the .NET support policy. Recheck that policy when planning a release. Do not move a PPJ application to a newer target solely because Microsoft supports it: first establish PPJ, Wisej, provider, and report-engine compatibility.
Database Dependencies
| Dependency | What must match | Minimum evidence before release |
|---|---|---|
| SQL Server ADO.NET provider | Exact provider family and version, .NET target, server version, authentication and encryption configuration. | Connect under the deployment identity; bind nulls/decimals/dates; fetch results; commit and roll back; exercise timeout and reconnect paths. |
| Oracle ODP.NET | Managed or unmanaged provider, PPJ driver mapping, Oracle-specific operations, and any native client architecture. | Parameter names/order, output parameters, stored procedures, array binding where used, and provider error codes. |
| SQLBase, ODBC, OLE DB, or a custom driver | PPJ adapter configuration, driver installation, DSN location where applicable, native dependencies and bitness. | Run on a clean deployment machine. A provider implementing ADO.NET interfaces is only the beginning of compatibility. |
| Shared connections / multiple readers | PPJ connection-sharing options and provider behavior. | Two handles, transaction ownership, nested reads, active readers, and separate users. MARS and separate connections are different mechanisms. |
Use ADO.NET Drivers and SQL Configuration to identify the settings to record. Do not change provider family and business logic in the same baseline test.
Reporting and Native Dependencies
| Integration | Established by these chapters | What remains application-specific |
|---|---|---|
| Crystal Reports | A PPJ adapter and report conversion workflow. | Exact engine/runtime, redistribution rights, architecture, platform support, and converted formulas. |
| List & Label | Adapter, converted definitions, and XSD data contract. | Matching designer/runtime, licenses, native binaries, fonts, and server execution rights. |
| Stimulsoft | Report conversion, grouping, formulas, and page-cache guidance. | Engine edition/version, target support, preview/export integration, cache ownership, and licensing. |
| Reporting Services / RDLC | Local ReportViewer processing of converted RDLC definitions. | ReportViewer runtime and designer support. SSRS server processing is a separate architecture. |
| COM, ActiveX, printers, and desktop controls | Windows integration described in the desktop guide. | Browser substitutes, native deployment, apartment/threading requirements, service-account permissions, and server isolation. |
An engine's own cross-platform product does not establish that a particular PPJ adapter targets it. The report lifecycle provides the acceptance tests for the chosen combination.
Keep an Application Compatibility Record
For each release, save the following beside the build artifacts:
- Identity: source revision, conversion date, Ice Porter build, conversion options, and unresolved warnings.
- Resolved dependencies: exact package and assembly versions, target frameworks, lock file if used, native files, and licenses. Record resolved versions rather than wildcard declarations.
- Environment: OS, architecture, runtime/hosting bundle, database/server versions, culture, timezone, fonts, and printers.
- Evidence: baseline test results, deployment-machine results, concurrent-user results, and report comparisons.
- Decision: accepted limitations, responsible owner, next review date, and rollback artifact.
For SDK-style projects, inspect the project file and resolved NuGet assets; for older projects, inspect assembly references and packages.config where present. Build output alone does not establish which dependencies will be present on a clean machine. Review this record whenever a dependency changes, even when the application source does not.