Add full VB Support to Xamarin in 2018.

[ericmutta]

First let me say a prayer for the wonderful people who created portable class libraries: God bless you a million times! 👍 👍 👍

I am getting heavily into Android development and the Xamarin tooling is really cool. With portable class libraries targetting .NET Standard, I can write 99% of my app in VB. The remaining 1% code is just a small bit of C# to manage the UI and access the Android SDK.

@AnthonyDGreen given your insider's perspective: are there any technical reasons for lack of full VB support in Xamarin? If not and it just a matter of effort, can we in the community do something to help bring it to life this new year of 2018?

[reduckted]

I haven't used Xamarin, so I thought this might simply be a case of project templates only being available in C#. Looking at this page, that seems to only be part of the problem. Here's a quote from the bottom of that article:

Limitations of Visual Basic in Xamarin.Forms

As stated on the Portable Visual Basic.NET page, Xamarin does not support the Visual Basic language. This means there are some limitations on where you can use Visual Basic:

• Custom Renderers cannot be written in Visual Basic, they must be written in C# in the native platform projects.

• Dependency Service implementations cannot be written in Visual Basic, they must be written in C# in the native platform projects.

• XAML pages cannot be included in the Visual Basic project - the code-behind generator can only build C#. It is possible to include XAML in a separate, referenced, C# portable class library and use databinding to populate the XAML files via Visual Basic models (an example of this is included in the sample).

• Xamarin does not support the Visual Basic.NET language.

Maybe someone with a bit more knowledge of the inner workings of Xamarin could explain why things like custom renderers and dependency service implementations are limited to C#.

...the code-behind generator can only build C#.

That seems like an easy one. If it's a code generator, it should be simple to make a VB.NET equivalent. ¯\(ツ)/¯

[AnthonyDGreen]

All of the limitations were implemented before Xamarin joined Microsoft. It takes effort to abstract language away from all tooling and that takes time that the Xamarin team invested elsewhere all those years ago. The code generator is one issue that affects this and other technologies that is on the agenda to discuss in 2018. After investigation I'm no longer convinced the solution is as simple as it was with WinForms, WebForms, WPF, etc., and a bigger hammer may be needed. Details coming this month.

[ericmutta]

@reduckted I haven't used Xamarin...

If you ever want to try Android development, you should definitely check our Xamarin...it's pretty amazing how @migueldeicaza and co, managed to get .NET to work on it. They generate Java code which is executed by the Android Runtime. That code uses JNI (which is like Java's version of .NET's P/Invoke) to talk to an open-source glue library called monodroid, which itself loads the Mono Runtime/VM, which is what executes the .NET code you write. Truly fascinating piece of engineering (I can see why they used to charge a fortune for the thing before Microsoft acquired them)!

@AnthonyDGreen After investigation I'm no longer convinced the solution is as simple as it was with WinForms, WebForms, WPF, etc., and a bigger hammer may be needed. Details coming this month.

Many thanks for taking the time to follow up, looking forward to the details! 👍

[vbcodec]

@reduckted Don't be excited right now, it is not confirmation that they will support VB in Xamarin. They promised to support VB in ASPNET CORE, https://blogs.msdn.microsoft.com/webdev/2015/04/24/making-it-better-asp-net-with-visual-basic-14/, and now they don't even mention about it in ASPNET CORE's roadmap https://github.com/aspnet/Home/wiki/Roadmap

@AnthonyDGreen , can you explain what happened to VB support in ASPNET CORE ?

[craigajohnson]

@vbcodec and @reduckted I 100% share your views that Xamarin should get VB support. I work with Xamarin projects and I would much prefer to use VB. I've asked about this several times as well and would love to see this finally get done.

Regarding ASP.NET Core support, although there is not a default template I am still happily using VB with ASP.NET Core. You have to use the new .vbproj format and specify "Microsoft.NET.Sdk.Web" as the Sdk format. As a reference, create a console app in VB and a ASP.NET Core web app in C#, then compare the main project tags, then modify the VB project tag to match and everything should work.

[reduckted]

@vbcodec Yep, that's something I've been meaning to ask about over in the aspnet project. Thanks for the reminder! 😄

