by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Paul M Cohen
    @paul1956
    @aarondglover yes. @jnm2 contributed the conversion to a standalone Async converter. Since it’s based on Roslyn it can get very close. Now that it does projects it can get much better as type resolution. I don’t know anything about GRPC so can’t comment on what’s needed. I assume it’s Open Source so I might take a look. Also don’t why why just referencing the library isn’t good enough to handle SingleInstance.
    Mohammad Hamdy Ghanem
    @VBAndCs
    I cloned ADG Roslyn fork to my PC. I think this is the VB we should evolve, but first we should wait to last MS VB update, then try to convince ADG to update his fork, then we can send PR to his fork if he is willing to be responsible for that, or someone of us can fork it and talk over this job. This doesn't mean he should do most of the work, but just keep all efforts summing in one fork. We Can call it VB.Core.
    I have an idea: Why doesn't every VB programmer send an issue to the MS user voice to ask to keep VB alive and evolving assuring they will not move on to C#? If they received a flood of at least 1 million issues, I think they will think twice!
    Aaron Glover
    @aarondglover
    @paul1956 I'm definitely going to look at your project to convert c#. Thanks!
    Regarding your comment about referencing the library... Do you mean why isn't referencing the C# library good enough?
    I don't have a huge issue with that. It works fine but it does require VB developers to switch to C# for atleast one project in your solution and it also adds to the futher "degradation" of VB.NET by the erosion of support in tooling etc. Death by a thousand cuts. My desire for VB native support in GRPC tooling is to continue to keep VB as an approachable language and platform for new developers.
    Aaron Glover
    @aarondglover
    RPC will remain a fundamental requirement in many cases and given this is the recommended path forward to achieve RPC in CORE applications, removing impediments/Complications such as switching to C# to develop the DTOs and/or generate proxy classes would be a positive step forward.
    Thoughts?
    @VBAndCs mobilising the VB community will always remain difficult. F# proved it can be done with a small team of dedicated, passionate people... That's the model we have to some how achieve and convince MSFT to adopt. How we achieve that is the million dollar question.
    I tend to agree with ADG that forking VB would represent a failure.
    Aaron Glover
    @aarondglover
    I feel like convincing product teams (Azure Functions comes to.mind) that they should create VB project templates, documentation and samples in VB is a commitment that can only be driven by MSFT. Language development should not cease but we should not thrive to have a myriad of new language features. Compatibility and the ability to consume or otherwise interact with C# libraries should be the most critical driver to change the VBLANG. That's just my two cents of course
    Paul M Cohen
    @paul1956
    @aarondglover sorry for the length, VB developers call libraries in C# all the time without knowledge. Even my converter needs a C# library for Unchecked math. I didn't write it, it is stable and I never expect to look at the code. If and when VB gets unchecked math I might get rid of it but there is really no need. When I worked on file VB IO for Winforms I ported the code which was trivial and then wrote many tests since none existed, naturally in VB. When I pushed the PR someone ported all the tests to C# which was a ridiculous waste of effort, so from that point I agree. I believe there are differences between F# and VB two are key. F# has dedicated resource with Repo merge permission and it is a separate repo from any other language. VB is tightly intertwined with C# and much code (and more every day) is shared. When I did a prototype for Unchecked I finished it and then went to merge with my current fork of Roslyn/Master I ran into many merge conflicts because the Roslyn team had combined more VB and C# code into C# interfaces. This appears to me to be done to continue allow VB to get the latest refactoring in VS which I love but it means, as one engineer said, every change to Roslyn is twice the work.
    Aaron Glover
    @aarondglover
    Referencing a library I don't mind, but the tooling requires me to create a C# project to define
    Mohammad Hamdy Ghanem
    @VBAndCs
    If C# code doesn't contain any new syntax feature that is required to complete the job, we can use a Vazor-style solution:
    Do it in VB.NET, and generate the C# necessary project at runtime
    Mohammad Hamdy Ghanem
    @VBAndCs
    So, we can mark some classes in VB with attributes to be converted to c# and added to that generated project., and the rest of vb code goes to a dll library referenced in the C# project. Paul can provide us with robust VB to C# converter Try to do that for Azure functions. Finally we will write all in VB.NET, and trick them with a generated C# project!
    Aaron Glover
    @aarondglover
    Whoa the level of understanding you guys have with Roslyn and code gen is far beyond me! Sounds impressive... Would be a cool extension for VS.
    Mohammad Hamdy Ghanem
    @VBAndCs
    I did nothing with Roslyn in ZML. You can generate every thing as a text (code and project files are text files after all. It would need a complex code to implement ZML with Roslyn code. So, if you use an existing VB to C# converter, all the rest work if to generate the expected text files that forms the C# project and its dependencies.
    If there is a final step to load and compile the project with Roslyn, we will seek assistance. But I think this is not necessary. We can just open the C# project manually for testing. After all the functional VB code is still in VB library projects and we can debug.
    Mohammad Hamdy Ghanem
    @VBAndCs
    Or at least make the whole thing a C# project template that adds the necessary VB libray skeleton, so we focus on VB only.
    Think like this, and the experience will evolve while you are working
    We can even hide the C# files from the solution explorer, and manipulate them with VB files where any change in them triggers a VB to C# converter that overwrite the C# files.
    Mohammad Hamdy Ghanem
    @VBAndCs
    The whole idea in short: write what you want, and output what they want, so every one is happy.
    Give it some thinking, and you'll find many easy solutions.
    Aaron Glover
    @aarondglover
    Yeah that approach certainly does open up many possibilities for tooling support etc
    Aaron Glover
    @aarondglover
    It's an approach which as an extension could interativly add new project types... Think of creating a new c# project from a template, then convert it to a VB proj... Fewer complaints about lack of template support
    Paul M Cohen
    @paul1956
    Compiling code with Roslyn is not difficult if you understand what compile options and flags you need (something that VS handles for you in the background, I just learned how to include a projectReference this week), I am still learning everything that is needed. I don't know what tooling is referred to by @aarondglover.
    Aaron Glover
    @aarondglover
    I was describing a non existent tool... The general approach outlined by @VBAndCs lends it's self well to an extension for visual studio to create VB projects from C# templates/wizards. This would overcome the problem of missing visual studio templates ... new VB projects could be created on the fly after using the C# project wizard/template
    Mohammad Hamdy Ghanem
    @VBAndCs
    A new overload resolution bug and a crash
    Mohammad Hamdy Ghanem
    @VBAndCs
    untitled1.jpg
    It's working now at basic level
    There are few things to perfect, such as not suggesting tags that can appear only once
    Paul M Cohen
    @paul1956
    According to WinForms Repo singleInstance is schedule for the 5.0 release. It doesn't look extremely difficult using the existing design and using existing Core IPC functionality, I don't see needing gRPC. It would be nice if it was moved out of VB namespace so it could be used by any language but that might be a stretch.
    Aaron Glover
    @aarondglover
    I thought Kathleen ruled it out. Said it wasn't going to happen.
    What IPC methods are available in Core? Named Pipes?
    Paul M Cohen
    @paul1956
    Named pipes and memory mapped files. In the repo updated Feb 20th it listed as core 5.0 milestone. It looks like < 100 lines of code in reference source and when I dropped it in as a trial there were only a few of unsupported functions most of which are in Repo except the actual remoting which has a workaround and 1 windows API call where source to call it is provided in C# but easily ports to VB. If someone want to partner that understands remoting it could be done in a day. Then it would need to a UI in Visual Studio as does many VB features that are already in WinForms but can’t be enabled.
    Mohammad Hamdy Ghanem
    @VBAndCs
    For willing contributors:
    I added a VbXmlCompletionProvider to this repo
    You can add these two files to your Roslyn fork, in the folder Completion/CompletionProviders in the project Microsoft.CodeAnalysis.VisualBasic.Features
    It will provide HTML5 auto completion in VB.NET XML Literals, but only inside the <vbxml></vbxml> tag.
    I did this for two reasons:
    1. not to mess with other xml literals that doesn't deal with html.
    2. to support Vazor.
      I will make a VSIX for this to allow install it as a VS extension (in progress now), but my aim from publishing this, is to allow contributors to build upon to provide a generic XML literals completion provider, based on the xsd that user supplies in the context as this missing feature was described in the docs
    Mohammad Hamdy Ghanem
    @VBAndCs

    I created the vbxml auto completion VSIX. It provides auto completion for HTML5 in VB.NET, but it is allowed only inside vbxml tags:

    <vbxml>
       <!—auto completion for HTML 5 is available here -->
    </vbxml>

    give it a try:
    https://github.com/VBAndCs/Vazor/blob/master/vbxmlCompletionProviderVSIX.zip?raw=true
    Feedback is appreciated:
    https://github.com/VBAndCs/Vazor/issues

    Aaron Glover
    @aarondglover
    Awesome work... I'll give it a go and let you know
    Mohammad Hamdy Ghanem
    @VBAndCs
    @aarondglover Thanks. Enjoy :)
    Hisham Bin Ateya
    @hishamco
    Hi Mohammed
    Mohammad Hamdy Ghanem
    @VBAndCs
    @hishamco Hi Hisham.
    Filippo Bottega
    @filippobottega
    Hi Mohammed, Vazor it's a really interesting project. I'm a VB programmer, VB is my first and favorite programming language. But after years of C# evolution and after a lot of C# to VB conversion tasks I have lost the faith and I have moved to C#. Moreover I'm moving my projects to .NET Core and .NET Standard with C#. I'm really tired to refresh my knowledge of 2 languages to produce the same output. It's a waste of time for me. Anyway I'll remember VB for my life.
    Mohammad Hamdy Ghanem
    @VBAndCs
    You can keep VB.NET code in .NET standard libraries, and use it from C#. In fact WinForms and WPF VB projects will run on .NET 5, so you don't want to convert to C#.
    Hisham Bin Ateya
    @hishamco
    Exactly all should work together
    Filippo Bottega
    @filippobottega
    Sure! You're right. For a mid-term solution it's possibile to mix VB projects and C# projects. For a long-term solution, I prefer to convert all to C#. The thing that convinced me to make the big step is how C# and VB treat the linq queries. There are some subtle differences that prevent online conversion tools to transparently translate linq queries from VB to C# and viceversa. The time I needed to convert C# snippets found on internet into VB grew longer and longer. At the end I have realized that C# is the .NET Esperanto. It's only my opinion but there are two community of programmers that make same things and spent a lot of time to translate between C# and VB what they are thinking. We are one people, the .NET people, and we waste our time because we speak 2 different languages to make the same thinks. And nobody admit that, everyone doesn't accept to change his programming language. But Microsoft has made the choice to focus the effort to improve C# better than VB and I, painfully, have accepted that.
    Hisham Bin Ateya
    @hishamco
    This broke the language parity that Microsoft talked about long time ago
    Filippo Bottega
    @filippobottega
    Exactly! It's the Darwinian selection. Tremendous to feel like the losing species...
    And I finally swallowed the bitter bite: { } ;