-
-
Notifications
You must be signed in to change notification settings - Fork 45
Multi-project orchestration and improved Solution/Project output structure #1776
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR introduces multi-project orchestration capabilities to VFPXPorter, enabling migration of complex Visual FoxPro systems with multiple modules (DLLs, APPs, EXEs) into a single Visual Studio Solution. The changes support real-world migration scenarios where VFP applications consist of several interdependent projects.
Key changes:
- Added ProjectType enum with support for Windows EXE, Class Library, and Console application output types
- Implemented solution-level orchestration with "Append to Solution" feature for incremental migration
- Enhanced folder structure with hierarchical project organization and configurable solution placement
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 16 comments.
Show a summary per file
| File | Description |
|---|---|
| XPorterSettings.prg | Adds ProjectType enum and new properties (OutputType, AppendToSolution, PlaceSolutionInSameDirectory, SolutionName) to control migration behavior |
| XPorterProject.prg | Updates solution generation to support hierarchical folder structure, conditional VFPStart.prg generation based on project type, and solution append logic |
| VSSolution.prg | Adds Load method for reading existing solutions, implements proper tab indentation to prevent Visual Studio "dirty" flag, and includes project deduplication logic |
| VSProject.prg | Refactors IsLibrary property to use ProjectType enum, adds RelativePath property for solution references, and implements OutputType/AssemblyName mapping |
| ExportProjectWindow.prg | Integrates new UI controls for project type selection and solution options, implements selective folder cleanup for append mode |
| ExportProjectWindow.Designer.prg | Adds UI controls (TypeComboBox, AppendCheckBox, PlaceSolutionInSameDirectory, SolutionName) to support new migration options |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Hi team!
Because VFPXPorter is the "jewel in the crown" to attract the VFP community to the X# ecosystem, I started analyzing the project and I want to start contributing to meke it even more powerful and closer to real-world migration scenarios.
After some research and testing with complex VFP examples (like the classic COM+ Events sample with multiple PJX files), I realized that many VFP applications are not just a 1-to-1 migration. Often, a large system consists of several modules (DLLs, APPs, EXEs) that need to work together within a single Visual Studio Solution.
In this PR, I'm proposing a refinement to the project's orchestration logic to better handle these scenarios:
Key changes included in this PR:
- Project Type Support: Added an
OutputTypesetting (Windows EXE, Class Library, Console) so the porter knows when to generate aVFPStart.prgand how to configure the<OutputType>in the.xsprojfile.- Solution Orchestration: Introduced an "Append to Solution" feature. This allows users to migrate multiple PJX files sequentially into the same output folder, mergin them into a single
.slnfile rather than creating separate ones.- Improved Folder Structure: The porter now supports hierarchy. It can place the
.slnfile in the root directory while keeping each migrated project in its own subfolder, using paths for the solution references.- Solution File Refinement: Updated
VSSolutionlogic to include proper tab-indentation and GUID preservation when loading/appending projects. This prevents VS from flagging the solution as "dirty" or "modified" immediately after opening.- UI Updates: Small, non-intrusive additions to the
ExportProjectWindowto allow users to specify the Solution Name and migration preferences.Compile it and try to migrate for example the COM+ Events sample from:
C:\Program Files (x86)\Microsoft Visual FoxPro 9\Samples\Com+\Events. There are three projects:This is a design and logic proposal, I'll be happy to receive your feedback.
Irwin.