@craigajohnson When I last tried it out briefly a few months ago, everything seemed to work OK like you mentioned. The only thing that wasn't nice was the editor experience (you'd get a console window opening up when you started debugging, which wasn't what happened when using C#). It's good to know that you're happily using it without any complaints.

[AnthonyDGreen]

The Razor code generator for ASP.NET Core only generates C#. So you can have your models and controllers be VB but the views will still be in .cshtml. But since .cshtml generates C# behind the scenes and you can't mix VB and C# in the same project you have to have your controllers etc in a different project from your views.

EFCore: The code generator only generates C#; there is no CodeDOM like technology for generating code for multiple languages in .NET Core.

There's a theme here. Today I was discussing these issues with the compiler architects questioning whether some solution to let you mix VB and C# in the same project would be the more future-proof approach. This is veeeeeeeeeeeeeeeeery early discussion and nothing resembling a proposal came out of the discussion but it's a topic on the agenda for the VB LDM this month to put some brainpower to since writing abstract code generators is prohibitively tedious.

[AnthonyDGreen]

The .vbhtml razor engine from MVC 5 wasn't ported to Core primarily because less than 1% of all VB web projects used it after 5 versions. Razor in and of itself is ... challenging to maintain. Moreso with VB (XML literals) so it numerically doesn't make sense to even try to re-implement it given expected use. But with .NET Core and .NET Standard support it's now possible to make an ASP.NET Core app whose code is 99% in VB.NET. We've started to help one customer migrate their VB projects over and I'm working with folks to publish docs/starter projects more broadly soon.

[Bill-McC]

" can't mix VB and C# in the same project " @anthonydgreen What if you could ? Would thus add

[Bill-McC]

Would that address many of the issues ?

[AnthonyDGreen]

That's what we're going to be discussing. It could solve some of the issues. The question is at what cost and with what limitations. Today was just the first of many conversations the design team will have to have to see if we can come up with something useful that doesn't break the universe. So far we can do one or the other but not both :) But the idea is being taken more seriously this year than ever before because of these problems. No promises though.

[reduckted]

@vbcodec and anyone else interested, I've created an issue about VB.NET support in ASP.NET Core over at aspnet/home#2738

[ericmutta]

@AnthonyDGreen But the idea is being taken more seriously this year than ever before because of these problems. No promises though.

Even without promises, this (i.e mixing source files in different languages within one project) is definitely interesting 😄

