Fix Avalonia Build Errors
Budget: $10 – $1,750 USD
I have several legacy VB6 programs that were automatically migrated to C#. Their core business logic is in place, but the Avalonia UI layer was wired up by the migration tool and now the solution refuses to compile. All blocking issues show up at build time—so we are talking pure compilation errors, not IDE warnings.
The brief is deliberately narrow:
• Get the project to build and run on .NET with Avalonia, nothing more.
• Touch only the UI glue code that is currently breaking the build; leave the business logic, architecture, and any MVVM concerns exactly as they are.
• Once compiled, the app just needs to open and allow basic user testing, with particular attention to the Data Entry Forms. We expect some unexpected runtime behaviour for now, and that is acceptable.
Deliverables
1. A compiling Visual Studio (or JetBrains Rider) solution.
2. Fixed Avalonia XAML / code-behind wiring sufficient for the main window and Data Entry Forms to render and accept input.
3. A concise change log or commit notes so we can reproduce the build on another machine.
No refactor, redesign, or cleanup tasks are in scope; speed and minimal surface-area changes are the priority. If you are comfortable untangling Avalonia XAML, event handlers, and resource references, this should be a focused, quick engagement.
Basic user testing here means the UI opens and accepts input, not that the underlying workflows are complete.
The brief is deliberately narrow:
• Get the project to build and run on .NET with Avalonia, nothing more.
• Touch only the UI glue code that is currently breaking the build; leave the business logic, architecture, and any MVVM concerns exactly as they are.
• Once compiled, the app just needs to open and allow basic user testing, with particular attention to the Data Entry Forms. We expect some unexpected runtime behaviour for now, and that is acceptable.
Deliverables
1. A compiling Visual Studio (or JetBrains Rider) solution.
2. Fixed Avalonia XAML / code-behind wiring sufficient for the main window and Data Entry Forms to render and accept input.
3. A concise change log or commit notes so we can reproduce the build on another machine.
No refactor, redesign, or cleanup tasks are in scope; speed and minimal surface-area changes are the priority. If you are comfortable untangling Avalonia XAML, event handlers, and resource references, this should be a focused, quick engagement.
Basic user testing here means the UI opens and accepts input, not that the underlying workflows are complete.
Related categories:
Visual Basic
.NET
C# Programming
Software Testing
WPF
Debugging
Software Development
XAML
Visual Studio