Add VB support, plus other goodies

[rdeago]

As code generator support is part of Roslyn APIs, it also works for Visual Basic projects. I have a demo project that proves it (VS2022 even shows generated code, just like it does on C# projects).

I see there is currently some work underway to add support for both VB and F#; the latter being, however, bound to a dead end, as F# does not support code generators nor is there any support in sight for the foreseeable future.

Would a PR for what follows be accepted?

• Add VB support for all generators
• Remove F# support
• Close Do not test LangVersion #101
• Close Wrong links in "New issue" page #102
• Close ThisAssembly.Strings: If resource name is not a valid code identifier, compilation fails #83 by implementing proper quoting of strings
• Pave the road to close Allow switching to static readonly properties instead of constants #64 (and probably more) by creating a shared project with code reused by all generators
• Implement the change suggested in Consider change some `const string` to `static readonly string` #63
• Implement the change suggested in Add a API to change generated class name #71
• Implement the change suggested in Add support for non-string constants #103
• Make all generators incremental, thus allowing me to close Use source generators instead of code generation tasks Tenacom/Buildvana.Sdk#148 in the best possible way i.e. by using ThisAssembly
• Change the minimum supported toolchain to .NET SDK v6.0.300 / MSBuild v17.2 / Visual Studio 2022 v17.2, thus closing Source Generator doesn't work anymore with .NET 6.0.200 SDK #85 too

I promise it's not going to be a mega-spaghetti-commit! 😄 It's just that doing one thing per PR would take approximately 5x the time.

If @kzu agrees I can use .NET SDK Preview 3 to build (of course it will not be required by referencing projects): the combination of raw string literals and a few StringBuilder extension methods may efficiently replace Scriban. The preview is "go-live", meaning that Microsoft supports its use in production by companies big enough to sue them 😈 so I guess it's stable enough.

[kzu]

Looks like an awesome plan, if on the large-ish side :)

[rdeago]

No static classes in Visual basic

Visual Basic has no concept of static (i.e. non-abstract, non-instantiable) classes.

Modules, a concept inherited from VB6 / COM, are similar to static classes, in that they are not instantiable and their members are implicitly Shared (VB for static). However, unlike Classes, Modules can neither be nested in other types, nor contain nested types; their use in ThisAssembly is thus out of question.

The type most similar to a non-instantiable class in VB is a NotInheritable Class with a Private Sub New(), where all Public members are Shared: in C# terms, a sealed class with a private parameterless constructor, where all public members are static. If said Class is declared Partial, however, more constructors can be added to it in user code, throwing non-instantiability out the window.

For the reasons above, ThisAssembly cannot be a "static" class in VB. As for nested classes (ThisAssembly.Info, ThisAssembly.Project, etc.), we could make them non-instantiable if we don't declare them partial, but this would introduce a potential breaking change in user code.

In conclusion, unless someone comes up with a better idea, I think ThisAssembly-generated classes should remain static in C# but be "normal" classes with Shared members in VB. This should be made clear in README, of course.

[kzu]

I think it's OK if it's a normal class