Perhaps the first step would be to view foreign language source files (e.g C# files in VB project) as opaque resources with a special "generate and import assembly" (GIA) build action. So when building VB code, the build process would invoke GIA on all foreign language files, then simply invoke the standard VB compiler with those generated assemblies as references. The VB compiler would see them just like other assemblies generated in entirely seperate projects. In effect its like the foreign language files were in implicitly defined projects which reference or are referenced by the "host" project.

Still not sure "which way round" the dependencies would work (i.e do implicitly defined projects depend on their host project or vice versa?) but I imagine we could say the "host" project depends on the implicitly defined projects which must be compiled first.

So with Xamarin for example, one would create a C# host project to appease the code generators, and in that project add VB files as foreign language source files. The Xamarin tooling would do its thing as if it was working exclusively with C# source code when in reality, it is using compiled VB code (pretty much the same way it does when you put that VB code in a seperate portable class library project then add a reference to it in the C# project).

I am sure there might be some problems (e.g if the Xamarin tooling actually inspected C# code in source form to do some of its magic) but there's some initial food for thought! 👍

[Nukepayload2]

@reduckted If you want to use Xamarin.Forms Xaml in your VB project, the code-behind generator (XamlG) is not the biggest problem. It can be replaced with a short T4 template.

The real problem is that XamlC is incompatible with WithEvents members. See https://github.com/xamarin/Xamarin.Forms/issues/1479 for details.

[ericmutta]

@KathleenDollard So if there is something you want reviewed early, please make a comment - ideally indicating why you think it should be reviewed (quoted from #251).

My vote for early review goes to this issue: support for VB in Xamarin mobile development. As for why:

1) Mobile app development is pretty much inevitable these days. Either you are designing with mobile in mind (e.g. responsive layout in web apps) or you are developing on mobile directly with the really cool Xamarin toolset.

2) We can already use VB for 99.9999% of the code we write, thanks to the awesome .NET Standard library support, however it turns out that 0.0001% of the code that has to be in C# still matters largely because of the starkly different experience of working in that language in all areas: language features, intellisense behaviour, debugger interface, etc.

Visual Studio and .NET have always been language-agnostic. I understand Xamarin was not part of Microsoft so they could choose to be language-specific, but now they have joined the mothership, I really hope this issue can be worked on this year. Since I (and many many others) will be spending the rest of our natural lives writing mobile apps using Xamarin for Android, being able to do that 100% in our preferred language/toolset would be a HUGE win 👍

PS: the broader request here is "all project types should be supported by all languages"...and when the "all languages" ideal can't be met due to real-world constraints then a clear plan should be put in place to address those constraints (especially now that .NET "open source " is a thing and a community is forming around it).

PPS: major props to the Xamarin team for the work they've done so far, especially baking in support for .NET Standard libraries because without that there would be no VB story for modern mobile development.

[ymg2006]

as the Xamarin website stated in : https://www.xamarin.com/licensing Xamarin has relicensed the Mono runtime under the MIT license and has contributed the code for Mono, as well as the Xamarin SDKs for iOS and Android to the .NET Foundation. and the Mono website http://www.mono-project.com/docs/about-mono/languages/visualbasic Visual Basic.NET support in Mono is relatively new. The Visual Basic runtime has been available for Mono for a while, and with the release of Mono 1.2.3, the Visual Basic support is complete. then what is the laziness about adding this feature to the visual basic ?

[vbcodec]

still no words from team, if it will be implemented or not, if there are any talks or not, if there are any decisions or not.

[Nukepayload2]

@ymg2006 I don't think it's laziness, at least Xamarin.Forms VB support will not take long if they want. I have investigated why Xamarin.Forms does not support VB. There are three missing parts:

Templates

• A project template that contains a .NET Standard VB class library with Xamarin.Forms, an UWP VB project, a Xamarin.Android C# project and a Xamarin.iOS C# project.
• Item templates that help us write Xamarin.Forms app in VB.

I don't think creating these templates will take much time.

XamlG

XamlG is a design-time code generator. It uses CodeDom to generate C# code. So, if they want to support VB, They only have to add VBCodeProvider and handle the special case for WithEvents.

XamlC

XamlC is a compile-time IL code generator. It works fine if you don't access named Xaml controls via WithEvents members. If they want to support VB, just handle the WithEvents special case.

So, why are they not planning to add VB support? Let's guess. Maybe there is nobody within the Xamarin team want to be committed to maintain VB related stuffs?

[Nukepayload2]

@ericmutta If you use generated c# files in your VB Xamarin.Forms projects, you will not be able to access named Xaml controls via WithEvents. The c# code generator will generate fields for named Xaml controls.

[ericmutta]

@nukepayload2 If you use generated c# files in your VB Xamarin.Forms projects,...

I am not personally using Xamarin.Forms (though I know other people do). I just use the Android SDK directly when building the UI (along with the form designer from Android Studio).

@KathleenDollard any updates on this issue?

[KathleenDollard]

@ericmutta I probably won't be able to further explore this for a couple of weeks. It is on my radar.

[ymg2006]

@KathleenDollard @AnthonyDGreen will vb.net get xamarin support on 2019 release ?

[KathleenDollard]

We have no plans for Xamarin support for VB at present.

[Padanian]

Kathleen, enlarging the developers base should be anyone's first point in agenda. Your dry and dismissive answer is disappointing and displeasing.

[rrvenki]

      We have no plans for Xamarin support for VB at present.

While MS has plans to support F# in Xamarin and ignore VB, it does not sound helpful. Your future roadmap may look a nice plan (technically) for you - MS but not for us - Developers. This deliberate ignorance of VB by its creator is very disappointing no matter what answer you give.

[ericmutta]

@KathleenDollard We have no plans for Xamarin support for VB at present.

While a disappointing answer, it is better to get a clear answer than to be left guessing :+1:

You can no doubt feel the frustration in the air. Perhaps as the person overseeing VB, you could tell us what you DO have plans for as far as VB is concerned. Maybe this has already been mentioned elsewhere (in which case anyone with the link kindly share), but if not, it would be great to make it explicit.

At the moment it feels like all the innovation is happening elsewhere and VB is in "maintenance mode". If this is not an accident and VB is in fact on maintenance mode with no plans to add anything new for the foreseeable future, then an official statement would pretty much settle all questions we may have (and in one stroke, close most issues filed in this repo).

Ever since I opened this issue, I have kept using Xamarin for Android. Most of the code is in VB and the little C# I have had to write for the UI is not much of a problem to be honest. Perhaps this is the reason why your team has no plans at present, and I can understand that. Though like I asked earlier, if there are no plans for this, then what else is taking priority? What can we look forward to from VB in the near future? If the answer is nothing, can we get a direct answer on that too?

[ocdtrekkie]

@ericmutta It is hard to argue that VB is in "maintenance mode" immediately following all of Windows Forms and WPF hitting open source repositories, and significant focus being put into porting VB-specific code like the My namespace over to .NET Core, where all modern .NET innovation happens.

[ericmutta]

@ocdtrekkie It is hard to argue that VB is in "maintenance mode"...

While porting VB-specific parts to .NET Core is certainly awesome and welcome, what I mean by "maintenance mode" is stuff like this: the other day I asked how can I experiment with machine learning using familiar Microsoft tools?

I was pleased to discover the ML.NET Machine Learning Library.

I then read it is an open source and cross-platform machine learning framework... which is awesome :+1:

Then I read that it is supported on Windows, Linux, and macOS which is another thumbs up :+1:

Scroll down and just when you think life is wonderful, this shows up:

Use your .NET and C# or F# skills to easily integrate custom machine learning into your applications without any prior expertise in developing or tuning machine learning models.

Most of us are pretty much used to C# getting priority treatment, but now even this F# thing is getting priority over VB. One could bring that old argument that "VB people don't care about this cutting edge stuff" but that paragraph explicitly targets people "without any prior expertise..." in this machine learning field, yet VB is excluded by default. It's like the Xamarin thing all over again.

That's what I mean by "maintenance mode" (i.e from where I stand, the policy seems to be "make sure it keeps compiling on new versions of .NET but nothing more").

Again there's nothing wrong with maintenance mode (I am hard-pressed to find a project I can't code adequately using just VB and .NET Standard 2.0 as it currently stands), but if it's the official policy and not an unfortunate accident, then they should just come out and say so...or at least give technical reasons why, for example, ML.NET is a .NET library but doesn't consider VB (samples are missing).

