Microsoft-ui-xaml: Discussion: Support for VB.Net

[SimonJonesFF]

I think that supporting C++and C# only is short-sighted. Supporting VB.Net (and for that matter F#) should be seriously considered. If you want WinUI 3 to have broad adoption you should not restrict which languages can be used.

[mrlacey]

For developers who currently use VB.NET in WinForms or WPF, the lack of support for VB.NET in WinUI is a barrier to adopting new technologies and migrating existing apps.

[Nukepayload2]

The lack of VB WinUI template should be documented in the "Preview 1 limitations and known issues" section of https://docs.microsoft.com/en-us/windows/apps/winui/winui3 . Because "Visual Basic" is currently on the roadmap.

Edit: Added a screenshot of the roadmap incase the WinUI team remove "Visual Basic" from the roadmap quietly as the asp.net core team did.

[marb2000]

Thanks. Actually, we should update the roadmap instead. Unfortunately, supporting VB.NET won't happen for 2020.

[SimonJonesFF]

@marb2000 That is disappointing. Can I ask when you may be providing support for VB.Net, or is it not scheduled so it won't happen?

[ocdtrekkie]

Some manner of timeline on when support for VB will happen would be much appreciated.

[marb2000]

Unfortunately, at this point we don't have a timeline for when WinUI will support VB.NET. I invite VB developers who are planning to use WinUI thumb-up this Discussion, so WinUI team is aware the impact of this request.

[DualBrain]

@marb2000 I'm going to ask the question from a different direction...

Instead of asking when it will be supported, I'm going to (instead) ask what will it take to get it supported?

"Thanks. Actually, we should update the roadmap instead. Unfortunately, supporting VB.NET won't happen for 2020." -- marb2000

I would have been patient and take the wait-and-see approach with the above statement. I completely understand that things need to be prioritized and there is only so much that can get done in a particular timeframe. The above statement at least tells me that we are designing our stack to be able to support this in the future; so be patient and keep an eye out.

However...

"I invite VB developers who are planning to use WinUI thumb-up this Discussion, so WinUI team is aware the impact of this request." -- marb2000

Seriously!?!?!? How are VB dev's supposed to plan on using something that most likely won't allow them to use????? This basically SHOUTS that it's not going to happen. It's a preview of "If there isn't enough interest... it's not our fault... there wasn't any interest. For those that are (were) interested... too bad... your community failed you; don't blame us."

I'm a VB developer and I "plan" on using Blazor. I'm a VB developer and I "plan" on using Xamarin. I'm a VB developer and I "plan" on using Code Generation. Where is any of that going to get me?

To be blunt, it is absolutely ridiculous and fantastical to even consider that the splintered (abused) community is going to come to this discussion to "up vote" given that the impression in the community is that it no longer matters what they want since Microsoft is no longer interested/listening. This isn't a reflection on this team, it's just the simple fact that this is the current environment which has been slowly battered and bruised into this state over the past 10+ years. Although the realist in me sees this as the current state of things; the eternal optimist in me believes that there has to be a way that we can turn this around. Asking for community that is nearly impossible to communicate with to up vote on something isn't going to work. We as a community haven't done a very good job cultivating (positive) change, welcoming the community into the conversation and encouraging/accepting of their contributions into the world of open source.

I saw something in a Facebook group recently that made a lot of sense recently... the statement was "I use .NET because it supports VB." If stacks don't support VB, why would VB even look to those stacks?

Additionally, as I see it... it's really isn't about "supporting language X"... it's more about not pigeon-holing things so that it only works with C#. From my perspective, it appears that we've somehow redefined what CLR stands for and frameworks, layers and API's are being built so that they are no longer taking advantage of what the promise of the CLR truly holds.

(Note: CLR, contrary to popular opinion, does not mean "C# Language Runtime".)

I, for one, don't care if it is "officially supported" - what I mean by that is I don't care if there is any documentation, samples, etc. All I really care is that it's not a technology stack that is actively preventing us from leveraging and being involved. For example, Xamarin... Blazor... Razor and now Code Generators. All of these are actively exclude by nature of only including the language of choice du jour.

So I return this back to my alternate question... what is it going to take? How can we - Microsoft and Community - work together to ensure that:

a) None of this is tied directly to a particular language - for example, not using (or at least not exclusively) API's that use, for example, spans (or any other language specific features not available across, at the very least the big three - C#, VB and F#).
b) If any sort of code generation is to be done, that this isn't locked into a particular language - at the very least, if this is "necessary" - then put together a plan where it can be layered so that someone else can step in to do what is necessary (from a community point of view) - encouraging contribution.

To me it is a simple problem that can easily be addressed by just paying attention to the fact that there are other languages that would like to join the party... but the fact that this isn't being done leads to the problem of other languages not only not being invited, but actively being outright denied. Make design choices that are inclusive (and not actively ignorant of the capabilities of the other languages.)

VB developers are left with the following... when (NOT IF) you, as a VB dev, want to develop for WebAssembly, Android, iOS, etc. you have to do the heavy lifting and are forced to not only be a polyglot but also have to figure it out yourself - very little help or guidance is available/provided. Which, to me, seems both interesting and odd that the publicly accepted perception of a VB dev is that they aren't as "smart" as others. ;-)

@KathleenDollard

[ocdtrekkie]

To echo @DualBrain here... if Microsoft isn't interested in putting the man-hours in on VB support, make it clear how we can contribute VB support. If someone comes up with, for example, a project template to support VB and some project stack, how do we get it into Visual Studio (since that's obviously not on GitHub)? If Microsoft enables the points for the VB community to add support to things, Microsoft may not have to invest in supporting VB and still get good VB support.

[marb2000]

First, thank you, @ocdtrekkie , @DualBrain , @SimonJonesFF, and others, for your feedback, enthusiasm about VB, and being open to collaborate in WinUI 3.

We are planning to make open-source WinUI 3 this summer so that you will be able to grab the code and compile it. We will also accept Pull Requests, so we will love to take PRs from the Visual Basic community.

Although I don't think the VB community can make progress on supporting WinUI 3 in VB until we open-source WinUI 3, I want to share the list of the high-level tasks that we have in our Azure DevOps required to this work

1. Create the Visual Studio project templates
2. Extend the XAML Compiler to code generation (.g files) in VB, like update WeakReferences
3. Create a test plan and integrate it into the pipeline
4. Write docs and samples.

It won't be needed to do any work on x-lang, CS/WinRT produces CLR compliant code so it can be used for VB. Also, the C# WinUI 3 in Desktop is using the CPS project system type that is agnostic to the language so that it can be reused for VB.

We are happy to help the community to roll out this support :)