We’re running a large VB.NET WPF app (.NET Framework 4.7.2) on ThinkGeo.Core / UI.Wpf / Gdal / SqlServer. We’d like to test the 15.0 betas, but every beta since beta028 breaks our build.
The problem
Since 15.0.0-beta028 the shipped DLLs contain obfuscated internal types in single-letter top-level namespaces. In 15.0.0-beta108 (latest) ThinkGeo.Core (net462) has 26 of them:
a A b B c C d D e E f F g G h H i I k K l L m M n O
UI.Wpf has a A, Gdal and SqlServer have A. The types are internal, but namespaces have no accessibility in .NET, so every consuming compiler sees them anyway.
Why that kills VB.NET
With Option Infer On (the default), VB binds a For-loop variable to an existing symbol if one is in scope. i and f now resolve to your namespaces, so this no longer compiles:
For i = 0 To 10 ' BC30112: 'i' is a namespace and cannot be used as an expression
Next
For Each f In features ' same story
Next
That’s hundreds of errors across our solution. The only “workaround” would be explicitly typing every inferred loop variable, forever. Not realistic. (C# is unaffected — locals win the lookup there.)
Which versions
We scanned every 15.0.0-beta* on nuget.org (PEReader over the net462 assemblies, counting top-level namespaces of all types, including internal):
- beta001 – beta027: clean
- beta028 – beta108 (latest, checked 22 Jul 2026): broken — beta108 even adds one more namespace (
m) compared to beta086 - 14.5.x stable (up to 14.5.3): clean
Ask
This looks like an obfuscator config change in your release pipeline at beta028: renamed internal types end up in short top-level namespaces instead of staying nested / in the global namespace. Could you fix that? A release check that fails when a shipped assembly contains a 1-character top-level namespace would have caught this at beta028.
Until then VB.NET users are effectively locked out of the whole 15.0 beta line.
Kind regards,
Guido van den Boom