The place for the VB community to join our collective voice! See https://github.com/CommunityVB/Main for more info.
I suggested to add Embedded unit tests. If you like the idea please vote for it: https://developercommunity.visualstudio.com/idea/956194/embedded-unit-tests.html
I just finished Checked/UnChecked expressions for VB the problem I was having was in Roslyn and when it was fixed and I merger Visual Studio now works correctly with my new expression if anyone want to try it https://github.com/paul1956/roslyn/tree/UncheckedExpression
A hot discussion here regarding a logical comparison different behavior between C# and VB, which I reported as a VB bug but some VBers say otherwise. I hope I hear the decision prospective form C#, VB and Roslyn team.
dotnet/vblang#507
dotnet/vblang#507
@InteXX I neglected the whole thing since Anthony Green evolved it to includ Xamarin and WPF. I found some talking about Vazor in the web, some listing Vazor Nuget amoung top ten nugets should VB developer have, but the sample written for Core 3.0 preview broke in later releases, so I imagine this drove away many VB developers. When they announced freezing VB, I updated the project, and published the complete VB version of eShopOnWeb for core 3.1. I hope I can get developers attention back, and wish .NET magazine speak about it. The next step is to write some VS extension to provide HTML5 intellisense in XML literals, which make it a productive and easy to use tool. I wish someone help in that, because I am not an expert in this area.
@VBAndCs What great work you're doing. Keep it up if you can.
I've been thinking about the recent MS announcement... and I'm not nearly as upset as I was orginally once I realized (and reflected) on all of the announcements over the past 15 years. I suspect that things will (and do) change with regards to the "current plan"... so I suspect the reality is that this is the plan between now and .NET 5.0. I don't have any sort of inside track... but, ultimately, I suspect this is most likely the case. Given the surface area and the pressure to "get things working" from the point of view of the current technologies that #VisualBasic devs are currently used to (minus, of course, WebForms) the plan seems to make sense (again, between now and .NET 5.0). Don't get me wrong, I'm absolutely interested in Blazor (as an example)... but, with that said, I'm definately not interested in another Silverlight, Windows Phone, Project Acropolis, etc. etc. In other words, I am kind of tired of "the next big thing"; maybe it would be a good idea to let the dust settle on some of this stuff. The landscape is changing all the time... some of us (speaking particularly, of course, about myself) desire some "stability" in the technology that we target so I don't blow the budget on "here we go... again". With that out of the way... I still don't understand why (as it's not a language thing) we still aren't included as part of Try.NET???
While looking whether or not the Try.NET situation has changed... I stumbled across https://docs.microsoft.com/en-us/dotnet/ Scroll down to the programming languages... FINALLY... a description that doesn't sound like CRAP. "An approachable language with readable syntax" NICE! (The descriptions in the past didn't really impress me - or represent what I believe the language is. I also like the "A modern, object-oriented type-safe member of the C family" description for C#... WHAT A MOUTHFUL (and, for the record, #VisualBasic does all those things too...)
@VBAndCs Out of curiosity... any idea what effort would be involved in doing the same sample treatment you did eShopOnWeb for https://github.com/madskristensen/Miniblog.Core ? Would you be able to put together a basic outline as to what would be necessary (beyond converting C# -> #VisualBasic)?
Often, usually when I want to return an object with a status without extending the Object or pairs of objects. Just a few examples
Dim Braces As (LeftBrace As SyntaxToken, RightBrace As SyntaxToken) = node.Body.GetBraces
Dim CompileResult As (Success As Boolean, EmitResult As EmitResult) = CompileVisualBasicString(TextToCompile, DiagnosticSeverity.Error, _resultOfConversion)
If CompileResult.Success AndAlso CompileResult.EmitResult.Success Then
' In both cases the same Type is returned but I need to know if an error was in the original typeInfo.
If (typeInfo.Type.IsErrorType) Then
Return (PredefinedTypeObject, _Error:=True)
ElseIf SymbolEqualityComparer.Default.Equals(typeInfo.Type, Model.Compilation.ObjectType) Then
Return (PredefinedTypeObject, _Error:=False)
End If- 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. - 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.
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.
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?
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.
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. ;-)
I am tampering with xml literals intellisense
I took the xml doc cooment Completionprovider and made it work for XML literals :)
But I am happy that this baby step worked :)
@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
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
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.
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.
@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?
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
@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.
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.
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....