[ocdtrekkie]

@ericmutta We have "new versions of .NET" in Framework, so the port to Core is definitely more than maintenance, IMHO. Additionally, since a lot of Microsoft's new libraries and tools are for Core, porting VB to it sets the stage for a lot of the future VB support you'd like to see.

WRT ML.NET, my guess is that like a lot of other .NET libraries, it'll work just fine in VB if you convert the samples. I've used numerous libraries in VB projects that lack sample code for VB. And converting samples tends to be the sort of thing community contribution excels at, since it's not making any new decisions/features.

In fact, if you check out the "Community Samples" section of your link, which leads to https://github.com/dotnet/machinelearning-samples/blob/master/docs/COMMUNITY-SAMPLES.md the top entry is ML.NET samples for VB.NET!

[KathleenDollard]

@Padanian I'm sorry if that felt dry or dismissive. I just meant to be clear. I understand @rrvenki point - there is simply no way to make this news sound "nice".

@ericmutta Visual Basic as a language on current platforms has a big following. Those platforms - WinForms and WPF are undergoing a big change with .NET Core 3.0. The move to .NET Core 3.0 is not trivial for Visual Basic because the VB runtime was not designed for the kind of modular design we do today. Getting this right is the key effort VB will have in this next release. As I said here Visual Basic 16.1 and 16.2 will include changes for better C# and inter and new features. We aren't ready to lay out specifics for that. VB is not in "maintenance mode" although we consider maintenance and stability to be very high values for VB.

The version numbers will be a bit confusing for VB programmers for several months. VB 16.0 will release as part of Roslyn in parallel with C# 8. This will coincide with .NET Core 3.0 NOT Visual Studio 16.0. So, there will be some offset between VB and VS version numbers.

I would love to see more samples and blog posts. If you (or anyone) wants to work on a blog post on either what does work in Xamarin and VB or ML.NET, I'd be happy to help amplify the message - probably via the VB Blog if you are interested, and definitely by working to get samples incorporated.

