by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Mohammad Hamdy Ghanem
    @VBAndCs
    1. Translate C# code to VB and take care of special vb behaviors specially in EF. Try to avoid lambdas in fluent api and use NameOf() instead.
    2. You can keep cshtml files, but in Razor pages you change the .cshtml.cs code behind file to .cshtml.vb file.
      That's all and the project will run!
      This is a big evidence that MS planned to kill VB three years ago. They added an F# project template that uses c# razor to design the views, but refused to do the same with vb, which made VB developers think they can't create ASP.NET core apps at all! Even Katherine Dollard though that C# razor code can't exist in VB project and I responded to her that it is just a script and Razor Engine is responsible for compiling it at runtime, so it has nothing to do with the VB project, and the side effect of that is there is no intellisnse and syntax check for C# in such VB project.
    The optional step is to translate the views/pages of type cshtml (containing C# code in razor) to vbxml code or ZML code. I described how in the ReadMe file in each repo.
    Another option, is to use a mix:
    Let the existing cshtml files untouched, put design any new pages with Vazor and ZML.
    You have a variety of options.
    Paul M Cohen
    @paul1956
    Can someone explain who is “they” with respect to VB. Does the dotnet Foundation own it? Who has checkin rights, only Microsoft? If so that doesn’t seem very open. I know anyone can extend Roslyn and even run the extended Roslyn in Visual Studio so my question is how to we get 1 VB maintainer with checkin rights not controlled by MS?
    Cory Smith
    @DualBrain
    My gut tells me that, based on continuing to see the term LDM for C# - as well as the usage of it for #VisualBasic in the past, is that Microsoft has complete ownership and say so. I wouldn't mind seeing this transition; however, I would also demand that the person in this roll have to take on a very undesirable task of having to say NO more often than yes. There should be a provable benefit to the majority and/or very little to no impact to existing developers or potential future restriction with regards to adding/changing the language. This isn't an easy task. To give an example, I had to argue against the addition of several new keywords or, worse, breaking changes against "fixing" the issue of not having a way to quickly truncate a floating point value into a whole number that would have the same performance level (proven benefit) that C# has with the way they "cast". My stance was that the language didn't need to change; just fix the existing pattern that was already in use... which provided the result desired AND is of instant (unknown) benefit to everyone. My point is that language design is hard... and, I would argue that most of the time, the right answer isn't to change the language - but instead improve what is already there. ;-) Right now we have a group in place, that for whatever reason(s), is pretty much in no as a response mode... this isn't necessarily a bad thing. With all of that out of the way, there are clearly things that many people (including myself) desire to have in place... so it would be nice to know if the stance is forever or until .NET 5 releases. Now with that out of the way, we also need to find an answer to a much more important query... for things that aren't language related (ie Try.NET, Blazor, etc.)... how do we encourage those responsible to include us? On that note, I've reached out to the #OpenSilver team (a Silverlight alternative built on top of Blazer not done by Microsoft) and am waiting for them to get back to me on this very subject. It would be awesome if it were possible to leverage a Xaml, Silverlight method to build for WebAssembly using #VisualBasic. I think it is also equally important that we, as a community, take a queue from the F# community where we (outside of the language - as we haven't gotten that figured out as yet) to "just do it". For example, no Razor... fine, let's walk to our own beat ala Vazor. ;-) I know that all of this isn't ideal, but given that #VisualBasic is no longer a product... one where we are allowed to "vote" with our dollars... we have to evolve and adapt to this new world.
    Cory Smith
    @DualBrain
    On a similar note... it might help if we can figure out what would "wet Microsofts wistle". For example, what would happen if there was a way, say with regards to Azure that we, as a community, could say "well, we'd like to play in that particular pond... but you don't have support for x... and we don't want to switch to something else... let us know when you support x and we'll be happy to make the move there". I'm not sure where exactly this would be... but given that Microsoft's clear public strategy is cloud... it would seem to make some sense to me that, if we can figure this out, someone would stand up and listen. ;-)
    Mohammad Hamdy Ghanem
    @VBAndCs
    VB developers are silent, and search and ask questions in C# (I myself do that) which made C# dominate and MS are assure that we will move easily to C#, so it just keeping our code base running on .net core to wrap it in dlls and use it in new C# apps.
    untitled1.jpg
    I am tampering with xml literals intellisense
    I took the xml doc cooment Completionprovider and made it work for XML literals :)
    Mohammad Hamdy Ghanem
    @VBAndCs
    Of cource I need more work to view suggestions for html5 (in general, for and xsd schema)
    But I am happy that this baby step worked :)
    Aaron Glover
    @aarondglover
    Cool
    Aaron Glover
    @aarondglover
    @VBAndCs ... Do you think the efforts and yourself will come to anything with regard to VB getting future language changes? I'm feeling exhausted and disappointed right now so sorry for the pessimism. I just can't see any change where product owners will support VB.net properly... An example is Azure Functions etc..
    Lack of support in new frameworks and tools is in my mind worst than perhaps the language not rev'ing
    Mohammad Hamdy Ghanem
    @VBAndCs
    We have to start to think of vb as an open source. We van take it where we want. Other frameworks also are open source so, we can add anything we want in a fork, or just by using the extension points of those frameworks. VS is also extensible, so I will make the xml literal CompletionProvider as an extension instead of a pull request to Roslyn. This will allow me to make a built in auto completion for html5 and ZML inside <vbxml> blocks. But I hope we dive in Roslyn to add the new lang features we want, such as Records. And as Molder says: The source is out there :D
    Aaron Glover
    @aarondglover
    What will be the best.method for achieving of single instance applications given that it won't be included in .NET 3.X/5 etc
    Will we.need to take a dependency on grpc or some other IPC technology? Similar to how remoting is done now... I assume single instance code is what enables passing of command line params from second instances etc. Perhaps we just use the file system with filesystem watchers to pass the info between the instances.
    Aaron Glover
    @aarondglover
    @VBAndCs your work with Vazor looks incredible. Blazor/Vazor is programming model which really appeals to me.
    It sucks that a few of ADG's proposals for VB are getting some traction in C# and ignored by VB ☹️
    What is the single or top most new LANGUAGE features you guys would hope to see make it into the language? For me, pattern matching and Pattern-Based XML Literals as described by ADG.
    Aaron Glover
    @aarondglover
    @paul1956 how much performance can be gained by unchecked math? One of the major reasons for unchecked math as I understand it is to improve performance - particularly on a block of code which is not expected to result in overflow exceptions. Is that your key driver for this feature?
    Aaron Glover
    @aarondglover
    Does anyone know of any work being done on a grpc VB.NET proxy generator?
    The solution this far seems to have a dedicated c# project for the proxy and DTO objects ... Native VB generator would improve the approachability of this for VB devs
    Cory Smith
    @DualBrain
    @aarondglover On the single instance front, let me put something together on that early in the week. I just need to pull some code out of one of my projects that handles this as I needed to find a work around due to a problem I found with single instance and click once updates.
    Paul M Cohen
    @paul1956
    @aarondglover that was not the direct reason for me. I did it because I inherited a lot of code that calls into C# to do unchecked math, things like hash and the call is a high overhead and I fully expect overflow.
    As far an single instance that really should be added to WinForms. A lot of VB code will break if it isn’t supported in Core 5.
    Paul M Cohen
    @paul1956
    @aarondglover I have a DLL that can translate the proxy and DTO objects if anyone wants.
    Aaron Glover
    @aarondglover
    @paul1956 Single instance isn't going to happen... Kathleen already stated as such.
    Is that your general C# to VB converter youve been working on? That sounds much more useful than the current online converters which seem to miss the mark more times than not these days....
    Wouldnt it be great if GRPC added support for VB projects natively. Conversion of the code is nice but generally not much more achieved when compared to just throwing the generated code into its own DLL is there?
    Aaron Glover
    @aarondglover
    I've reached out to GRPC team... There are no plans to support such an initiative... The answer... Just do it in c# and reference the Class Library ☹️
    It's disappointing but not surprising given that .NET core not moving forward with WCF or any other type of RPC, they're essentially recommending HTTP REST or GRPC moving forward. So for those wanting to develop with a more RPC type approach in visual basic - yet again we are forced to use C# for atleast some of the development.
    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.