Skip to content

Commit 6488b96

Browse files
mattleibowmattleibow
committed
ai-triage: classify #3380 
1 parent a3ddafa commit 6488b96

File tree

1 file changed

+153
-0
lines changed

1 file changed

+153
-0
lines changed

‎repos/mono-SkiaSharp/ai-triage/3380.json‎

Lines changed: 153 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,153 @@
1+
{
2+
"meta": {
3+
"schemaVersion": "1.0",
4+
"number": 3380,
5+
"repo": "mono/SkiaSharp",
6+
"analyzedAt": "2026-02-13T00:24:40Z",
7+
"currentLabels": [
8+
"community ✨"
9+
]
10+
},
11+
"summary": "Community PR by first-time contributor bumping OpenTK.GLWpfControl from 3.3.0 to 3.3.1 for .NET Framework targets in SkiaSharp.Views.WPF. This restores strong-naming support, fixing #3379 where strong-named applications get FileLoadException because GLWpfControl 3.3.0 is not strong-named. The change is a single-line version bump in the csproj. PR is mergeable but needs rebasing on top of current main.",
12+
"classification": {
13+
"type": { "value": "type/bug", "confidence": 0.95 },
14+
"area": { "value": "area/SkiaSharp.Views", "confidence": 0.98 },
15+
"platforms": ["os/Windows-Classic"],
16+
"tenets": ["tenet/compatibility"]
17+
},
18+
"evidence": {
19+
"bugSignals": {
20+
"severity": "medium",
21+
"isRegression": true,
22+
"errorType": "FileLoadException",
23+
"errorMessage": "Could not load file or assembly 'GLWpfControl, Version=3.3.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)",
24+
"reproQuality": "complete",
25+
"targetFrameworks": ["net48"]
26+
},
27+
"reproEvidence": {
28+
"relatedIssues": [3379]
29+
},
30+
"versionAnalysis": {
31+
"mentionedVersions": ["3.116.0", "3.119.1"],
32+
"workedIn": "2.88.9",
33+
"brokeIn": "3.116.0",
34+
"currentRelevance": "likely",
35+
"relevanceReason": "The csproj on main still references OpenTK.GLWpfControl 3.3.0 for net4 targets. The bug persists in all current SkiaSharp 3.x releases."
36+
},
37+
"regression": {
38+
"isRegression": true,
39+
"confidence": 0.85,
40+
"reason": "Reporter states it worked in 2.88.9. The OpenTK.GLWpfControl dependency was introduced or changed during the SkiaSharp 3.x modernization, bringing in the unsigned 3.3.0 version.",
41+
"workedInVersion": "2.88.9",
42+
"brokeInVersion": "3.116.0"
43+
},
44+
"fixStatus": {
45+
"likelyFixed": false,
46+
"confidence": 0.95,
47+
"reason": "This PR is the proposed fix but has not been merged. Main branch still references OpenTK.GLWpfControl 3.3.0.",
48+
"relatedPRs": [3380]
49+
}
50+
},
51+
"analysis": {
52+
"summary": "This is a straightforward community PR that bumps OpenTK.GLWpfControl from 3.3.0 to 3.3.1 for .NET Framework 4.x targets. The 3.3.1 release of GLWpfControl added strong-name signing, which is required for consumers that enable SignAssembly. The change is minimal (one line in the csproj), has no API or behavioral changes, and directly resolves the bug reported in #3379. The PR needs rebasing but is otherwise ready for review.",
53+
"rationale": "Classified as type/bug because it fixes a concrete FileLoadException (#3379) that prevents strong-named WPF applications from using SkiaSharp.Views.WPF on .NET Framework. Area is SkiaSharp.Views since the change is in the WPF views csproj. Severity is medium — it blocks a specific use case (strong-named apps) but doesn't affect unsigned applications. It's a regression from 2.88.x where either strong-naming wasn't an issue or the dependency was different.",
54+
"keySignals": [
55+
{
56+
"text": "Fixes #3379 — Version update to restore strong-naming support",
57+
"source": "PR description",
58+
"interpretation": "PR explicitly links to the bug report and states the intent clearly."
59+
},
60+
{
61+
"text": "OpenTK.GLWpfControl 3.3.0 → 3.3.1 (net4 targets only)",
62+
"source": "PR diff",
63+
"interpretation": "Minimal, targeted change — only affects the .NET Framework 4.x conditional ItemGroup. Non-net4 targets already use 4.2.3."
64+
},
65+
{
66+
"text": "SignAssembly Condition=\"!$(TargetFramework.StartsWith('net4'))\">false",
67+
"source": "source/SkiaSharp.Views/SkiaSharp.Views.WPF/SkiaSharp.Views.WPF.csproj:10",
68+
"interpretation": "SkiaSharp.Views.WPF disables strong-naming for non-net4 targets but keeps it enabled for net4. This explains why net4 requires all dependencies to be strong-named."
69+
},
70+
{
71+
"text": "mergeable_state: behind",
72+
"source": "GitHub API",
73+
"interpretation": "PR needs rebasing on current main before merge. No merge conflicts detected."
74+
}
75+
],
76+
"codeInvestigation": [
77+
{
78+
"file": "source/SkiaSharp.Views/SkiaSharp.Views.WPF/SkiaSharp.Views.WPF.csproj",
79+
"lines": "13-16",
80+
"finding": "The net4 ItemGroup references OpenTK 3.3.1 but OpenTK.GLWpfControl 3.3.0 — an inconsistency. OpenTK itself was already bumped to 3.3.1 (strong-named), but GLWpfControl was left at 3.3.0 (unsigned).",
81+
"relevance": "direct"
82+
},
83+
{
84+
"file": "source/SkiaSharp.Views/SkiaSharp.Views.WPF/SkiaSharp.Views.WPF.csproj",
85+
"lines": "10",
86+
"finding": "SignAssembly is only disabled for non-net4 targets. For net4, the assembly is strong-named, requiring all dependencies to also be strong-named.",
87+
"relevance": "direct"
88+
},
89+
{
90+
"file": "scripts/VERSIONS.txt",
91+
"lines": "27",
92+
"finding": "VERSIONS.txt tracks OpenTK.GLWpfControl at 4.3.4 (release). This is for the non-net4 path which currently uses 4.2.3 — a separate version gap that could be addressed in a follow-up.",
93+
"relevance": "context"
94+
}
95+
],
96+
"workarounds": [
97+
"Users can work around this by not strong-naming their assembly, though this may not be viable for enterprise applications with strong-naming requirements."
98+
],
99+
"nextQuestions": [
100+
"Should the non-net4 OpenTK.GLWpfControl also be bumped from 4.2.3 to 4.3.4 per VERSIONS.txt?",
101+
"Are there any breaking changes in OpenTK.GLWpfControl 3.3.1 relative to 3.3.0?"
102+
],
103+
"resolution": {
104+
"hypothesis": "OpenTK.GLWpfControl 3.3.0 lacks strong-name signing. Since SkiaSharp.Views.WPF is strong-named for net4 targets, all its dependencies must also be strong-named. Bumping to 3.3.1 (which added strong-naming) resolves the FileLoadException.",
105+
"proposals": [
106+
{
107+
"title": "Merge PR #3380",
108+
"description": "Accept this community PR after rebase. The one-line version bump from 3.3.0 to 3.3.1 restores strong-naming compatibility. No API or behavioral changes.",
109+
"confidence": 0.95,
110+
"effort": "trivial"
111+
},
112+
{
113+
"title": "Also bump non-net4 GLWpfControl to 4.3.4",
114+
"description": "While merging #3380, also update the non-net4 OpenTK.GLWpfControl from 4.2.3 to 4.3.4 to match VERSIONS.txt. This is a separate improvement but could be bundled.",
115+
"confidence": 0.70,
116+
"effort": "trivial"
117+
}
118+
],
119+
"recommendedProposal": "Merge PR #3380",
120+
"recommendedReason": "The PR is minimal, correct, and directly fixes the reported bug. Rebasing is the only prerequisite."
121+
}
122+
},
123+
"output": {
124+
"actionability": {
125+
"suggestedAction": "keep-open",
126+
"confidence": 0.92,
127+
"reason": "Valid community PR that fixes a real bug (#3379). Needs rebase on main, then can be merged. No concerns with the change itself."
128+
},
129+
"actions": [
130+
{
131+
"type": "update-labels",
132+
"description": "Apply bug, views, Windows, compatibility labels",
133+
"risk": "low",
134+
"confidence": 0.95,
135+
"labels": ["type/bug", "area/SkiaSharp.Views", "os/Windows-Classic", "tenet/compatibility"]
136+
},
137+
{
138+
"type": "link-related",
139+
"description": "Cross-reference the bug report this PR fixes",
140+
"risk": "low",
141+
"confidence": 0.98,
142+
"linkedIssue": 3379
143+
},
144+
{
145+
"type": "add-comment",
146+
"description": "Acknowledge the contribution and request rebase",
147+
"risk": "high",
148+
"confidence": 0.88,
149+
"comment": "Thanks for the fix — the version bump looks correct and matches the strong-naming change in GLWpfControl 3.3.1.\n\nThe PR is currently behind `main`. Would you be able to rebase onto the latest `main` so CI can run? Once that's green, this should be ready to merge."
150+
}
151+
]
152+
}
153+
}

0 commit comments

Comments
 (0)