Maui: [Enhancement] Include Support for VB

[njsokalski]

Summary

Previous Xamarin project templates supported only C#, I would like to see support for VB as well

API Changes

The API would remain primarily the same aside from being a different language

Intended Use Case

The use cases would include the ability to use VB for code. Allowing developers to reuse pieces of existing code that are not full assemblies, as well as take advantage of Intellisense for the language they are most fluent in would significantly reduce development time as well as simplify debugging.

[VladislavAntonyuk]

VB.NET and C# have the same IL code as the output. You can call your VB.NET shared code from C# library

[njsokalski]

I understand that, I may have been unclear in my question. My question is whether Visual Studio (the related project templates) will allow you to use VB when writing the code for the current project, including event handlers and other code that is not shared.

[DualBrain]

I would also like to see this. Having to constantly do the mental shift is unnecessarily taxing... and shouldn't be. Sure, I could switch to C#... but I don't desire to do that either as I PREFER to code in VB.

My main question around this is Xamarin planning on redesigning the code generation to utilize Source Generators? If so, will it be designed so that it would be relatively easy to choose the (assuming they exist) necessary Source Generator - thus providing us (the VB community) the ability to assist in providing the VB versions of these Source Generators?

I could be way off base here... as Source Generators are still very new and they may not actually fit the "hidden" side of how Xamarin does things... with that said, I suppose it doesn't hurt to ask. ;-)

[DualBrain]

VB.NET and C# have the same IL code as the output. You can call your VB.NET shared code from C# library

Certainly... as this is the way that it has to be done today. However, this means that there is a C# project for the "UI" and one-or-more projects for the "business logic". The context shift is a pain-in-the-arse! Considering that the problem is the generated code code part forces us to have to write the rest of our UI logic (code-behind) in the same language as that which was generated, it's hard for us VB folks to understand why the code-spit can't be in our language instead of being forced to write code in "what other people want us to use".

[DualBrain]

"People, I just want to say, can't we all get along? Can't we all get along?" -- Rodney King, May 1, 1992.

In response to the, what appears to be, an unreasonable number of thumbs-downs simply (IMO) a topic that has the VB reference in it's title. We are all, after all, just using a thin facade (our language of choice) to generate IL... so our code-generator of choice is just that... choice. And whatever happened to respecting one's choice - especially when that choice doesn't negatively impact your choice?

I have a dream! Can't we all just get along, coexist peacefully, respect each others choices in their personal preference of "template generator" and unite as one community of .NET Developers? Oh what a dream that is (and a dream I've been having for almost 20 years).

[charlesroddie]

Certainly... as this is the way that it has to be done today. However, this means that there is a C# project for the "UI" and one-or-more projects for the "business logic".

Any .Net project can reference Xamarin.Forms and create UI using that. So it's not true that VB/F# can only be used for business logic.