Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add full VB Support to Xamarin in 2018. #238

Closed
ericmutta opened this issue Dec 31, 2017 · 41 comments

Comments

@ericmutta
Copy link

@ericmutta ericmutta commented Dec 31, 2017

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

This comment has been minimized.

Copy link
Contributor

@reduckted reduckted commented Jan 2, 2018

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.
炉\(銉)/炉

@dotnet dotnet deleted a comment from vbcodec Jan 2, 2018
@AnthonyDGreen

This comment has been minimized.

Copy link
Contributor

@AnthonyDGreen AnthonyDGreen commented Jan 2, 2018

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

This comment has been minimized.

Copy link
Author

@ericmutta ericmutta commented Jan 2, 2018

@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

This comment has been minimized.

Copy link

@vbcodec vbcodec commented Jan 2, 2018

@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

This comment has been minimized.

Copy link

@craigajohnson craigajohnson commented Jan 3, 2018

@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

This comment has been minimized.

Copy link
Contributor

@reduckted reduckted commented Jan 3, 2018

@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

This comment has been minimized.

Copy link
Contributor

@AnthonyDGreen AnthonyDGreen commented Jan 3, 2018

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

This comment has been minimized.

Copy link
Contributor

@AnthonyDGreen AnthonyDGreen commented Jan 3, 2018

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

This comment has been minimized.

Copy link

@Bill-McC Bill-McC commented Jan 3, 2018

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

@Bill-McC

This comment has been minimized.

Copy link

@Bill-McC Bill-McC commented Jan 3, 2018

Would that address many of the issues ?

@AnthonyDGreen

This comment has been minimized.

Copy link
Contributor

@AnthonyDGreen AnthonyDGreen commented Jan 3, 2018

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

This comment has been minimized.

Copy link
Contributor

@reduckted reduckted commented Jan 3, 2018

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

@ericmutta

This comment has been minimized.

Copy link
Author

@ericmutta ericmutta commented Jan 3, 2018

@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

This comment has been minimized.

Copy link

@Nukepayload2 Nukepayload2 commented Jan 7, 2018

@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 xamarin/Xamarin.Forms#1479 for details.

@ericmutta

This comment has been minimized.

Copy link
Author

@ericmutta ericmutta commented Feb 13, 2018

@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

This comment has been minimized.

Copy link

@ymg2006 ymg2006 commented Mar 14, 2018

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

This comment has been minimized.

Copy link

@vbcodec vbcodec commented Mar 14, 2018

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

This comment has been minimized.

Copy link

@Nukepayload2 Nukepayload2 commented Mar 15, 2018

@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

This comment has been minimized.

Copy link

@Nukepayload2 Nukepayload2 commented Mar 15, 2018

@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

This comment has been minimized.

Copy link
Author

@ericmutta ericmutta commented Mar 19, 2018

@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

This comment has been minimized.

Copy link
Contributor

@KathleenDollard KathleenDollard commented Mar 19, 2018

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

@ymg2006

This comment has been minimized.

Copy link

@ymg2006 ymg2006 commented Dec 7, 2018

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

@KathleenDollard

This comment has been minimized.

Copy link
Contributor

@KathleenDollard KathleenDollard commented Dec 10, 2018

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

@Padanian

This comment has been minimized.

Copy link

@Padanian Padanian commented Dec 11, 2018

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

@rrvenki

This comment has been minimized.

Copy link

@rrvenki rrvenki commented Dec 11, 2018

      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

This comment has been minimized.

Copy link
Author

@ericmutta ericmutta commented Dec 11, 2018

@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 馃憤

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

This comment has been minimized.

Copy link

@ocdtrekkie ocdtrekkie commented Dec 11, 2018

@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

This comment has been minimized.

Copy link
Author

@ericmutta ericmutta commented Dec 11, 2018

@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 馃憤

Then I read that it is supported on Windows, Linux, and macOS which is another thumbs up 馃憤

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

This comment has been minimized.

Copy link

@ocdtrekkie ocdtrekkie commented Dec 11, 2018

@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

This comment has been minimized.

Copy link
Contributor

@KathleenDollard KathleenDollard commented Dec 11, 2018

@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

This comment has been minimized.

Copy link
Contributor

@reduckted reduckted commented Dec 12, 2018

@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

This comment has been minimized.

Copy link

@rrvenki rrvenki commented Dec 12, 2018

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

This comment has been minimized.

Copy link
Author

@ericmutta ericmutta commented Dec 12, 2018

@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 馃憤)

@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 馃憤 馃憤

@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 馃槃

@KathleenDollard

This comment has been minimized.

Copy link
Contributor

@KathleenDollard KathleenDollard commented Dec 15, 2018

@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

This comment has been minimized.

Copy link
Author

@ericmutta ericmutta commented Dec 15, 2018

@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 馃憤

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 馃憤

@ericmutta ericmutta closed this Dec 15, 2018
@zspitz

This comment has been minimized.

Copy link

@zspitz zspitz commented Dec 15, 2018

@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

This comment has been minimized.

Copy link
Author

@ericmutta ericmutta commented Dec 15, 2018

@zspitz will check them out and share my thoughts over there 馃憤

@Spoonman2

This comment has been minimized.

Copy link

@Spoonman2 Spoonman2 commented May 9, 2019

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

This comment has been minimized.

Copy link
Contributor

@KathleenDollard KathleenDollard commented May 11, 2019

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

This comment has been minimized.

Copy link
Author

@ericmutta ericmutta commented May 11, 2019

@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:

doclang_2

...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:

doclang_1

...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

This comment has been minimized.

Copy link

@ElektroStudios ElektroStudios commented Oct 15, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can鈥檛 perform that action at this time.