Add Avalonia project type support and default packages

[gaoconggit]

Summary

• add Avalonia project type detection to the runtime, default package provisioning, and safer package downloads
• merge default packages server-side for completion/run/build requests and expose a helper for controllers
• surface the Avalonia option in the UI project type selector and update labels/normalization

Testing

• MSBUILDTERMINALLOGGER=false dotnet build SharpPad.sln (fails: unable to reach NuGet feeds through proxy, build cancelled)

---

https://chatgpt.com/codex/tasks/task_e_68f5dfcc9c488333bd68dcc3894152c6

[claude]

Code Review - PR #67: Add Avalonia project type support

Summary

This PR adds Avalonia UI framework support to SharpPad, including project type detection, default package provisioning, and UI integration. Overall, this is a well-structured addition with good architectural consistency. Below are my findings organized by category.

---

✅ Strengths

1. Consistent Architecture: The changes follow existing patterns (similar to WinForms implementation)
2. Cross-platform Support: Properly distinguishes between Windows-only (WinForms) and cross-platform (Avalonia) desktop apps via the AllowNonWindows flag
3. Comprehensive Integration: Touches all necessary layers (runtime, controllers, frontend)
4. Default Packages: Sensible Avalonia package defaults (11.3.4 versions)

---

🐛 Potential Bugs & Issues

1. Ordering Issue in NormalizeProjectType (MonacoRoslynCompletionProvider/Api/CodeRunner.cs:126-140)

The Avalonia check comes AFTER the WinForms check. This could cause misclassification:

if (filtered.Contains("winform") || filtered.Contains("form") || filtered.Contains("windows"))
{
    return "winforms";
}
// ... 
if (filtered.Contains("avalonia"))  // This might never execute!
{
    return "avalonia";
}

Impact: A project type like "avaloniaform" or "avalonia-windows" would be incorrectly classified as WinForms.

Recommendation: Move the Avalonia check BEFORE the WinForms check, or make WinForms check more specific.

2. Inconsistent Old Code Removal (MonacoRoslynCompletionProvider/Api/CodeRunner.cs:144-152)

The old GetRunBehavior method signature appears to still exist in the diff context, but the PR introduces a new RunBehavior struct. This suggests incomplete refactoring.

Impact: Compilation errors or confusion about which method to use.

Recommendation: Verify the old method is completely removed and all call sites updated.

3. Duplicate Package Download Calls (MonacoRoslynCompletionProvider/Api/CodeRunner.cs:452 & 690)

Package downloads are called in both ExecuteInProcessAsync and ExecuteInIsolatedProcessAsync:

if (!string.IsNullOrWhiteSpace(nuget))
{
    DownloadNugetPackages.DownloadAllPackages(nuget);
}
var nugetAssemblies = DownloadNugetPackages.LoadPackages(nuget);

Impact: Potential race conditions and unnecessary duplicate downloads.

Recommendation: Consider caching or checking if packages are already downloaded before calling DownloadAllPackages.

---

⚡ Performance Considerations

1. Synchronous Package Download in Request Path (CompletionController.cs & CodeRunController.cs)

The PreparePackages method calls CodeRunner.DownloadPackage(specification) synchronously during API requests:

if (!string.IsNullOrWhiteSpace(specification))
{
    CodeRunner.DownloadPackage(specification);  // Blocking!
}

Impact: This blocks the request thread during NuGet downloads, which can be slow (potentially seconds or minutes for large packages).

Recommendations:

• Make package downloads asynchronous
• Consider a background worker for package resolution
• Add timeout handling for package downloads
• Show progress feedback to users during downloads

2. Repeated Package Merging (All Controller Methods)

PreparePackages is called on EVERY completion, hover, signature help request. This rebuilds the package reference map each time.

Impact: Unnecessary CPU cycles for unchanged package lists.

Recommendation: Implement caching based on package list hash.

---

🔒 Security Concerns

1. No Package Version Validation

The PR adds Avalonia packages with hardcoded versions "11.3.4", but there's no validation that these versions exist or are safe.

Recommendation: Consider version validation or using a known-good package registry.

2. Package Download Without Integrity Checks (MonacoRoslynCompletionProvider/Api/CodeRunner.cs:452)

The code downloads packages but doesn't appear to verify checksums or signatures.

Recommendation: Ensure DownloadNugetPackages validates package integrity.

---

🧪 Test Coverage

Concern: No test changes included in this PR.

Recommendations:

• Add unit tests for NormalizeProjectType("avalonia")
• Add tests for GetRunBehavior with Avalonia project type
• Test cross-platform behavior (AllowNonWindows flag)
• Test default package merging for Avalonia projects
• Integration test for running a simple Avalonia app snippet

---

📝 Code Quality & Best Practices

1. Good: Introduction of RunBehavior Struct

The new RunBehavior struct is a great improvement over the tuple return type. This improves code readability and maintainability.

2. Good: Helper Method Extraction

PreparePackages and GetDefaultPackages are properly extracted and reusable.

3. Issue: Inconsistent Null Handling

Some places use request?.Packages ?? Enumerable.Empty<Package>(), others use request?.Packages ?? new List<Package>().

Recommendation: Standardize on one approach (prefer Enumerable.Empty<Package>()).

4. Issue: Missing XML Documentation

New public methods like GetDefaultPackages and PreparePackageReferences lack XML documentation comments.

Recommendation: Add XML docs describing parameters, return values, and purpose.

5. Minor: Overly Defensive Null Checks (CompletionController.cs multiple locations)

if (request != null)
{
    request.Packages = packages;
}

This pattern is used extensively, but request is already dereferenced earlier, so these checks are redundant.

---

🎨 Frontend Changes

Positive

• Clean integration in index.html (adds Avalonia option to dropdown)
• Proper label in runner.js ('Avalonia 桌面')
• Correct inclusion in allowed types in fileManager.js

Recommendation

Consider alphabetical ordering in the UI dropdown for consistency:

<option value="avalonia">Avalonia</option>
<option value="console">Console</option>
<option value="webapi">Web API</option>
<option value="winforms">WinForms</option>

---

📋 Additional Recommendations

1. Documentation: Update README or CLAUDE.md to mention Avalonia support
2. Example Code: Add sample Avalonia code snippet to KingOfTool/ directory
3. Error Messages: Add Avalonia-specific error messages if needed
4. Version Configuration: Consider making Avalonia package versions configurable rather than hardcoded

---

🎯 Priority Issues to Address

High Priority:

1. Fix the ordering bug in NormalizeProjectType (potential misclassification)
2. Make package downloads async to avoid blocking API requests
3. Add basic unit tests for new functionality

Medium Priority:
4. Remove duplicate package download calls
5. Add XML documentation to new public methods
6. Implement package caching to improve performance

Low Priority:
7. Standardize null handling patterns
8. Add example Avalonia code snippets
9. Update documentation

---

Conclusion

This is a solid PR that extends SharpPad's capabilities in a consistent way. The main concerns are around the performance implications of synchronous package downloads in the request path and the potential ordering bug in project type detection. Once these are addressed, this should be ready to merge.

Great work on maintaining architectural consistency with the existing WinForms support! 🎉

---

Generated with Claude Code