-
-
Notifications
You must be signed in to change notification settings - Fork 39
Add comprehensive .NET 8 migration analysis with detailed risk assessments and alternative migration proposals #518
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
Refine AI onboarding and workflows: * Update copilot-instructions.md with agentic workflow links and clearer pointers to src-catalog and per-folder guidance (COPILOT.md). * Tune native and installer instructions for mixed C++/CLI, WiX, and build nuances (interop, versioning, upgrade behavior, build gotchas). Spec kit improvements: * Refresh spec.md and plan.md to align with the feature-spec and bugfix agent workflows and FieldWorks conventions. Inner-loop productivity: * Extend tasks.json with quick checks for whitespace and commit message linting to mirror CI and shorten feedback loops. CI hardening for docs and future agent flows: * Add lint-docs.yml to verify COPILOT.md presence per Src/<Folder> and ensure folders are referenced in .github/src-catalog.md. * Add agent-analysis-stub.yml (disabled-by-default) to document how we will run prompts/test-failure analysis in CI later. Locally run CI checks in Powershell * Refactor scripts and add whitespace fixing algorithm * Add system to keep track of changes needed to be reflected in COPILOT.md files. git prune task
Co-authored-by: johnml1135 <[email protected]>
Co-authored-by: johnml1135 <[email protected]>
|
@copilot Add a section to the migration overview detailing the 5 highest risks including the project you identidied as high complexity. I would like you to not only review the COPILOT.md files for the worst projects, but review all the files in the folders themselves when detailing the worst or most complex issues. Search the internet for gotchas with the migration, especially around support for complex views in WinForms. |
Co-authored-by: johnml1135 <[email protected]>
Added comprehensive "Top 5 Highest Risks" section to Src/DOTNET_MIGRATION.md (commit d55f783). The analysis includes: Risk #1 (CRITICAL): Native Views rendering engine P/Invoke compatibility - 66.7K lines of C++ with COM interop, marshaling changes, and TSF integration risks Risk #2 (HIGH): WinForms designer and custom controls - Out-of-process designer architecture breaks traditional design-time patterns, affecting all 37 WinForms projects including LexTextDll (the high complexity project identified) Risk #3 (HIGH): XCore framework reflection-heavy plugin architecture - Mediator pattern and colleague discovery at risk Risk #4 (MEDIUM-HIGH): Resource/localization infrastructure - Large .resx files and Crowdin integration must be validated Risk #5 (MEDIUM): Database/ORM compatibility - LCModel data access with SQL Client and serialization changes Each risk includes:
Research sources include Microsoft .NET 8 breaking changes documentation, WinForms designer migration patterns, and COM interop gotchas. |
|
Agent analysis is currently a stub and does not execute prompts. |
|
@copilot These risks look significant. Make a markdown file per risk called MIGRATION-RISK-.md and reference it. For each risk, think through 2-3 ways to address it. After considering all the main risks, update the main migration plan with 2-3 proposals on how to go about this transition. Name them MIGRATION-PROPOSAL-.md. |
Co-authored-by: johnml1135 <[email protected]>
Created detailed risk and proposal documents (commit 3eab498): Risk Analysis Files (5 files):
Migration Proposals (3 files):
Graphite & Legacy Removal: Risk #4 Approach #3 and Proposal B specifically address removing Graphite complexity you mentioned. Modern alternatives (HarfBuzz, platform text APIs) replace 15-year-old code. MIGRATION-PLAN-0.md Integration: Extensively referenced throughout. Proposal B implements the patch-by-patch plan (P0-P5). Risk analyses reference specific patches (e.g., P5.1-P5.3 for XCore MVVM migration). Main DOTNET_MIGRATION.md updated with links to all documents and comparison table. |
Provides a complete roadmap for migrating FieldWorks from .NET Framework 4.6.2 to .NET 8, including per-component assessments, a phased migration strategy, detailed risk analysis with alternative approaches, and three comprehensive migration proposals.
Analysis Scope
DOTNET_MIGRATION.mdnext to eachCOPILOT.md)Src/DOTNET_MIGRATION.md- 700+ lines)MIGRATION_ANALYSIS_README.md)MIGRATION-RISK-<N>.md) with 2-3 approaches eachMIGRATION-PROPOSAL-<A/B/C>.md)Key Findings
Project Categorization:
Complexity Distribution:
Migration Strategy
6-phase approach over 12-18 months:
Key decisions:
Priority migration candidates (Phase 2):
Top 5 Highest Risks
Detailed analysis based on code review, COPILOT.md files, and research into .NET 8 migration gotchas:
Risk #1: Native Views P/Invoke Compatibility⚠️ CRITICAL
Risk #2: WinForms Designer & Custom Controls⚠️ HIGH
Risk #3: XCore Framework⚠️ HIGH
Risk #4: Resources/Localization⚠️ MEDIUM-HIGH
Risk #5: Database/ORM⚠️ MEDIUM
Total Risk Mitigation Effort: 20-28 weeks (~5-7 months)
Migration Proposals
Three comprehensive strategies with different risk/timeline profiles:
Proposal A: Conservative .NET 8-Only Migration
Proposal B: Combined .NET 8 + Avalonia Migration
Proposal C: Pragmatic Hybrid Approach ⭐ RECOMMENDED
Per-Component Assessments
Each
DOTNET_MIGRATION.mdprovides:Example structure:
Resources Required
Key Features of This Analysis
✅ Comprehensive risk analysis - Each of 5 risks analyzed with 2-3 alternative approaches
✅ Strategic alternatives - Three complete migration proposals with different risk profiles
✅ Graphite removal - Addresses legacy complexity removal with modern tooling
✅ Avalonia integration - References and implements MIGRATION-PLAN-0.md
✅ Decision gates - Proposal C includes validation checkpoints
✅ Cross-referenced - All documents link together for easy navigation
Original prompt
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.
This change is