Introduction
The Porting Project (PPJ) is Ice Tea Group's toolchain for migrating OpenText/Gupta Team Developer (SQLWindows) applications to .NET. Ice Porter translates application and report definitions. The PPJ Framework supplies the runtime types, controls, SQL binding, messaging, and reporting adapters used by the translated code.
The goal is to preserve existing business behavior while producing source code that a .NET development team can maintain and extend. Conversion is one stage of a migration: resolving warnings, adapting platform dependencies, and testing business workflows remain part of the project.
Desktop and Web
| Target | User interface | Main considerations |
|---|---|---|
| PPJ Desktop | Windows Forms | Windows deployment, native DLLs, COM/ActiveX, printers, and desktop integration. |
| PPJ Web | Wisej.NET | Browser interaction, server deployment, session isolation, file transfer, and replacements for client-machine integrations. |
Both targets use familiar PPJ namespaces and SAL concepts. That does not make every desktop feature available in a browser. Windows handles, ActiveX controls, local file paths, and printer references need to be evaluated in the target environment. See Framework and Ported Application.
PPJ Web and Wisej.NET
PPJ Web uses Wisej.NET for its web user interface. Learning its controls, application lifecycle, and session model helps developers extend migrated applications using C# and Visual Studio. Ordinary static fields are shared by sessions in the server process; user-specific state requires a session-aware design. See Wisej.NET statics.
The courses on LearnWisej.net provide video lessons and hands-on C# coding labs.
Scope of this Manual
This guide explains the compatibility layer and the decisions that need attention during migration:
- Framework: SAL data types, controls, context, SQL access, tracing, and extensions.
- Ported Application: project layout, global items, forms, inheritance, events, and interop.
- Ported Reports: data delivery, conversion differences, engine selection, and report validation.
The examples assume familiarity with Team Developer and basic C# and Visual Studio usage. They explain migration-specific behavior rather than replace the .NET or reporting-engine manuals. Use the Web API or Desktop API reference matching your installed PPJ release for exact signatures and availability.
A Practical Reading Path
The Practical Guides turn these concepts into a compatibility record, a small migration exercise, and a web deployment plan. They also include an architecture diagram and interactive walkthroughs of context, SQL errors, inheritance, and reporting.
- Identify the source Team Developer version, target UI platform, PPJ release, .NET target, and third-party dependencies.
- Read Project Structure, Data Types, and Global Items.
- Review SQL Support, Message Actions, and Issues & Workarounds against the conversion log.
- Compare the original and migrated application's outputs using the same data, culture, and business scenarios. Include error paths, transactions, and reports.
- Establish a working baseline before changing the UI, replacing database providers, or refactoring generated compatibility code.
Conventions and Disclaimers
- SAL refers to Team Developer's application language. Older chapters and source code may use the historical names CTD or SQLWindows.
- .NET Framework refers to the Windows product used by many desktop examples. .NET is the broader platform name; supported target frameworks depend on the PPJ release and its dependencies.
- Assembly names containing a number sign stand for a release-specific suffix. Names such as .46 in older configuration examples are historical examples, not installation instructions for every release.
- Code snippets are C# unless labeled otherwise. Excerpts containing ellipses illustrate a pattern and are not complete programs. VB.NET projects require the corresponding syntax and language-specific behavior.
- Historical limitations are identified where relevant. Confirm support with the installed release rather than interpreting an old example as a compatibility guarantee.
- Microsoft, Windows, Visual Studio, SQL Server, Gupta, SQLBase, SQLWindows, Team Developer, Report Builder, and other product names belong to their respective owners. References identify the technologies involved and do not imply endorsement.