[reduckted]

@ericmutta At the moment it feels like all the innovation is happening elsewhere and VB is in "maintenance mode".

I'm probably getting a bit off topic here since this isn't Xamarin-related, but I felt the need to comment on this. I know VB's not in maintenance mode, but I can definitely understand where you're coming from. The other day I came across the Language Feature Status document and felt particularity underwhelmed. Of the 41 items listed, only two are for VB, one of which seems to be for a pretty specific scenario (null coalescing with generic types). I do appreciate the work being done on those issues though, especially getting rid of more line continuations! 😄.

I can only hope the lack of features coming to VB is because either that document is out-of-date, or because the focus is entirely on getting the VB runtime ported to .NET Core. 🤞

[rrvenki]

Hi @KathleenDollard, How about an idea to start with? I've converted "Intelligent Kiosk" Cognitive services based UWP app into VB.NET. Though there were few impossible direct conversions, I managed to workaround and make it work even though the "services" project of the solution is still in C# (Which hardly requires any change). Further I've written some SQL server Addons in VB even though there's no template in VB for this. We want to start with an option in GitHub samples folder - to upload equivalent VB code for C# samples. That I believe could be a good starting point besides having a blog contribution.

[ericmutta]

@ocdtrekkie Additionally, since a lot of Microsoft's new libraries and tools are for Core, porting VB to it sets the stage for a lot of the future VB support you'd like to see.

This makes sense and I am glad it is happening. Once upon a time, you couldn't build a VB project targeting .NET Standard 2.0 and then they did something and now it works (peeking into the decompiled code I can see embedding of portions of the VB runtime, so if the whole thing is being ported to .NET Core then, as you say, VB should see more support in the future which is a definite plus :+1:)

@KathleenDollard The move to .NET Core 3.0 is not trivial for Visual Basic because the VB runtime was not designed for the kind of modular design we do today. Getting this right is the key effort VB will have in this next release.

Many thanks for making this super clear :+1: :+1:

@KathleenDollard As I said here Visual Basic 16.1 and 16.2 will include changes for better C# and inter and new features. We aren't ready to lay out specifics for that.

Thank you again for being super clear. Though I wish we could get some idea of what 16.1 and 16.2 will bring, even if you have to apply a giant disclaimer that nothing is guaranteed. I suppose it's the issues marked LDM Considering?

@KathleenDollard I would love to see more samples and blog posts.

Me too! As an insider who gets to see what goes on behind the scenes, could you kindly look into why this situation exists at all? Why is it that VB doesn't get samples? What's the underlying bug here? My suspicion is that the teams there work on what they are passionate about, and for a long time that has meant C# (and apparently now F# too). Perhaps the most important feature request we can all ask of you at the moment is to get more people who are deeply passionate about VB working in those teams and if they already exist then give them more power.

@reduckted The other day I came across the Language Feature Status document and felt particularity underwhelmed.

I wasn't aware of that document but looking at it, I can see what you mean by "underwhelmed". Tons of stuff happening for C# with lots of LDM Champions but only two for VB with just one LDM Champion who is also championing the C# stuff too. This is a bug.

In fact looking at the list of LDM Champions there I can partly see now how even F# is beginning to get more love than VB. @jaredpar is the champ for several features and he is also the main guy behind the life-saving VsVim extension. That awesome extension is written in F#.

Results follow the passion and the way things look right now, that passion exists in greater numbers for C# and F# than VB. Luckily though, there's plenty of passion from all of us who frequent this repo, so maybe we should dust up our CVs and send them to Kathleen :smile:

[KathleenDollard]

@KathleenDollard As I said here Visual Basic 16.1 and 16.2 will include changes for better C# and inter and new features. We aren't ready to lay out specifics for that.

Thank you again for being super clear. Though I wish we could get some idea of what 16.1 and 16.2 will bring, even if you have to apply a giant disclaimer that nothing is guaranteed. I suppose it's the issues marked LDM Considering?

We will look at C# interop as the primary importance - default interfaces as an example (as they are fleshed out of C#). We are definitely interested in the most VB like approach to pattern matching as we think that could be a great addition. At this point places that increase the surface area to save a handful of characters will be a lower priority. I do not expect us to look at Null Reference Types until we have a lot of feedback from C#, since this is a feature designed to break your app compiling.

@KathleenDollard I would love to see more samples and blog posts.

Me too! As an insider who gets to see what goes on behind the scenes, could you kindly look into why this situation exists at all? Why is it that VB doesn't get samples? What's the underlying bug here? My suspicion is that the teams there work on what they are passionate about, and for a long time that has meant C# (and apparently now F# too). Perhaps the most important feature request we can all ask of you at the moment is to get more people who are deeply passionate about VB working in those teams and if they already exist then give them more power.

Do you know how to show VB samples? It's in the upper right and does not look like a drop down. That said, we are missing some samples and VB content can be improved.

This is all open source. There is no easier or more (at least by me) appreciated route to getting OSS contributions than helping with our docs. I would love to give some folks visibility on the team blog, and if someone wants to make a change to docs and write a post about the experience I'd love to share it (particularly if you let us iron out anything you encounter).

[ericmutta]

@KathleenDollard We will look at C# interop as the primary importance - default interfaces as an example (as they are fleshed out of C#). We are definitely interested in the most VB like approach to pattern matching as we think that could be a great addition.

Thanks for sharing these plans and while I know nothing is guaranteed, it's helpful to know what your team is considering! The pattern matching would definitely be a great addition: in the little C# I have had to write when working with Xamarin, pattern matching has been useful, specifically the switch use case:

public static double ComputeAreaModernSwitch(object shape)
{
    switch (shape)
    {
        case Square s:
            return s.Side * s.Side;
        case Circle c:
            return c.Radius * c.Radius * Math.PI;
        case Rectangle r:
            return r.Height * r.Length;
        default:
            throw new ArgumentException(
                message: "shape is not a recognized shape",
                paramName: nameof(shape));
    }
}

@KathleenDollard ...if someone wants to make a change to docs and write a post about the experience I'd love to share it...

I have managed to make a few doc changes lately (e.g #1256) it turns out to be easier than one might think when you try it though I think the github workflow is too heavy-handed for making small changes like correcting typos. Maybe a one-step process could be made that does all the stuff (fork, edit, commit, PR) behind the scenes while allowing you to simply make the fix in a pop-up box and submit :+1:

Thanks everyone who contributed to this extended discussion. Since the Xamarin support question has been settled and we know what the VB team is working on instead, I think it is safe to close this issue :+1:

[zspitz]

@ericmutta What do you think of the goals of pattern matching that I've laid out here?

@KathleenDollard What is the current thinking in the LDT about the syntax and features of pattern matching? Have there been any concrete decisions made?

[ericmutta]

@zspitz will check them out and share my thoughts over there :+1:

[Spoonman2]

Do you know how to show VB samples? It's in the upper right and does not look like a drop down. That said, we are missing some samples and VB content can be improved.

How stupid am I? I've been working for weeks on a project presuming all the help samples were only C# and having to mentally modify them for my vb.net code! Duh. Mind you come to that I didn't even know about this place except for watching Kathleen Dollard on the panel talk about it...

[KathleenDollard]

You are NOT stupid. This UI is stupid. It's getting better, but it's still not good since you don't look at the top of the page when you are looking at code :(

[ericmutta]

@KathleenDollard: It's getting better, but it's still not good since you don't look at the top of the page when you are looking at code :(

That's probably the single biggest reason most people don't know that the drop-down even exists. I have seen a scheme that works quite well (in terms of discoverability) from the Android docs:

...the code samples above are presented in a tabbed UI with all the languages available so its dead easy to notice which languages are supported and to switch between them. I imagine the same "tabbed UI for samples" could be used by the docs team?

For reference docs they list out the languages at the top like this:

...notice the words Kotlin and Java on the bottom right which when clicked will switch the entire page to render code in the selected language.

Let me know if this is a workable solution and I can file an issue for @mairaw and team to follow up.

[ElektroStudios]

Year 2019... near 2020, Xamarin still does not support Visual Basic.NET directly. Nice marketing strategy...

What we can see here is a development team that does not empathize with the rest of the programmers who depends on the second most used language supported in Visual Studio. Should I do like the others who have commented and smile, praise, admire and be grateful for this lack of support?... thanks for nothing.

I'm very dissapointed year after year, with not enough motivation to use Xamarin instead of other products which at least have fully VB-like lang. support.

[dddns]

+1 Why no vb.net for xamarin? Sometimes I heard "c# is the future, bla bla", really? I can't read c#, makes my head crash, when i look at vb code, which is a native language, everything's clear. Strange is, i can read without trouble vb, C code, PHP (which is so easy and understenable), and c# is just a nightmare, along with java!

So please, why doesn't the vb community don't have vb in xamarin? in percentage, maybe the vb community is equal to the c# one, or maybe, even bigger? Just imagine that until 2001 +- everybody was coding in vb, which was a native language, don't forget that.

Let us know a date for vb in xamarin, forget F#, why reinvent?

[ocdtrekkie]

My primary lack of interest in Xamarin is that it can't also be used on Windows/Linux desktops. But yeah, VB support would be huge on making mobile app development easy and accessible.

[Spoonman2]

I totally agree with dddns about C# (and Java) readability.

[AliParLouS]

After 2 years still nobody care to add VB to xamarin.forms, Why? Why i have to convert more than 500,000 line of vb.net code to c# so i can use it in mobile app? Why i have to use C# which doesn't have support static variable in a function? Why i have to use C# which i have to put ; in every line? Why i have to use C# which force me to put () in end of every method and voids without suggesting? Why i have to use C# which i can only write LastName.trim() but not trim(LastName)? Why i have to use C# which i can't have static method inside of non static class?

There are tons of things VB support while C# doesn't, So why i have to migrate to this low level language?

If you want someone get interested in your C# language stop force them to use that language and try to improve it, If you can't : JUST ADD VB TO XAMARIN.FORMS، That's really simple, Why you fighting this fact?

[njsokalski]

As a UWP developer that is being forced to convert their apps for Android, I obviously need to learn Xamarin.Android. For my entire career in .NET I have used VB, and with Xamarin only supporting C#, that means learning another language as well (I do have basic knowledge & experience with C#, but nowhere near knowing all the little tricks I have learned for VB). It is true that things such as custom classes, interfaces, enumerations, etc. can be written in another project and referenced, but in my opinion most apps that are intended for Android will have a majority of their code in the UI components (apps that have extremely complex logic are more likely to be productivity related apps intended for a desktop), which is the part that cannot be put in another project (because of the code that is generated from the UI). With all the language converters that are available, I would think that it wouldn't be too hard to make a VB version of the generated code, even if it is initially generated as C# and then immediately and automatically converted to VB, especially since most of the generated code is not extremely complex.

[dddns]

I just moved to flutter, if i have to learn something new, i learn something great, and not the mess of c#. If for some reason MS add vb.net in xamarian, i may get back to xamarin.

I think it's a terrible decision for MS to not have vb in xamarian, another error, like windows phone.

[ocdtrekkie]

Indeed, Microsoft's refusal to support VB is going to cost a lot of developers. The language exists, the frameworks exist, we just need Microsoft to properly support all of their languages on their major frameworks.

Telling me I should abandon .NET is the message I get every time Microsoft announces a new framework or platform will only support C#.

[dddns]

yea, instead of they be creating stuff like f# and similar, they should just stick with vb and c# and improve them. bad decision, but that's their call, they're looking at profit, not customer/devs satisfaction.

the problem for sure it's me, i can do php, C, and some other one's, but i just can understand the damn c# syntax, it's a mess and horrible in my perpective. It's my problem for sure.

[njsokalski]

I never had anything AGAINST C#, I even know the basic syntax of it, I'm even ok with the fact that most .NET documentation shows the examples using it. It is simply the fact that I am much more fluent in VB and most of my .NET work since .NET was created is in VB. I would even be willing to convert my final code to C# for the release versions of my apps if I had to. The problem is that I cannot do the debugging with VB because the generated code is C#. Converting code is easy, just use a code converter and you barely need to know the language, unfortunately, you cannot do that until the code is finished. When .NET was first created, the goal was to have all .NET languages compile into the same runtime, so once it is compiled, there literally is no difference between the different languages. If the compiled result is identical (which, for nearly everything, it is), then you cannot argue that one language is better than another, and since VB & C# are both capable of the same things, it is strictly personal preference.